Nhóm đang ước tính điểm câu chuyện, doanh nghiệp muốn thời gian thực tế

Tôi chắc chắn đây không phải là một chủ đề hiếm gặp. Chúng tôi có hai nhóm scrum đang thực hiện công việc ước tính câu chuyện của người dùng bằng cách sử dụng điểm câu chuyện (các chòm sao hiện tại chỉ khoảng 8 tháng, mặc dù các thành viên trong nhóm có nhiều năm kinh nghiệm về scrum). Nhưng thật khó cho bộ phận kinh doanh của công ty liên quan đến câu chuyện của người dùng; họ muốn các đơn vị thời gian thực tế (hoặc "công thức chuyển đổi điểm câu chuyện thành giờ") để họ có thể lập kế hoạch khi nào mọi thứ sẽ sẵn sàng ( "chúng tôi cần biết khi nào chúng tôi có thể nói với khách hàng rằng Tính năng X sẽ được sản xuất " ).

Tôi, và những người tiền nhiệm bậc thầy của tôi, tất nhiên đã giải thích rằng "không có mối quan hệ nhất định giữa điểm câu chuyện và thời gian thực tế" và rằng "điểm câu chuyện được sử dụng để xác định đội có thể chạy được bao nhiêu trong một lần chạy nước rút", và tôi chắc chắn bạn có thể đoán mức độ hài lòng của họ với câu trả lời đó. Họ vẫn muốn biết, trong thời gian theo lịch, khi chúng ta sẽ đến câu chuyện người dùng thứ 27 đó trong hồ sơ tồn đọng.

Trong mọi trường hợp, tôi đã biên soạn một số thống kê, và ước tính SP của chúng tôi chuyển thành dữ dội kết quả thời gian dành thực tế khác nhau (được đo bằng phần mềm bảng scrum của chúng tôi, mà giữ theo dõi bao nhiêu thời gian vé chi tiêu trong cột "làm việc trên" ). Đối với các câu chuyện của người dùng 1-SP, tất nhiên có sự thiên vị nặng nề đối với các khoảng thời gian rất ngắn (với sự bùng nổ thường xuyên), nhưng đặc biệt đối với các câu chuyện 2-SP, chúng ở khắp mọi nơi: có hệ số 20 giữa hoàn thành "nhanh nhất" và "chậm nhất". Đối với các câu chuyện 3, 5 và 8-SP, mức độ lây lan cũng nhiều hơn hệ số 2.

Điều này cho thấy rằng (a) nhóm cần nhất quán hơn nhiều trong việc ước tính các câu chuyện của người dùng về độ phức tạp tương tự (nên là gì) và (b) nhóm cần cải thiện độ chính xác của mình trong báo cáo thời gian (ví dụ: nhớ chuyển vé ra khỏi "làm việc" khi họ đang họp, ăn trưa hoặc chơi đá bóng).

Tôi có kế hoạch cải thiện cả (a) và (b) nhưng tôi cảm thấy điều đó là chưa đủ, rằng doanh nghiệp mong đợi "sự cụ thể hơn" so với những gì các sáng kiến ​​này sẽ mang lại.

Một số chiến lược tốt trong việc xoa dịu phía doanh nghiệp là gì , để họ sẽ không can thiệp quá nhiều vào cách chúng tôi làm việc (ví dụ: bằng cách áp dụng sử dụng theo dõi thời gian riêng biệt, IMHO sẽ bị câm vì trong mọi trường hợp sẽ kém chính xác hơn theo dõi "tự động" hiện tại), đồng thời cho phép họ có được một số biện pháp cụ thể hóa khi nào câu chuyện sẽ được thực hiện?

(Trong lịch sử, trong quá trình lập kế hoạch, chúng tôi đã chia các câu chuyện của người dùng thành các mục công việc được ước tính riêng trong thời gian làm việc thực tế , nhưng những gì tôi đang nói ở đây là các câu chuyện của người dùng ở nhật ký sau sẽ không có mức độ chi tiết hoặc phá vỡ đó -xuống.)

Cập nhật: Người quản lý của tôi có linh cảm rằng có một loại phân phối đường cong chuông theo giờ dành cho mỗi câu chuyện, nhưng dữ liệu tôi đối chiếu và các biểu đồ mà anh ta đã hoàn toàn không cho anh ta biết về khái niệm đó. :-)

Bạn đã đúng, không có một công thức để chuyển đổi điểm câu chuyện thành giờ. Bạn có thể nhận được một chuyển đổi khá mất mát từ mét sang feet, và ngược lại, nhưng bạn không thể nói câu chuyện 3 điểm sẽ mất X giờ, vì vậy câu chuyện 5 điểm sẽ mất Y giờ (giải quyết cho Y).

HorusKol đã chạm vào phần tiếp theo này. Vận tốc nước rút của bạn như một đội có thể giúp đỡ với các sản phẩm dài hạn hơn. Giả sử nhóm của bạn ở mức 50 điểm mỗi lần chạy nước rút và mỗi lần chạy nước rút là 2 tuần. Vì vậy, 50 điểm cho mỗi lần chạy nước rút nhân với 50 tuần trong một năm (giả sử mọi người nghỉ 2 tuần để nghỉ phép) thì nhóm hiện tại của bạn có thể thực hiện tối đa 2.500 điểm trong 12 tháng.

Vì vậy, doanh nghiệp đến với bạn với 170 điểm truyện và sử thi. Chia cho vận tốc lịch sử của đội là 50 điểm (trung bình của mỗi lần chạy nước rút cho đến nay) và bạn nhận được 3,4 lần chạy nước rút. Vì chúng tôi đang ước tính, làm tròn tối đa 4 lần chạy nước rút: 8 tuần. Hai tháng, về cơ bản. Tôi cũng thích thực hiện 3-4 lần chạy nước rút cuối cùng và lấy một ước tính khác. Giả sử nhóm của bạn trong 3 lần chạy nước rút gần đây đã thực hiện lần lượt 53, 67 và 55 điểm. Tính ra là 58 điểm, với tốc độ đó là 2,9 lần chạy nước rút - về cơ bản là 3 lần chạy nước rút. Có vẻ như dòng thời gian của bạn cho 170 điểm đó trông giống như 6 đến 8 tuần.

Nói với doanh nghiệp 2 tháng. Đừng nói với họ 6-8 tuần, vì họ sẽ chỉ nghe "6 tuần". Thậm chí đừng nói với họ 8 tuần, vì hầu hết các tháng có khoảng 4,5 tuần trong đó và khi mọi người nghe thấy "4 tuần", họ lập tức nghĩ "1 tháng". Khi ước tính đạt khoảng 4 tuần, nó sẽ trở thành 1 tháng. Sau đó chỉ làm việc trong tháng. Nếu bạn đạt được một năm hoặc hơn thì thành thật chỉ cần không ước tính công việc đó. Nó là vô nghĩa. Quá nhiều có thể thay đổi trong một năm.

Tôi đã thấy đây là một cách khá chính xác để chuyển đổi điểm câu chuyện thành giờ ... dù sao thì thời gian cũng vậy.

Bạn sẽ nhận được một sự khác biệt trong khoảng thời gian cần thiết để hoàn thành các câu chuyện riêng lẻ. Một số nhà phát triển làm việc nhanh hơn những người khác. Đặt tất cả các điểm câu chuyện vào một cái bát và bật máy xay để làm việc với mức trung bình giúp giảm bớt những mâu thuẫn đó.

Ồ, và đừng quên phần quan trọng nhất:

Làm tròn lên. Luôn luôn.

Bạn có thể đã có một số chuyển đổi vốn có từ điểm câu chuyện sang ước tính thời gian - làm thế nào để bạn quyết định rằng bạn đã chọn đủ công việc cho lần chạy nước rút của mình? Có lẽ bạn đã nói điều gì đó như "nhóm có thể xử lý 20 (hoặc 40 hoặc bất cứ điều gì) một tuần". Sau một vài lần chạy nước rút, bạn sẽ có thể sửa đổi điều đó dựa trên sự hoàn thành - vì vậy bây giờ là 15 hoặc 25 (hoặc 35 hoặc 50 hoặc ...) chỉ ra một lần chạy nước rút - đây là vận tốc của đội bạn .

Đối với các câu chuyện của người dùng 1 SP, tất nhiên có sự thiên vị nặng nề đối với các khoảng thời gian rất ngắn (với sự nổ tung thường xuyên), nhưng đặc biệt đối với các câu chuyện 2 SP, chúng ở khắp mọi nơi: có hệ số 20 giữa hoàn thành "nhanh nhất" và "chậm nhất". Đối với các câu chuyện 3, 5 và 8-SP, mức độ lây lan cũng nhiều hơn hệ số 2.

