Làm thế nào để ước tính các nhiệm vụ trong scrum?

Giả sử chúng ta có một hồ sơ tồn đọng Câu chuyện người dùng, mỗi câu chuyện có số lượng Điểm câu chuyện ước tính và hiện chúng tôi đang thực hiện Kế hoạch Sprint.

Bây giờ, các Câu chuyện nên được chia thành các nhiệm vụ và nhiều tài nguyên Scrum cho thấy rằng mỗi nhiệm vụ nên được ước tính theo giờ. Vì tất cả các câu hỏi đã được nhóm thảo luận tại thời điểm này, việc ước tính một nhiệm vụ không nên mất nhiều hơn một phút . Tuy nhiên, vì một nhiệm vụ không nên dài hơn một ngày, giả sử chạy nước rút ba tuần với 8 nhà phát triển có nghĩa là 120 nhiệm vụ và chỉ mất hai giờ để ước tính có vẻ hơi nhiều đối với tôi.

Tôi biết rằng các đội có kinh nghiệm có thể bỏ qua hoặc ước tính nhiệm vụ ngắn, nhưng giả sử chúng ta chưa ở giai đoạn đó.

Theo kinh nghiệm của bạn, có bao nhiêu nhiệm vụ trong một lần chạy nước rút và mất bao lâu để ước tính tất cả chúng? (Ước tính chỉ một nửa trong số họ không có ý nghĩa nhiều, phải không?)

Làm rõ:

Tôi biết câu trả lời phụ thuộc vào độ dài nước rút và quy mô đội, vì vậy hãy giả sử 8 nhà phát triển và ba tuần.

Các con số được đề cập có thể là quy tắc ngón tay cái, nhưng ngay cả khi chúng bị tắt (ví dụ: nhiều nhiệm vụ hơn, cần ít thời gian hơn để ước tính), chúng tôi sẽ kết thúc với khoảng 2 giờ để ước tính. Vì vậy, có lẽ câu hỏi nên là "Bao nhiêu phần trăm của cuộc họp lập kế hoạch nên được dành riêng cho ước tính nhiệm vụ thuần túy, và chúng ta không có những điều tốt hơn để làm?"

Thành thật mà nói, tôi nghĩ rằng nếu bạn hỏi câu hỏi này, bạn thực sự không hoàn toàn bị thuyết phục về việc sử dụng kế hoạch chạy nước rút.
Quan điểm của kế hoạch chạy nước rút là đưa nhóm vào trạng thái mà họ cảm thấy thoải mái khi tham gia vào một tập các câu chuyện người dùng nhất định, nơi họ cảm thấy họ biết đủ để bắt đầu. Wether mất một giờ, hoặc 2 trong 4 hoặc cả ngày là hoàn toàn bên cạnh điểm; nó sẽ được thực hiện khi nó sẽ được thực hiện.
Nói rằng bạn muốn rút ngắn nó và giới hạn trong 2 giờ. Thực tế là họ cần thông tin sẽ không thay đổi, do đó, bạn chắc chắn sẽ kết thúc với các phần của kế hoạch chạy nước rút, xuất hiện trong phần còn lại của nước rút.
Cuối cùng, tất cả những gì quan trọng là nhóm có thể cam kết thực hiện một số công việc và thực sự cung cấp công việc đó cho sự hài lòng của cả chính họ và các bên liên quan khác. Tất cả phần còn lại không quan trọng. Tập trung vào những gì thực sự mang lại giá trị, đừng tập trung vào các số liệu phù phiếm.

Tái bút: cho dù bạn có ước tính bao nhiêu tài liệu trong vài giờ, tôi vẫn thấy đó là một ý tưởng vô dụng và phản tác dụng khủng khiếp và tôi biết tôi không đơn độc trong việc này.

Theo kinh nghiệm của bạn, có bao nhiêu nhiệm vụ trong một lần chạy nước rút và mất bao lâu để ước tính tất cả chúng? (Ước tính chỉ một nửa trong số họ không có ý nghĩa nhiều, phải không?)

