Khám phá 7 phương pháp đánh giá độ ưu tiên trong Agile

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

Đánh giá độ ưu tiên trong Agile là gì? Trong Agile, quyết định về độ ưu tiên của các tính năng là một phần quan trọng để Business Analyst đảm bảo dự án tiến triển hiệu quả. 7 phương pháp đánh giá độ ưu tiên trong Agile sẽ giúp BA xác định những tính năng cần thiết. Vì vậy, chúng ta hãy cùng khám phá những phương pháp này để nâng cao hiệu suất của dự án Agile nhé!

Trên thực tế, có nhiều hơn 7 phương pháp đánh giá độ ưu tiên trong Agile và điều này có thể làm cho BA hoang mang trong quá trình chọn lựa và áp dụng vào dự án phát triển sản phẩm phần mềm. Tuy nhiên, đừng lo lắng, Askany ở đây để hỗ trợ bạn. Bạn có thể trò chuyện 1:1 từ xa với những chuyên gia BA giàu kinh nghiệm, kỹ năng và kiến thức BA tại nền tảng Askany để tìm ra hướng giải quyết phù hợp nhất nhé!

Các mô hình đánh giá độ ưu tiên trong Agile

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

Mô hình đơn giản

Một cách tiếp cận đơn giản để đánh giá mức độ ưu tiên là sử dụng nhãn “Mức độ ưu tiên 1”, “Mức độ ưu tiên 2”, “Mức độ ưu tiên 3”, và cứ tiếp tục. Mặc dù phương pháp này dễ hiểu, nhưng nó có thể gặp khó khăn vì thường ngày, mọi thứ đều được gắn nhãn “Mức độ ưu tiên 1”. Điều này có thể dẫn đến việc mô hình trở nên không hiệu quả khi có quá nhiều mục được đánh giá là “Mức độ ưu tiên 1”.

Khách hàng hoặc Product Owner (PO) thường ít khi yêu cầu một tính năng mới và chỉ định mức độ ưu tiên là “Mức độ ưu tiên 2” hoặc “3”, bởi họ có thể nghĩ rằng các mục có mức độ ưu tiên thấp có thể bị loại bỏ khỏi dự án. 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ể gặp vấn đề tương tự. Nếu không có lý do chính đáng được cung cấp cho việc đánh giá các mục có độ ưu tiên “cao”, danh sách “Ưu tiên cao” có thể trở nên quá tải, làm mất đi tính chính xác của mức độ ưu tiên.

Ngoài ra, bạn có thể tìm hiểu thêm về quản lý dự án theo mô hình Agile mà các chuyên gia BA đã chia sẻ cho bạn

Mô hình MoSCoW

Mô hình đánh giá ưu tiên MoSCoW 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”), là một cách tiếp cận rất độ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ó): Các yêu cầu hoặc tính năng “Must have” là những yêu cầu cơ bản, không thể thiếu để hệ thống hoạt động một cách đầy đủ và có giá trị.
  • Should have (Nên có): Đây là các tính năng rất quan trọng; có chúng giúp đảm bảo hệ thống hoạt động chính xác và đáp ứng đúng nhu cầu.
  • Could have (Có thể có): Những tính năng này là các bổ sung, tăng thêm giá trị hữu hình cho sản phẩm.
  • Won’t have (Không có): Hoặc “Would like to have, but not this time” đại diện cho các yêu cầu không cần thiết trong lúc này và có thể được xem xét trong tương lai.

Ưu điểm:

  • Các danh mục ưu tiên trong MoSCoW dễ xác định, giúp tạo ra một hệ thống ưu tiên rõ ràng.
  • Mô hình cho phép sự 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 đôi khi “Won’t have” có thể tạo hiểu lầm nếu không được BA giải thích đầy đủ.

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, đưa vào dự án 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.

  • 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.
  • Xác định mức độ ưu tiên chung của các thành phần hệ thống 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 BA tập trung vào những tính năng quan trọng nhất và đồng thời 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.
  • Monopoly Money 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

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

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 hiệu quả và linh hoạt, chủ yếu được áp dụng trong nhiều trường hợp khác nhau. Đây là một cách tiếp cận độc đáo để 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ó thể tự do phân phối 100 điểm của họ theo bất kỳ cách nào.
    Ví dụ: Stakeholders 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 khác nhau

Dot Voting hoặc Multi-Voting

Dot Voting hoặc Multi-Voting là một kỹ thuật đánh giá ưu tiên mà 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 hay yêu cầu. Phương pháp này tập trung vào việc tận 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 hay yêu cầu.
  • Thành viên có thể phân phối dấu chấm của mình 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 cá nhân và ưu tiên cá nhân.
  • Sự đa dạng về ý kiến, kỹ thuật này giúp BA đưa ra quyết định dựa trên đồ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. Việc 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 nào là 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.

>>>Tham khảo: Khóa học Business Analyst từ cơ bản đến nâng cao dành cho bạn.

Đánh giá độ ưu tiên trong Agile là chìa khóa để xây dựng sản phẩm thành công. Bằng cách chọn lựa giữa 7 phương pháp đánh giá độ ưu tiên trong Agile, BA không chỉ đảm bảo rằng nhóm của mình đang làm những công việc quan trọng mà còn tạo nên một quy trình làm việc linh hoạt và sáng tạo.

Nếu BA đang gặp khó khăn về đánh giá độ ưu tiên trong Agile mà không tìm được giải pháp thì đừng ngại lắng nghe lời khuyên hữu ích đến từ những chuyên gia giàu kinh nghiệm trong ngành tại ứng dụng Askany nhé!

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *