Subasking sớm vào đầu mỗi lần chạy nước rút

Tôi đã tham gia một nhóm mới đang sử dụng Agile / Scrum và quá trình phát triển của họ như sau:

1) nhà phát triển xem xét từng câu chuyện trước mỗi lần chạy nước rút để đảm bảo nó không bỏ sót điều gì quan trọng. Có một trạng thái chính thức cho quy trình đó.

2) trong thời gian khởi động Sprint, toàn đội thực hiện ước tính (lập kế hoạch chơi bài) về số điểm câu chuyện mà mỗi câu chuyện sẽ có giá.

3) cuối cùng, ngay sau mỗi lần chạy nước rút bắt đầu, mỗi nhà phát triển được yêu cầu háo hức chia nhỏ tất cả các câu chuyện được chỉ định thành các nhiệm vụ với ước tính thời gian (trái ngược với ẩn phụ trước khi bắt đầu mỗi câu chuyện).

Lập luận chính cho bước cuối cùng là nó giúp khám phá nếu việc thực hiện một câu chuyện sẽ mất nhiều thời gian hơn dự đoán và cảnh báo chủ scrum về những rủi ro tiềm ẩn của việc hết thời hạn nước rút.

Tuy nhiên, tôi thấy điều này phản tác dụng, chủ yếu là vì những lý do sau:

• nếu mục đích là để cung cấp ước tính sơ bộ, điểm câu chuyện (bước # 2) là công việc gì. Nếu không tại sao phải bận tâm với điểm câu chuyện ở tất cả? - chỉ cần làm phụ đề sớm.
• nếu mục đích là cung cấp các ước tính chính xác, thì đây là một ví dụ rõ ràng về những gì được mô tả trong Chuyển mạch nhiệm vụ của con người được coi là có hại . Điều này, tôi nghĩ, đặc biệt là trường hợp đối với các nhà phát triển mới tham gia các nhóm hiện có trong các dự án lớn, nơi hiểu được những gì cần phải làm có thể mất tới 50% thời gian. Bạn được yêu cầu tìm hiểu chi tiết về câu chuyện số 1, sau đó là câu chuyện số 2, số 3, v.v., điều này mang lại rất nhiều thông tin.

Tôi cũng được cho biết rằng thực tế như vậy là "bởi cuốn sách" và tôi thậm chí không có ý định thảo luận về điều này. Bất cứ ai cũng có thể cung cấp một tài liệu tham khảo cho thực tiễn như vậy - liệu điều này được xác định rõ ràng trong kinh thánh Scrum, và / hoặc có lẽ cung cấp bất kỳ cái nhìn sâu sắc thêm?

Điều này không giống với cách chúng tôi chạy một số quy trình scrum của chúng tôi. Chúng tôi

1. Ước tính các câu chuyện gần đầu của tồn đọng trong "điểm câu chuyện"
2. Chọn / giải thích các câu chuyện dựa trên các điểm câu chuyện mà chúng tôi nghĩ sẽ "tạo nên" nước rút
3. Chia nhỏ các câu chuyện thành các nhiệm vụ kỹ thuật chi tiết hơn
4. Ước tính các nhiệm vụ kỹ thuật và so sánh với ước tính điểm câu chuyện ban đầu (chúng tôi biết khoảng thời gian phát triển mà một điểm câu chuyện thường tương đương với)

Nhưng những gì bạn muốn biết là tại sao chúng tôi ước tính hai lần!

• Chúng tôi ước tính thô (dựa trên câu chuyện) bởi vì chúng tôi muốn có thể đưa ra dự đoán về những gì có thể trong lần chạy nước rút tiếp theo , và thậm chí có thể là sau đó. Quản lý cuối cùng phải có khả năng giao tiếp với khách hàng về các thang đo thời gian có khả năng, vì vậy nếu chúng ta không có ước tính quy mô thô này thì việc lập kế hoạch dài hạn là gần như không thể.
• Rõ ràng, điều này có nghĩa là chúng tôi ước tính thô không chỉ cho lần chạy nước rút hiện tại. Bởi vì không có gì đảm bảo thứ tự tồn đọng sẽ không thay đổi cho lần chạy nước rút tiếp theo, chúng tôi không muốn đầu tư thời gian để thực hiện các phân tích nhiệm vụ và ước tính quy mô tốt cho đến khi chúng cần thiết.
• Chúng tôi chia nhỏ nhiệm vụ để đảm bảo rằng tất cả các nhiệm vụ đã được liệt kê và các câu chuyện có thể được thực hiện song song dễ dàng hơn.
• Chúng tôi thực hiện các ước tính tỷ lệ tốt (dựa trên nhiệm vụ) bởi vì điều này mang lại cho chúng tôi một biểu đồ phân tích mượt mà hơn nhiều (đặc biệt là không có cách nào dễ dàng để tách một câu chuyện lớn thành các "tính năng" khả thi).
• Bởi vì chúng tôi làm cả hai, họ đóng vai trò kiểm tra sự tỉnh táo cho nhau - sự khác biệt hoang dã cho thấy chúng tôi cần một sai lầm ở đâu đó mà chúng tôi cần xác định. Đây là một sản phẩm phụ hữu ích, nhưng bản thân nó không phải là lý do tại sao chúng tôi ước tính "hai lần".

Đọc lại câu hỏi và nhận xét của bạn, tôi thấy có một số khác biệt giữa quy trình làm việc của chúng tôi và của bạn.

• Chúng tôi chia nhỏ thành một nhóm , chúng tôi thấy mặc dù chi phí lớn hơn là cuộc thảo luận kỹ thuật mà chúng tôi nhận được từ việc này thường rất có giá trị và có thể phát hiện ra những thiếu sót trong câu chuyện của chúng tôi. Khi chúng ta có kinh nghiệm, kiến ​​thức hoặc khả năng chênh lệch, cuộc thảo luận này cũng là nơi những người có nhiều hơn có thể giúp đỡ những người có ít hơn (rất hữu ích với những người tuyển dụng mới).
• Chúng tôi ước tính ở cấp độ nhiệm vụ với tư cách là một nhóm , một trong những lý do khiến "lập kế hoạch chơi bài" hoạt động là do hiện tượng "khôn ngoan của đám đông" - như tôi đã đề cập trong các bình luận, đến thời điểm này, việc ước tính một nhiệm vụ chỉ mất chưa đến 30 giây , do đó, chi phí không đáng kể.

Nghe có vẻ như lý do nhóm của bạn thực hiện phân tích nhiệm vụ và ước tính nhiệm vụ là để giải quyết suôn sẻ - điều đó tốt, đó là tất cả các phần của việc theo dõi tiến trình chạy nước rút và cho phép chủ nhân của bạn phát hiện và giải quyết vấn đề sớm. Nếu bạn muốn thông tin này, bạn phải thực hiện các phân tích và ước tính và trước tiên bạn phải thực hiện chúng.

Theo tôi, chuyển đổi nhiệm vụ dường như không phải là vấn đề đối với bạn ở đây, tôi không nghĩ rằng việc phá vỡ các nhiệm vụ khác nhau thực sự là một chuyển đổi nhiệm vụ theo cùng một nghĩa là chuyển từ phát triển một tính năng này sang một phần khác là chuyển đổi nhiệm vụ . Tôi nghĩ rằng đạt được một sự hiểu biết về "kiến trúc" tổng thể của nước rút có lẽ là một điều khá hữu ích.

Tuy nhiên, tôi nghĩ có thể có một số vấn đề khác bạn có thể xem xét. Như mọi khi với nhanh nhẹn, bạn nên xác định một vấn đề bạn gặp phải và đề xuất giải pháp , sau đó quyết định xem giải pháp của bạn có hoạt động theo hồi cứu hay không . Đây là mấu chốt của việc xây dựng một giải pháp nhanh nhẹn phù hợp với công ty và nhóm của bạn. Vì vậy, một số vấn đề bạn có thể có:

• Bạn đang thực hiện các sự cố riêng lẻ - vậy làm thế nào các thành viên nhóm thiếu niên / thiếu kinh nghiệm của bạn học hỏi từ các thành viên nhóm cao cấp của bạn? Chắc chắn, họ có thể tự học mọi thứ - nhưng họ sẽ học nhanh hơn nếu họ được cố vấn. Là thành viên đội thiếu niên mất nhiều thời gian để phá vỡ mọi thứ? Có phải họ đang mắc sai lầm hoặc thiếu những thứ làm mất thời gian của đội trong thời gian dài? Chia nhỏ như một đội có thể giúp đỡ ở đây.
• Bạn đang thực hiện các ước tính riêng lẻ - áp dụng tương tự như điểm đầu tiên, nhưng ngoài ra các ước tính này có kém chính xác hơn mức có thể không?
• Nghe có vẻ như các nhiệm vụ được giao khi bắt đầu chạy nước rút, nhưng nếu đây là trường hợp thì bạn sẽ thấy nó đắt đến mức nào khi bạn phải thay đổi nhiệm vụ? Nếu ai đó bị tụt lại phía sau hoặc bị bệnh, việc người khác nhận nhiệm vụ của họ dễ dàng như thế nào? Họ có phải trải qua các sự cố nhiệm vụ và cố gắng hiểu chúng mà không làm gián đoạn người được giao ban đầu không? Nếu bạn suy sụp và ước tính như một đội thì mọi người sẽ có thể làm việc trên mọi thứ!
• Có phải câu chuyện của bạn quá lớn? Nếu sự cố mất 50% thời gian, thì những câu chuyện nghe có vẻ như chúng rất liên quan - có lẽ chúng có thể được làm nhỏ hơn? Chúng tôi giữ câu chuyện của chúng tôi trong vòng 1 tuần làm việc.
• Là nhiệm vụ của bạn quá nhỏ? Nếu bạn dành nhiều thời gian để lập danh sách nhiệm vụ, có lẽ bạn đang đi vào quá nhiều chi tiết? Chúng tôi có xu hướng có các nhiệm vụ từ 1 đến 8 giờ làm việc để trong suốt một ngày mọi người đều có một số tiến bộ để báo cáo trong lần chờ hàng ngày tiếp theo.

Nếu đó là cách công ty của bạn muốn điều hành sự phát triển của họ và ngừng thảo luận, các lựa chọn của bạn bị hạn chế hoặc ít nhất bạn có nguy cơ làm phiền mọi người.

Vì mục tiêu cuối cùng của agile là phần mềm hoạt động có giá trị, bạn có thể thử cung cấp để giúp đỡ bằng cách cung cấp khả năng cung cấp của nhóm của bạn (điểm được giao / ước tính, lỗi trong nước rút, không có kiểm tra, bảo hiểm mã, thời gian hoạt động, doanh số được tạo - bất cứ điều gì). Hãy chuẩn bị cho tất cả các kết quả - có thể là cách làm việc này phù hợp với họ ngay cả khi nó không có ý nghĩa với bạn. Nếu bạn đúng, sự lãng phí sẽ trở nên rõ ràng.

Hãy cảnh giác với quy trình sau vì lợi ích của quá trình - điều này gây lãng phí thời gian và vẫn cung cấp các sản phẩm kém. Một nhóm thí nghiệm nhanh nhẹn, biện pháp và học hỏi. Cách tốt nhất để thay đổi hành vi mà không đi xuống ý kiến ​​là bằng các quyết định dựa trên bằng chứng.

Đây cũng là ý kiến ​​của tôi. Tôi khuyên bạn nên tự mình thử và đo lường kết quả - xem những gì tôi đã làm ở đó :)

