Làm cách nào để chúng tôi cung cấp các ước tính thời gian hợp lệ trong Lập kế hoạch Sprint mà không thực hiện thiết kế quá nhiều của Cameron?

Nhóm của tôi đang bắt kịp tốc độ với Scrum, nhưng hầu hết chúng ta đều quen thuộc hơn với các phương pháp nhanh không giả hoặc "giả". Phần cản trở lớn nhất đối với chúng tôi là điều hành một cuộc họp Lập kế hoạch Sprint hiệu quả nơi chúng tôi chia các mục tồn đọng của mình thành các nhiệm vụ và ước tính giờ. (Tôi đang sử dụng thuật ngữ từ Mẫu Scrum VS2010; xin lỗi nếu tôi sử dụng từ sai ở đâu đó.)

Khi chúng ta cố gắng tìm hiểu một nhiệm vụ sẽ diễn ra trong bao lâu, chúng ta thường rơi vào cái bẫy của việc thiết kế tính năng ở cấp mã - bố trí bảng, giao diện, v.v. - để tìm hiểu xem sẽ mất bao lâu .

Tôi khá chắc chắn rằng đây không phải là nơi thích hợp để thực hiện kiểu thiết kế đó. Chúng ta nên sắp xếp các nhiệm vụ cho các cuộc họp thiết kế này trong giai đoạn nước rút. Tuy nhiên, chúng tôi đang gặp khó khăn trong việc tìm ra cách khác để đưa ra các ước tính có ý nghĩa cho các nhiệm vụ.

Có bất kỳ thói quen / kỹ thuật thực tế / vv. để thực hiện một cuộc gọi phán xét về việc một tính năng sẽ mất bao lâu, mà không biết bạn dự định thực hiện nó như thế nào? Nếu ước tính thời gian của chúng tôi sẽ thay đổi đáng kể sau khi thiết kế được hoàn thành, làm thế nào chúng tôi có thể dự trù ngân sách tồn đọng Sprint của chúng tôi trước thời hạn?

BIÊN TẬP:

Chỉ cần làm rõ, vì một số ý kiến ​​/ câu trả lời là rất hợp lệ nhưng tôi nghĩ rằng việc giải quyết câu hỏi sai.

Chúng tôi biết rằng những gì chúng tôi đang làm là không đúng, và chúng tôi nên xây dựng thời gian vào giai đoạn nước rút cho thiết kế này. Về mặt khái niệm tất cả các nhà phát triển đều hiểu điều đó. Chúng tôi cũng mang đến một thành viên trong nhóm có kinh nghiệm về Scrum để giúp chúng tôi theo dõi nếu chúng tôi bắt đầu đi vào đám cỏ dại.

Vấn đề là, nếu không trải qua quá trình thiết kế này, chúng tôi đang gặp khó khăn trong việc cung cấp các ước tính thời gian cụ thể cho bất cứ điều gì. Chúng tôi liên tục nói những câu như "tốt nếu chúng tôi thiết kế theo cách này có thể mất 8 giờ nhưng nếu cuối cùng chúng tôi phải làm theo cách khác thay vào đó sẽ mất khoảng 32 nhưng nó có thể không tệ như vậy khi chúng tôi bắt đầu viết nó ... ".

Tôi cũng cho rằng quá trình này sẽ trở nên tốt hơn khi chúng ta có một số vận tốc lịch sử để làm việc, nhưng nhiều công nghệ và mô hình kiến ​​trúc mà chúng ta đang sử dụng là mới đối với chúng ta. Nhưng nếu các ước tính có khả năng cực kỳ sai lầm chỉ là một phần tự nhiên của việc thích ứng quá trình này thì chúng ta sẽ chỉ cần xem xét lại bản thân để chấp nhận điều đó :)

