Trong dự án Agile, công việc ước tính có thật sự cần thiết?

23/07/20

Viện Quản lý dự án Atoha

Các nhà quản lý dự án thường thích các kế hoạch và ước tính để chúng tôi có thể dự đoán khi nào mọi thứ nên được thực hiện và chi phí có thể là bao nhiêu. Nó giúp quản lý kỳ vọng của khách hàng và trả lời câu hỏi mà họ đặt ra, chẳng hạn như "Khi nào thì hoàn thành?" và “Cái này có giá bao nhiêu?"

Các nhà quản lý dự án thường thích các kế hoạch và ước tính để có thể dự đoán khi nào mọi thứ nên được thực hiện và chi phí có thể là bao nhiêu. Nó giúp thỏa mãn kỳ vọng của khách hàng và trả lời cho câu hỏi "Khi nào thì hoàn thành?" và “Cái này có giá bao nhiêu?"

Vì vậy, các nhà quản lý dự án có thể phản ứng bất ngờ khi nghe về những ý tưởng như "chúng ta đừng ước tính nữa". Điều này nghe có vẻ là người không mấy siêng năng và chỉ muốn né tránh công việc khó khăn khi phải ước lượng. Có vẻ như mọi người muốn trốn tránh trách nhiệm và nghĩa vụ của họ. Ban đầu, những chuyên gia Agile (agilist) chuyên "trì trệ" muốn ngừng làm công việc giấy tờ; và bây giờ họ cũng muốn dừng cái việc phải ước tính này lại!

Đã có một cuộc tranh luận nổ ra từ năm 2012 về sự hữu dụng và giá trị của các ước tính trong các dự án Agile. Hashtag #NoEstimates (không ước tính) đã bắt đầu xuất hiện dần trên website, cuốn sách và vô số bài đăng trên blog cũng như bài thuyết trình hội nghị.

Đồng điệu với những ý tưởng cấp tiến khác, khi đào sâu vào tư duy “NoEstimates”, sẽ có một số ý tưởng hay, khá logic — hoặc có cả đống hiểu lầm xung quanh nó. Bài viết dưới đây sẽ làm sáng tỏ một số vấn đề sau:

Góc nhìn của tôi đối với “NoEstimates”

Tôi nên bắt đầu từ việc tôi đứng về phía nào trong cuộc tranh luận. Ban đầu, tôi nghĩ mình hoàn toàn tin tưởng vào các ước tính — nhưng không phải là kiểu ước tính chi tiết một cách vô bổ khi thông tin còn hạn chế. Thay vào đó, tôi nỗ lực đặt mục tiêu tạo ra các ước tính hợp lý đôi khi có thể bị giới hạn bởi dữ liệu đầu vào không chắc chắn. Sau đó, truyền đạt các ước tính dưới dạng một phạm vi để phản ánh độ không chắc chắn và tinh chỉnh chúng khi có thêm thông tin.

Sau đó, tôi phát hiện ra điều này khá tương đồng với những điều mà người theo chủ nghĩa NoEstimates cho là phù họp. Họ chỉ gọi chúng là dự đoán chứ không phải ước tính. Tên gọi chỉ là nhãn mác bên ngoài và không quan trọng bằng ý nghĩa đằng sau đó. Vì vậy, tôi cảm thấy mâu thuẫn.

NoEstimates bắt đầu được biết đến

Vào năm 2012, Woody Zuill đã viết một bài đăng trên blog hỏi rằng liệu việc ước tính được cho là tốt hơn có phải là cách duy nhất để tiếp tục hay không. Ông tự hỏi liệu việc tạo ước tính dựa trên quan sát về tỷ lệ công việc đã hoàn thành có thể là một giải pháp thay thế chăng. Phong trào bắt đầu diễn ra, những người cấp tiến hơn đã chọn tham gia. Họ gây ra nhiều lập luận chống lại NoEstimates. Tuy nhiên, đừng phức tạp quá và xem xét một số ý tưởng để bắt đầu cho cuộc thảo luận rồi mọi người hẳn quyết định dựa trên môi trường đặc thù của mình.

