Ước lượng Agile trong Scrum? Điểm câu chuyện và Planning Poker

Trong quá trình phát triển phần mềm, đội ngũ thường có một câu hỏi:

Thời gian làm việc được ước lượng như thế nào để chính xác hơn?

Đối với chủ sở hữu dự án hoặc sản phẩm, đây là thông tin rất quan trọng cho việc đo lường tài nguyên và thời gian của dự án, nhưng thực tế điều này đã gây ra nhiều vấn đề.

Nhiều nhà phát triển luôn cảm thấy rằng PM đang sử dụng thời hạn để đẩy qua đẩy lại. Họ không quan tâm liệu tính năng có thể hoàn thành với chất lượng hay không.

“Hoàn thành trước, sau đó tìm kiếm tốt hơn” vì vậy đã lưu hành trong ngành công nghiệp phần mềm từ lâu.

Nhiều PM luôn cảm thấy rằng các nhà phát triển có xu hướng “phóng đại” khi họ ước lượng công việc của mình. Có vẻ như họ đều sử dụng phương pháp ước lượng công việc điển hình: “Ước lượng gấp ba lần thời gian thực tế làm đệm”

Trên thực tế, giờ làm việc không thể được ước lượng là “hoàn toàn chính xác”, nhưng có một số cách để ước lượng “tương đối khách quan”. Do sự phức tạp của giờ làm việc và yêu cầu, thường có một mối tương quan tích cực. Do đó, bài viết này sẽ đầu tiên giải thích các vấn đề chung để đáp ứng sự phức tạp của các yêu cầu, đề xuất một giải pháp, và giải thích mục đích của nhiều thiết kế trong giải pháp.

Vấn đề

Mỏ của nhà phát triển

• “Nó rất đơn giản. Nó không nên mất quá nhiều thời gian để làm điều đó?”
• PM đã nói với bạn hôm nay: “Tôi phải bàn giao trước ngày mai. “Hoàn thành trước khi tìm kiếm chất lượng”
• PM đã nói với bạn ngày kia: “Tại sao chất lượng của chương trình lại tệ như vậy?”
• Khi nó bị trì hoãn, các đồng nghiệp khác: “Tại sao bạn cần phải mất nhiều thời gian như vậy? Điều này có mã sẵn để tham khảo. Điều này có một lớp nền tốt để sử dụng. Tại sao bạn không hỏi tôi?”
• Các đồng nghiệp khác: “Tôi chỉ cần một ngày, tại sao bạn đã mất nhiều ngày như vậy?”
• “Đây là lẽ thường! Nếu chúng ta không đề cập đến yêu cầu, bạn nên biết phải làm gì.”

Mỏ của PM/PO

• “Tại sao nó lại đơn giản như vậy? Tại sao lại mất nhiều thời gian như vậy?”
• “Tại sao bạn thấy rằng bạn đang truy cập Facebook, nhưng bạn không có thời gian để làm điều đó?”
• “Tại sao chất lượng của những thứ được làm lại tệ như vậy?”
• “Tại sao anh ấy đã làm điều đó lần trước, bạn phải mất bao nhiêu ngày để làm?”
• Bởi vì các thông số kỹ thuật hoặc yêu cầu không được viết rõ ràng, nhà phát triển được mô tả như một sự thay đổi yêu cầu.

Kết quả

