2008-09-22 29 views
13

Chúng tôi chỉ mới bắt đầu một dự án khá lớn với nhiều dự án phụ. chúng tôi hiện không sử dụng bất kỳ loại quy trình đặt tên nào nhưng tôi hy vọng sẽ có được một loại quy trình nhanh nhẹn/scrumlike ở cửa sau.Quản lý các câu chuyện của người dùng cho một dự án lớn

Khu vực mà tôi sẽ tập trung nhất là có tồn đọng tốt cho toàn bộ dự án và, ít nhất là trong đầu của tôi, ý tưởng về một sự lặp lại, nơi một số thứ được lấy từ backlog, xem chi tiết hơn và phát triển đến một thời hạn hợp lý.

Tôi tự hỏi những kỹ thuật nào mọi người sử dụng để phá vỡ các dự án thành những thứ cần thực hiện trong quá trình tồn đọng và một khi tồn đọng được tạo ra như thế nào được duy trì và đặt hàng. cũng như thế nào mối quan hệ giữa các yếu tố được duy trì (tức là điều này phải được thực hiện trước khi nó có thể làm điều đó, hoặc đây là một câu chuyện bây giờ nó là năm)

Tôi không chắc chắn những gì tôi mong đợi câu trả lời cho câu hỏi này trông giống như . Tôi nghĩ rằng những gì có thể hữu ích nhất là nếu có một dự án mã nguồn mở giữ backlog của nó trực tuyến theo một cách nào đó để tôi có thể thấy những người khác làm như thế nào.