Tôi cho rằng Sprint Kickoff của bạn có nghĩa là cuộc họp Lập kế hoạch Sprint. Tôi nghĩ rằng Scrum Master của bạn đã hiểu sai về cuộc họp này nên diễn ra như thế nào. Bạn không chỉ quyết định những câu chuyện sẽ phát triển, bạn còn kiểm tra chúng cho nhóm của bạn định nghĩa của nó là sẵn sàng để đảm bảo họ không bỏ lỡ bất cứ điều gì (thường sử dụng INVEST ), và bạn cũng chia các câu chuyện đó thành các nhiệm vụ. Để trích dẫn Mike Cohn (một trong những người sáng lập Liên minh Scrum);

Backlog chạy nước rút là đầu ra khác của kế hoạch chạy nước rút. Backlog chạy nước rút là một danh sách các mặt hàng tồn đọng của sản phẩm mà nhóm cam kết phân phối cộng với danh sách các nhiệm vụ cần thiết để phân phối các mặt hàng tồn đọng của sản phẩm đó. Mỗi nhiệm vụ trên tồn đọng nước rút cũng thường được ước tính.

Vì vậy, việc chia nhỏ các câu chuyện và ước tính chúng là tất cả các phần của phiên Lập kế hoạch Sprint; không phải sau khi phiên kế hoạch kết thúc và không riêng lẻ.

