Đánh giá độ ưu tiên dựa trên giá trị 

Việc đánh giá độ ưu tiên là một quy trình nền tảng của Agile. Để hiểu tại sao, hãy nhớ lại nguyên tắc thứ hai của Agile cho chúng ta biết rằng các nhóm Agile phải “Luôn chào đón các thay đổi về yêu cầu, ngay cả khi ở giai đoạn sau này của dự án”. Mặc dù nghe có vẻ rất tốt về mặt lý thuyết, nhưng điều gì thực sự xảy ra khi một yêu cầu mới được thêm vào dự án khi dự án đã và đang làm việc hết công suất? Nếu khách hàng không đưa ra độ ưu tiên cho các hạng mục công việc, thì nhóm sẽ rơi vào tình huống khó xử. Nhóm sẽ “ép” mình như thế nào cho công việc mới thêm vào?

Trên thực tế, có thể khách hàng sẽ nói "Tôi muốn có tất cả!". Tuy nhiên, nếu khách hàng đưa ra được độ ưu tiên cho các công việc trong backlog, thì yêu cầu mới đó chỉ cần được chèn vào vị trí thích hợp trong backlog và các yêu cầu có mức độ ưu tiên thấp nhất sẽ (có thể) bị loại khỏi danh sách công việc để đáp ứng thay đổi đó.

Đánh giá độ ưu tiên dựa trên giá trị đề cập đến việc nhanh chóng triển khai các công việc mang lại giá trị cao nhất cho khách hàng trước. Khách hàng hoặc Product Owner (PO) có trách nhiệm giữ cho các hạng mục trong backlog (danh sách công việc cần phải làm) được ưu tiên dựa theo giá trị mang lại. Khi các hạng mục công việc mới được thêm vào, chẳng hạn như yêu cầu thay đổi hoặc sửa lỗi, khách hàng sẽ đánh giá độ ưu tiên để giá trị của chúng có thể được so sánh với các hạng mục hiện có trong danh sách. 

Việc đánh giá độ ưu tiên này là một quá trình liên tục trong suốt dự án. Thông thường, nhóm sẽ ngồi lại với khách hàng vào cuối mỗi lần lặp lại để đánh giá độ ưu tiên cho các hạng mục công việc còn lại. Ví dụ sẽ hỏi "Có gì thay đổi không?" hay "Chúng ta có muốn triển khai tính năng B này chứ?". Các buổi này đóng vai trò là các điểm kiểm tra quan trọng giúp đảm bảo rằng công việc đang tiến triển theo mục tiêu của dự án. Mọi ưu tiên mới đều được ghi lại trong product backlog và được đánh giá lại vào buổi lên kế hoạch cho lần lặp tiếp theo. Điều này giúp đảm bảo rằng nhóm đang đi đúng hướng để đạt được mục tiêu mong muốn.

Bằng cách hỏi khách hàng các tính năng ưu tiên hàng đầu của họ là gì, chúng ta tìm hiểu về động cơ, rủi ro và tiêu chí chấp nhận của họ. Khi một nhóm không thực hiện việc đánh giá độ ưu tiên dựa trên giá trị đem lại cho khách hàng, thì có khả năng họ sẽ bỏ lỡ việc xác định các yếu tố quan trọng quyết định tới thành công của dự án.

Các kỹ thuật đánh giá độ ưu tiên

Không có kỹ thuật đánh giá độ ưu tiên cụ thể nào là tốt nhất cho các dự án Agile. Mỗi nhóm nên chọn kỹ thuật của mình dựa trên nhu cầu của dự án và những gì phù hợp nhất cho tổ chức. Chúng ta sẽ cùng tìm hiểu một số kỹ thuật đánh giá độ ưu tiên phổ biến được sử dụng ngay sau đây.

1. Mô hình đơn giản

