Có nên xem xét khả năng cá nhân trong điểm câu chuyện?

Sự hiểu biết của tôi về ước tính câu chuyện là người ta nên ước tính kích thước của một câu chuyện vì nó sẽ dành cho một nhà phát triển trung bình, tưởng tượng - giống như khái niệm "người ngoài cuộc hợp lý" trong luật. Đó là, bạn không nên ước tính kích thước của câu chuyện giả sử bạn phải làm điều đó .

Để đưa ra một ví dụ: trong công việc trước đây của tôi, tôi là thành viên của một nhóm nơi tôi là nhà phát triển Ruby tự tin nhất. Các đồng đội của tôi thường ước tính những câu chuyện liên quan đến Ruby lớn hơn tôi nhiều, với những lý lẽ như: "Tôi không biết X hoạt động như thế nào trong Ruby, vì vậy điều này sẽ khiến tôi mất nhiều thời gian để làm."

Lập luận của tôi chống lại điều này xuất phát từ thực tế rằng kế hoạch chạy nước rút là nơi phát huy năng lực của đội. Đó là diễn đàn chính xác để nói, "Khả năng chạy nước rút của chúng tôi sẽ thấp hơn một chút so với thông thường vì phần lớn các nhiệm vụ đều dựa trên Ruby và chúng tôi chỉ có một nhà phát triển Ruby mạnh." Bao thanh toán này trong quá trình ước tính sẽ tăng gấp đôi khía cạnh này.

Tôi đánh giá cao bất kỳ tài liệu tham khảo có thẩm quyền trong câu trả lời, nhưng ý kiến ​​đơn giản cũng sẽ rất tuyệt.

Điểm câu chuyện là một ước tính tương đối. Vì vậy, hai lần điểm có nghĩa là gấp đôi mức độ nỗ lực. Ước tính tương đối ít chịu sự thay đổi mức độ kỹ năng. Câu hỏi không phải là bạn mất bao nhiêu thời gian cho 1 điểm, mà là 2 điểm đòi hỏi nỗ lực tiềm năng gấp 2 lần. Cấp độ kỹ năng có thể quan trọng hơn nếu bạn mất những ngày lý tưởng thay vì điểm câu chuyện, bởi vì bạn giả định mức năng suất cá nhân.

Ước tính tương đối là mạnh mẽ hơn. Ngoài ra, việc đánh giá điểm câu chuyện không nên được thực hiện bởi một cá nhân, mà là kết quả của nỗ lực tập thể . Đối với những câu chuyện ít phức tạp hơn, thường có một thỏa thuận nhanh chóng. Đối với những câu chuyện khó khăn hơn, nhóm sẽ đi kèm với một kết quả mà hầu hết các thành viên sẽ đồng ý, và do đó hoàn toàn tính đến mức độ kỹ năng tập thể của nhóm.

Cuối cùng, việc đánh giá câu chuyện được thực hiện tại một thời điểm khi các bài tập trong nhóm không nhất thiết phải được quyết định. Đây là một đối số nữa không tính đến cấp độ kỹ năng cá nhân. Để lập kế hoạch chạy nước rút, bạn sẽ lấy năng lực điểm câu chuyện của nhóm, đây là con số sẽ phát triển dựa trên số liệu hiệu suất thực tế, để nó tự điều chỉnh theo cấp độ kỹ năng toàn cầu của nhóm của bạn.

Để kết luận, khả năng cá nhân không nên được tính đến cho ước tính. Nhưng ngay cả khi nó sẽ được thực hiện, do các ước tính tập thể, và sự mạnh mẽ của phương pháp tương đối, nó sẽ không quan trọng lắm.

Câu trả lời chính tắc là bạn không nên thay đổi ước tính cho mỗi nhà phát triển. Điều đó có nghĩa là bạn sẽ kiếm được nhiều điểm hơn trong mỗi lần chạy nước rút so với các đồng nghiệp của mình và điều đó tốt vì các điểm đo vận tốc của đội chứ không phải nhà phát triển. Doanh nghiệp có thể ước tính nhóm sẽ sản xuất bao nhiêu để có được những kỳ vọng sơ bộ về việc giao hàng và mọi thứ đều tuyệt vời.

Tuy nhiên, điều đó gây ra tất cả các loại rắc rối trong thực tế. Điều gì xảy ra nếu bạn đi nghỉ tuần đó? Điều gì xảy ra khi thời gian xem xét xuất hiện và bạn nhận ra mình đang tạo ra 200% điểm câu chuyện trung bình cho 110% mức lương trung bình? Điều gì xảy ra khi doanh nghiệp bắt đầu nghĩ rằng vận tốc nhóm chia cho mọi người thực sự là một xấp xỉ chính xác? Điều gì xảy ra khi doanh nghiệp nhận ra bạn đang sản xuất nhiều lỗi hơn so với các đồng nghiệp của bạn (trong khi bỏ qua bạn sản xuất nhiều chức năng hơn)? Điều gì tạo nên những câu chuyện "cỡ cắn" khi con người có những vết cắn đa dạng như vậy?

Những gì tôi đã tìm thấy trong sự nghiệp của mình là nó hầu như không thành vấn đề. Quá trình là để phục vụ bạn, không phải ngược lại. Nếu org của bạn cần đánh giá nếu các nhà phát triển bị quá tải, thì điểm câu chuyện trên mỗi nhà phát triển là một giải pháp tốt. Nếu org của bạn cần đánh giá vận tốc của đội, thì điểm câu chuyện dev-agnellect sẽ cung cấp một bức tranh rõ ràng hơn. Tuy nhiên, chúng luôn luôn là một xấp xỉ, và sẽ luôn bị lạm dụng và giải thích sai.

Cuối cùng, họ đã tạo ra các điểm cho một quy trình tạo nên mà bạn cần thích nghi với môi trường của mình .

TL; DR
Chúng ta nên luôn luôn cho rằng chỉ những nhà phát triển có năng lực mới được chỉ định cho một câu chuyện cụ thể.

Năng lực (hoặc thiếu nó) không phải là một sự xúc phạm. Nó chỉ đơn giản là một thước đo hợp lý cho các kỹ năng của một nhà phát triển, người không bị tụt lại phía sau cũng không có kinh nghiệm đặc biệt.

Đây có thể là một vấn đề của cách tiếp cận của một công ty cụ thể. Tôi đã thấy các công ty ước tính điều chỉnh cho các nhà phát triển cụ thể. Tôi cũng đã thấy các công ty thực thi một hệ thống trong đó ba nhà phát triển được chọn ngẫu nhiên đưa ra ước tính câu chuyện trước khi giao gần như ngẫu nhiên một nhà phát triển (không phải một trong ba nhà phát triển ban đầu) cho nhiệm vụ.

Mọi hệ thống đều có thể hoạt động, mọi hệ thống đều có thể thất bại. Câu hỏi không phải là quá nhiều hệ thống nào tốt hơn, mà là những sai sót mà công ty có thể / sẵn sàng giải quyết .

Về nguyên tắc, không nên đưa vào thời gian nghiên cứu để thành thạo ngôn ngữ / khung. Tiếp tuyến nhỏ: mặc dù chúng không nên tồn tại trong một thế giới lý tưởng, nên bao gồm thời gian nghiên cứu cho các trở ngại cụ thể theo dự án hoặc theo câu chuyện.

Có nhiều lý do để làm như vậy, nhưng tôi tin rằng phương pháp này nói chung là một lựa chọn tốt hơn, bởi vì nó đúng với ý định ước tính khối lượng công việc. Đây có thể chỉ là vấn đề của quan điểm của tôi, hơn là khách quan. Tôi không thể nói chắc chắn.

Thời gian học là cá nhân . Đó là trong phạm vi cho một nhà phát triển cụ thể, những người cần phải làm việc trên một công nghệ cụ thể. Nó không liên quan khi đánh giá khối lượng công việc của một câu chuyện người dùng, vì một câu chuyện người dùng chỉ nằm trong phạm vi của ứng dụng (và công nghệ mà nó sử dụng).

Thời gian học nói chung không chồng. Hãy nói rằng tân binh của chúng tôi biết rất ít về C # và chúng tôi ước tính rằng anh ấy cần thêm ba ngày để tìm ra môi trường trước khi anh ấy có thể thực hiện công việc. Như thường thấy ở nhiều công ty tôi từng làm việc, chúng tôi hiện đang tham gia một cuộc họp nơi chúng tôi dự kiến ​​sẽ ước tính một số câu chuyện của người dùng (cá nhân). Ví dụ, giả sử chúng ta có ba câu chuyện để giải quyết.

