Đánh giá độ ưu tiên trong Agile, tiết kiệm 50% thời gian triển khai

Đánh giá độ ưu tiên trong Agile, tiết kiệm 50% thời gian triển khai
Tô Lãm

09/05/2024

304

0

Chia sẻ lên Facebook
Đánh giá độ ưu tiên trong Agile, tiết kiệm 50% thời gian triển khai

Đánh giá độ ưu tiên trong Agile là điều vô cùng quan trọng, khi đánh giá đúng, bạn có thể tiết kiệm được tới 50% thời gian triển khai. Nếu bạn vẫn chưa biết cách xác định thứ tự thực hiện hạng mục trong backlog sản phẩm, hãy tham khảo bài viết dưới đây của Topchuyengia. Chúng tôi sẽ cho bạn biết các phương pháp phổ biến và các yếu tố cần xem xét khi đánh giá độ ưu tiên trong Agile.


Nếu muốn được hướng dẫn cách áp dụng phương pháp MoSCoW vào dự án cá nhân của mình? Hãy đặt lịch tư vấn miễn phí cùng chuyên gia BA trên app Askany ngay hôm nay!

Các yếu tố cần xem xét khi đánh giá độ ưu tiên trong Agile là gì?

Đánh giá độ ưu tiên trong Agile
Nhãn

Khi đánh giá độ ưu tiên trong Agile, Business Analyst cần lưu ý những yếu tố này: 

Giá trị cho khách hàng

Để đảm bảo sự ưu tiên hiệu quả trong phương pháp Agile, quan trọng nhất là xác định giá trị mà mỗi tính năng mang lại cho khách hàng. Việc đánh giá mức độ quan trọng của tính năng đối với người dùng cuối sẽ giúp nhóm phát triển tập trung vào những yếu tố thực sự mang lại giá trị cho người dùng.

Chi phí và rủi ro

Trong quá trình đánh giá độ ưu tiên, nhóm cũng cần xem xét chi phí triển khai và rủi ro liên quan đến từng tính năng. Việc xác định chi phí và mức độ dự đoán được của tính năng sẽ hỗ trợ quá trình ra quyết định và lập kế hoạch phát triển.

Lợi ích kinh doanh

Một góc nhìn quan trọng là ảnh hưởng của từng tính năng đối với mục tiêu kinh doanh. Nhóm cần đánh giá cách mà tính năng ảnh hưởng đến sự phát triển và doanh thu, giúp ưu tiên các tính năng theo hướng tối ưu cho mục tiêu kinh doanh.

Ưu tiên của khách hàng

Khảo sát và lắng nghe ý kiến của khách hàng là yếu tố chủ chốt để xác định ưu tiên. Sự hiểu rõ về mong đợi và yêu cầu cụ thể từ khách hàng đối với từng tính năng giúp định hình mức độ ưu tiên.

Sự linh hoạt

Việc đánh giá khả năng thay đổi và linh hoạt của từng tính năng rất quan trọng. Điều này bao gồm việc xác định tính khẩn cấp và sự cần thiết của tính năng cho dự án, giúp nhóm thích nghi linh hoạt với thay đổi

Khả năng triển khai

Xuất phát từ việc xác định khả năng triển khai và tích hợp, nhóm có thể đánh giá khả năng giao hàng nhanh chóng và hiệu quả của từng tính năng. Việc này đóng vai trò quan trọng trong việc xác định kế hoạch và tiến độ dự án.

Quy mô và ưu tiên tổng thể

Để đảm bảo ưu tiên hợp lý, nhóm cần xem xét quy mô tổng thể của tính năng trong ngữ cảnh toàn bộ dự án. Điều này giúp đảm bảo rằng ưu tiên được đặt ra một cách cân nhắc và phản ánh mục tiêu tổng thể của dự án.

Các phương pháp đánh giá độ ưu tiên phổ biến

Đánh giá độ ưu tiên trong Agile
Những cách đánh giá độ ưu tiên trong Agile

Đánh giá độ ưu tiên trong Agile có thể được thực hiện thông qua các phương pháp sau: 

Phương pháp đơn giản

Một phương pháp đơn giản để đánh giá mức độ ưu tiên là sử dụng nhãn như "Mức độ ưu tiên 1," "Mức độ ưu tiên 2," và "Mức độ ưu tiên 3," và tiếp tục theo cấp độ ưu tiên. Tuy nhiên, mặc dù phương pháp này đơn giản và dễ hiểu, nhưng nó có nhược điểm khi mọi mục đều được gắn nhãn "Mức độ ưu tiên 1," có thể gây khó khăn trong việc quản lý khi có nhiều mục được đánh giá là "Mức độ ưu tiên 1."

 

Phương pháp này có thể gặp vấn đề khi khách hàng hoặc Product Owner ít khi chỉ định mức độ ưu tiên là "Mức độ ưu tiên 2" hoặc "3," có thể dẫn đến việc mất đi khả năng phân biệt giữa các mức độ ưu tiên thực sự. Tương tự, việc sử dụng đánh giá "cao," "trung bình," và "thấp" cũng có thể gặp vấn đề tương tự, khi danh sách "Ưu tiên cao" có thể trở nên quá tải và mất đi tính chính xác trong đánh giá mức độ ưu tiên.

Mô hình MoSCoW

Đánh giá độ ưu tiên trong Agile
Mô hình MoSCoW

Đây là một phương pháp đánh giá ưu tiên xuất phát từ các chữ cái đầu tiên của các khái niệm "Must have," "Should have," "Could have," và "Won’t have" (hoặc "Would like to have, but not this time"). Đây là một cách tiếp cận độc đáo và mạnh mẽ để xác định mức độ ưu tiên của yêu cầu và tính năng trong dự án.

  • Must have (Phải có): Đây là những yêu cầu cơ bản, không thể thiếu để hệ thống hoạt động đầy đủ và có giá trị.
  • Should have (Nên có): Các tính năng quan trọng giúp đảm bảo hệ thống hoạt động chính xác và đáp ứng nhu cầu.
  • Could have (Có thể có): Những tính năng bổ sung, tăng giá trị hữu hình cho sản phẩm.
  • Won’t have (Không có): Đại diện cho các yêu cầu không cần thiết trong lúc này, có thể xem xét trong tương lai.

Ưu điểm:

  • Danh mục ưu tiên dễ xác định, giúp tạo ra hệ thống ưu tiên rõ ràng.
  • Mô hình linh hoạt trong việc quyết định mức độ ưu tiên của từng yêu cầu.

Nhược điểm:
Mặc dù rõ ràng, nhưng "Won’t have" có thể tạo hiểu lầm nếu không được giải thích đầy đủ bởi Business Analyst.

Monopoly Money

Mô hình đánh giá ưu tiên Monopoly Money là một cách tiếp cận độc đáo và sáng tạo, sử dụng yếu tố tiền bạc như một công cụ để đánh giá và quản lý mức độ ưu tiên của các tính năng và yêu cầu trong dự án.

  • Các bên liên quan được cung cấp một số tiền tương đương với ngân sách dự án và được yêu cầu phân phối số tiền đó giữa các tính năng của hệ thống.
  • Mức độ ưu tiên chung của các thành phần hệ thống được xác định bằng cách sử dụng số tiền như một đơn vị đo lường.

Ưu điểm:

  • Đánh giá ưu tiên dựa trên ngân sách giúp Business Analyst (BA) tập trung vào những tính năng quan trọng nhất và phản ánh sự quan trọng của nguồn lực.
  • Monopoly Money hiệu quả khi được giới hạn ở việc ưu tiên các tính năng cụ thể của sản phẩm hoặc phần mềm.

Nhược điểm:

  • Monopoly Money có thể gây thắc mắc và hiểu lầm nếu các bên liên quan bắt đầu đặt câu hỏi về việc sử dụng nguồn lực cho các hoạt động khác ngoài việc phát triển tính năng.
  • Phương pháp này hoạt động hiệu quả nhất khi chỉ sử dụng để ưu tiên tính năng và không linh hoạt đối với các khía cạnh khác của dự án.

Phương pháp 100 điểm

Phương pháp 100 điểm được sáng tạo bởi Dean Leffingwell và Don Widrig, là một công cụ đánh giá ưu tiên linh hoạt và hiệu quả, thường được áp dụng trong nhiều trường hợp khác nhau để xác định mức độ quan trọng và ưu tiên của các yêu cầu và tính năng trong một dự án.

Cách triển khai:

  • Mỗi người tham gia được phân phối 100 điểm để bỏ phiếu cho các yêu cầu quan trọng nhất theo quan điểm của họ.
  • Bên liên quan có tự do phân phối 100 điểm của họ theo bất kỳ cách nào.
    Ví dụ: Các bên liên quan có thể cấp 30 điểm cho yêu cầu A, 15 điểm cho yêu cầu B, hoặc toàn bộ 100 điểm cho một yêu cầu C nếu đó là ưu tiên quan trọng nhất đối với họ.