Điều này giống như hỏi có bao nhiêu hạt mưa trong cơn giông bão. Hoàn toàn không có cách nào để trả lời câu hỏi này, ngay cả khi bạn nói về hai cơn bão khác nhau có cùng kích thước. Không có quy tắc ngón tay cái, bất kể kích thước đội hoặc kích thước nước rút.

Điểm ước tính giờ trong các nhiệm vụ là để nhóm có thể học cách ước tính tốt hơn câu chuyện của họ. Ví dụ, hãy xem xét hai câu chuyện mà bạn đã ước tính: một câu chuyện được ước tính là 2 và một là 4 hoặc 5. Khi bạn bắt đầu thực hiện nhiệm vụ, bạn nhận ra rằng cả hai đều có cùng số giờ được giao cho các nhiệm vụ. Điều đó dạy bạn điều gì?

Nguyên tắc duy nhất tôi nghĩ tôi có thể đưa ra là, nếu nhóm của bạn có vận tốc ổn định, bạn không cần phải ước tính các nhiệm vụ. Nếu bạn thấy rằng vận tốc của bạn không ổn định, có thể là do kỹ năng ước tính của bạn yếu. Bạn có thể củng cố chúng bằng cách chia nhỏ các câu chuyện thành các nhiệm vụ tại thời điểm lập kế hoạch như một loại kiểm tra sự tỉnh táo cho ước tính của bạn.

Trong câu hỏi của bạn, bạn nói rằng nhóm của bạn chưa có, vì vậy việc ước tính là rất quan trọng. Nếu đó là sự thật, đừng lo lắng về thời gian bạn dành cho việc đó. Nó sẽ mất chừng nào nó cần. Bạn đang đầu tư vào nhóm của bạn. Vâng, lúc đầu sẽ mất rất nhiều thời gian, nhưng hy vọng bạn sẽ học hỏi được kinh nghiệm. Bạn có thể học được điều đó thật lãng phí thời gian hoặc bạn có thể học được rằng bạn không thông minh về việc ước tính như bạn nghĩ.

Hãy nhớ rằng: scrum không phải là một bộ quy tắc bạn phải tuân theo, mà là một bộ công cụ để giúp bạn lập kế hoạch và sắp xếp công việc. Bất cứ khi nào các công cụ này cản trở năng suất của bạn, bạn nên ngừng sử dụng chúng. Hãy chắc chắn rằng họ thực sự cản trở năng suất của bạn thay vì xuất hiện như vậy.

giả sử chạy nước rút ba tuần với 8 nhà phát triển có nghĩa là 120 nhiệm vụ và chỉ mất hai giờ để ước tính có vẻ hơi nhiều đối với tôi.

Đối với tôi điều này có nghĩa là 8 nhà phát triển dành 15 phút để lên kế hoạch cho 3 tuần tới. Qua nhiều? Điều đó giống như một cuộc đứng lên hàng ngày.

Đó là một ước tính. Lập kế hoạch nước rút đầu tiên của bạn. Ghi chú và đo lường tốt. Chạy nước rút đầu tiên của bạn có thể sẽ được cách ra khỏi nhãn hiệu. Nếu đây là một vấn đề, hãy đặt thời gian và các bước cần thiết để cải thiện bước tiếp theo. Là nhiệm vụ mất nhiều thời gian hơn dự kiến? Mỗi nhà phát triển có thể thực hiện nhiều nhiệm vụ trong một lần chạy nước rút như họ mong đợi không?

Hãy cởi mở và trung thực về những gì đã thực sự được thực hiện và mất bao lâu. Nếu mọi người sợ hãi, họ sẽ chỉ chơi trò chơi hệ thống. Bạn sẽ dựa trên quyết định lập kế hoạch của bạn về dữ liệu xấu. Nếu quá nhiều nhiệm vụ mất hơn một ngày (hoặc bất cứ điều gì bạn nghĩ rằng họ nên thực hiện), hãy xác định xem chúng có bị chia thành các mảnh nhỏ không.