1. Lên lịch một cuộc họp "chải chuốt" định kỳ, nơi bạn có những cuộc thảo luận thiết kế này. Đội tôi tham gia có họ một lần mỗi lần chạy nước rút, vào ngày trước khi lên kế hoạch. Mục tiêu là để thiết kế đủ xa để nhóm có thể đồng ý về ước tính thời gian cho câu chuyện tổng thể. Bạn có thể xem xét thực hiện các phân tích nhiệm vụ trong cuộc họp này, để việc lên kế hoạch hoàn toàn là một bài tập trong việc quyết định chọn bao nhiêu. Nói cách khác, bạn nên thực hiện thiết kế trong các lần chạy nước rút TRƯỚC KHI bạn bắt đầu thực hiện công việc thực tế.

2. Cân nhắc sử dụng lập kế hoạch chơi bài , tức là điểm / đơn vị "nỗ lực" thay vì ngày công để ước tính nhiệm vụ. Cũng cố gắng chia nhỏ những câu chuyện nhiều nhất có thể. Câu chuyện càng dài / phức tạp thì khả năng ước tính của bạn sẽ càng chính xác.

3. Trong kế hoạch, chủ scrum nên giữ kế hoạch theo dõi bằng cách tạm dừng bất kỳ cuộc thảo luận nào quá xa để "giải quyết". Tại thời điểm đó, các thành viên trong nhóm được yêu cầu nhanh chóng đi đến thỏa thuận về ước tính, thường đưa ra số giới hạn / trường hợp xấu nhất. Việc nhận nhiều công việc sẽ dễ dàng hơn nhiều nếu các nhiệm vụ kết thúc dễ dàng hơn bạn dự định, hơn là giải quyết các lịch trình bị trượt do các nhiệm vụ mất nhiều thời gian hơn so với kế hoạch và các câu chuyện được đưa vào nhiều lần chạy nước rút.

4. Nói về cách các ước tính được đưa ra trong phần hồi tưởng ở cuối nước rút. Đặc biệt nếu có bất kỳ đó là xa đáng kể. Đội có học được gì từ cách câu chuyện diễn ra so với cách họ mong đợi nó sẽ diễn ra không? Chủ scrum nên tập trung vào các thay đổi có thể thực hiện được cho quá trình thiết kế / ước tính của bạn.

Tôi nghĩ vấn đề là bạn đang cố gắng ước tính thời gian. Đừng.

Ước tính độ phức tạp. Xem xét một yêu cầu, (hy vọng là một câu chuyện của người dùng) và đánh giá mức độ phức tạp của nhóm nghĩ rằng sẽ tìm ra cách xây dựng nó và kiểm tra nó, liên quan đến mức độ phức tạp của các yêu cầu hoặc câu chuyện người dùng khác. Đôi khi bạn sẽ sai, nhưng thường thì bạn sẽ biết được mức độ khó của một thứ gì đó. Bạn cũng sẽ thấy rằng các mục có cùng độ phức tạp có xu hướng mất cùng một nỗ lực để hoàn thành.

Vì vậy, thứ hạng phức tạp trở thành "điểm câu chuyện" liên quan đến câu chuyện của người dùng trong sản phẩm tồn đọng của bạn. Sau khi bạn vượt qua một vài lần chạy nước rút, bạn sẽ có ý tưởng về số điểm câu chuyện bạn có thể vượt qua trong lần chạy nước rút, và đó là vận tốc của bạn. Tại thời điểm đó, bạn sẽ có ý tưởng tốt hơn nhiều về việc mỗi mục sẽ mất bao lâu.

Tôi đặc biệt khuyên bạn nên áp dụng Câu chuyện người dùng của Mike Cohn .

Tôi biết câu hỏi của bạn là đặc biệt về việc tránh thiết kế trong kế hoạch. Nhưng đây là một vấn đề XY .

Tôi đã từng ở nơi bạn đang ở. Thay vì cung cấp cho bạn thứ gì đó có thể mang lại sự cải thiện gia tăng, tôi muốn giúp bạn vượt qua một số trạng thái trung gian đó.