Một số thay đổi về thời gian để hoàn thành các câu chuyện cụ thể là ổn trong các giá trị điểm - vận tốc theo dõi sự không chắc chắn đó bằng cách là trung bình trong lịch sử gần đây.

Tuy nhiên, bạn có thể cần xem xét kỹ lưỡng cách bạn chỉ định điểm, đặc biệt là những con trỏ 2 điểm đó nếu bạn đang có một biến động lớn như vậy. Các tác vụ điểm cao hơn được cho là không chắc chắn (và nên được chia nhỏ) - nhưng các tác vụ nhỏ như con trỏ 2 nên khá nhất quán.

Vì tất cả các nhiệm vụ được gán cùng một giá trị điểm cần có nỗ lực tương tự, nên không có nghĩa là có một khoảng thời gian như vậy để hoàn thành.

Vì vậy, hãy nhìn vào con trỏ 2 mất nhiều thời gian nhất trong quá trình hồi tưởng của bạn. Tại sao một cái gì đó có lẽ nên có thể biến một buổi sáng biến thành một khẩu hiệu 10 ngày? Có thể một cái gì đó đã được gắn cờ vào buổi sáng đầu tiên để nói rằng "điều này cần phải trở thành và hoành tráng và được chia thành các nhiệm vụ nhỏ hơn"? Tất nhiên, ngay khi điều đó xảy ra, tất nhiên, công việc làm thêm cần được đưa vào tồn đọng và không can thiệp vào phần còn lại của nước rút.

Ngoài ra, hãy thử và xem nhóm đánh giá thấp mặt hàng đó như thế nào - bạn có thể làm tốt hơn đối với các mặt hàng trong tương lai đã xem xét nó không?

Có, ngày giao hàng sẽ được đẩy tương ứng hoặc danh sách các tính năng cho bản cập nhật có thể được sửa đổi để việc phân phối không bị ảnh hưởng. Nhưng mục đích là để cải thiện các ước tính điểm trong tương lai, và cũng để có được một dòng thời gian chính xác hơn.

Nó giống như dự báo thời tiết: càng xa, càng kém tin cậy. Đó là một sự tương tự mọi người sẽ hiểu. Lỗi trong ước tính cộng lại.

Bán hàng phải học cách nói chuyện theo thuật ngữ Scrum cho khách hàng. Scrum không có ý nghĩa trong sự cô lập, nó được cho là sẽ được áp dụng theo chiều dọc trong toàn công ty và tốt nhất là mở rộng vào lĩnh vực khách hàng.

Bạn là một nhóm phát triển nên vững chắc về điều này. Bạn có thể cung cấp cho họ những kỳ vọng và phỏng đoán nhưng đừng để đó là những cam kết kéo dài một lần chạy nước rút.

Tôi làm một vài điều khi tôi nhận được câu hỏi như thế này.

Đầu tiên, tôi trả lời các câu hỏi về tương lai bằng cách mô tả quá khứ. Tôi sẽ nói một cái gì đó giống như chúng ta vượt qua khoảng hai trong số những câu chuyện này mỗi tuần. Vì vậy, nếu không có gì thay đổi, chúng tôi hy vọng sẽ được thực hiện với câu chuyện 27 trong khoảng 14 tuần.

Thứ hai, tôi muốn khách hàng đối mặt với mọi người phải chịu trách nhiệm về lịch giao dịch và rủi ro. Tôi sẽ nói một cái gì đó giống như Ghi nhớ, nhóm kỹ thuật làm việc trên cơ sở ước tính 50/50. Nếu không có gì thay đổi, có 50/50 cơ hội tính năng 27 đã sẵn sàng trong 14 tuần. Có lẽ bạn không muốn báo cáo điều gì đó với mức độ rủi ro đó cho khách hàng. Bạn có muốn tôi đưa ra một ước tính mà chúng tôi có, nói, tin tưởng 90% vào? Sau đó, bạn cần xem lại bằng chứng lịch sử của mình và nói điều gì đó như: Có 90% khả năng câu chuyện 27 sẽ được thực hiện trong 25 tuần .

