Đáp án đúng: B. "Whole Team" trong XP nói về THÀNH PHẦN của nhóm: mọi kỹ năng cần để giao được sản phẩm — phân tích, lập trình, kiểm thử, thiết kế, cùng đại diện khách hàng — đều phải có mặt trong nhóm, để nhóm tự chủ và không phải chờ bộ phận khác. A nói về cam kết chung, C nói về tinh thần và nhiệt huyết — đều là những điều tốt nhưng không phải nội dung thực hành này. D là "sit together", một thực hành RIÊNG và tách bạch của XP; ngoài ra "luôn luôn phải ngồi chung một phòng" cũng quá cứng so với thực tế nhóm phân tán.

Đáp án đúng: C. Agile chuyển gánh nặng từ tài liệu sang giao tiếp: cần Product Owner sẵn sàng, khách hàng tham gia đều đặn qua sprint review, các bên liên quan phản hồi liên tục. Chính đòi hỏi mức cộng tác cao và liên tục này là thách thức lớn nhất khi một tổ chức quen mô hình dự đoán chuyển sang Agile. A, B, D đều là đặc điểm của mô hình PREDICTIVE chứ không phải thách thức của Agile: yêu cầu cứng nhắc ở pha đầu, tài liệu nặng ở đầu dự án, và phản hồi khách hàng đến muộn — Agile sinh ra để loại bỏ đúng ba thứ này.

Đáp án đúng: A. Planning Poker đúng quy trình như mô tả: mỗi thành viên chọn thẻ ước lượng một cách độc lập và bí mật, tất cả lật thẻ cùng lúc; nếu con số chênh nhau nhiều thì người cao nhất và thấp nhất giải thích góc nhìn của mình, rồi cả nhóm ước lượng lại cho tới khi hội tụ. Việc chọn độc lập trước khi thảo luận là để tránh hiệu ứng mỏ neo theo người nói đầu tiên. B Card Sorting và D Story Board là kỹ thuật nhóm và sắp xếp hạng mục, không phải ước lượng. C Free Form là thảo luận mở, thiếu đúng bước ước lượng độc lập vốn là đặc trưng của Planning Poker.

Đáp án đúng: C. Sprint Review diễn ra cuối sprint: nhóm trình diễn Increment cho các bên liên quan, cùng nhau xem xét sản phẩm và điều chỉnh Product Backlog dựa trên phản hồi vừa nhận. Đúng hai vế của câu hỏi: kiểm tra increment và điều chỉnh backlog. A Sprint Planning là lúc lập kế hoạch, chưa có increment để xem. B Daily Scrum kiểm tra tiến độ hướng tới Sprint Goal và điều chỉnh Sprint Backlog, không phải Product Backlog. D Retrospective soi QUY TRÌNH làm việc của nhóm, không soi sản phẩm.

Đáp án đúng: A, B. Câu chuyện "I want the software to be easy to use" hỏng ở hai chỗ. Thứ nhất, không xác định được người dùng nào: "I" là ai, quản trị viên hay khách vãng lai, mỗi nhóm có định nghĩa "dễ dùng" khác hẳn. Thứ hai, "dễ dùng" không kiểm chứng được — không có tiêu chí chấp nhận nào cho phép nói story này đã xong hay chưa. C tuy cũng nói về người dùng nhưng lặp ý với A ở dạng hẹp hơn. D sai: giá trị của story vẫn rõ (phần mềm dễ dùng thì có ích). E sai: story không phải quá to mà là quá mơ hồ. ⚠ Nhãn trên đề ghi "Choose 2 answers" nhưng bản in chỉ tô đúng một phương án (B) — dữ liệu key của đề bị thiếu. Đã chốt đủ hai lỗi kinh điển của story này theo tài liệu môn.

Đáp án đúng: D. Agile Manifesto (2001) là một tuyên ngôn ngắn nêu bốn cặp giá trị được đề cao: cá nhân và tương tác hơn quy trình và công cụ; phần mềm chạy được hơn tài liệu đầy đủ; hợp tác với khách hàng hơn đàm phán hợp đồng; phản hồi với thay đổi hơn bám sát kế hoạch. Kèm theo là 12 nguyên tắc. A sai: Manifesto cố tình KHÔNG chỉ cách triển khai — nó là tuyên ngôn giá trị, việc "làm thế nào" thuộc về Scrum, XP, Kanban. B và C sai: đây là văn kiện chung của ngành do 17 người soạn năm 2001, không phải tài liệu sinh ra trong một dự án hay cho một khách hàng cụ thể.