Để cung cấp thêm thông tin chi tiết, quy trình làm việc của chúng tôi trong cuộc họp Lập kế hoạch Sprint như sau:

1. chúng tôi lấy một câu chuyện từ phần đầu của sản phẩm tồn đọng và chia nó thành các nhiệm vụ. Theo nguyên tắc thông thường, một nhiệm vụ thường phải nhỏ hơn một ngày.

2. Chúng tôi ước tính câu chuyện đưa ra các nhiệm vụ chúng tôi đã khấu trừ. Nếu câu chuyện trở nên lớn, chúng tôi cố gắng và chia câu chuyện thành những câu chuyện nhỏ hơn.

3. Rửa sạch và lặp lại cho đến khi chúng ta đạt được tổng số điểm ước tính

Trái với những gì Cohn nói, tôi thấy rằng không có nhu cầu thực sự để ước tính từng nhiệm vụ một cách riêng biệt, vì các nhiệm vụ được chỉ định là nhỏ hơn một ngày. Cho rằng các nhiệm vụ nhỏ hơn một ngày làm việc, bạn có thể dễ dàng nhận thấy trong Chế độ chờ hàng ngày khi một nhiệm vụ mất nhiều thời gian hơn dự kiến, vì người thực hiện nhiệm vụ cụ thể sẽ nói rằng anh ta vẫn đang thực hiện công việc đó.

Trong quá trình chạy nước rút, nhóm nghiên cứu theo cách của mình thông qua các câu chuyện, và cuối cùng, nhóm nên suy nghĩ về việc thực sự đã làm được bao nhiêu. Đây là những gì cuộc họp hồi cứu scrum là dành cho. Nếu vẫn còn những câu chuyện trên bàn, bạn có thể khấu trừ rằng ước tính của bạn quá lạc quan và hành động theo nó cho lần chạy nước rút tiếp theo. Ngoài ra, có thể có một số sự cố đã xảy ra ảnh hưởng đến số tiền bạn đã thực hiện, v.v. Bạn sẽ thấy rằng các ước tính sẽ tốt hơn theo thời gian khi bạn phản ánh về chúng.

"bởi cuốn sách" - đó là vấn đề của bạn. Bạn đang chết đuối trong quá trình nhiều hơn bạn sẽ có nếu bạn đang làm việc thác nước.