Đối với các dự án phần mềm theo hướng tiếp cận bằng Agile, cả nhóm thường được yêu cầu ước tính nỗ lực phát triển cho các story trong checklist. Khi nhóm bắt đầu làm việc với những story này, họ có thể phát hiện ra một số story phức tạp hơn dự đoán ban đầu và cần chia thành nhiều story. Một số story thì đi theo kế hoạch, và một số khác bị thay thế bởi những thay đổi có mức độ ưu tiên cao hơn và không bao giờ được phát triển.

Dự đoán dựa trên thông lượng như một phương án thay thế cho công việc ước tính

Độ nỗ lực và tính chặt chẽ của phương pháp ước lượng phải tỷ lệ thuận với chất lượng của dữ liệu đầu vào. Việc áp dụng phân tích Monte Carlo tốn nhiều thời gian vào việc phỏng đoán sẽ không phải là một cách sử dụng hiệu quả ngân sách hoặc con người. Vì vậy, một số người đi theo chủ nghĩa NoEstimate nhận định rằng phân tích quá kỹ và quy trình phức tạp hơn dữ liệu đầu vào thì xứng đáng là một điều lãng phí.

Ngay cả khi hành động ước tính với dữ liệu đầu vào không hoàn hảo vẫn có giá trị và giúp nhóm có thể khai thác thông tin chi tiết. Ngoài ra, khi sử dụng ngân sách của người khác, thì cũng cần có trách nhiệm. Tuy nhiên, hãy làm theo logic NoEstimates trước khi đưa ra phán đoán.

Để thay thế cho việc ước tính tất cả các story trong lần lặp tiếp theo, những người ủng hộ cho NoEstimates đề xuất một phương pháp dự đoán dựa trên thông lượng. Nếu nhóm đã hoàn thành 20 user stories (câu chuyện người dùng) trong lần lặp cuối cùng, thì thử nghĩ xem giả sử họ cũng sẽ hoàn thành 20 lần lặp này — và sử dụng thời gian của các lần lặp tiếp theo để xây dựng chức năng mới thay vì ước tính.

Có thể dễ dàng phát hiện ra lỗ hổng trong logic này. Điều gì xảy ra nếu 20 stories tiếp theo này lớn hơn hoặc phức tạp hơn nhiều so với 20 stories vừa hoàn thành? Câu trả lời là nhóm sẽ không hoàn tất được 20 stories và dự đoán sẽ sai. Tuy nhiên, trước khi loại bỏ phương pháp không khả thi này, hãy kiểm tra một số điều có thể sai với các ước tính truyền thống trên một dự án phần mềm.

Chúng ta có thể dành nhiều thời gian để ước tính các nhiệm vụ mặc dù vẫn không nằm trong dự đoán hoặc phức tạp hơn khi chúng ta thực hiện các nhiệm vụ đó. Chúng ta cũng có thể dành thời gian ước tính công việc bị tước bỏ hoặc bị hoán đổi bằng công việc mới.

"Cùng một kết quả kém, nhưng với nỗ lực ít hơn nhiều"

Vào khoảng năm 2006 tại các hội nghị về Agile, tôi nhớ lại một bài thuyết trình của Motorola về hiệu quả của việc sử dụng phương thức ước tính “planning poker” so với phương pháp tiếp cận nghiêm ngặt trước đây của hãng. Motorola có một số bộ phận CMMI (Mô hình năng lực trưởng thành tích hợp) Cấp 5 đã tiến hành các phiên phân tích rất chi tiết và ước tính có quy trình.

Một phần của việc trở thành CMMI Cấp 5 là để cải tiến liên tục. Vì vậy, ngoài việc ước tính chặt chẽ, các nhóm đã điều tra nguyên nhân gốc rễ của bất kỳ lỗi ước tính nào nhằm cải thiện quy trình. Trong một cuộc thử nghiệm, ba đội đã thay thế việc lập “planning poker” bằng quy trình ước tính nội bộ của họ. Thêm ba nhóm tiếp tục ước tính như bình thường, họ tạo ra các ước tính chi tiết với các đánh giá, phân tích nguyên nhân gốc rễ và hướng dẫn ước tính chi tiết hơn sau đó.