Đáp án đúng: A. Continuous Delivery là thực hành giữ cho nhánh chính LUÔN ở trạng thái phát hành được nhờ pipeline tự động build - test - deploy, cho phép đưa thay đổi lên production thường xuyên và an toàn. Đây chính là thực hành triển khai đặc trưng của Agile. B Manual Cutover là chuyển đổi thủ công, chậm và rủi ro. C Parallel là chạy song song hệ cũ và hệ mới trong thời gian chuyển đổi — một chiến lược cutover, không phải nhịp giao hàng. D Big Bang là dồn toàn bộ thay đổi vào một lần chuyển, đối lập hẳn với tinh thần giao thường xuyên.

Đáp án đúng: A. Sprint Burndown Chart có trục hoành là thời gian của sprint, thường tính theo NGÀY từ ngày đầu tới ngày cuối; trục tung là khối lượng công việc còn lại, tính bằng giờ hoặc story point. C Hours là đơn vị của trục TUNG chứ không phải trục hoành — đây là nhầm lẫn hay gặp nhất ở câu này. B Tasks và D tên thành viên đều không phải trục nào của biểu đồ: burndown theo dõi tổng khối lượng còn lại của cả nhóm, không tách theo từng người.

Đáp án đúng: B. Tư duy Agile lấy nhu cầu người dùng làm chuẩn cuối cùng, cao hơn cả chữ nghĩa trong đặc tả đã ký. Đoạn hội thoại ở B đúng tinh thần "Responding to change over following a plan" và "Customer collaboration over contract negotiation": tính năng đã đúng đặc tả nhưng không phục vụ được người dùng thì vẫn nên sửa. A đo tiến độ bằng pha đã xong (yêu cầu và thiết kế = 50%) — Agile chỉ tính phần mềm chạy được. C bám vào việc chốt cứng nhu cầu và đưa vào hợp đồng, đúng kiểu đàm phán hợp đồng mà Manifesto đặt ở vế thấp hơn. D né họp mặt trực tiếp, đi ngược nguyên tắc giao tiếp mặt đối mặt là cách truyền đạt hiệu quả nhất.

Đáp án đúng: B. Sprint Burndown Chart vẽ xu hướng công việc CÒN LẠI theo thời gian trong một sprint: đường đi xuống dần về 0 vào ngày cuối. Nhóm dùng nó để thấy sớm nguy cơ không kịp cam kết và xử lý ngay trong sprint. C mô tả biểu đồ burn-UP (công việc đã hoàn thành, đường đi lên) — đây là cặp dễ nhầm nhất: burndown đo phần còn lại, burnup đo phần đã xong. A và D chỉ là chơi chữ với từ "burn" và "burnout", không liên quan tới nội dung biểu đồ.

Đáp án đúng: C. Product Backlog trong Scrum là danh sách được SẮP THỨ TỰ (ordered), do Product Owner chịu trách nhiệm: hạng mục giá trị nhất nằm trên cùng và cũng là hạng mục được làm mịn kỹ nhất, càng xuống dưới càng thô và càng ít ưu tiên. Nhờ đó nhóm luôn kéo từ trên xuống mà không phải bàn lại thứ tự ở mỗi sprint. A phân loại theo nhóm P1, P2, P3 không tạo được thứ tự tuyến tính rõ ràng trong từng nhóm. B sắp theo kích thước, D sắp ngẫu nhiên — cả hai đều bỏ qua yếu tố duy nhất có ý nghĩa với Product Owner là GIÁ TRỊ.

Đáp án đúng: B. Đặc trưng cốt lõi của dự án Agile là cộng tác liên tục — nhóm liên chức năng làm việc cùng nhau và cùng với khách hàng suốt dự án, thông qua daily scrum, sprint review, và sự hiện diện thường xuyên của Product Owner. A, C, D đều là đặc điểm của mô hình dự đoán: pha lập kế hoạch dài với ít phản hồi, bàn giao cứng nhắc giữa các đội chuyên môn, và dồn tài liệu chi tiết trước khi lập trình. Agile ra đời chính để thay thế ba thứ này.