• Chúng ta có thêm ba ngày cho mỗi câu chuyện không? Nếu cả ba câu chuyện đều có trọng tâm kỹ thuật tương tự nhau, điều đó có nghĩa là tân binh sẽ không thực sự cần thêm thời gian cho câu chuyện thứ hai và thứ ba. Chúng tôi đã đánh giá quá cao công việc trong sáu ngày.
• Chúng ta có thêm một ngày cho mỗi câu chuyện không? Điều này cũng không đúng. Nếu cuối cùng chúng ta chỉ giao cho tân binh này vào một trong ba câu chuyện, thì chúng ta đã trao đổi với anh ta hai ngày cần thiết cho thời gian học tập; và chúng tôi đã dành hai ngày không cần thiết cho thời gian nghiên cứu cho (các) nhà phát triển khác.
• Chúng ta có thêm ba ngày vào một câu chuyện không? Làm thế nào chúng ta có thể đảm bảo rằng câu chuyện này sẽ được xử lý trước hai người kia? Toàn bộ quan điểm của việc tạo các câu chuyện người dùng riêng biệt là các câu chuyện thường có thể được xử lý độc lập với nhau. Tính chính xác của ước tính của chúng tôi bây giờ dựa trên cả giả định rằng tân binh của chúng tôi sẽ thực hiện công việc, cộng với thứ tự anh ấy được giao những nhiệm vụ đó (nếu có vấn đề, ví dụ nếu khối lượng công việc kết hợp vượt qua một lần chạy nước rút).

Lưu ý :
Có những trường hợp khác, nơi mà thời gian học tập làm chồng, ví dụ như nếu ba câu chuyện trên một cách hoang dại chủ đề khác nhau và đòi hỏi kỹ năng khác nhau.
Nhưng để tìm hiểu xem đây có phải là trường hợp hay không, chúng ta sẽ cần phải xem xét cả ba câu chuyện cùng một lúc, từ từ bắt đầu vi phạm nguyên tắc có câu chuyện người dùng độc lập . Nếu chúng tôi đã giải quyết các ước tính này trong các cuộc họp riêng biệt, có thể với các nhà phát triển khác nhau có mặt; chúng tôi sẽ không thể đánh giá chính xác sự chồng chéo giữa các câu chuyện.

Bởi vì chúng tôi không thể đảm bảo những câu chuyện nào thực sự sẽ được thực hiện (khách hàng có thể từ chối một ước tính lớn) và ai sẽ được chỉ định cho họ, cố gắng tính toán cho một nhà phát triển cụ thể được gán cho một câu chuyện cụ thể là vô ích. Nó chỉ kết thúc làm vẩn đục nước.

Thay vào đó, chúng ta nên đưa ra ước tính về khối lượng công việc giả định rằng tân binh đã được đưa lên tốc độ (và do đó là một nhà phát triển tương đương với đồng nghiệp của anh ta).
Ước tính như vậy là không tin tưởng của nhà phát triển và do đó, tính chính xác của ước tính do đó không biến động tùy thuộc vào việc nhà phát triển cuối cùng được chỉ định vào câu chuyện.

Lưu ý
Vẫn có liên quan để xác nhận rằng một nhà phát triển cụ thể có thể cần thêm thời gian để nghiên cứu trước khi có thể giải quyết một câu chuyện cụ thể. Đó vẫn là một sự cân nhắc rất phù hợp. Nhưng sự cân nhắc này không nên gắn liền với câu chuyện , mà là sự phân công của nhà phát triển cụ thể này cho câu chuyện đặc biệt này.

Nhưng, khi tôi bắt đầu, điều này có thể khác nhau giữa các công ty. Một số công ty có thể không bận tâm về thời gian nghiên cứu (ví dụ: nếu nhà phát triển chắc chắn sẽ phải học cách sử dụng công nghệ này). Những người khác có thể phụ thuộc rất nhiều vào tính chính xác của các ước tính này, vì nó ảnh hưởng đến việc thanh toán cho khách hàng.

Cuối cùng, đó là vấn đề chọn chất độc của bạn. Không có cách tiếp cận nào trong số này được đảm bảo chính xác hơn các phương pháp khác.