Cái gì khác mà sẽ nhận được 1 từ tôi là ví dụ về những câu chuyện sử dụng thực tế từ các dự án thực tế (các "người dùng có thể đăng nhập vào" câu chuyện không giúp tôi điều hình ảnh trong dự án của tôi.

Cảm ơn.

+1

Tôi phải đề cao bạn vì hai lý do. Tôi thích nghe về ý tưởng của mọi người về những thứ như thế này, nhưng danh tiếng của bạn cũng đã được ngồi trên 666! – mattlant

Trả lời

9

Tôi khuyên bạn nên suy nghĩ cẩn thận trước khi áp dụng một công cụ, đặc biệt là vì có vẻ như quá trình của bạn có khả năng là chất lỏng lúc đầu khi bạn tìm thấy đôi chân của mình. Cảm giác của tôi là một công cụ có thể có khả năng hạn chế bạn hơn là cho phép bạn ở giai đoạn này, và bạn sẽ thấy nó không thay thế cho một số good card-wall in physical space. Tôi sẽ đề nghị bạn thay vì tập trung nỗ lực của bạn vào nhiệm vụ ở bàn tay, và lấy một công cụ khi bạn cảm thấy như bạn thực sự cần một. Bởi giai đoạn đó bạn sẽ có nhiều khả năng có một ý tưởng rõ ràng về các yêu cầu của bạn.

Tôi đã chạy một số dự án nhanh nhẹn ngay bây giờ và chúng tôi chưa bao giờ cần một công cụ phức tạp hơn so với bảng tính và trên dự án có ngân sách hơn một triệu bảng. Hầu hết chúng ta thấy rằng một bảng trắng và thẻ chỉ mục (một cho mỗi câu chuyện của người dùng) là quá đủ.

Khi xác định các câu chuyện của bạn, hãy đảm bảo bạn luôn thể hiện chúng theo cách có ý nghĩa với người dùng của bạn - một số chức năng nổi bật (có lẽ chỉ nhỏ). Không bao giờ cho phép bản thân viết các câu chuyện về các chi tiết kỹ thuật mà bạn không thể chứng minh cho người dùng. Kỹ năng khi lên lịch cho câu chuyện là cố gắng ưu tiên những thứ bạn biết ít nhất về trước (kế hoạch cho những gì bạn muốn học, thay vì những gì bạn muốn làm) trong khi bắt đầu với những câu chuyện sẽ cho phép bạn phát triển các tính năng cốt lõi của ứng dụng của bạn, sử dụng các câu chuyện tiếp theo để bọc chức năng (và độ phức tạp kỹ thuật) xung quanh chúng.

Nếu bạn tự tin rằng bạn có thể để lại một số câu đố cho đến sau này, đừng đổ mồ hôi vào chi tiết về điều đó - chỉ cần viết một thẻ câu chuyện đại diện cho cuộc trò chuyện lớn bạn cần có sau đó, và tiếp tục với những thứ quan trọng hơn. Nếu bạn cần phải có một cảm giác về kích thước của những gì sắp tới, hãy nhìn vào kỹ thuật ước lượng băng rộng delphi được gọi là planning poker.

Sách Mike Cohn, đặc biệt là Agile Estimating and Planning sẽ giúp bạn rất nhiều ở giai đoạn này và cung cấp cho bạn một số kỹ thuật hữu ích để làm việc.

Chúc may mắn!

2

Tôi không chắc chắn nếu đây là những gì bạn đang tìm kiếm, nhưng nó vẫn có thể hữu ích Max Pool từ codesqueeze có một đoạn video giải thích "bức tường nhanh nhẹn" của anh ấy. Thật tuyệt khi thấy quá trình của anh ấy, ngay cả khi nó có thể không nhất thiết liên quan đến câu hỏi của bạn:

My Agile Wall (Plus A Few Tricks)

2

Vì vậy, đây là một số mẹo: Chúng tôi sử dụng RallyDev.
Chúng tôi đã tạo chế độ xem các gói yêu cầu của chúng tôi. Các câu chuyện lớn được gắn nhãn là sử thi và được đặt vào bản phát hành tồn đọng của bản phát hành mà họ dự định. Câu chuyện trẻ em được thêm vào sử thi. Chúng tôi đã tìm thấy nó tốt nhất để giữ cho các câu chuyện rất chi tiết. Những câu chuyện hạt thô làm cho việc ước tính và thực thi câu chuyện trở nên khó khăn.

Vì vậy, nói chung:

  1. Tổ chức theo việc phát hành

  2. Giữ lặp giữa 2-4 tuần

  3. chủ sản phẩm và dự án nhà quản lý thêm câu chuyện để việc phát hành tồn đọng

  4. Nhóm dev ước tính những câu chuyện dựa trên kích thước sản phẩm Áo Thun, điểm, vv ...
  5. Trong mùa xuân lên kế hoạch meeetings đội dev chọn làm việc cho lặp từ việc tồn đọng phát hành.

Đây là những gì chúng tôi đã làm trong 4 tháng qua và thấy nó hoạt động tốt. Rất quan trọng để giữ cho kích thước của những câu chuyện nhỏ và dạng hạt.

Hãy nhớ rằng các Invest và từ viết tắt thông minh để đánh giá những câu chuyện của người dùng, một câu chuyện hay nên là: I - Độc lập N - Thỏa thuận V - có giá trị E - đáng mến S - Nhỏ T - Testable

thông minh :

S - cụ M - đo lường A - Achievable R - có liên quan T - Time-đóng hộp

1

Tôi bắt đầu bằng cách nói Keep it Simple .. sử dụng bảng tính được chia sẻ với theo dõi (và sao lưu). Nếu bạn thấy các vấn đề về mở rộng hoặc đồng bộ hóa như vậy, việc duy trì tình trạng tồn đọng ở trạng thái nhất quán ngày càng trở nên tốn thời gian, hãy tăng cường giao dịch. Điều này sẽ tự động xác nhận và biện minh cho chi phí/chi phí đào tạo lại.

Tôi đã đọc một số điều tốt về Mingle from Thoughtworks.

4

Giống như DanielHonig, chúng tôi cũng sử dụng RallyDev (trên quy mô nhỏ) và có vẻ như nó có thể là một hệ thống hữu ích giúp bạn ít nhất là điều tra.

Ngoài ra, một cuốn sách tuyệt vời về phương pháp phát triển câu chuyện của người dùng là User Stories Applied bởi Mike Cohn. Tôi chắc chắn khuyên bạn nên đọc nó nếu bạn chưa có. Nó sẽ trả lời rất nhiều câu hỏi của bạn.

1

Rất nhiều những phản ứng đã được với các đề xuất về các công cụ để sử dụng. Tuy nhiên, thực tế là quá trình của bạn sẽ quan trọng hơn nhiều so với các công cụ bạn sử dụng để thực hiện quy trình. Tránh xa các công cụ cố gắng nhồi nhét một phương pháp xuống cổ họng của bạn. Tuy nhiên, hãy cảnh giác với việc thực hiện một quy trình không nhanh nhẹn cũ bằng cách sử dụng một công cụ mới. Dưới đây là một số sự kiện mạnh cần xem xét khi xác định các công cụ cho các quá trình:

  1. Một quá trình xấu instrumented với một công cụ phần mềm sẽ cho kết quả trong một xấu phần mềm công cụ implemention.
  2. Quy trình sẽ thay đổi dựa trên nhóm bạn đang quản lý. điều quan trọng là con người chứ không phải quá trình. Thực hiện điều gì đó họ có thể làm việc thành công và dự án của bạn sẽ thành công.

Tất cả những gì đã nói, đây là một vài hướng dẫn để giúp bạn:

  • Bắt đầu với một thực hiện thuần túy của một quá trình ghi chép,
  • Hãy lặp đi lặp lại của bạn nhỏ,
  • Sau mỗi lần lặp talk với các nhóm của bạn và hỏi họ những gì họ sẽ thay đổi, thực hiện các thay đổi có ý nghĩa.

Đối với các tổ chức lớn hơn, nếu bạn đang sử dụng SCRUM, hãy sử dụng cơ chế đứng lên xếp tầng. Các bậc thầy Scrum gặp gỡ các đội của họ. Sau đó, các Scrum Masters gặp nhau trong các cuộc nổi bật của 6 - 9, với một Super-Scrum-MAster chịu trách nhiệm báo cáo các mục từ Scrum-Master của scrum đến cấp độ tiếp theo ... và vv ..

Bạn có thể thấy rằng có các cuộc họp siêu scrum hàng tuần sẽ đủ ở cấp cao nhất trong hệ thống phân cấp của bạn.

Các vấn đề liên quan