• Sự thù địch vai trò: Đơn vị yêu cầu và đơn vị phát triển không còn cung cấp một sản phẩm có thể mang lại lợi ích cho người dùng, mà tấn công lẫn nhau vì mục đích riêng của họ, nhằm tránh phải chịu trách nhiệm bổ sung. Do đó, tình huống mà đơn vị yêu cầu và đơn vị phát triển không phải là một đội duy nhất.
• Trách nhiệm: Đội ngũ nghĩ rằng “Tôi không sai, vì vậy sự trì hoãn không phải là trách nhiệm của tôi”, thay vì ưu tiên nhu cầu của người dùng.
• Đóng băng yêu cầu: Các nhà phát triển bị buộc phải thay đổi yêu cầu của họ vì áp lực thời hạn, nếu không họ sẽ bị trì hoãn và trách nhiệm sẽ được tính cho nhà phát triển. Do đó, hoặc bị yêu cầu làm thêm giờ để sản xuất một cái gì đó ẩn chứa nhiều lỗi, hoặc làm một loại tính năng không đáp ứng nhu cầu của người dùng; và cả hai sẽ giảm sự hài lòng của người dùng.
• Chất lượng thấp: Trạng thái của PM thường cao hơn so với các nhà phát triển. Do đó, để đáp ứng thời hạn của hợp đồng hoặc để tránh các hình phạt, v.v., đội ngũ sẽ được yêu cầu “Hoàn thành trước, sau đó tìm kiếm tốt hơn”, nhưng cuối cùng thường là “trước tiên, không có thời gian để tìm kiếm tốt.” Sự tích lũy nợ kỹ thuật đang gia tăng, và kết quả là mô hình chuỗi trách nhiệm trong thế giới thực, có trách nhiệm và chi phí lớn nhất ở cuối chuỗi. Vì vậy, đội ngũ giống như một ngăn xếp, các nhà phát triển không thể duy trì từng người một, đây là một trong những yếu tố khiến kỹ sư công ty dự án thường có tỷ lệ nghỉ việc cao.
• Tăng trọng số của mã: Để tối ưu hóa hiệu suất, vị trí của người quen thuộc nhất luôn được sử dụng để ước lượng giờ làm việc, vì vậy người quen thuộc nhất với mô-đun và quy trình sẽ luôn quan tâm đến các yêu cầu liên quan. Cuối cùng, chỉ những người đó mới có thể duy trì mã của riêng họ, nó giống như một chiếc hộp Pandora, bạn không bao giờ biết những con bò và ma nào sẽ chạy ra sau khi mở. Bởi vì hộp đen thường bẩn thỉu, nhưng công ty không biết cách giải quyết vấn đề này. Bạn cũng hy vọng rằng anh ấy sẽ không rời đi, nếu không một số mã sẽ không được hiểu.

Giải pháp

Giải pháp được đề xuất ở đây là một cách phổ biến để ước lượng độ phức tạp của các yêu cầu trong Scrum, nhưng ngay cả khi không phải là một đội Scrum, cũng được khuyến nghị rằng độc giả có thể xác định cách tốt nhất để ước lượng đội của bạn dựa trên các nguyên tắc và mục tiêu thiết kế.

Hãy nhớ rằng không có viên đạn bạc, thực tiễn tốt nhất của người khác không nhất thiết áp dụng cho đội của bạn, vì vậy trước tiên hãy hiểu vấn đề mà đội của bạn đang gặp phải, và sau đó tìm ra điều gì là đúng cho bạn để giải quyết vấn đề từ thực tiễn của người khác, miễn là nó không gây ra các vấn đề mới hoặc rủi ro chi phí của một vấn đề mới là chấp nhận được.

Đơn vị được sử dụng ở đây để ước lượng độ phức tạp của các yêu cầu là điểm câu chuyện (đơn vị tương đối), không phải giờ làm việc (đơn vị tuyệt đối).

Đơn vị được sử dụng để ước lượng độ phức tạp của yêu cầu ở đây là điểm câu chuyện (đơn vị tương đối), không phải thời gian làm việc (đơn vị tuyệt đối). Có một số lý do cho việc này:

1. So sánh không thay đổi từ người này sang người khác: độ phức tạp của yêu cầu thường không thay đổi từ người này sang người khác, và thời gian cần thiết cho thực hành sẽ thay đổi từ người này sang người khác.

2. “Tương đối” dễ đánh giá hơn “Tuyệt đối”: Nếu bạn nhìn vào giờ làm việc, bạn sẽ cần ước lượng số tuyệt đối, và bạn sẽ cần nghĩ về các chi tiết thực hiện trong quá trình ước lượng. Để sử dụng điểm câu chuyện để ước lượng độ phức tạp, bạn chỉ cần so sánh kích thước với các yêu cầu khác.

Ví dụ, thật khó để nói rõ rằng “Một tòa tháp cao bao nhiêu mét”, nhưng dễ hơn để chỉ ra rằng “Tòa tháp này cao khoảng 2 lần tòa nhà kia.”

3. Áp lực để ước lượng điểm câu chuyện của một câu chuyện người dùng nhỏ hơn so với ước lượng thời gian làm việc của nó: tập trung vào yêu cầu chính nó, không lo lắng về tài nguyên của chính nó và tài nguyên dự án, chỉ cần đánh giá độ phức tạp của yêu cầu. Trong quá trình ước lượng, các thành viên trong nhóm ít căng thẳng hơn và tham gia vào phát triển phần mềm như một trò chơi.

