Story point là vô nghĩa, hãy đo lường hàng đợi

• Story point hoàn toàn không đáng tin cậy, gây ra nhầm lẫn và liên tục buộc phải nhắc những người liên quan về ý nghĩa của nó
  • Giá trị point thấp thì chính xác hơn, nhưng giá trị point cao giả định độ biến động lớn hơn và thể hiện một khoảng, nên không thể cộng dồn một cách chính xác
  • Story point không biểu thị thời gian, nhưng khi kết hợp với metric velocity thì trên thực tế lại mang nghĩa thời gian, khiến ngay từ đầu việc cộng các con số và khoảng trở nên vô lý
• Ước lượng phần mềm là việc khó, và đầu ra của quy trình này nhìn chung không hữu ích tương xứng với đầu vào
• Những nhóm nhỏ ít bị gián đoạn trông có vẻ như đang ước lượng chính xác, nên trong đa số trường hợp tạo cảm giác rằng cách làm hiện tại đang hoạt động tốt
• Khi capacity được sử dụng hết mức, độ biến động của mọi công việc tăng vọt, tác động mạnh đến mọi ước lượng và timeline
• Hàng đợi được đo lường giúp giải quyết các vấn đề ước lượng ngắn hạn và dài hạn, tự nhiên xử lý thay đổi phạm vi, đồng thời loại bỏ bất định và mang lại một thực hành có giá trị hơn nhiều cho các nhóm lớn
• Hàng đợi được đo lường cung cấp một chỉ báo sớm dự đoán vấn đề nhanh hơn 20 lần so với các metric liên quan đến velocity hay cycle time

Story point là gì?

• Theo Atlassian, story point là đơn vị dùng để biểu diễn ước lượng tổng nỗ lực cần thiết để triển khai hoàn chỉnh một hạng mục product backlog hoặc công việc khác
• Point biểu thị độ phức tạp, khối lượng công việc, rủi ro hoặc bất định, và lượng việc
• Việc đo độ phức tạp là một khái niệm tương đối, nên mỗi nhóm có thể đánh giá cùng một công việc theo cách khác nhau
• Do tính tương đối của point, việc so sánh giữa các nhóm là vô nghĩa, và đây là vấn đề thường xảy ra ở cấp quản lý

Độ biến động nội tại

• Story point dựa trên dãy Fibonacci, nên giá trị càng cao thì độ biến động được biểu thị càng lớn
• Cộng các giá trị point có độ biến động cao là vô nghĩa, và việc cộng point trong metric velocity là sai lầm
• Theo luật Goodhart, khi một phép đo trở thành mục tiêu thì phép đo đó không còn là một phép đo tốt nữa

Những vấn đề đã biết

• Các vấn đề của story point đã được biết đến rộng rãi, nhưng nó vẫn được sử dụng vì các kỹ thuật ước lượng thay thế cũng gặp những vấn đề tương tự
• Ron Jeffries, người tạo ra story point, đã phủ nhận nó và chỉ trích việc lạm dụng nó
• Trong Scrum, "Commitment" đã được đổi thành "Forecast" nhưng vẫn tiếp tục bị sử dụng sai
• Thậm chí còn xảy ra tình huống nghịch lý là làm được nhiều hơn mức ước lượng lại bị trách móc

Ưu tiên theo ROI

• Doanh nghiệp ưu tiên công việc để tối ưu hóa tài nguyên (thời gian, tiền bạc, công cụ, con người)
• Ước lượng phát triển là cần thiết để tính chi phí đầu tư, nhưng bản thân việc ước lượng vừa khó vừa tốn kém
• Software Estimation: Demystifying the Black Art là một cuốn sách rất hay bàn về sự khó khăn của việc ước lượng

Đầu ra của quy trình

• Quy trình ước lượng story point tiêu tốn nhiều thời gian nhưng đầu ra lại không có giá trị
• Các buổi grooming định kỳ rất tốn thời gian và được áp dụng rất khác nhau giữa các nhóm, không có tính nhất quán
• Thay vì story point, việc lập ra một danh sách công việc có ý nghĩa sẽ có giá trị hơn

Đề xuất phương án thay thế

• Ước lượng bằng cỡ áo thun có thể là một phương án tốt hơn, nhưng cách này cũng có vấn đề
• Ước lượng theo thời gian cũng gặp các vấn đề tương tự, vì thời gian nhóm thực sự làm việc khác với thời gian mà phía kinh doanh kỳ vọng
• Với nhóm nhỏ, ước lượng theo thời gian có thể hoạt động tốt, nhưng khi nhóm lớn lên thì độ chính xác của ước lượng giảm xuống
• Cuốn sách "The Principles of Product Development Flow" của Donald Reinertsen đưa ra một phương án thay thế
  • Trọng tâm là tối ưu hóa luồng công việc bằng cách tập trung vào quản lý hàng đợi (Queue)
  • Cần lập kế hoạch năng lực và đảm bảo có vùng đệm năng lực để hấp thụ độ biến động

Giải pháp

• Bắt đầu bằng việc cả nhóm cùng phân tích công việc, chia nhỏ thành các task và loại bỏ bất định
• Danh sách task sẽ trở thành hàng đợi (Queue), và tổng số task biểu thị khối lượng công việc (Job Size)
• Dùng tốc độ hoàn thành task trung bình (Average Task Rate) để ước lượng thay cho story point
• Theo dõi công việc dựa trên tốc độ xử lý trung bình và tính toán tỷ lệ hoàn thành công việc
• Khi cập nhật task theo thông tin mới hoặc phản hồi mới, ước lượng cũng được điều chỉnh một cách tự nhiên
• Nhà phát triển không còn phải chịu áp lực tâm lý về việc ước lượng