Kết quả cho thấy rằng ngay cả các nhóm thực hiện theo quy trình nội bộ chi tiết cũng khá yếu trong việc ước tính. Một số sản phẩm được đánh giá quá cao, và nhiều sản phẩm khác lại bị đánh giá thấp hơn. Phân tích nguyên nhân gốc rễ được thực hiện để tạo ra các danh sách kiểm tra dài hơn nhưng không loại bỏ được sự biến đổi trong việc ước tính qua sự thay đổi của con người, sự không chắc chắn, sự phức tạp và độ rủi ro.

Các nhóm “planning poker” cũng không khá hơn; cách họ ước tính cũng không có gì mới mẻ, vẫn thiếu các vấn đề gây ra sự chậm trễ. Sự khác biệt đáng kể là việc lập “planning poker” nhanh hơn nhiều so với cách tiếp cận ước tính hiện có của họ và các thành viên trong nhóm thích thú hơn nhiều. Tôi vẫn còn nhớ phần nào bản tóm tắt của người thuyết trình qua việc lập “planning poker” mang lại "Kết quả kém như nhau, nhưng với nỗ lực ít hơn nhiều."

Dự đoán dựa trên thông lượng

Hội NoEstimates đưa bài học này tiến thêm một bước nữa. Họ khẳng định rằng việc đo lường thông lượng là một cách dự đoán tạm ổn (hoặc chính xác hơn là kém) như cách ước tính theo giờ hoặc điểm — nhưng quan trọng là đòi hỏi ít nỗ lực hơn nhiều. Khi sử dụng ngân sách của người khác, chúng ta có nên tập trung vào việc xây dựng các sản phẩm có giá trị hay chỉ cần tạo ra các ước tính, ngay cả khi đó là một quy trình nghiêm ngặt tốn kém, tầm thường?

Tất nhiên, có những sắc thái của màu xám. Một số phần mềm có thể biết được và có thể được ước tính một cách đáng tin cậy. Có lẽ chúng ta nên sử dụng ước tính ở đó. Một số khách hàng mong đợi sự thẩm định và bằng chứng về tính chặt chẽ của việc lập kế hoạch, và có thể muốn biết công việc đang được ước tính ra sao và không muốn bắt đầu khi không được xem xét cẩn trọng.

Tôi đã làm việc với cả hai loại ước tính. Mỗi khi ước tính dựa trên thông lượng được sử dụng, nhóm đã bắt đầu ước tính với các điểm. Sau đó, khi nhóm trở nên ổn định và niềm tin với khách hàng được gầy dựng, chúng tôi nhận thấy các chỉ số thông lượng là chỉ số đáng tin cậy cho ngày bàn giao cũng như năng suất.

Các công cụ quản lý dự án Agile hiện đại luôn theo dõi khi các story thay đổi trạng thái, chẳng hạn như Sẵn sàng cho sự phát triển thông qua Mã hóa, Kiểm tra và Hoàn thành. Nếu quá trình này diễn ra trung bình năm ngày cho mỗi story và chủ sở hữu sản phẩm hỏi sẽ mất bao lâu để thêm một số tính năng ưu tiên cao mới, miễn là nó không quá phức tạp — thì có thể là khoảng năm ngày.

Tương tự như vậy, nếu mất hai tháng để hoàn thành 50 stories cuối cùng và 100 stories còn lại đang tồn đọng, thì có lẽ sẽ mất bốn tháng để hoàn thành dự án.

Tùy chọn kết hợp

Trong trường hợp tôi đã sử dụng phân tích thời gian chu kỳ và thông lượng để tạo dự đoán, chúng tôi cũng đã cố gắng tối ưu về điều đó. Cả nhóm đều biết quy trình sẽ chỉ hoạt động nếu các story có kích thước phù hợp. Vì vậy, họ dành một chút thời gian để tìm kiếm mọi thứ mà có thể mang ý nghĩa về mặt cấu tạo để điều tra mức tăng đột biến. Họ cũng dành thời gian chia nhỏ các story lớn — và đôi khi gắn thẻ các story theo các kích thước áo thun như nhỏ (S), vừa (M) và lớn (L).

