Câu hỏi: SWR302 - Phần 11: Đặt thứ tự ưu tiên cho yêu cầu

Khi thực hiện quá trình ưu tiên và tất cả các yêu cầu đều có cùng mức độ ưu tiên, có thể nói rằng bạn chưa thực sự ưu tiên chúng. Điều này có nghĩa là quá trình ưu tiên không mang lại hiệu quả như mong đợi. Trong thực tế, nếu tất cả các yêu cầu đều có cùng mức độ ưu tiên, điều đó có nghĩa là bạn chưa phân biệt được giữa các yêu cầu quan trọng và không quan trọng. Quá trình ưu tiên là nhằm mục đích xác định và ưu tiên các yêu cầu quan trọng nhất, giúp bạn tập trung vào các công việc quan trọng và đạt được mục tiêu một cách hiệu quả hơn. Vì vậy, nếu tất cả các yêu cầu đều có cùng mức độ ưu tiên, có thể nói rằng bạn chưa thực sự ưu tiên chúng.

Phương pháp xác định ưu tiên yêu cầu dựa trên mức độ quan trọng và cấp thiết thuộc về kỹ thuật so sánh cặp đôi và xếp hạng (Pairwise comparison and rank ordering). Điều này có nghĩa là các yêu cầu sẽ được so sánh với nhau một cách cặp đôi để xác định mức độ quan trọng và cấp thiết của từng yêu cầu. Sau đó, các yêu cầu sẽ được xếp hạng theo mức độ quan trọng và cấp thiết để xác định ưu tiên thực hiện. Phương pháp này giúp đảm bảo rằng các yêu cầu quan trọng và cấp thiết được ưu tiên thực hiện trước.

Một trong những lý do không nên ưu tiên thực hiện một trường hợp sử dụng (use case) là vì nó sẽ không được thực hiện trong nhiều tháng. Điều này có thể dẫn đến việc lãng phí thời gian và nguồn lực vào một thứ không cần thiết. Thay vào đó, chúng ta nên ưu tiên những trường hợp sử dụng quan trọng và cần thiết cho hệ thống. Ví dụ, nếu một trường hợp sử dụng mô tả một phần của quy trình kinh doanh cốt lõi mà hệ thống cho phép, hoặc nếu nó được yêu cầu bởi một nhóm người dùng quan trọng, hoặc nếu nó cần thiết để tuân thủ các quy định pháp luật, thì đó là lý do để ưu tiên thực hiện. Tuy nhiên, nếu trường hợp sử dụng đó sẽ không được thực hiện trong nhiều tháng, thì chúng ta nên xem xét lại ưu tiên của nó.

Đáp án đúng: "Must, Should, Could, Won’t". MoSCoW là kỹ thuật xếp ưu tiên yêu cầu thuộc hoạt động phân tích, chia yêu cầu vào bốn nhóm: Must (bắt buộc có, thiếu thì đợt phát hành thất bại), Should (quan trọng nhưng có thể hoãn), Could (có thì tốt, làm nếu còn nguồn lực) và Won’t (lần này không làm, có thể xét ở đợt sau); hai chữ o viết thường chỉ để đọc thành tiếng. "Must, Should, Could, Will" sai ở chữ cuối: nhóm W là những thứ sẽ không làm trong đợt này, không phải sẽ làm. "Must, Should, Can, Will" sai cả hai chữ cuối, Can không phải tên nhóm và Will lại đảo nghĩa nhóm loại trừ. "Must, Shall, Could, Won’t" sai vì nhóm thứ hai là Should, thể hiện mức ưu tiên thấp hơn Must, còn shall trong văn bản yêu cầu thường mang nghĩa bắt buộc như Must.

Việc ưu tiên các yêu cầu là một bước quan trọng trong quy trình phát triển phần mềm. Mục đích chính của việc này là đảm bảo rằng nhóm phát triển tập trung vào các tính năng quan trọng nhất hoặc có tính cấp thiết nhất trước. Điều này giúp đảm bảo rằng sản phẩm cuối cùng đáp ứng được nhu cầu của khách hàng và mang lại giá trị cao nhất. Ngoài ra, việc ưu tiên các yêu cầu còn giúp xác định được từng phiên bản hoặc increment nào sẽ chứa các tính năng hoặc tập hợp yêu cầu cụ thể. Điều này giúp nhóm phát triển có thể lập kế hoạch và quản lý dự án một cách hiệu quả hơn.

Đáp án đúng: "Enhanced focus on high-value features". Xếp ưu tiên yêu cầu (requirements prioritization) là quyết định yêu cầu nào làm trước dựa trên giá trị, chi phí và rủi ro, để khi thời gian và nguồn lực có hạn nhóm vẫn giao được những tính năng mang lại nhiều giá trị nhất trước. Phương án "Improved project management" là hệ quả gián tiếp và quá chung, ưu tiên có hỗ trợ lập kế hoạch nhưng lợi ích trực tiếp của nó là tập trung vào giá trị. Phương án "Decreased stakeholder involvement" sai vì xếp ưu tiên đòi hỏi các bên liên quan tham gia nhiều hơn để cân nhắc giá trị. Phương án "Reduced scope creep" không phải lợi ích trực tiếp: phình phạm vi (scope creep) được kiểm soát chủ yếu bằng quy trình kiểm soát thay đổi, ưu tiên chỉ giúp quyết định yêu cầu mới thay chỗ yêu cầu nào.

Trước hết, chúng ta cần hiểu rằng việc ưu tiên là một cách để xử lý các yêu cầu cạnh tranh cho các nguồn lực hạn chế. Khi đó, việc xác định ưu tiên tương đối của từng khả năng sản phẩm cho phép chúng ta lập kế hoạch xây dựng để cung cấp giá trị với chi phí tối ưu. Trong quá trình này, chúng ta cần phân loại các khả năng sản phẩm theo mức độ ưu tiên cao hay thấp. Mức độ ưu tiên cao nhất thường được dành cho các khả năng sản phẩm mang lại giá trị cao nhất cho tổ chức, trong khi mức độ ưu tiên thấp nhất thường được dành cho các khả năng sản phẩm không quá quan trọng. Vì vậy, khi được hỏi về cách sắp xếp các mức độ ưu tiên, chúng ta cần chọn đáp án "tối đa, tối thiểu".

Việc thường xuyên đánh giá và cập nhật lại ưu tiên dựa trên mục tiêu kinh doanh đang phát triển là rất quan trọng. Điều này giúp đảm bảo rằng nỗ lực phát triển vẫn phù hợp với bối cảnh kinh doanh hiện tại. Khi mục tiêu kinh doanh thay đổi, ưu tiên cũng cần được điều chỉnh để đáp ứng nhu cầu mới. Nếu không, các dự án có thể trở nên không phù hợp hoặc không hiệu quả. Ngoài ra, việc cập nhật ưu tiên cũng giúp giảm thiểu rủi ro và tăng cường khả năng thành công của dự án. Điều này đòi hỏi sự linh hoạt và khả năng thích nghi trong quản lý dự án.

Đáp án đúng: "It categorizes requirements into Must-haves, Should-haves, Could-haves, and Won't-haves to guide prioritization". MoSCoW là kỹ thuật ưu tiên hoá yêu cầu chia yêu cầu thành bốn nhóm: Must là bắt buộc phải có, Should là quan trọng nên có, Could là có thì tốt, Won't là không làm trong đợt này; việc xếp nhóm dựa trên mức đóng góp của yêu cầu vào mục tiêu kinh doanh, giúp tập trung nguồn lực vào phần giá trị nhất. Phương án nói MoSCoW ưu tiên "solely based on stakeholder preferences" sai vì ý kiến bên liên quan chỉ là đầu vào, tiêu chí phải gắn với mục tiêu kinh doanh chứ không chỉ sở thích. Phương án "excludes business objectives from the prioritization process" đi ngược hẳn bản chất kỹ thuật này. Phương án "only considers technical specifications" sai vì MoSCoW xét giá trị nghiệp vụ, ràng buộc kỹ thuật chỉ là một yếu tố tham khảo.

Câu hỏi này yêu cầu bạn chọn phương pháp không liên quan đến kỹ thuật ưu tiên. Trong đó, 'In or out' không phải là một kỹ thuật ưu tiên. Kỹ thuật này thường được sử dụng để quyết định liệu một yêu cầu hoặc một dự án có được thực hiện hay không. Trong khi đó, các phương pháp khác như 'So sánh đôi và xếp hạng', 'Bảng thang ba mức', 'MoSCoW', 'Dựa trên rủi ro' đều liên quan đến việc ưu tiên các yêu cầu hoặc dự án.