Mặc dù độ phức tạp của yêu cầu thường có mối quan hệ tích cực với giờ làm việc, nhưng do các điều kiện thực hiện khác nhau, vẫn có thể có một tính năng với điểm câu chuyện cao, và yêu cầu về giờ làm việc thấp hơn điểm câu chuyện. Nhưng trong Scrum, bạn có thể sử dụng sprint lặp lại để đánh giá mức độ phức tạp mà mỗi đội sprint có thể tiêu hóa. Đối với PO/PM, thay vì ước lượng một thời gian không thành công, tốt hơn là ước lượng một thời gian chính xác và khách quan hơn để họ có thể hiểu ngay từ lần đầu tiên, cách xa thời gian dự kiến của dự án bao xa. Nếu tài nguyên hạn chế, làm thế nào để ưu tiên yêu cầu hoặc tìm kiếm hỗ trợ khác.

Tiếp theo, giải thích các khía cạnh khác nhau của giải pháp.

Khi nào

Tiến hành đánh giá trước khi quyết định ai cần làm điều đó: Lợi ích của việc này là giảm thiểu các yếu tố cá nhân của nhà phát triển. Bởi vì bạn không biết ai sẽ làm điều đó, không cần phải ước lượng quá mức để thêm đệm do nhiệm vụ hoặc thời hạn của chính bạn.

Ai

Chỉ những người làm việc mới có thể đánh giá cùng nhau: hai điểm chính:

1. Chỉ những người làm việc mới có thể được ước lượng. Thời gian hoặc độ phức tạp được ước lượng bởi đơn vị yêu cầu không khách quan, vì họ không phải là người thực hiện công việc, và không có quyền ảnh hưởng đến ước lượng của đội phát triển dựa trên đánh giá khả năng làm việc. Điều này cũng giúp dễ dàng hơn để tránh việc đánh giá độ phức tạp của các yêu cầu từ thời hạn.
2. Những người làm việc cùng nhau ước lượng. Bởi vì bạn không biết ai sẽ làm điều đó, các con số mà mỗi người ước lượng cùng nhau dễ dàng đạt được sự đồng thuận sau khi thảo luận và ước lượng lại. Mọi người đều tham gia, họ sẽ có cảm giác tham gia, và vì mọi người đều tham gia, kết quả ước lượng được quyết định bởi mọi người, vì vậy ai sẽ làm điều đó trong tương lai sẽ không phàn nàn.

Cái gì

Sử dụng Planning Poker để ước lượng điểm câu chuyện.

Thẻ poker và chuỗi Fibonacci

ChuỗiChuỗi Fischercó một đặc điểm thú vị, và mỗi số là tổng của hai số đầu tiên. Mặt khác, sự chênh lệch càng lớn giữa số này và số tiếp theo, thì sự chênh lệch càng lớn.

Như đã chỉ ra ở trên, khoảng cách giữa 8 và 13 là 5, và sự khác biệt giữa 13 và 20 là 7. Tuy nhiên, điều này liên quan gì đến việc ước lượng độ phức tạp của nhu cầu? Chúng ta không ở trong lớp toán.

Đặc điểm của ước lượng liên quan đến chuỗi Fibonacci

Ước lượng cũng có một đặc điểm, đó là, càng lớn thì càng chính xác, nhu cầu hoặc nhiệm vụ lớn hơn được chia nhỏ đến độ chi tiết hơn, thường được ước lượng chính xác hơn. Giống như nếu một mảnh đá lớn không đều được lắp vào một cái cốc, sẽ có nhiều khoảng trống ở giữa, đó là phần không khớp hoặc lãng phí. Nếu bạn lắp một viên đá có kích thước nhỏ hơn và cùng một độ không đều, khoảng trống sẽ tương đối nhỏ, và dễ dàng điều chỉnh, và có thể lấp đầy khoảng trống một cách thuận tiện hơn.

Ngay cả khi sự khác biệt trong các số liệu trước đó tương đối nhỏ, điều đó không quan trọng vì số lượng nhỏ, có nghĩa là sự di chuyển linh hoạt và rủi ro thấp. Nếu ước lượng thời gian không chính xác do một số yếu tố nhất định, nhiệm vụ của số nhỏ ở phía trước khoảng 20 phút làm thêm giờ. Thay vì làm thêm giờ trong 2 hoặc 5 ngày.