Cuối cùng, hãy nhắc nhở đồng nghiệp của bạn rằng một khi anh ta đưa ra một cam kết bên ngoài, công ty sẽ bị chèn ép. Thực hiện những lời hứa bên ngoài về câu chuyện số 27 sẽ lấy đi tất cả sự nhanh nhẹn của công ty. Sau đó, bạn sẽ được cam kết cho một quá trình hành động cụ thể. Bất cứ khi nào ai đó đến với bạn với một yêu cầu thay đổi, bây giờ bạn cần trả lời Chúng tôi đã cam kết hoàn thành câu chuyện 27 trước ngày x. Tôi chỉ có thể thực hiện thay đổi này nếu bạn liên hệ với khách hàng và nói với họ rằng cam kết của chúng tôi không còn hiệu lực. Về cơ bản, thực hiện các cam kết cụ thể cho công việc hơn một tháng hoặc lâu hơn trong tương lai đi kèm với rất nhiều vấn đề.

Bạn đã có một chuyển đổi (rất thô sơ):
Chạy nước rút Scrum là (thông thường) hai tuần.
Bạn biết bạn có thể hoàn thành, giả sử, khoảng 20 điểm tính năng trong hai tuần đó (hoặc cách khác bạn xác định những gì & bao nhiêu tính năng được đóng gói trong một lần chạy nước rút?) Và lần chạy nước rút trước đó của bạn xác nhận ước tính đó (giả sử bạn đã hoàn thành các tính năng đáng kể 18, 21, 23, 19 và 20 điểm trong năm lần chạy nước rút gần đây nhất).

Giả sử tính năng X (và tất cả các phụ thuộc của nó) đã được ước tính là 47 điểm câu chuyện.
Vì vậy, bạn có thể ước tính rằng nếu bạn thực hiện điều đó ở mức ưu tiên cao nhất, bạn nên mất khoảng 3 lần chạy nước rút, tức là 6 tuần (nhưng hãy đảm bảo rằng các ước tính của bạn có tính đến ai có thể làm gì - nếu 35 điểm đó là DB hoạt động và bạn chỉ có trên anh chàng DB, bạn cần xem lại vận tốc ước tính của mình để tính đến điều đó).

Điều đó nói rằng - thông báo chắc chắn rằng đó là những ước tính thô thiển - có một lý do tại sao nước rút là hai tuần chứ không phải sáu. Càng nhiều thứ mà forcast của bạn cần bảo hiểm, càng không chắc chắn và lỗi xảy ra. Cũng liên lạc chắc chắn về chi phí - nghĩa là điều này có nghĩa là đặt nhiệm vụ lên ưu tiên hàng đầu, nghĩa là không có nhiệm vụ nào khác được thực hiện. Nếu không, bạn có thể gặp phải tình huống:

"Khi nào tính năng Y sẽ được thực hiện?"
"Nếu chúng ta tập trung vào nó tiếp theo ... 12 tuần"
" 12 tuần?!? Bạn nói sẽ mất 4."
"Có, nhưng bạn đã bảo chúng tôi ưu tiên tính năng X , mà chúng tôi đã nói với bạn rằng sẽ ràng buộc tất cả các tài nguyên của chúng tôi và mất 8 tuần."
"Bạn không thể làm việc trên tính năng X và tính năng Y cùng một lúc?"
" rên rỉ "

Sprint được xác định thời gian, nói 2 tuần. Bạn không thể dự đoán một số câu chuyện sẽ được thực hiện hơn 2 lần chạy nước rút, giống như bạn có lần chạy nước rút hiện tại và lần chạy nước rút tiếp theo. Tôi giả sử bạn đã chuẩn bị những câu chuyện được thảo luận với nhóm cho lần chạy nước rút tiếp theo và được doanh nghiệp ưu tiên. Vì vậy, tốt nhất bạn có thể nói chắc chắn là 4 tuần làm việc tiếp theo.

Mọi thứ hơn 4 tuần có thể thay đổi và doanh nghiệp có thể đưa ra lộ trình không được thiết lập theo giờ. Điều đó nên được lên kế hoạch cho mỗi lần chạy nước rút, giả sử một số sử thi1 (sử thi như trong các câu chuyện được nhóm lại) và epic2 nên được thực hiện trong lần chạy nước rút 47 và 48 và epic3 nên được thực hiện trong lần chạy nước rút 49. Sử thi tôi ước tính khoảng vài giờ xem nếu một hoặc hai sẽ phù hợp với nước rút, dòng thời gian sẽ trượt. Nếu các tính năng không hoạt động, doanh nghiệp phải cắt giảm phạm vi hoặc chấp nhận các giải pháp không hoàn hảo có thể được cải thiện sau này khi cần (điều đó phải nhanh nhẹn, nắm lấy thực tế thay vì theo kế hoạch).