Có thể lập luận rằng đây là một hình thức ước tính, và tôi đồng ý. Tuy nhiên, việc nhanh chóng quy kết (S), (M) hoặc (L) cho một story trở nên nhanh chóng và có thể được thực hiện bởi một nhà phát triển cấp cao mà không đòi hỏi (hoặc có được sự thông thái) của cả nhóm.

Bây giờ chúng ta cần làm một số phép toán cơ bản với các dự đoán của chúng ta. (S), (M) và (L) phải là tương đối, vì vậy 1 (M) là 2 (S), và 1 (L) là 3 (S). Giờ đây, nhóm có thể cung cấp 60 stories nhỏ hoặc 30 stories trung bình hoặc 20 stories lớn cho mỗi lần lặp — hoặc nhiều khả năng hơn, một số kết hợp như 5 stories lớn, 10 stories vừa và 35 stories nhỏ.

Chúng tôi đã giải thoát nhóm khỏi công việc ước tính (công việc mà ngay cả những người giỏi nhất cũng không giỏi lắm), do đó, nhóm có thể tập trung vào việc xây dựng các sản phẩm với hy vọng sẽ tốt hơn. Chúng tôi có thể sử dụng dữ liệu thông lượng được cung cấp miễn phí bởi phần mềm theo dõi của chúng tôi để dự đoán ngày hoàn thành. Sử dụng các ước tính này nhân với chi phí hoạt động của nhóm (cộng với các chi phí khác), chúng tôi cũng có thể tạo ước tính chi phí.

Nhược điểm

Tôi chỉ có kinh nghiệm dự đoán dựa trên thông lượng hoạt động tốt với các nhóm ổn định trong môi trường có độ tin cậy cao. Những nhóm này trước đó đã ước tính công việc của họ và hiểu rõ về chi phí tiêu hao của họ so với ngân sách và công việc tồn đọng.

Ở một số nơi hoặc ở một số nền văn hóa nhận thấy việc không ước lượng là vô trách nhiệm. Ngoài ra, một số bước tiến trong việc phát triển có thể được ước tính khá chính xác và do đó, các ước tính riêng lẻ có thể cung cấp dự đoán đạt tỷ lệ cao hơn so với theo dõi thông lượng trung bình.

Bài viết này đã mô tả các lựa chọn thay thế dựa trên thông lượng đối với các ước tính dựa trên tác vụ truyền thống. Một số người theo chủ nghĩa NoEstimates cho rằng điều đó cũng lãng phí và tin rằng các nhóm chỉ nên làm việc cho đến khi hoàn thành. Tuy nhiên, tôi vẫn chưa gặp một nhà tài trợ nào mà không quan tâm đến các dự đoán về tiến độ và hoàn thành dựa trên bằng chứng.

Tóm lại

Giảm hoặc loại bỏ ước tính có thể tiết kiệm đáng kể nỗ lực. Khi nhóm cuối cùng mà tôi tham gia thực hiện chuyển đổi, chúng tôi thấy số lượng story hoàn thành mỗi tuần tăng 8% do dành nhiều thời gian hơn để phát triển.

Cuộc tranh luận NoEstimates có thể được tái diễn như một cuộc thảo luận giữa ước tính tham số theo bottom-up (ước tính nhóm thông qua điểm số) so với ước tính heuristic về thông lượng mỗi lần lặp. Cả hai cách tiếp cận đều có những lợi ích và thiếu sót.

Một số tổ chức coi trọng quy trình và thông tin do phương pháp ước tính bottom-up (ước tính từ dưới lên) mang lại. Nhưng những người khác lại muốn chuyển hướng nỗ lực đó sang hướng phát triển và sử dụng một ước tính heuristic khác (ngay cả khi kém hơn). Các nhà tài trợ sẽ luôn hỏi, "Sẽ mất bao lâu?" và "Cái này có giá bao nhiêu?". Chúng ta có các sự lựa chọn để giúp trả lời những câu hỏi đó; nhưng cuối cùng, nó phải là quyết định của nhóm sponsor về cách họ muốn thấy nó xảy ra.

Tác giả: Mike Griffiths

(References: Estimating Agile Projects...Or Not)