Bởi vì khoảng cách số lớn là lớn (tỷ lệ chênh lệch giữa hai giá trị trước và sau của chuỗi Fermi gần bằng 1.618), có thể tránh việc ước lượng “liệu độ phức tạp này là 20 hay 21”. “Nếu bạn muốn 13, bạn muốn 20, bạn muốn 40.

Khoảng cách như vậy có thể làm nổi bật sự khác biệt trong ước lượng của cùng một yêu cầu, vì hầu như tất cả chúng đều tệ hơn 1.5 lần. Tỷ lệ này khá dễ dàng cho con người đánh giá kích thước tương đối, và do đó có thể giảm bớt nhiều sắc thái và chi phí quá trình ước lượng lại không cần thiết.

Các số đặc biệt trong bài Poker

Ngoài ra, bức tranh trên có thể thấy một vài số đặc biệt, đó là 0, vô cực và dấu hỏi.

• 0 có thể có nghĩa là yêu cầu này không cần phải thực hiện, hoặc nó đã được hoàn thành.
• Vô cực có nghĩa là nhu cầu rõ ràng, nhưng cái vượt quá số tối đa cho thấy rằng nhu cầu cần được chia nhỏ thành nhiều yêu cầu có kích thước nhỏ hơn.
• Dấu hỏi cho thấy rằng nhu cầu không rõ ràng và cần PO/PM giải thích hoặc làm rõ.

Cách

1. Đầu tiên xác định đơn vị độ phức tạp 1, chẳng hạn như chức năng của một truy vấn tổng hợp bảng đơn. Bởi vì quy trình ước lượng của chúng tôi dựa trên kích thước tương đối, chúng tôi đầu tiên xác định đơn vị chuẩn so sánh, và có một cơ sở để so sánh sau khi nhóm ước lượng.

2. Người chủ nói to các yêu cầu (chẳng hạn như Thẻ Câu chuyện Người dùng) để đảm bảo rằng mọi người hiểu các yêu cầu và mỗi người trình bày độ phức tạp ước lượng của riêng mình. Lý do sử dụng planning poker là vì các số mà bạn đánh giá có thể được trình bày cùng một lúc, thay vì xoay vòng các số mà bạn đã đánh giá. Rất dễ để lật các số ra và khiến kết quả của những người phía sau bị ảnh hưởng bởi các số liệu trước đó.

3. Nếu có các ước lượng khác nhau trong nhóm, hai số được ước lượng là nhỏ nhất và lớn nhất, và họ sẽ đánh giá lý do tại sao chúng phức tạp hoặc đơn giản. Trong ví dụ trên, trong quá trình ước lượng, nếu một người ước lượng rằng điểm câu chuyện là 13, hầu hết mọi người ước lượng 20 và một người khác ước lượng 40. 13 và 40 gần như tệ hơn 3 lần, vì vậy về cơ bản phải có một số thông tin quan trọng chưa được đồng bộ.

Ví dụ, những người ước lượng 13 nghĩ rằng nhu cầu này gần như giống như một yêu cầu trong quá khứ, và yêu cầu này không phức tạp như tưởng tượng. Người ước lượng 40 có thể cảm thấy tương đối phức tạp vì anh ta không quen thuộc đủ với yêu cầu hoặc quy trình này.

4. Các số liệu tối thiểu và tối đa lý do cho việc đánh giá đã hoàn thành và một cuộc bỏ phiếu tiếp theo được tổ chức. Nếu vẫn còn các số phiếu khác nhau, và phần lớn mọi người có sự đồng thuận, và không có sự đồng thuận rằng độ phức tạp ước lượng chỉ cách một cấp so với độ phức tạp đồng thuận, bạn có thể hỏi các thành viên ước lượng các số khác nhau liệu họ có thể chấp nhận các số liệu mà bạn đã đánh giá hay không.

5. Nếu số vẫn còn khoảng cách trên một cấp độ, hoặc nếu không thể đạt được sự đồng thuận, hãy lặp lại các bước 3 đến 5 cho đến khi đạt được sự đồng thuận.

Một lần nữa, chỉ những người thực sự thực hiện nhiệm vụ hoặc hoàn thành yêu cầu mới có thể tham gia vào quá trình bỏ phiếu, và PO/PM không thể can thiệp.