Các kỹ thuật ưu tiên yêu cầu là các phương pháp được sử dụng để xác định mức độ ưu tiên của các yêu cầu trong một dự án. Trong số các lựa chọn trên, '1000' không phải là một kỹ thuật ưu tiên yêu cầu. 'Pairwise comparison' là kỹ thuật so sánh song song, 'In or out' là kỹ thuật xác định liệu một yêu cầu có nằm trong danh sách ưu tiên hay không, 'Three-level scale' là kỹ thuật sử dụng thang đo ba mức độ, 'MoSCoW' là kỹ thuật sử dụng chữ cái M, S, C, W để biểu thị mức độ ưu tiên. '1000' không phải là một trong những kỹ thuật này.

Phương pháp MoSCoW được sử dụng để phân loại các yêu cầu trong quá trình ưu tiên hóa. Theo phương pháp này, các yêu cầu được phân loại thành bốn loại chính: Must, Should, Could và Won't. 'Must' là các yêu cầu bắt buộc phải được thực hiện, 'Should' là các yêu cầu nên được thực hiện nhưng không bắt buộc, 'Could' là các yêu cầu có thể được thực hiện nếu có đủ thời gian và nguồn lực, và 'Won't' là các yêu cầu không được thực hiện. Phương pháp MoSCoW giúp các nhà phát triển và quản lý dự án xác định được ưu tiên của các yêu cầu và tập trung vào việc thực hiện các yêu cầu quan trọng nhất trước.

Mô hình Kano giúp phân tích yêu cầu người dùng bằng cách phân loại các tính năng thành ba loại: cơ bản, hiệu suất và thú vị. Các tính năng cơ bản là những tính năng cần thiết để sản phẩm hoạt động, chẳng hạn như khả năng hoạt động của một chiếc điện thoại. Các tính năng hiệu suất là những tính năng giúp sản phẩm hoạt động tốt hơn, chẳng hạn như tốc độ xử lý nhanh hơn. Các tính năng thú vị là những tính năng giúp sản phẩm trở nên thú vị hơn, chẳng hạn như khả năng chơi game. Mô hình Kano giúp các nhà phát triển hiểu rõ hơn về những gì người dùng mong đợi từ sản phẩm và giúp họ tập trung vào việc phát triển các tính năng quan trọng nhất.

Kỹ thuật ưu tiên yêu cầu dựa trên tầm quan trọng và cấp thiết dựa trên phương pháp so sánh cặp đôi và xếp hạng. Phương pháp này yêu cầu người tham gia phải so sánh từng cặp yêu cầu và xếp hạng chúng theo tầm quan trọng và cấp thiết. Điều này giúp đảm bảo rằng các yêu cầu quan trọng và cấp thiết được ưu tiên trước. Phương pháp này thường được sử dụng trong các dự án phát triển phần mềm để đảm bảo rằng các yêu cầu quan trọng và cấp thiết được ưu tiên trước.

Khi thực hiện quá trình ưu tiên và tất cả các yêu cầu đều có cùng mức độ ưu tiên, điều đó không có nghĩa là bạn đã thực sự ưu tiên chúng một cách đầy đủ. Trong thực tế, nếu tất cả các yêu cầu đều có cùng mức độ ưu tiên, điều đó có nghĩa là bạn chưa thực sự phân biệt được mức độ quan trọng của từng yêu cầu. Việc ưu tiên các yêu cầu đòi hỏi phải có sự phân tích và đánh giá kỹ lưỡng để xác định mức độ quan trọng của từng yêu cầu. Nếu tất cả các yêu cầu đều có cùng mức độ ưu tiên, điều đó có nghĩa là bạn chưa thực sự ưu tiên chúng một cách hiệu quả.

Kỹ thuật xác định ưu tiên yêu cầu dựa trên tầm quan trọng và cấp thiết thuộc về phương pháp MoSCoW. MoSCoW là một kỹ thuật được sử dụng để xác định và sắp xếp các yêu cầu của dự án dựa trên tầm quan trọng và cấp thiết. Các yêu cầu được phân loại thành bốn loại: Must-Haves (phải có), Should-Haves (nên có), Could-Haves (có thể có) và Won't-Haves (không có). Phương pháp này giúp cho các nhà phát triển và quản lý dự án xác định được những yêu cầu quan trọng nhất và ưu tiên thực hiện chúng trước.