Các nhà phát triển của bạn có thể không có đủ 8 giờ mỗi ngày để thực hiện các nhiệm vụ hoặc bất cứ điều gì mà quản lý số ma thuật muốn nghe để cảm thấy họ đang làm việc cả ngày với mức lương đủ ngày.

Sẽ là một điều khủng khiếp khi khám phá sau 2 tuần bạn hoàn thành chạy nước rút 3 tuần hoặc bạn chỉ hoàn thành 75% nhiệm vụ khi kết thúc cuộc chạy nước rút? Học hỏi từ những điều không mong muốn (Đây là ước tính, vì vậy chúng ta đừng tập trung vào chúng và gọi chúng là những sai lầm.).

Mục tiêu là làm cho khách hàng hài lòng trong bối cảnh những gì họ muốn thực hiện trong thời gian và nguồn lực nhất định. Đó không phải là để lấy ý chí sống của mọi lập trình viên mà bạn phải hoàn thành dự án này.

Vì vậy, để trả lời câu hỏi của bạn: Chỉ cần làm hết sức mình để ước tính lần chạy nước rút đầu tiên của bạn. Học hỏi từ nó và điều chỉnh cái tiếp theo. Nói lại.

Ý kiến ​​riêng của tôi là việc ước tính giờ làm việc bị lãng phí thời gian trong kế hoạch chạy nước rút. Nói chung, các ước tính là sai và tôi không nhận được giá trị khi báo cáo về chúng. Tuy nhiên, nhiều công cụ theo dõi nhiệm vụ nhanh nhẹn sử dụng những giờ này để tạo ra sự thay đổi, vì vậy chúng ta cần một cái gì đó trong đó.

Để tiết kiệm thời gian, tôi bắt đầu theo quy trình này:

1. Đặt mỗi tác vụ được tạo thành "1 giờ" ngay khi tác vụ được tạo.
2. Khi các nhà phát triển giải quyết các nhiệm vụ trong suốt giai đoạn nước rút, nếu họ nghĩ rằng phải mất hơn một giờ trong nhiệm vụ, họ có thể cập nhật nó thành một giá trị thực tế hơn.
3. Khi các nhiệm vụ được hoàn thành, báo cáo phát hành cập nhật vào giờ còn lại.

Bạn vẫn có khả năng xem tiến độ đang diễn ra như thế nào và liệu bạn có đang đi đúng hướng hay không, nhưng bạn có thể sử dụng thời gian lập kế hoạch nước rút của mình cho các hành động có giá trị hơn như hiểu các câu chuyện và tìm ra những nhiệm vụ phải làm.

TL; DR

[H] ow có nhiều nhiệm vụ đang ở giai đoạn nước rút và phải mất bao lâu để ước tính tất cả chúng?

Câu hỏi của bạn không có câu trả lời kinh điển có thể. Mặc dù bạn chắc chắn có thể sử dụng một số quy tắc ngón tay cái để tính giới hạn trên hợp lý cho khối lượng tác vụ, không có tỷ lệ chuyển đổi phổ biến nào cho các câu chuyện thành nhiệm vụ hoặc nhiệm vụ theo giờ.

Ví dụ, một quy tắc thông thường được chấp nhận là một nhiệm vụ nên có kích thước trong khoảng nửa ngày đến hai ngày để vòng phản hồi được thực hiện / không được thực hiện vẫn chặt chẽ. Các đội có thể và thực hiện vi phạm quy tắc này, vì đó không phải là một yêu cầu khung, nhưng các nhóm thành công nhất mà tôi đã làm việc với tất cả đều tuân theo tinh thần của quy tắc này.

Nhiệm vụ trên mỗi Sprint

Tôi biết câu trả lời phụ thuộc vào độ dài nước rút và quy mô đội, vì vậy hãy giả sử 8 nhà phát triển và ba tuần.

Điều này là sai hoàn toàn, vì số lượng nhiệm vụ phụ thuộc vào số lượng câu chuyện và số lượng và độ chi tiết của mỗi nhiệm vụ được phân tách của câu chuyện. Tuy nhiên, bạn có thể tính toán giới hạn trên thô để kiểm tra độ tỉnh táo.