Đây là một chủ đề phức tạp, và có những cuộc tranh luận thường xuyên về chủ đề này. Tôi không thích khái niệm ý kiến ​​"kinh điển" về vấn đề này: có nhiều ý kiến ​​khác nhau có giá trị. Nhưng có những giá trị, nguyên tắc và thực tiễn hỗ trợ nên hướng dẫn cách tiếp cận.

Sau đây là dựa trên ý kiến ​​của riêng tôi làm việc với các nhóm scrum trong hơn 10 năm. Nhưng đó chỉ là ý kiến ​​của tôi.

1. Điểm câu chuyện như một phương pháp dự báo Mục đích ban đầu của các điểm câu chuyện là tìm ra một phương pháp nhanh chóng để ước tính nỗ lực với mục đích dự báo những gì một nhóm có thể hoàn thành trong một khoảng thời gian. Một số trạng thái "độ sáng" cho biết các điểm chỉ được sử dụng để dự báo phạm vi dài hạn (ví dụ: trên một bản phát hành) và không xác định công suất ở cấp độ nước rút. Ngoài ra, khái niệm là các đội đang áp dụng "kích thước tương đối" dựa trên các giá trị lịch sử (Effort X tương tự như Effort B, được 3 điểm). Điều này tăng tốc quá trình ước tính để các nhóm không phải chia nhỏ công việc trong tương lai thành các gói công việc chi tiết và áp dụng hàng giờ cho tất cả các nhiệm vụ. Các nhóm hiệu suất cao cố gắng phát triển tất cả các công nhân kỹ thuật thành các thành viên rất có năng lực ở các cấp độ kỹ năng tương tự. (Khái niệm này sẽ được khám phá nhiều hơn ở điểm số 4) Khi đạt được điều này, thì mức độ kỹ năng cá nhân thực sự không phải là một biến số trong kích thước. NHƯNG: Thường mất khá nhiều thời gian và nỗ lực phối hợp để đạt được mục tiêu đó. VẬY ... chúng ta phải làm gì trước khi đến đó?

2. Giờ làm việc xác định khả năng chạy nước rút: Theo cùng một "ngôi sao sáng" nói rằng các điểm được sử dụng để dự báo dài hạn, họ cũng đề xuất rằng Giờ nhiệm vụ được sử dụng để xác định khả năng chạy nước rút, thay vì điểm. Theo tôi, điều đó cũng tốt, nhưng tôi sẽ nói rằng khi tôi đã giúp các đội huấn luyện viên "Hiệu suất cao", các kỹ năng san bằng của họ trung bình đến nơi họ có thể xác định chính xác những gì họ có thể hoàn thành trong lần chạy nước rút chỉ bằng Story Points . Một lần nữa, đó có thể là một mục tiêu mà chúng tôi phấn đấu, nhưng các đội mới hơn chưa sẵn sàng cho điều đó. Do đó, bạn có thể tìm thấy trong một lần chạy nước rút một Câu chuyện với 2 điểm có 12 giờ nỗ lực và một điểm khác với 25 giờ nỗ lực. Vậy bạn làm gì? Một số người mà tôi gọi là "những người theo chủ nghĩa thuần túy" sẽ nói rằng kích thước Câu chuyện (tính theo điểm) nên không theo thời gian. Những người khác không đồng ý. Đọc qua logic trên mục số 3 và xem những gì bạn nghĩ.

3. Kể chuyện theo sự đồng thuận: Áp dụng khối lượng, ẩn số, độ phức tạp, kiến ​​thức

Vì vậy, các nhóm xem xét một phần công việc và cần thống nhất về các điểm sẽ là ủy quyền cho Mức độ nỗ lực. Đúng? Giả sử rằng tất cả các kỹ năng đều bình đẳng, thì sự đồng thuận là dễ dàng đạt được. Nhưng thường thì các đội có một anh chàng là một bậc thầy về Java, một người khác không giỏi về Java (có thể cô ấy là người C # hoặc .Net hoặc Cobol và đang học Java). Vì vậy, nhiệm vụ X cho Bob rất đơn giản. Đối với Jane, điều đó khó khăn hơn.

Các nhóm Agile cố gắng thúc đẩy quyền sở hữu mã tập thể và phát triển / mở rộng chuyên môn. Vì vậy, chúng tôi thường không phân công câu chuyện cho mọi người dựa trên chuyên môn của họ: chúng tôi thích các nhóm cùng nhau làm việc trên các câu chuyện và học hỏi cùng nhau. Điều này phù hợp với khái niệm "làm chậm để tăng tốc": nếu chúng ta dành thời gian để cho Jane trải nghiệm với Java, trong khi điều này có thể làm chúng ta chậm lại, sau này chúng ta sẽ có nhiều nhà phát triển Java có năng lực hơn. Trên thực tế, nếu chúng ta chỉ có MỘT chuyên gia Java và mọi người làm việc trên các lĩnh vực chuyên môn của riêng họ, chúng ta sẽ tạo ra một tình huống có nhiều "điểm thất bại" tiềm năng. Điều gì xảy ra trong giai đoạn nước rút khi 90% công việc là Java, nhưng Bob (chuyên gia Java của chúng tôi) bị ốm hoặc đang trong kỳ nghỉ? Bằng cách mở rộng các kỹ năng, chúng tôi loại bỏ các tắc nghẽn tiềm năng và giảm rủi ro. Với ý nghĩ đó: Khi nhóm nghiên cứu xem xét một câu chuyện, họ nên có một vài khái niệm trong đầu khi định cỡ. Bạn có thể nghĩ về chữ viết tắt Vucks để ghi nhớ điều này.

Khối lượng: Một số nỗ lực khá đơn giản, nhưng đòi hỏi một khối lượng lớn các nhiệm vụ lặp đi lặp lại. (Tôi đã có một anh chàng phải sao chép và định dạng lại hơn 50 bảng, người nói rằng đó là 1 điểm vì nó đơn giản. Nhưng khi suy nghĩ, nhóm đã nhận ra rằng trong khi nó dễ dàng, nó đã tốn thời gian và có một khối lượng lớn các bảng để được di chuyển và tối ưu hóa. Vì vậy, chúng tôi đã phải điều chỉnh lại điểm do khối lượng công việc)

Những điều chưa biết: Đôi khi chúng tôi nghĩ rằng chúng tôi biết phải làm gì, nhưng chúng tôi cũng xác định một số điều chưa biết - những điều này đại diện cho RỦI RO . Và điều này ngụ ý rằng chúng tôi có thể gặp phải các sự cố không mong muốn mà chúng tôi phải giải quyết, thiết kế lại hoặc thử một giải pháp khác.

Độ phức tạp: Điều này là khá rõ ràng. Một số giải pháp phức tạp về mặt kỹ thuật. Chúng tôi biết chính xác những gì cần làm, nhưng nó đòi hỏi chuyên môn kỹ thuật. Sự phức tạp cũng tiềm ẩn một số rủi ro, phải không? Vì vậy, ngay cả khi tất cả chúng ta đều có các kỹ năng như nhau, sự phức tạp về kỹ thuật ngụ ý rằng chúng ta có thể gặp phải những thách thức không lường trước được. Vì vậy, chúng tôi có thể làm cho câu chuyện này lớn hơn.

Kiến thức: Chúng ta có THỰC SỰ biết những gì chúng ta đang giải quyết không? Đôi khi khách hàng không hoàn toàn rõ ràng về giải pháp họ muốn và chúng tôi đang thử nghiệm một chút. Hoặc có lẽ chưa ai từng thực hiện giải pháp này (công nghệ mới chưa từng được sử dụng trước đây) và vì vậy chúng tôi không biết những gì chúng tôi không biết.

Theo tôi, mỗi một trong những cân nhắc này thực sự là một proxy cho thời gian kéo dài. Câu chuyện dễ, nhiều âm lượng? Sẽ mất nhiều thời gian hơn, hoặc chúng ta cần chia câu chuyện. Không biết? Thêm rủi ro, nghiên cứu, thử nghiệm, có thể mất nhiều thời gian hơn hoặc chúng ta cần phải chia tách câu chuyện. Phức tạp? Đã thêm rủi ro, cần sửa lỗi, thiết kế lại, v.v ... nên có thể mất nhiều thời gian hơn. Không biết chúng ta có Kiến thức cần thiết không? Chúng tôi có thêm rủi ro, có thể cần thử nghiệm, v.v., vì vậy có thể mất nhiều thời gian hơn ...

Thấy nơi đang tới không? Vì vậy, trong khi khái niệm về các điểm câu chuyện khiến chúng ta không nghĩ về thời lượng khi ước tính, mặt khác, sẽ là phi logic khi có một câu chuyện 1 điểm mà chúng ta có thể hoàn thành trong 4 giờ và một câu chuyện 1 điểm khác đơn giản nhưng sẽ mất 2 tuần.

4. Các nhóm có hiệu suất cao loại bỏ Silo & Nút cổ chai: Bởi vì các đội cố gắng tăng cấp cho tất cả các thành viên, đôi khi họ có các thành viên ít kinh nghiệm hơn thực hiện các thử thách mới hoặc sẽ ghép mã để chia sẻ kiến ​​thức để cải thiện thành một nhóm. Như đã đề cập trước đây, đây là điều cần thiết nếu nhóm sẽ đạt được mức Hiệu suất cao thực sự.

Vì vậy, nếu Jane tình nguyện thực hiện nỗ lực Java đó và điều đó sẽ khiến nỗ lực đó gấp 2 hoặc 3 lần thời gian của cùng một nỗ lực nếu Bob làm điều đó, bạn sẽ làm gì? Theo thời gian, các nhóm của tôi đã giải quyết việc định cỡ các câu chuyện dựa trên mức độ nỗ lực (LOE) / Vucks cho những người làm việc nỗ lực. Thật vô nghĩa khi Bob, nhóm Chuyên gia, nói rằng "đó là 1" khi đối với Jane, sẽ không dễ dàng và phải mất một tuần để hoàn thành, cộng với yêu cầu một số thời gian của Bob để xem xét mã hóa và mã hóa cặp. Do đó, chúng tôi đã tìm ra những điểm đó để phản ánh LOE thực sự. Lần tiếp theo, một câu chuyện tương tự xuất hiện, số 8 đối với Jane trước đó đã trở thành 5. Cuối cùng, mọi người đều đồng ý rằng đó là một điều dễ dàng 3. Vào thời điểm đó, chúng tôi biết rằng chúng tôi đang phát triển như một đội.

TLD

Không, nhưng có lẽ không phải vì lý do bạn nghĩ.

Phiên bản dài

Nhiều câu trả lời khác đã giải thích rằng Điểm câu chuyện nên được tính toán hoàn toàn liên quan đến các phần công việc khác. Điều này là hoàn toàn đúng. Vì Story Points ước tính khối lượng công việc thay vì thời gian cần thiết để hoàn thành nó, nên việc đưa ra Story Points dựa trên một cá nhân là vô nghĩa.

Ví dụ: (một trong những mục yêu thích của tôi), hãy xem xét nhiệm vụ của bạn "Đào một cái lỗ". Bạn có thể ước tính điều này dựa trên số lượng trái đất sẽ bị loại bỏ hoặc thời gian bạn sẽ phải loại bỏ trái đất. Bạn tôi đào toàn bộ với tốc độ 3 mét mỗi giờ, tôi có một máy đào cơ khí lớn để tôi có thể quản lý 100! Hằng số duy nhất là lượng trái đất - do đó, đó là thứ chúng ta sử dụng làm đơn vị ước tính.

Tuy nhiên, một lý do thứ hai (và theo quan điểm của tôi quan trọng hơn) về việc giảm khả năng của nhà phát triển để ước tính các câu chuyện của người dùng là thực tế là hầu hết mọi câu chuyện của người dùng sẽ có thể được thực hiện bởi nhiều người.

Bạn có thể có một kiến ​​trúc sư, một nhà phát triển, một người thử nghiệm, có lẽ là một nhà phát triển thứ hai để làm UI. Trước khi câu chuyện người dùng của bạn được đánh dấu là Xong (được triển khai và thực hiện lý tưởng), nhiều người khác nhau sẽ làm việc với nó. Đột nhiên, ý tưởng ước tính dựa trên nhà phát triển được đề cập rất ít ý nghĩa, cách duy nhất để ước tính chính xác bao nhiêu nỗ lực sẽ có từ nhóm là đo vận tốc của đội và ước tính công việc để nhóm hoàn thành.

Không có "tôi" trong đội và hoàn toàn không có tôi trong kế hoạch nhanh nhẹn!