Kỹ thuật thang đo ba mức (Three-level scale technique) là một phương pháp phân loại yêu cầu dựa trên mức độ quan trọng và cấp độ khẩn cấp. Theo kỹ thuật này, các yêu cầu có mức độ quan trọng cao và cấp độ khẩn cấp cao được coi là yêu cầu có mức độ ưu tiên cao. Ngược lại, các yêu cầu có mức độ quan trọng thấp và cấp độ khẩn cấp thấp được coi là yêu cầu có mức độ ưu tiên thấp. Câu trả lời sai về kỹ thuật thang đo ba mức là: 'Yêu cầu có mức độ ưu tiên trung bình là quan trọng (khách hàng cần khả năng này) nhưng không khẩn cấp (họ có thể chờ đợi cho bản phát hành sau).'

Đáp án đúng: "It helps in delivering the most critical or valuable functionality as early as possible, ensuring maximum business value within project constraints.". Trong dự án agile, backlog sản phẩm được sắp ưu tiên liên tục để mỗi vòng lặp (iteration) giao phần có giá trị cao nhất trước; khi kỳ vọng của khách hàng cao mà thời gian ngắn, ưu tiên hoá (prioritization) là cách quyết định làm gì trước, hoãn gì, để giá trị kinh doanh đạt tối đa trong giới hạn thời gian, ngân sách và nhân lực. Phương án nói việc ưu tiên giúp quản lý dự án làm "without customer input, focusing solely on cost and efficiency" sai vì ưu tiên hoá cần khách hàng hoặc product owner tham gia đánh giá giá trị, không thể chỉ dựa vào chi phí. Phương án cho rằng ưu tiên để bỏ bớt tính năng và chỉ đảm bảo "only critical bugs are fixed before release" sai vì ưu tiên hoá áp cho mọi hạng mục trong backlog, mục đích là giao giá trị chứ không phải chỉ sửa lỗi nghiêm trọng. Phương án cho quản lý dự án "choose which requirements to ignore" chỉ theo ngân sách và nhân sự sai vì ưu tiên không phải đơn phương gạt bỏ yêu cầu mà là sắp thứ tự cùng các bên liên quan, cân nhắc giá trị, chi phí và rủi ro.

Đáp án đúng: "It ensures that high-value requirements are implemented first.". Khi các bên liên quan đưa ra yêu cầu xung đột hoặc vượt quá nguồn lực, ưu tiên hoá (prioritization) là hoạt động phân tích giúp quyết định cái gì làm trước dựa trên giá trị kinh doanh, chi phí, rủi ro; nhờ đó xung đột được giải quyết bằng tiêu chí chung thay vì theo ai nói to hơn, và phần giá trị cao nhất được giao sớm. "It eliminates non-functional requirements from consideration." sai vì ưu tiên hoá áp dụng cho cả yêu cầu phi chức năng; thuộc tính chất lượng như bảo mật hay hiệu năng có thể được xếp ưu tiên rất cao. "It finalizes all requirements before the design phase." sai vì xếp ưu tiên không chốt cứng toàn bộ yêu cầu; danh sách ưu tiên còn được xem lại khi có thay đổi. "It focuses on budget over stakeholder needs" sai vì ưu tiên hoá cân nhắc chi phí cùng với giá trị cho bên liên quan, không đặt ngân sách lên trên nhu cầu của họ.

Đáp án đúng: "By categorizing requirements as Must-have, Should-have, Could-have, and Won’t-have". MoSCoW là kỹ thuật ưu tiên hóa yêu cầu trong hoạt động phân tích và lập kế hoạch phát hành, xếp mỗi yêu cầu vào bốn nhóm: Must (bắt buộc phải có), Should (nên có nhưng không sống còn), Could (có thì tốt nếu còn thời gian) và Won’t (lần này sẽ không làm). Nhờ các nhóm rõ nghĩa, bên liên quan và đội phát triển dễ thống nhất phạm vi cho từng bản phát hành. Phương án "By focusing on technical feasibility" sai vì MoSCoW dựa trên mức cần thiết với nghiệp vụ, tính khả thi kỹ thuật chỉ là một yếu tố tham khảo. Phương án "By skipping stakeholder engagement" sai vì việc xếp nhóm đòi hỏi bên liên quan cùng thảo luận và đồng thuận. Phương án "By eliminating low-priority requirements" sai vì nhóm Won’t không xóa yêu cầu mà chỉ ghi nhận rằng nó không nằm trong lần giao này và có thể xem lại ở bản sau.