Cuốn "Scrum in Action" giới thiệu một phương pháp estimate hiệu quả và khá đơn giản. Xin lược dịch lại và giới thiệu với các bạn.
Phương pháp này có tên là "Objective Criteria – Based Estimate". Theo phương pháp này, nó cho rằng có những yếu tố sau đây sẽ ảnh hưởng tới kích thước của phần mềm:
- Mức độ phức tạp của giao diện (VD: giao diện để tương tác với người dùng, hoặc giao diện SOAP để tương tác bằng API với hệ thống khác)
- Kiểu tương tác dữ liệu (VD: thêm mới, chỉnh sửa hay xoá bỏ)
- Số lượng thực thể tham gia vào nghiệp vụ (VD: nghiệp vụ xuất kho yêu cầu sự tham gia của thủ kho, phiếu xuất kho, đơn vị vận chuyển)
Tuy nhiên ,cùng một kích thước nhóm yếu thì thấy phần mềm này là khó, còn nhó giỏi thì thấy phần mềm này là dễ. Phương pháp này đưa ra hai hệ số hiệu chỉnh là hệ số hiệu chỉnh liên quan đến môi trường và hệ số hiệu chỉnh liên quan đến năng lực của nhóm.
Dưới đây, xin lược trích phương pháp estimate từng bước một:
Đầu tiên, hãy tạo ra danh sách chức năng, với mỗi chức năng cần xác định các yếu tố sau
Bước 1. Xác định kiểu tương tác (Interaction).
| インタラクションタイプ | Mô tả | Giá trị |
| Đơn giản | Giao diện được định nghĩa rõ ràng | 1 |
| Trung bình | Giao diện động | 2 |
| Phức tạp | Giao diện tương tác với người dùng | 3 |
Ví dụ: Chức năng cần làm giao diện người dùng thì phức tạp, nhưng chức năng làm API thì là giao diện đơn giản. Một số trường hợp export excel hoặc csv thì độ khó giao diện chỉ ở mức trung bình.
Bước 2. Xác định các nguyên tắc nghiệp vụ (Biz Rule).
| Nguyên tắc nghiệp vụ | Mô tả | Giá trị |
| Đơn giản | 1 nguyên tắc | 1 |
| Trung bình | 2-3 nguyên tắc | 2 |
| Phức tạp | > 3 nguyên tắc | 3 |
Ví dụ: "Người dùng phải là nữ và có độ tuổi từ 17 trở lên" thì độ khó nguyên tắc là 2.
Bước 3. Chúng ta sẽ xác định số lượng thực thể nghiệp vụ (Entity).
| Thực thể | Mô tả | Giá trị |
| Đơn giản | 1 thực thể | 1 |
| Trung bình | 2 – 3 thực thể | 2 |
| Phức tạp | > 3 thực thể | 3 |
Ví dụ: Chức năng đăng kí user chỉ cần có thực thể User thì độ khó là 1. Tuy nhiên chức năng search user theo tần suất tham gia mạng xã hội thì cần phải liên kết với các thực thể khác nên độ khó có thể là 3.
Bước 4. Xác định tham số tương tác dư liệu (DB Interaction).
| Kiểu tương tác dữ liệu | Mô tả | Giá |
| Đơn giản | Read, Delete | 1 |
| Trung bình | Create | 2 |
| Phức tạp | Update | 3 |
Tổng số giá trị được xác định ở các bước trên tạo thành một con số, tạm gọi là UP (Unadjusted Points).
UP = SUM($value[]);
Để tính toán được giá trị cuối cùng còn cần thực hiện thêm bước xác định Environment Dimensions (ED) và Coefficient (C).
Tuy nhiên để đơn giản chúng ta sẽ thiết lập tham số này như một hằng số là ED = 12 và C = 2.
Công thức tính toán sẽ như sau:
AP (Adjusted Points) = UP (Unadjusted Points) * C (Coefficient)
PPS (Points per Story) = (AP ED)/36
Effort = HPP (Hours Per Point) * PPS (Points Per Story)
Ví dụ như một bản estimate sẽ có dạng như thế này.
Theo kinh nghiệm của chúng tôi, nếu làm cả TDD, HPP sẽ là 3. Dù đối với Scrum việc xác định Hour Effort không quan trọng, tuy nhiên chúng tôi vẫn sử dụng chúng như một dữ liệu tham khảo quan trọng để lên kế hoạch cho khách hàng cuối, người luôn có câu hỏi: "Khi nào thì các cậu xong?". Phương pháp này cũng khá phù hợp với trường hợp maintenance.
Bạn có thể tham khảo thêm cách estimate UCP để có thêm kiến thức về estimate, mỗi kĩ thuật có vấn đề riêng của nó nên việc lựa chọn áp dụng cần phải suy xét kĩ.