Agile Estimation – Kỹ thuật ước tính trong phát triển phần mềm

Hầu hết các dự án phát triển phần mềm hiện nay đều hướng đến 2 mục tiêu: tạo ra sản phẩm chất lượng, đúng yêu cầu khách hàng và bàn giao sản phẩm đúng thời hạn. Để làm được điều này, việc ước tính thời gian hợp lý luôn là điều mà các nhà quản lý dự án quan tâm. Agile Estimation – phương pháp ước tính linh hoạt sẽ giúp giải quyết vấn đề trên!

Agile Estimation là gì?

Theo định nghĩa từ Wikipedia, Estimation (Ước tính) là một quá trình để tìm ra số lượng ước đoán hay con số xấp xỉ, nhằm đem đến giá trị hữu ích cho một số mục đích nào đó – ngay cả khi trường hợp dữ liệu đầu vào không đầy đủ, không đáng tin cậy và không ổn định”.

Trong các dự án phát triển phần mềm theo mô hình Agile, Estimation là kỹ thuật dự báo, xác định số effort cần thiết cho việc phát triền sản phẩm. Mục đích nhằm làm căn cứ để lên lịch, dự đoán tiến độ và theo dõi công việc của nhóm Scrum. Estimation không phải để đưa ra con số chính xác về thời gian hay công sức hoàn thành các hạng mục, mà chỉ mang tính tương đối.

Các đặc điểm cơ bản của Agile Estimation:

• Không thể chính xác 100%
• Đơn vị: giờ hoặc story point
• Việc ai làm thì người đó ước tính
• Cần tính đến yếu tố không đoán trước được (contingency)
• Cần được rà soát và cập nhật thường xuyên.

2 kỹ thuật Estimation đơn giản và dễ ứng dụng

Trước khi đến với các kỹ thuật Agile Estimation, chúng ta cần hiểu về thuật ngữ Story point. Bởi, thông thường các dự án Agile dùng “point” thay cho giờ khi ước tính dự án.

Nói một cách đơn giản, Story point là đơn vị tính độ khó của một task. Ví dụ, task dễ tương ứng 1 point, trung bình tương ứng 2 point, task khó tương ứng với 3 point. 

Vậy làm thế nào để xác định kích thước Story point? Đó là lúc chúng ta cần áp dụng kỹ thuật Estimation:

Planning Poker

Đây là kỹ thuật hiệu quả, được sử dụng rộng rãi tại các công ty phần mềm hiện nay. Với phương pháp này, bộ poker sẽ chứa các quân bài thuộc dãy số Fibonaci: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Quy trình thực hiện như sau:

• Bước 1: Xác định hạng mục Product Backlog/Sprint Backlog cần ước lượng.
• Bước 2: Chọn một hạng mục (thường là User story hoặc Task)
• Bước 3: Mỗi thành viên tự xác định số point bằng cách chọn cây poker có số tương ứng, và không tiết lộ cho người khác.
• Bước 4: Tất cả số điểm Story points sẽ được công bố cùng một lúc.
• Bước 5: Đánh giá và thảo luận. Nếu số point của các thành viên đưa ra là tương ứng thì việc ước lượng cho hạng mục đó đã xong. Ngược lại, nếu có sự khác biệt, thành viên lựa chọn sẽ đưa ra lý giải của mình. Quy trình này sẽ lặp lại ở bước 2 cho đến khi đi đến sự thống nhất.

T-shirt sizing 

Phương pháp này thường được thực hiện ở giai đoạn đầu của dự án – khi chưa có nhiều thông tin chi tiết.

Về nguyên lý, kỹ thuật T-shirt sizing không có quá nhiều khác biệt so với kỹ thuật Planning Poker. Dựa trên ý tưởng chia theo các sizes (kích cỡ) khác nhau của áo T-shirt, Scrum team sẽ gán số size tương ứng với với độ phức tạp của các User story.

Do chưa có thông tin chắc chắn, đơn vị ước lượng sẽ là từ cực nhỏ – extra small (ES) đến cực lớn – extra large (XXL). Kỹ thuật T-shirt sizing không đòi hỏi ước lượng kích thước tuyệt đối của từng hạng mục công việc, hay thậm chí độ chênh lệch chính xác giữa các kích thước là bao nhiêu. Tất cả thông tin cần biết sẽ là extra small nhỏ hơn small; small nhỏ hơn medium và tiếp tục như thế.

Tuy vậy, nhóm cũng có thể gán số point cho từng kích thước. Ví dụ, extra small tương ứng 1 điểm, 2 điểm cho tính năng small, 3 điểm cho tính năng medium (trung bình)…

Những yếu tố ảnh hưởng đến độ chính xác của Estimation

Không hiếm trường hợp mà kết quả thực tế sai lệch lớn so với con số đưa ra từ Estimation. Dưới đây là những yếu tố ảnh hưởng đến độ chính xác của Kỹ thuật Agile Estimation:

• “Parkinson’s Law” (quy luật Parkinson) và Student Syndrome (hội chứng Sinh viên) – ám chỉ việc “ngâm” task thay vì hoàn thành sớm. 
• Một công việc muộn dẫn đến hiệu ứng dây chuyền.
• Các hoạt động không được tiến hành độc lập của con người.
• Những vấn đề chủ quan như cảm xúc, tâm lý con người, năng lực cộng tác giữa các thành viên, thiết bị kỹ thuật không đáp ứng, yêu cầu phi lý từ khách hàng…

Do đó, khi thực hiện Estimation, nhóm cũng cần tính toán đến các yếu tố rủi ro. Đồng thời, dựa trên kinh nghiệm từ những dự án trước đó. Việc ước lượng đôi khi bị sai lệch là câu chuyện thường gặp trong các dự án, nhóm không nên điều chỉnh mà hãy lưu lại thông tin để làm cơ sở cho việc xác định Story point ở những lần sau được chính xác hơn.

Tóm lại, Agile Estimation là để lập kế hoạch – không phải thực tế và cũng không phải là cam kết. Việc ước lượng story points ban đầu có thể gặp nhiều sai lệch, song bằng cách cùng kiểm soát kế hoạch, Scrum team sẽ dần đạt được sự thuần thục, nhất quán hơn; họ cũng sẽ hiểu hơn về các hạng mục công việc, từ đó giảm rủi ro khi triển khai.