Một trong những phương pháp đơn giản để đánh giá là gắn nhãn các mục với “Mức độ ưu tiên 1”, “Mức độ ưu tiên 2”, “Mức độ ưu tiên 3”, v.v. Mặc dù cách tiếp cận này là dễ hiểu, nhưng nó có thể có vấn đề, vì các bên liên quan có xu hướng chỉ định mọi thứ là “Mức độ ưu tiên 1”. Nếu có quá nhiều mục được gắn nhãn "Mức độ ưu tiên 1", mô hình sẽ trở nên không hiệu quả. Khách hàng/PO hiếm khi yêu cầu một tính năng mới và nói rằng nó phải là Mức độ ưu tiên 2 hoặc 3, vì họ nghĩ rằng các mục có mức độ ưu tiên thấp có nguy cơ bị loại khỏi dự án. Vì những lý do tương tự, việc đánh mức độ ưu tiên theo kiểu “cao”, “trung bình” và “thấp” cũng có thể có vấn đề tương tự. Nếu không có lý do chính đáng được đưa ra cho những mục đã được đánh giá có độ ưu tiên "cao", chúng ta sẽ có quá nhiều hạng mục trong danh sách “Ưu tiên cao”, từ đó mức độ ưu tiên thật sự không còn chính xác nữa.

2. MoSCoW

Mô hình đánh giá ưu tiên MoSCoW, lấy tên từ các chữ cái đầu tiên của các khái niệm sau:

• “Must have”
• “Should have”
• “Could have”
• “Won’t have”, hoặc “Would like to have, but not this time”

Các danh mục ưu tiên được sử dụng trong MoSCoW dễ xác định và có cơ sở hơn việc gắn nhãn “Mức độ ưu tiên 1” hoặc “Mức độ ưu tiên cao”.

• Các yêu cầu hoặc tính năng “Must have” là những yêu cầu cơ bản đối với hệ thống; không có chúng, hệ thống sẽ không hoạt động hoặc sẽ không có giá trị.
• Các tính năng “Should have” rất quan trọng - theo định nghĩa, chúng ta nên có chúng để hệ thống hoạt động chính xác;
• Các tính năng “Could have” là các bổ sung để tăng thêm giá trị hữu hình.
• Các yêu cầu “Won’t have”, hoặc “Would like to have, but not this time” là các yêu cầu có cũng được không có cũng không sao.

3. Monopoly Money

Một cách tiếp cận khác hoạt động hiệu quả là cung cấp cho các bên liên quan số tiền tương đương với số tiền của ngân sách dự án và yêu cầu họ phân phối số tiền đó giữa các tính năng của hệ thống. Cách tiếp cận này hữu ích để xác định mức độ ưu tiên chung của các thành phần hệ thống, nhưng có thể gây thắc mắc nếu những người tham gia bắt đầu đặt câu hỏi về các hoạt động khác của dự án, chẳng hạn như viết tài liệu, vì họ cho là không đem lại nhiều giá trị cho dự án. Kỹ thuật Monopoly Money hiệu quả nhất khi được giới hạn ở việc ưu tiên các tính năng của sản phẩm/phần mềm.

4. Phương pháp 100 điểm - 100-Point Method

Phương pháp 100 điểm, ban đầu được phát triển bởi Dean Leffingwell và Don Widrig cho nhiều trường hợp khác nhau, đây cũng là một cách khác để đánh giá mức độ ưu tiên cho các tính năng. Trong phương pháp này, mỗi người tham gia được phát cho 100 điểm mà họ có thể sử dụng để bỏ phiếu cho các yêu cầu quan trọng nhất. Các bên liên quan có thể phân phối 100 điểm theo bất kỳ cách nào: 30 điểm cho yêu cầu A, 15 điểm cho yêu cầu B hoặc tất cả 100 điểm cho một yêu cầu C, nếu đó là ưu tiên duy nhất của họ.

5. Dot Voting hoặc Multi-Voting

Đây là một kỹ thuật mà mỗi bên liên quan nhận được một số lượng dấu chấm xác định trước (hoặc điểm, sao, v.v.) để phân phối giữa các tùy chọn. Để minh họa cách hoạt động, hãy cùng xem một ví dụ sau.

Hãy tưởng tượng cả nhóm đã hoàn thành một buổi brainstorming để đưa ra những rủi ro tiềm ẩn trong dự án. Kết quả đã đưa ra danh sách 40 rủi ro hiện cần được ưu tiên. Mỗi người được phát 8 phiếu để chỉ ra mục nào họ cảm thấy quan trọng nhất theo ý muốn. Đó có thể là một phiếu trên 8 mục khác nhau, 4 phiếu trên một mục và hai phiếu trên một số mục khác hoặc bất kỳ kết hợp nào khác phản ánh độ ưu tiên của các bên liên quan.