Không có "cuốn sách" nào cho Agile, chỉ có bản tuyên ngôn nhanh nhẹn có nội dung "hoàn thành công việc mà không cần tất cả chi phí". Vì vậy, nếu bạn đang ước tính kích thước và sau đó chia các câu chuyện thành các nhiệm vụ để ước tính lại chúng, thì đó là một quá trình vô nghĩa cần phải được thực hiện hiệu quả hơn - đây là điều nhanh nhẹn. Scrum và tất cả những người khác thực sự là hướng dẫn điểm khởi đầu cho cách bạn bắt đầu thực hiện nhanh nhẹn. Khi bạn làm điều đó, bạn nên xác định những điểm không có ý nghĩa hoặc không giúp nhóm của bạn làm việc hiệu quả hơn và bạn nên thay đổi chúng.

Tuy nhiên, một số người nghĩ rằng các cách làm việc bị cấm cần phải được viết bằng đá và không bao giờ đi chệch hướng, bất kể chúng trở nên ngu ngốc như thế nào. Tôi sẽ cố gắng phân chia các câu chuyện thành các nhiệm vụ trước cuộc họp scrum - bạn nói rằng các nhà phát triển được yêu cầu xem xét từng câu chuyện, đây là cơ hội để thực hiện việc phân tách cùng lúc với một phần của đánh giá. Sau đó, bạn có thể tuyên bố các nhiệm vụ bao gồm câu chuyện trong cuộc họp scrum (không phân bổ thời gian cho họ!) Và để mọi người sau đó quyết định gói công việc lớn đến mức nào, dựa trên thông tin bổ sung này (không bao giờ là điều xấu, thông báo ra quyết định tốt hơn nhiều so với phỏng đoán, lần thứ hai chỉ có thể được thực hiện khi bạn có thông tin để đưa ra quyết định).

Sau cuộc họp, bạn vẫn có thể chỉ định thời gian cho các nhiệm vụ (mặc dù tôi không thấy được điểm này, việc chạy nước rút không dựa trên thời gian, chúng dựa trên "số lượng công việc bạn dự kiến ​​sẽ làm" được tính theo điểm câu chuyện , không phải thời gian. Đây là một vấn đề phổ biến với scrum, điểm không có nghĩa là thời gian nhưng bạn phải hoàn thành, giả sử, 20 điểm mỗi hai tuần do đó 2 điểm = 1 ngày làm việc. Đây là một phỏng đoán nhanh về số lượng nhiệm vụ cần đặt trong giai đoạn nước rút để bạn không bị quá tải cũng như không làm việc, không phải là bao nhiêu sẽ thực sự hoàn thành. Những lần chạy nước rút tốt nhất là những nhiệm vụ còn sót lại, điều đó cho thấy bạn ước tính một cách hoàn hảo. trì hoãn hoàn thành chúng vào cuối - không hiệu quả).

Vì vậy, trong ngắn hạn - in một bản Tuyên ngôn Agile ra và phiên bản chống nhanh . Tôi cá là bạn đang làm nhiều việc hơn là nhanh nhẹn. Scrum có xu hướng như vậy. Cách duy nhất để khắc phục là tham gia với nhóm của bạn và nhận tiền mua để thay đổi. Đừng để quản lý cho bạn biết nhóm của bạn hoạt động như thế nào, điều đó cũng không nhanh nhẹn và điều đó sẽ được viết trong Sách.

Tại một số thời điểm trong mỗi Sprint, bạn nên có Cuộc họp sàng lọc tồn đọng sản phẩm . Tại cuộc họp này, bạn đảm bảo rằng phần trên cùng của Product Backlog được chia nhỏ đủ để các mục trong phần đó được thêm vào Sprint Backlog tiếp theo.

Nếu sàng lọc tồn đọng sản phẩm được quản lý tốt, thì Cuộc họp lập kế hoạch Sprint có thể hiệu quả hơn. Lý tưởng nhất, điều này sẽ làm giảm nhu cầu cho các nhà phát triển "háo hức phá vỡ" những câu chuyện sau khi Sprint bắt đầu.

Nếu các Mục tồn đọng của sản phẩm được thêm vào Sprint Backlog trước khi được chia nhỏ đủ để ước tính thực tế, điều đó sẽ gây khó khăn cho việc đưa ra quyết định tốt về những gì cần thêm vào Sprint.