Nếu bạn giả sử một tiên nghiệm rằng:

• mỗi tác vụ chỉ yêu cầu một nhà phát triển (điều này thường không xảy ra)
• 30% số lần chạy nước rút của bạn được sử dụng bởi chi phí khung (con số này thay đổi theo thời gian chạy nước rút)
• bạn đang không áp dụng bất kỳ yếu tố kẹo mềm cho thực tế là hiệu quả giờ làm việc nói chung là <= 6 giờ mỗi ngày làm việc

sau đó bạn có sẵn 10,5 "ngày" cho các nhiệm vụ cho mỗi nhà phát triển để phân bổ cho các nhiệm vụ trong mỗi lần chạy nước rút. Giả sử thêm:

• 8 nhà phát triển
• tất cả các nhà phát triển có thể hoán đổi cho nhau
• không có hoạt động xếp hàng hoặc phụ thuộc giữa các tác vụ
• bạn đang bao gồm Định nghĩa các hoạt động Xong là các nhiệm vụ rõ ràng

sau đó tuân theo quy tắc định cỡ nhiệm vụ được đề xuất sẽ cung cấp cho nhóm của bạn khả năng từ 21-148 nhiệm vụ mỗi lần chạy nước rút ba tuần.

Tránh ước tính nhiệm vụ trong giờ làm việc

Giải pháp đơn giản ở đây là tránh ước tính các nhiệm vụ trong giờ làm việc lý tưởng và ném tất cả các giả định có vấn đề (và thường không chính xác) lên trên. Bằng cách đơn giản là không chấp nhận các câu chuyện vào giai đoạn nước rút vượt quá tốc độ bền vững của bạn, bạn giải quyết hầu hết các vấn đề lập kế hoạch chạy nước rút mà không ước tính theo giờ.

Bằng cách đảm bảo rằng các câu chuyện của bạn được phân tách thành các nhiệm vụ được thực hiện / không hoàn thành đúng kích cỡ không quá một vài ngày, bạn có thể nhanh chóng xem liệu bạn có chấp nhận nhầm một câu chuyện phức tạp hơn ước tính điểm câu chuyện của bạn không, hoặc nếu có là công việc ẩn cần được ghi lại và sắp xếp lại với Chủ sở hữu sản phẩm trong Kế hoạch Sprint.

Các đội khỏe mạnh dành khoảng nửa ngày để phân tách các nhiệm vụ cho Sprint Backlog. Nếu bạn không dành thời gian để thực hiện việc này trong nửa sau của Kế hoạch Sprint, thì bạn có nhiều khả năng phát hiện ra những vướng mắc, sự phụ thuộc bất ngờ hoặc công việc không có kế hoạch sau này trong lần chạy nước rút.

Cuộc họp Sprint Backlog kéo dài bốn giờ đại diện cho ít hơn 3% thời lượng nước rút ba tuần của bạn và là nơi hầu hết các phân tích thiết kế và kiến ​​trúc được thực hiện trong khung Scrum. Việc cạo râu giảm xuống 2% bằng cách thay đổi ngắn phân tích nhiệm vụ có thực sự đáng để mạo hiểm cho dự án của bạn không? Tôi sẽ nói không, nhưng số dặm của bạn có thể thay đổi.

giả sử chạy nước rút ba tuần với 8 nhà phát triển có nghĩa là 120 nhiệm vụ và chỉ mất hai giờ để ước tính có vẻ hơi nhiều đối với tôi.

Giả định của bạn không đúng vì không phải tất cả các thành viên trong nhóm đều tham gia lập kế hoạch cho từng nhiệm vụ. Trong thực tế cho các câu chuyện, tất cả các thành viên tham gia ước tính tất cả các câu chuyện nhưng đối với các nhiệm vụ, thường là một vài thành viên trong nhóm ước tính từng nhiệm vụ.

Vì vậy, nếu trong ví dụ của bạn, mỗi hai thành viên ước tính một nhiệm vụ, Chỉ mất khoảng nửa giờ để ước tính tất cả chúng.