Sau đó, điều phối viên tổng hợp các phiếu bầu cho từng mục và tạo một danh sách xếp hạng dựa trên số phiếu nhận được của mỗi mục. Cuộc bỏ phiếu có thể là công khai hoặc riêng tư.

Để quyết định có bao nhiêu phiếu bầu cho mỗi người, có một nguyên tắc chung đó là số phiếu bầu cho mỗi người bằng 20% tổng số sự lựa chọn. Vì vậy, nếu có 40 mục được bình chọn, chúng ta sẽ tính 40 x 0,2 = 8, và mỗi người sẽ nhận được 8 phiếu để phân phối.

6. Phân tích Kano - Kano Analysis

Kỹ thuật này được sử dụng để phân loại sở thích của khách hàng thành bốn loại; Delighters/Exciters, Satisfiers, Dissatisfiers, và Indifferent. Các bên liên quan của dự án có thể sử dụng các danh mục này để hiểu nhu cầu của khách hàng sẽ ảnh hưởng đến sự hài lòng của khách hàng như thế nào. Phân tích Kano có thể giúp chúng ta giải quyết bài toán rằng tính năng nào nên được triển khai nhằm thúc đẩy sự hài lòng của khách hàng.

Cùng xem xét từng danh mục chi tiết hơn:

• Delighters / Exciters: Những tính năng này mang lại lợi ích bất ngờ, mới lạ hoặc giá trị cao mới cho khách hàng. Ví dụ, một tính năng thú vị, khiến cho khách hàng hứng thú như giao diện cho trang báo cáo cực đẹp và hiệu ứng 3D bắt mắt. Nếu không làm các tính năng này thì sự hài lòng của khách hàng cũng không giảm.
• Satisfiers: Đối với các tính năng được phân loại là Satisfiers, càng nhiều càng tốt. Những tính năng này mang lại giá trị cho khách hàng. Nếu không làm (hoặc làm không tốt) các tính năng này thì sự hài lòng của khách hàng sẽ giảm.
• Dissatisfiers: Đây là những tính năng sẽ khiến người dùng không thích sản phẩm/phần mềm nếu những tính năng này không được làm, nhưng nếu có làm thì cũng chưa chắc sẽ tăng sự hài lòng của khách hàng. Ví dụ, khả năng thay đổi mật khẩu trong hệ thống có thể là 1 dissatisfier.
• Indifferent: Những tính năng này không có tác động đến khách hàng theo cách này hay cách khác. Vì khách hàng thờ ơ với chúng, chúng ta nên cố gắng loại bỏ, giảm thiểu hoặc trì hoãn những tính năng này.

7. Mô hình ưu tiên yêu cầu - Requirements Prioritization Model

Mô hình ưu tiên yêu cầu - Requirements Prioritization Model do Karl Wiegers tạo ra là một phương pháp tính toán mức độ ưu tiên chặt chẽ hơn về mặt toán học so với các phương pháp khác mà chúng ta đã thảo luận. Với cách tiếp cận này, chúng ta sẽ dựa trên lợi ích, điểm phạt, chi phí và rủi ro của các tính năng được đề xuất và được đánh giá theo thang điểm tương đối từ 1 (thấp nhất) đến 9 (cao nhất). Khách hàng sẽ đánh giá điểm lợi khi thực hiện tính năng và điểm phạt nếu không có tính năng đó. Nhóm phát triển đánh giá về chi phí thực hiện tính năng và rủi ro liên quan đến việc thực hiện tính năng đó. Các điểm cho mỗi tính năng sau đó sẽ được nhập vào một ma trận trọng số, được sử dụng để tính mức độ ưu tiên tương đối của tất cả các tính năng.

8. Xếp hạng / Ưu tiên Tương đối

Bất kể mô hình đánh giá độ ưu tiên mà nhóm sử dụng là gì, mục tiêu cuối cùng phải cho chúng ta hiểu được mức độ ưu tiên của các tính năng. Đôi khi việc tập trung quá nhiều vào tranh cãi xem sử dụng phương pháp gì lại làm giảm hiệu quả của các cuộc thảo luận có ý nghĩa về mức độ ưu tiên. Vì lý do này, chúng ta có thể liệt kê các tính năng theo thứ tự ưu tiên tương đối, bằng một danh sách đơn giản (không cần đánh giá loại 1, 2 hoặc 3; không có cao, trung bình hoặc thấp; v.v.).