Bạn có thể tạo biểu đồ Gantt đẹp (đó là những gì doanh nghiệp thích) với các lần chạy nước rút trong tương lai và các chủ đề / sử thi chính cho những điều đó.

Tôi thích phát hành mỗi lần chạy nước rút và sau đó tôi chuẩn bị phát hành với những gì đã hoàn thành trong lần chạy nước rút (hoặc những thứ đã được ký kết để phát hành bởi doanh nghiệp mặc dù không hoàn hảo), những thứ còn dang dở sẽ đi đến lần chạy nước rút tiếp theo. Bằng cách này, tôi có thể giao hàng dự đoán trong khoảng 2-3 tuần thời gian (một tuần để sửa lỗi cuối cùng cho ứng viên phát hành).

Đó là kinh nghiệm của tôi với nhóm nhỏ, số lượng nhỏ phụ thuộc bên ngoài và những gì tôi tin rằng kinh doanh hợp lý. Milage của bạn có thể thay đổi.

Đối với các tính năng mới, gần như không thể ước tính thời gian cần thiết.

Kinh nghiệm với phát triển phần mềm cho thấy rằng trong hầu hết các trường hợp, có những chi tiết mà bạn không thể thấy trước khi thực sự bắt đầu phát triển. Trong trường hợp tốt nhất, những kẻ phá hoại có thể cần thêm thời gian, nhưng trong trường hợp xấu nhất, dự án cũng có thể thất bại. Lý do cho điều đó là sự phức tạp của chính sự phát triển phần mềm.

Đây là lý do tại sao SCRUM chỉ ước tính mức độ phức tạp của vấn đề (điểm câu chuyện), chứ không phải thời gian. Cơ hội duy nhất mà bạn có là chia các tính năng có độ phức tạp cao thành các tính năng nhỏ hơn. Bằng cách này bạn có thể giảm thiểu rủi ro.

Vì ước tính thời gian là gần như không thể, không có công thức chuyển đổi điểm câu chuyện thành ước tính thời gian. Vận tốc chỉ có thể là một ước tính rất thô, không nhiều hơn.

Trong SCRUM, chủ sở hữu sản phẩm có thể thay đổi mức độ ưu tiên của các mục tồn đọng trước mỗi lần chạy nước rút. Do đó, chủ SCRUM không thể đưa ra bất kỳ ước tính nào cho nhiều hơn một lần chạy nước rút. Anh ta không biết mục tồn đọng nào có thể trở nên quan trọng trong lần chạy nước rút tiếp theo.

SCRUM không phải là một phương pháp để làm những việc không thể (lên kế hoạch không thể thực hiện được) hoặc làm cho sự phát triển nhanh hơn. Đây là một hệ thống cảnh báo sớm nếu sự phát triển sắp hết thời gian. Nó cho phép phản ứng nhanh chóng theo yêu cầu mới.

Đến bài viết ban đầu:

Bạn đã rất tốt nếu bạn quản lý việc chia hầu hết các nhiệm vụ của mình thành 1 SP thành 5 câu chuyện SP. Các ước tính vận tốc có thể trở nên tốt hơn nếu các nhiệm vụ tương tự và nhóm của bạn có nhiều kinh nghiệm hơn. Nhưng nếu luôn có những phần mới, unkonwn trong các mục mới, bạn phải sống với sự không chính xác.

Vì các nhà phát triển của bạn thường dành một chút thời gian cho công việc không phát triển (ví dụ như các cuộc họp), bạn không nên lập kế hoạch với 8 giờ phát triển cho mỗi ngày, nhưng ít hơn, ví dụ như 6 giờ. Sau đó, bạn nhận được một dự trữ cho các nhiệm vụ khác hoặc cho các mục công việc mất nhiều thời gian hơn.

Nếu các đồng nghiệp kinh doanh của bạn muốn có ước tính chính xác (bản thân nó là một mâu thuẫn), hãy giải thích cho họ những vấn đề cố hữu của việc phát triển phần mềm. Sau đó cho họ thấy những lợi thế của phương pháp nhanh.