Ưu điểm:

  • Phương pháp này mang lại sự linh hoạt cho các bên liên quan, cho phép họ tự do quyết định mức độ quan trọng của từng yêu cầu.
  • Bằng cách cho mỗi người có quyền lựa chọn ưu tiên của mình, phương pháp này có thể tạo ra sự đồng thuận đối với các yêu cầu chính.

Nhược điểm:

  • Đòi hỏi sự hiểu biết chặt chẽ về mỗi yêu cầu và tính năng để đảm bảo điểm được phân phối công bằng và chính xác.
  • Sự chênh lệch trong quá trình đánh giá do góc nhìn của mỗi người có thể tạo ra động thái không nhất quán trong quá trình ưu tiên hóa.

Dot Voting hoặc Multi-Voting

Đánh giá độ ưu tiên trong Agile
Dot Voting hoặc Multi-Voting

Dot Voting hoặc Multi-Voting là một kỹ thuật đánh giá ưu tiên, trong đó mỗi bên liên quan được trang bị một số lượng dấu chấm, điểm, hoặc sao để phân phối giữa các tùy chọn hoặc yêu cầu. Phương pháp này tập trung vào việc sử dụng ý kiến đa dạng của nhóm để xác định sự quan trọng và ưu tiên của từng mục trong một danh sách.

Cách triển khai:

Mỗi thành viên trong nhóm nhận một số lượng dấu chấm xác định trước, ví dụ như 8 dấu chấm, để phân phối giữa các tùy chọn hoặc yêu cầu.

 

Thành viên có thể phân phối dấu chấm của mình bằng bất kỳ cách nào, đồng thời phải chỉ ra sự quan trọng của từng mục.

 

Ưu điểm:

  • Dot Voting cho phép mỗi người đóng góp dựa trên quan điểm và ưu tiên cá nhân.
  • Sự đa dạng về ý kiến trong kỹ thuật này giúp BA đưa ra quyết định dựa trên sự đồng thuận.
     

Nhược điểm:

  • Yêu cầu sự chú ý tích cực từ các thành viên để phân phối dấu chấm công bằng và chính xác.
  • Trong các nhóm nhỏ, ý kiến của một số người có thể ảnh hưởng trực tiếp đến kết quả cuối cùng.

Phân tích Kano – Kano Analysis

Phân tích Kano là một công cụ quan trọng trong đánh giá ưu tiên, được sử dụng để phân loại sở thích của khách hàng thành bốn loại cơ bản. Các bên liên quan có thể tận dụng kỹ thuật này để hiểu rõ hơn về cách nhu cầu của khách hàng ảnh hưởng đến sự hài lòng.

 

Cách triển khai:

  • Delighters / Exciters: Đây là những tính năng mang lại lợi ích bất ngờ và giá trị cao cho khách hàng. Ví dụ: Giao diện đẹp mắt và hiệu ứng 3D. Triển khai những tính năng này thường khiến sự hài lòng của khách hàng tăng lên.
  • Satisfiers: Những tính năng này mang lại giá trị cho khách hàng, và nếu không triển khai, sự hài lòng có thể giảm đi. Đây là những yếu tố cần được chú ý để duy trì mức hài lòng hiện tại.
  • Dissatisfiers: Đây là tính năng có thể khiến khách hàng không hài lòng nếu bị bỏ qua, nhưng nếu triển khai cũng không chắc chắn tăng sự hài lòng. Việc đánh giá và quản lý các dissatisfiers là quan trọng để tránh tình trạng tiêu cực.
  • Indifferent: Những tính năng này không ảnh hưởng đến sự hài lòng của khách hàng nếu được triển khai hay không.


Ưu điểm:

  • Phân tích Kano giúp đội ngũ dự án hiểu rõ hơn về nhu cầu và mong đợi của khách hàng.
  • Quyết định về delighters, satisfiers, dissatisfiers, và indifferent giúp tập trung vào những tính năng quan trọng nhất.

Nhược điểm:

 

Đòi hỏi quá trình nghiên cứu chi tiết để xác định đúng loại tính năng vào từng danh mục.

 

Mô hình ưu tiên yêu cầu