Hãy xem một ví dụ về danh sách ưu tiên tương đối đơn giản sau:

Trong sơ đồ trên, mỗi tính năng được liệt kê theo thứ tự ưu tiên. Các mục ở đầu danh sách - các tính năng từ A đến D - là một phần của sản phẩm khả thi tối thiểu được xác định. Nếu cần phải cắt giảm yêu cầu để đáp ứng các mục tiêu về ngân sách và tiến độ, dễ dàng chúng ta có thể thấy yêu cầu cần phải điều chỉnh đầu tiên đó chính là E.

Đánh giá ưu tiên tương đối cũng cung cấp một khuôn khổ để quyết định xem có nên tích hợp các thay đổi hay không. Khi có yêu cầu thay đổi, nhóm có thể hỏi Product Owner rằng "Những hạng mục nào quan trọng hơn thay đổi này?" Thay đổi mới sau đó có thể được chèn vào danh sách công việc ưu tiên tại điểm thích hợp, như hình dưới đây.

Nếu thời gian hoặc ngân sách dự án đã sử dụng hết với khối lượng công việc hiện tại, thì việc thêm một thay đổi mới chắc chắn sẽ đẩy một tính năng có mức độ ưu tiên thấp hơn xuống dưới điểm giới hạn.

9. So sánh cặp - Paired Comparison

Phân tích so sánh cặp là một hoạt động để đánh giá một loạt các yêu cầu bằng cách so sánh chúng với nhau. Đây là một kỹ thuật hữu ích và dễ dàng để đánh giá và xếp hạng các yêu cầu, trong đó các tiêu chí đánh giá mang tính chủ quan. Điều này hữu ích khi các ưu tiên không đủ rõ ràng, khi các yêu cầu hoàn toàn khác với nhau, hoặc khi có ít dữ liệu khách quan để đưa ra quyết định.

Phân tích so sánh cặp thường được thực hiện với sự hỗ trợ của một ma trận. Ma trận này phải được thực hiện theo cách tránh so sánh một yêu cầu với chính nó hoặc trùng lặp với bất kỳ so sánh nào. Cách thực hiện phân tích so sánh cặp như sau:

• Xác định các yêu cầu được đánh giá.
• Xác định tiêu chí đánh giá để giúp đưa ra quyết định (ví dụ: quan trọng nhất, giá trị nhất hoặc dễ thực hiện nhất).
• Liệt kê tất cả các yêu cầu trên cột bên trái và hàng trên cùng của ma trận.
• Trong mỗi ô trống, so sánh yêu cầu trong hàng với yêu cầu trong cột, sau đó viết vào ô yêu cầu nào đáp ứng tốt hơn tiêu chí đánh giá.
• Lặp lại quá trình cho đến khi tất cả các cặp có thể được đánh giá.
• Đếm số lần mỗi yêu cầu đã được chọn.
• Xếp hạng các yêu cầu dựa trên số lượng của chúng.
• Cân nhắc các yêu cầu có thứ hạng cao nhất.

Ví dụ: giả sử nhóm muốn quyết định nên ưu tiên thực hiện tính năng nào. Sử dụng phân tích so sánh cặp để đưa ra quyết định này.

Tổng kết

Không có phương pháp nào tốt nhất để sử dụng trong việc đánh giá độ ưu tiên các tính năng trên mọi dự án. Dù sử dụng kỹ thuật nào, hãy cố gắng quan sát xem có bất kỳ vấn đề nào phát sinh trong quá trình đánh giá độ ưu tiên hay không, có thể là “thiếu sự tham gia của cả nhóm” hoặc “có quá nhiều mức độ ưu tiên được đánh hạng 1”. Mục tiêu là để hiểu được thứ tự tương đối của các tính năng/yêu cầu với nhau, thay vì chỉ đơn giản là gán nhãn cho các danh mục. Từ đó chúng ta có được một danh sách linh hoạt và có thể sắp xếp lại khi cần thiết. Điều này cho phép các nhóm Agile duy trì sự nhanh nhẹn để mang lại những tính năng có giá trị cao nhất cho khách hàng trong thời gian và ngân sách khả dụng của dự án.