Tại sao

Có một số lợi thế cho cách ước lượng này:

1. Người đang làm việc cùng nhau quyết định một kết quả ước lượng hợp lý và khách quan, có cảm giác tham gia và không có phàn nàn.
2. Kết quả của quyết định là sự đồng thuận giữa PO và Nhóm, điều này sẽ giảm thiểu sự xuất hiện của các tình huống trả đũa trong tương lai.
3. Mọi người đều có thể hiểu yêu cầu. Trong tương lai, mọi người có thể đóng vai trò là người thực hiện yêu cầu. Khi cần hỗ trợ, mọi người cũng có thể giúp đỡ hoặc hỗ trợ lẫn nhau.
4. Trước khi bạn làm như vậy, bạn có thể làm rõ phần yêu cầu không rõ ràng và phần có nghi ngờ.
5. Trước khi bạn có thể làm điều đó, bạn có thể tìm ra cách làm việc tốt nhất và hiệu quả nhất trong nhóm.
6. Trừ khi toàn bộ nhóm là những người không đáng tin cậy, số này phản ánh thực tế rằng ước lượng được chia sẻ bởi nhóm, và PO có thể hiểu khoảng cách giữa nhu cầu và đánh giá.
7. Bằng cách so sánh kích thước tương đối của độ phức tạp giữa các yêu cầu, PO trong tương lai sẽ có thể hứa hẹn bao nhiêu công việc có thể được hoàn thành trong một vòng lặp, và sẽ có một cơ sở để so sánh.

Kết luận

Thông qua quy trình ước lượng trên, quyết định như vậy là công khai, minh bạch, khách quan và có sự đồng thuận. Đối với hai vai trò:

Đối với PO/PM:

• Đừng lo lắng về việc ước lượng quá cao một nhiệm vụ cho một bộ đệm bởi một số thành viên nhất định.
• Hiểu được độ khó tiềm ẩn của việc thực hiện các yêu cầu hoặc nhiệm vụ trong quy trình đánh giá.
• Hiểu xem có phần nào của yêu cầu cần được nêu rõ hoặc bị hiểu sai hay không.

Đối với nhóm:

• Những người không còn làm việc được giao một thời hạn không hợp lý theo thời hạn.
• Trao đổi kiến thức giữa các nhà phát triển trước khi họ bắt đầu làm việc vào nhiệm vụ. Bất kể số ước lượng có tăng hay giảm, nhu cầu trở nên rõ ràng hơn và ước lượng trở nên khách quan hơn.
• Bởi vì bạn vẫn không biết ai đang yêu cầu nhiệm vụ này, nên quy trình ước lượng có thể đạt được một cách khách quan và với sự đồng thuận của nhóm, bạn biết ai quen thuộc với nhiệm vụ này thông qua quy trình. Khi bạn thực sự làm điều đó, bạn có thể lập trình cặp hoặc biết ai để hỏi giúp đỡ.

Giải pháp được đề xuất trong tài liệu này là một giải pháp chung. Sự chú ý không nằm ở hình thức, mà ở mục đích thiết kế của từng liên kết trong quy trình ước lượng linh hoạt, nhằm giải quyết vấn đề gì.

Các bài viết trong Kỹ thuật Scrum

• Các sự kiện Scrum là gì?
• Các nghi lễ Scrum là gì?
• Grooming Product Backlog là gì?
• 3 câu hỏi quan trọng trong Daily Scrum là gì?
• Chu kỳ Sprint Scrum trong 8 bước
• Sprint trong Scrum là gì?
• Nhịp đập của Scrum — Cuộc họp Daily Standup
• Cuộc họp Daily Scrum — Hướng dẫn nhanh
• Tại sao lại có các Sprint có độ dài cố định trong Scrum?
• Lập kế hoạch phát hành Scrum là gì?
• Lập kế hoạch Sprint là gì?
• Đánh giá Sprint là gì?
• Cuộc họp hồi tưởng Sprint trong Scrum là gì?
• Tinh chỉnh danh sách sản phẩm là gì?
• Tích hợp / Giao hàng / Triển khai liên tục trong Scrum là gì?
• Các sự kiện có thời gian giới hạn trong Scrum là gì?
• Spike trong Scrum là gì?
• Poker lập kế hoạch trong Agile là gì?

This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.