Mô hình ưu tiên yêu cầu là một phương pháp tính toán mức độ ưu tiên chặt chẽ, dựa trên lợi ích, chi phí và rủi ro của từng tính năng được đề xuất. Với cách tiếp cận này, quy trình đánh giá trở nên khoa học hóa, giúp đội ngũ dự án đưa ra quyết định có cơ sở hơn.

 

Cách triển khai:

  • Khách hàng đánh giá lợi ích khi tính năng được thực hiện 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 và rủi ro liên quan.
  • Điểm cho mỗi yếu tố được nhập vào ma trận trọng số, từ đó tính toán mức độ ưu tiên tương đối của các tính năng.


Ưu điểm:

  • Quyết định dựa trên dữ liệu, đảm bảo tính khoa học và công bằng.
  • Kết hợp lợi ích, chi phí và rủi ro để đánh giá tính năng toàn diện.


Nhược điểm:

  • Đòi hỏi nhiều dữ liệu chi tiết và đánh giá chặt chẽ từ cả khách hàng và nhóm phát triển.
  • Quy trình đánh giá có thể phức tạp và yêu cầu sự chuyên sâu về toán học từ các bên liên quan.

Xếp hạng độ ưu tiên tương đối

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, bất kể bạn đang sử dụng mô hình đánh giá gì. Vì lý do này, bạn có thể liệt kê các tính năng theo thứ tự ưu tiên tương đối, bằng cách lập 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.).

Dưới đây là ví dụ về danh sách ưu tiên tương đối đơn giản như sau:

đánh giá độ ưu tiên trong Agile

 

Trong hình bên trên, các tính năng được liệt kê theo thứ tự ưu tiên từ A-D. Nếu trong trường hợp cần phải cắt giảm yêu cầu để đáp ứng về ngân sách/ thời gian thì chắc chắn E chính là mục chúng ta phải điều chỉnh đầu tiên.

Đánh giá độ ưu tiên tương đối cũng cho chúng ta cơ sở để quyết định xem có nên tích hợp các thay đổi hay không. Khi có yêu cầu cần được thay đổi, nhóm có thể hỏi PO - 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 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 minh họa dưới đây.

 

Đánh giá độ ưu tiên trong Agile

Nếu thời gian hoặc ngân sách của dự án chỉ đủ để đáp ứng 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 sẽ đẩy một tính năng có độ ưu tiên thấp hơn xuống dưới điểm giới hạn.

 

So sánh cặp - Paired Comparison

Paired Comparison là một hoạt động đánh giá 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 dễ nhưng hữu ích để đánh giá và xếp hạng các yêu cầu. Trong đó các tiêu chí đánh giá sẽ mang tính chủ quan. Bạn nên áp dụng nó khi các ưu tiên chưa đủ rõ ràng, khi có ít dữ liệu khách quan để đưa ra quyết định hoặc khi các yêu cầu hoàn toàn khác với nhau.

Phân tích so sánh cặp thường được hỗ trợ thực hiện bởi một ma trận. Ma trận này không được 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ụ thể, cách thực hiện phân tích so sánh cặp như sau:

  • Xác định yêu cầu cần được đánh giá.
  • Xác định tiêu chí đánh giá để đưa ra quyết định (ví dụ: quan trọng nhất, dễ thực hiện nhất,..).
  • Liệt kê tất cả các yêu cầu trong cột bên trái, trên cùng của ma trận.
  • Trong mỗi ô trống, tiến hành 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í đề ra.
  • Lặp lại tương tự 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 thu thập.
  • Xem xét các yêu cầu có thứ hạng cao nhất.

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

Đánh giá độ ưu tiên trong Agile

Đánh giá độ ưu tiên trong Agile là một bước không thể bỏ qua trong cả quá trình thực hiện dự án phần mềm. Thông qua các phương pháp như Kano Analysis, Dot Voting hay MoSCoW, hy vọng Business Analyst sẽ tìm được cách sắp xếp công việc khoa học và linh hoạt. Nếu BA đang không biết nên chọn phương pháp đánh giá độ ưu tiên nào phù hợp với dự án thì đừng ngại lắng nghe lời khuyên hữu ích từ những chuyên gia uy tín tại ứng dụng Askany nhé!

Bình luận

Kinh nghiệm thực tế

Tư vấn 1:1

Uy tín

Đây là 3 tiêu chí mà TOPCHUYENGIA luôn muốn hướng tới để đem lại những thông tin hữu ích cho cộng đồng