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

Đáp án đúng: "To prioritize high-value requirements for early implementation". Phân loại Must-have và Should-have là cách xếp ưu tiên kiểu MoSCoW: Must là bắt buộc để sản phẩm có giá trị, Should là quan trọng nhưng có thể dời nếu thiếu nguồn lực. Mục đích là để đội làm trước những yêu cầu mang giá trị cao nhất và có căn cứ khi phải cắt bớt phạm vi. "To eliminate low-priority requirements altogether" sai vì Should-have không bị loại; yêu cầu ưu tiên thấp chỉ bị dời sang đợt sau, vẫn nằm trong danh sách. "To finalize coding strategies" sai vì xếp ưu tiên là hoạt động phân tích yêu cầu, không quyết định chiến lược viết mã. "To reduce the scope of non-functional requirements" sai vì phân loại này áp dụng cho mọi loại yêu cầu và không nhằm thu hẹp riêng yêu cầu phi chức năng; một thuộc tính chất lượng hoàn toàn có thể là Must-have.

Đáp án đúng: "$100". Kỹ thuật $100 (chia 100 đô la) cho mỗi bên liên quan một ngân sách tưởng tượng 100 đô để phân bổ cho các yêu cầu; yêu cầu nào nhận nhiều tiền hơn thì được ưu tiên cao hơn, nhờ đó mức quan trọng tương đối được lượng hóa bằng giá trị tiền tệ và người tham gia buộc phải đánh đổi. Phương án "Pairwise comparison" so sánh từng cặp yêu cầu để xem cái nào quan trọng hơn, không gán giá trị tiền. Phương án "MoSCoW" xếp yêu cầu vào các nhóm Must, Should, Could, Won’t theo mức cần thiết. Phương án "Three-level scale" chia yêu cầu thành ba mức như cao, trung bình, thấp dựa trên tầm quan trọng và độ khẩn cấp. Cả ba đều là kỹ thuật ưu tiên hóa hợp lệ nhưng không dùng giá trị tiền tệ.

Đáp án đúng: "In or out". Kỹ thuật In or out là cách ưu tiên hóa đơn giản nhất: nhóm bên liên quan xét từng yêu cầu và chỉ quyết định nhị phân là nó có vào bản phát hành này hay không, rất hợp khi danh sách ngắn hoặc cần chốt phạm vi nhanh. Phương án "Pairwise comparison" so sánh từng cặp yêu cầu, cho thứ hạng chi tiết nhưng tốn công khi số yêu cầu lớn và không cho kết quả nhị phân. Phương án "MoSCoW" xếp yêu cầu vào bốn nhóm Must, Should, Could, Won’t, tức nhiều hơn hai mức. Phương án "The $100 method" yêu cầu bên liên quan chia một ngân sách tưởng tượng giữa các yêu cầu, cho ra mức quan trọng tương đối chứ không phải quyết định vào hay ra.

Đáp án đúng: "It categorizes requirements into Must-have, Should-have, Could-have, and Won’t-have to prioritize effectively". MoSCoW xếp yêu cầu vào bốn nhóm ưu tiên: bắt buộc phải có, nên có, có thể có và lần này sẽ không làm. Khi có yêu cầu mới hoặc thay đổi phạm vi, nhóm đặt nó vào một nhóm rõ ràng, nên dễ quyết định cái gì vào bản phát hành, cái gì bị đẩy ra sau mà không phá vỡ cam kết với nhóm bắt buộc. Phương án "It eliminates the need for stakeholder reviews" sai vì xếp nhóm MoSCoW cần chính các bên liên quan thảo luận và đồng ý. Phương án "It focuses only on technical requirements" sai vì MoSCoW áp cho mọi loại yêu cầu, chủ yếu theo giá trị nghiệp vụ. Phương án "It avoids scope creep entirely" sai vì không kỹ thuật nào loại bỏ hoàn toàn phình phạm vi; MoSCoW chỉ giúp kiểm soát nó bằng ưu tiên rõ ràng.

Đáp án đúng: "To make sure the product delivers the most critical or valuable functionality as early as possible". Xếp ưu tiên yêu cầu thuộc hoạt động phân tích: vì thời gian và nguồn lực luôn có hạn, nhóm cần biết yêu cầu nào mang lại giá trị cao nhất hoặc quan trọng nhất để làm trước, nhờ đó sản phẩm đem lại giá trị sớm và nếu phải cắt giảm thì phần bị cắt là phần ít giá trị. "To ensure all desired functionality is delivered by the initial target date." sai vì xếp ưu tiên chính là thừa nhận không thể làm hết mọi thứ cùng lúc. "To eliminate the need for any future requirements changes" sai vì ưu tiên không ngăn được thay đổi, danh sách ưu tiên còn được cập nhật liên tục khi có yêu cầu mới. "To reduce the overall project budget by cutting features." chỉ là một hệ quả có thể xảy ra, mục đích chính là sắp thứ tự giao giá trị chứ không phải cắt ngân sách.