Hàng đợi (Queue) là chỉ báo sớm

• Trong khi tốc độ hoàn thành task trung bình, cycle time, velocity... là các chỉ báo trễ, thì Queue là chỉ báo sớm
• Khi kích thước Queue tăng lên, có thể nhận biết trước vấn đề và phản ứng kịp thời

Tóm tắt

• Story point gây nhầm lẫn, không đáng tin cậy và được thiết kế để thất bại
• Thay vào đó, dành thời gian để cả nhóm cùng hiểu vấn đề, loại bỏ bất định, chia nhỏ theo task và quản lý Queue mới là việc có ý nghĩa và giá trị

Ý kiến của GN+

• Cách quản lý hàng đợi được bài viết đề xuất có vẻ là một phương án thay thế thực tế giúp vượt qua khó khăn của việc ước lượng trong phát triển agile
• Tuy nhiên, quá trình chia nhỏ task có thể làm tăng công sức cho các nhà phát triển, và ở giai đoạn đầu của dự án có thể mất nhiều thời gian hơn
• Ngoài ra, quy trình phân tích task đòi hỏi sự tham gia tích cực và việc nêu ý kiến thẳng thắn từ phía các nhà phát triển
• Mặt khác, cũng có thể kỳ vọng vào hiệu ứng tích cực là đội ngũ phát triển hiểu sâu hơn các yêu cầu kinh doanh và cùng nhau suy nghĩ về chúng

[heal9179]

Chẳng phải đó là phương pháp Kanban sao..?

[GN⁺]

Ý kiến Hacker News

• Theo kinh nghiệm cá nhân, con số story point không quan trọng, nhưng quá trình cả nhóm đánh giá độ phức tạp của công việc lại rất hữu ích

  • Việc dùng story point để dự đoán thời gian làm việc là một chỉ số không đáng tin cậy
  • Tôi cố tránh story point vì nhiều lý do như sự thay đổi của nhóm và lĩnh vực, cũng như tính biến động của các công việc ngoài phát triển
  • Ở những nhóm dùng story point, họ sử dụng nó như một công cụ để chia sẻ hiểu biết về công việc

• Việc trong Scrum Guide từ "Commitment" đổi thành "Forecast" không phải diễn ra vào năm 2011

  • Kiểm tra bản hướng dẫn 2010 và 2011 cho thấy từ "Commitment" không có trong các phiên bản trước năm 2011
  • "Forecast" đã thay thế "Estimate" trong bản hướng dẫn năm 2020

• Việc chia nhỏ gói công việc thành các đơn vị nguyên tử và đo độ dài hàng đợi là một vấn đề ở cấp độ khác

  • Có thể dùng story point khi tinh chỉnh gói công việc cùng với cả nhóm
  • Việc chia mọi công việc thành 1 story point là không hiệu quả
  • Việc liên hệ giữa độ dài hàng đợi và tác động của tính biến động là một khái niệm thú vị

• Cũng có trường hợp cách làm waterfall và ước tính theo đơn vị thời gian hoạt động tốt

  • Ở một nhóm dịch vụ chuyên môn quy mô nhỏ, họ ghi chép yêu cầu của khách hàng, thảo luận với nhóm rồi ước tính theo khoảng thời gian
  • Khi khách hàng phê duyệt, họ đi qua các bước thiết kế chi tiết, phát triển, QA và phát hành
  • Trong 20 năm quy trình không thay đổi và được đánh giá là một nhóm có năng suất cao

• Story point biểu thị độ phức tạp tương đối và mức độ bất định, chứ không phải đơn vị thời gian

  • Cần có khả năng đo một story bằng các con số lớn
  • Một số nhóm không chấm quá 7 point
  • Ở nơi khác, người ta vẫn chấm 21, 30 hoặc 50 point

• Story point thực chất là một đơn vị thời gian gần đúng

  • Việc gắn story point với một đơn vị thời gian rõ ràng có thể gây hiểu nhầm
  • Điều quan trọng là dự đoán lập trình viên sẽ dành bao nhiêu thời gian cho công việc
  • Muốn phân tích hàng đợi hữu ích thì cần biết thời gian dự kiến của từng công việc

• Khi mới dùng Scrum, họ đã dùng Rally

  • Họ theo dõi cả story point, thời gian ước tính và thời gian thực tế
  • Sau khi chuyển sang Jira thì việc theo dõi thời gian biến mất
  • Khi thời gian ước tính chính xác hơn, việc cân bằng khối lượng công việc trong nhóm trở nên dễ hơn

• Story point hữu ích khi thảo luận độ phức tạp của công việc, nhưng không phù hợp để đo vận tốc

  • Khi còn là một kỹ sư mới, họ xử lý được rất nhiều story point nhưng ban quản lý lại cố điều chỉnh điều đó
  • Rất khó đánh giá đúng mức các công việc phức tạp

• Việc ước tính các dự án phát triển phần mềm một cách đáng tin cậy là rất khó

  • Điều quan trọng là cùng cả nhóm chia nhỏ công việc thành các đơn vị nhỏ và ước tính theo khoảng thời gian
  • Khi dự án tiến triển, cần báo cáo danh sách tính năng và các khoảng ước tính mới

• Ước tính theo đơn vị thời gian là cách tốt hơn

  • Story point rốt cuộc vẫn được chuyển đổi thành đơn vị thời gian
  • Tránh các thủ tục Scrum phức tạp và hoàn thành công việc sẽ hiệu quả hơn