Dưới đây là ba điều mà nhóm chúng tôi thực hiện liên quan cụ thể đến việc lập kế hoạch và thực hiện công việc. Những điều này đã giúp chúng tôi tránh việc đập thiết kế và thoát khỏi các ước tính thời gian không chính xác.

Tiêu chí chấp nhận tự động

Câu chuyện của chúng tôi được chỉ ra bởi số lượng Tiêu chí chấp nhận tự động . Điều này có nghĩa, nếu chúng ta viết các bài kiểm tra tự động để xác nhận rằng câu chuyện đã được thực hiện, chúng sẽ là gì?

Ví dụ: "Khi người dùng nhấp vào 'phát' trên iPad chạy iOS 6+, video sẽ bắt đầu phát." Có thể khó thực sự tự động hóa thử nghiệm này, nhưng đó là một tiêu chí chấp nhận (AC) của câu chuyện và đóng góp một điểm.

Chúng tôi sử dụng thang đo Fibonacci và chúng tôi luôn làm tròn số. Vì vậy, nếu một câu chuyện có bốn tiêu chí chấp nhận tự động, thì đó là một câu chuyện năm điểm.

Kích thước điểm câu chuyện tối đa của chúng tôi là tám điểm, nhưng chúng tôi hiếm khi có những điểm đó. Nếu một câu chuyện có nhiều hơn năm tiêu chí chấp nhận tự động, chúng tôi sẽ tìm cách tách chúng ra.

Chăm sóc trước

Chúng tôi có một cuộc họp khởi động vào thứ Hai, nhưng các cuộc họp chải chuốt của chúng tôi là nơi kế hoạch nhóm xảy ra. Trước khi chải chuốt, các thành viên trong nhóm sẽ chuẩn bị trước một câu chuyện bằng cách mô tả kết quả và thực hiện các tiêu chí chấp nhận tự động.

Chải chuốt mang lại chuyên môn của đội để chịu đựng những câu chuyện được chuẩn bị trước, tìm ra những yêu cầu không xác định, phá vỡ những câu chuyện, v.v.

Đôi khi chúng tôi liệt kê các nhiệm vụ ngoài các tiêu chí chấp nhận, nhưng đây không phải là thời gian ước tính. Chúng tôi không bao giờ ước tính thời gian. Nhiệm vụ chỉ là tuyên bố công việc cần được thực hiện để hỗ trợ các tiêu chí.

Hạn chế tiến độ công việc

Scrum truyền thống cố gắng giới hạn thời gian làm việc trong thời gian chạy nước rút. Chúng tôi thấy rằng điều này một cách giả tạo khiến chúng tôi phải gấp rút đáp ứng thời hạn nước rút, giết chết những ngày cuối tuần của chúng tôi vì cuộc đua nước rút kết thúc vào thứ Sáu.

Một cách tiếp cận khác là hạn chế công việc đang tiến hành tại bất kỳ thời điểm nào. Chúng tôi đã di chuyển đến sau này và đã được hạnh phúc hơn đáng kể cho nó.

Khi một câu chuyện chuyển từ tồn đọng vào công việc đang diễn ra, chúng tôi mô tả nó như là một trong một số trạng thái:

• Tạm dừng - công việc nhóm không thể xảy ra vì chúng tôi đang chờ một số hoạt động của nhóm khác
• Trong phát triển - làm việc để đạt được các tiêu chí chấp nhận
• Kiểm tra nhu cầu - chúng tôi tin rằng chúng tôi đã gặp AC, chờ người khác xác minh
• Trong thử nghiệm - câu chuyện đang được đánh giá theo AC, các lỗi đang được giải quyết
• Sẵn sàng để triển khai - tại cơ hội có sẵn tiếp theo, nó sẽ ra mắt

Sau đó, chúng tôi sử dụng số lượng câu chuyện ở mỗi tiểu bang để tập trung vào đội. Ví dụ: nhà phát triển có thể sẵn sàng tiếp nhận một câu chuyện mới, nhưng nếu chúng tôi có nhiều câu chuyện trong Thử nghiệm, tốt hơn là họ sẽ giúp đỡ về những câu chuyện hiện có.

Đầu tiên, nhận ra rằng ước tính chính xác là không thể trong những trường hợp đó. Đừng căng thẳng nếu bạn hiểu sai. Tuy nhiên, bạn vẫn cần một ý tưởng sơ bộ để lập kế hoạch và thực sự cách duy nhất để tính đến sự không chắc chắn hoàn toàn là thêm nhiều điểm câu chuyện vào ước tính của bạn. Nếu bạn không biết đó là số 5 hay số 13, hãy sử dụng số 13.

Nó cũng hữu ích để chia nhỏ những câu chuyện nhỏ nhất có thể. Chúng ta thường có một câu chuyện nghiên cứu / thiết kế với mục đích duy nhất là làm đủ công việc để có ý tưởng tốt hơn về cách thực hiện tính năng, sau đó chính câu chuyện tính năng sẽ đi vào giai đoạn nước rút tiếp theo. Hãy suy nghĩ về lý do tại sao điều này hoạt động. Ngay cả khi bạn không biết điều gì sẽ khó khăn đến thế nào, bạn thường biết khá chính xác từ kinh nghiệm trong quá khứ mất bao lâu để tìm hiểu.

Có hai điều bạn có thể làm ở đây.

Trước tiên, có một số bậc thầy scrum, người có vai trò giám sát cuộc thảo luận và nói "Này, bạn đang thiết kế lại" khi bạn đang có. Nó khó hơn dường như, xoay người vào đó từng ngày và ban đầu mọi người đều là chủ nhân của scrum để bất cứ ai cũng có thể vượt lên.

Thứ hai, nếu bạn đang thiết kế trong kế hoạch chạy nước rút, bạn cần có khả năng phân biệt giữa việc không biết đủ để thực hiện cuộc gọi trong thời gian thực hiện nhiệm vụ, hoặc liệu bạn chỉ đang thiết kế vì điều đó thú vị hơn.

Một lần nữa, chủ scrum nên đá vào đây và bảo bạn đặt lại vật phẩm cho đến khi bạn biết đủ để lên lịch cho nó, hoặc khiến bạn ngừng thiết kế và trả lời câu hỏi ban đầu (Sẽ mất bao lâu).

Vì vậy, nếu bạn đang thực hiện kế hoạch chạy nước rút, sẽ rất hợp lý khi có một nhà tài trợ kinh doanh ở đó để vượt qua tồn đọng với bạn và ưu tiên những thứ họ muốn thấy trước tiên. Nếu bạn làm điều đó, bạn sẽ thấy khó thiết kế hơn trong phiên vì họ sẽ bồn chồn và cuối cùng sẽ không muốn đến.

Chúng tôi đã hoạt động trên cơ sở ước tính câu chuyện "lạnh" trong kế hoạch chạy nước rút chỉ với một số thảo luận hạn chế. Các ước tính thực sự khá không chính xác mặc dù việc thành lập các đội với trọng tâm khá hẹp ... chủ yếu là do sự tồn tại của rất nhiều mã di sản không có giấy tờ, không có thực tế về tất cả các ý tưởng về những gì thực sự sẽ xảy ra và nhân viên đã thay đổi phần lớn kể từ khi bản gốc được viết.

Những gì chúng tôi đang cố gắng bây giờ là dành một chút thời gian trước khi lên kế hoạch điều tra từng câu chuyện - và ở đây chỉ có một nhà phát triển sẽ điều tra một câu chuyện ... Chúng tôi hy vọng rằng điều này sẽ có nghĩa là nhà phát triển điều tra sẽ có thể cung cấp một số thông tin chi tiết giúp dự toán. Cho đến nay điều này đã giúp đỡ trong những dịp nó đã được thử.

Tôi vẫn chưa tin rằng cuộc điều tra bổ sung thực sự làm cho các ước tính đủ chính xác hơn để biện minh cho chi phí nhưng chúng tôi sẽ thử nó trong một vài lần chạy nước rút để xem.