Đáp án đúng: B. Bảy nguyên tắc Lean gồm Eliminate Waste, Amplify Learning, Decide as Late as Possible, Deliver as Fast as Possible, Empower the Team, Build Quality In, See the Whole. Trong đó Amplify Learning là nguyên tắc nói thẳng về việc tăng cường các vòng phản hồi: phát triển phần mềm là hoạt động học liên tục, nên rút ngắn và nhân nhiều vòng feedback để học nhanh hơn. A Defer Commitment nói về việc trì hoãn quyết định tới thời điểm cuối cùng còn đảo ngược được. C Eliminate Waste nói về loại bỏ lãng phí. D Build Quality In nói về việc cài chất lượng vào quy trình thay vì kiểm tra ở cuối.
Quiz: SWE201c_DE_297 - Có đáp án và giải thích chi tiết
Phiên có lưu tiến độ dùng toàn bộ 48 câu của bộ đề để tiến độ khớp với máy chủ.
Bạn cần đăng nhập để bắt đầu làm bài và lưu tiến độ.
48
Không giới hạn
0
48
48
Xem trước câu hỏi
Đáp án đúng: A. Kanban có sáu thực hành cốt lõi: trực quan hoá dòng công việc, giới hạn công việc đang làm dở (WIP), quản trị dòng chảy, làm rõ chính sách quy trình, triển khai vòng phản hồi, và cải tiến bằng mô hình. Daily stand-up KHÔNG nằm trong đó — đó là sự kiện đặc trưng của Scrum. Kanban không quy định cuộc họp bắt buộc nào. B, C, D, E đều là thuộc tính cốt lõi thật của Kanban. Đây là điểm phân biệt hay bị nhầm: nhiều nhóm dùng Kanban vẫn họp hằng ngày, nhưng đó là lựa chọn của nhóm chứ không phải yêu cầu của phương pháp.
Đáp án đúng: B. Nút thắt là mô-đun đường găng bị chậm, khiến thời gian dành cho kiểm thử bị cắt ngắn. Driver và stub là thứ cho phép kiểm thử một mô-đun mà không cần các mô-đun xung quanh hoàn thiện — chúng lại là công việc độc lập, vừa sức thực tập sinh và làm được NGAY BÂY GIỜ song song với đội chính. Khi mô-đun đường găng xong, bộ khung kiểm thử đã sẵn sàng, bù được phần lịch bị mất. A và C đều để đội kiểm thử làm việc mà không có driver/stub, tức chấp nhận kiểm thử yếu đi đúng lúc thời gian đã ít. D không thay đổi gì và đẩy thực tập sinh sang viết tài liệu — bỏ phí nguồn lực đúng lúc cần nhất.
Đáp án đúng: B. Bốn pha của Unified Process kết thúc bằng bốn cột mốc: Inception - Lifecycle Objectives (đồng thuận về mục tiêu và việc có làm tiếp dự án hay không), Elaboration - Lifecycle Architecture (đồng thuận về hướng tiếp cận kỹ thuật, kiến trúc nền đã được chứng minh bằng bản chạy được), Construction - Initial Operational Capability, Transition - Product Release. A chính là mốc Lifecycle Objectives của pha Inception. C là mốc Product Release ở cuối pha Transition. Nhớ theo cặp: Objectives hỏi "có nên làm không", Architecture hỏi "làm bằng cách nào".
Đáp án đúng: B. Bốn khía cạnh của tính module trong thiết kế phần mềm là modularity, coupling, cohesion và information hiding (kèm data encapsulation). Polymorphism là một cơ chế của lập trình hướng đối tượng — cách một lời gọi cùng tên cho ra hành vi khác nhau tuỳ kiểu thực tế — chứ không phải một khía cạnh của thiết kế module. A, C, D đều là khía cạnh thiết kế thật: chia hệ thống thành module, đo mức phụ thuộc giữa các module, và đo mức gắn kết bên trong mỗi module.
Đáp án đúng: B. Stage-Gate chia dự án thành các stage (giai đoạn làm việc) ngăn cách bởi các gate (cổng). Tại mỗi cổng, ban quản trị rà soát sản phẩm của giai đoạn vừa xong theo bộ tiêu chí định trước và ra quyết định go / kill / hold / recycle. Chính cơ chế phán quyết bắt buộc tại điểm chuyển giai đoạn này là thứ giữ chất lượng: không đạt thì không được đi tiếp. A, C, D đều là việc phá bỏ đúng cơ chế đó — bỏ review, phớt lờ rủi ro, không kiểm thử — nên không thể là câu trả lời cho việc bảo đảm chất lượng.
Đáp án đúng: B. Incremental giao sản phẩm theo từng phần chạy được, nên người dùng thấy và góp ý sớm hơn hẳn Waterfall vốn chỉ giao ở cuối. Cái giá phải trả là mỗi lần giao lại phải tích hợp phần mới vào phần cũ, nhiều lần tích hợp thì độ phức tạp và rủi ro tích hợp tăng lên. A đảo ngược vế đầu: Incremental cho phản hồi NHANH hơn chứ không chậm hơn. C tự mâu thuẫn — "kém linh hoạt nhưng thích ứng". D nói về quản trị rủi ro, đó là đặc trưng của Spiral chứ không phải Incremental.
Đáp án đúng: C. Bảy nguyên tắc Lean là Eliminate Waste, Amplify Learning, Decide as Late as Possible, Deliver as Fast as Possible, Empower the Team, Build Quality In, See the Whole. "Maximize Documentation" không có trong danh sách và còn đi ngược tinh thần Lean: tài liệu vượt mức cần thiết chính là một dạng lãng phí (extra features / partially done work) mà Eliminate Waste nhắm tới. A, B, D đều là nguyên tắc thật trong bảy nguyên tắc trên.
Đáp án đúng: C. Thang coupling xếp từ lỏng tới chặt: no coupling, message coupling, data coupling, data-structure coupling, control coupling, external coupling, common coupling, content coupling. Coupling càng lỏng càng đáng mong muốn, và message coupling là loại lỏng nhất trong các lựa chọn có mặt. A control coupling nằm ở nhóm trung bình, một module điều khiển luồng của module kia bằng cờ. B external coupling và D common coupling đều thuộc nhóm CHẶT — phụ thuộc vào định dạng bên ngoài, hoặc cùng chia sẻ một cấu trúc dữ liệu toàn cục. Cả ba đều tệ hơn C.
Đáp án đúng: B. Để chạy được một phép kiểm thử đúng nghĩa, ta cần ba thứ có TRƯỚC khi chạy: bộ dữ liệu đầu vào, kết quả kỳ vọng, và một oracle — cơ chế phán xét kết quả thực có khớp kỳ vọng hay không. C thừa "actual output": kết quả thực chỉ xuất hiện SAU khi chạy, nó là đầu ra của phép kiểm thử chứ không phải điều kiện chuẩn bị. A quá hẹp, chỉ có đầu vào thì không biết lấy gì mà so. D thiếu oracle, tức có kỳ vọng nhưng không có cơ chế phán xét — trong nhiều bài toán, việc xác định kết quả đúng lại chính là phần khó nhất.
Đáp án đúng: A. Chuỗi khái niệm chuẩn: fault là khiếm khuyết nằm trong mã (lỗi lập trình viên viết ra), error là trạng thái sai của hệ thống khi fault đó bị kích hoạt lúc chạy, failure là biểu hiện ra ngoài khi kết quả sai lệch tới người dùng. Câu hỏi mô tả "sai sót trong mã CHƯA được kích hoạt" — đúng định nghĩa fault. C latent error nghe hợp lý nhưng error theo định nghĩa là trạng thái đã phát sinh khi chạy, tức đã được kích hoạt. B "effective error" và D failure đều nằm sau trên chuỗi. Mấu chốt: chưa chạy tới thì mới chỉ là fault.
Đáp án đúng: A. Một lỗi (fault) nằm trong mã nguồn chỉ trở thành sai sót thực sự khi đoạn mã chứa nó được thực thi. Nếu component chứa lỗi không bao giờ được gọi tới trong quá trình chạy, lỗi đó vẫn nằm im và không ai phát hiện ra — đây chính là lý do độ phủ mã (code coverage) quan trọng: phần mã chưa từng chạy là phần chưa từng được kiểm chứng. B, C sai: test data và test case là thứ ta chủ động tạo ra để kích hoạt lỗi, chúng là công cụ phát hiện chứ không phải nơi lỗi ẩn náu. D sai: output là kết quả quan sát được sau khi mã đã chạy — nếu đã có output sai thì lỗi đã lộ diện rồi.
Đáp án đúng: C. Unified Process nổi tiếng là NẶNG và khó áp dụng: bốn pha, chín discipline, hàng chục artifact, cần cắt gọt (tailoring) đáng kể cho từng dự án. Vì vậy "dễ hiểu và dễ triển khai" không phải lợi ích của nó. A, B, D, E đều là lợi ích thật: lấy kiến trúc làm trung tâm nên hỗ trợ chất lượng và tái sử dụng; bản chất lặp và tăng dần nên buộc nhận diện và giảm thiểu rủi ro sớm; linh hoạt với thay đổi nhờ nhiều vòng lặp; và đủ tổng quát để lồng thực hành của mô hình khác vào, ví dụ dùng Agile trong pha Construction.
Đáp án đúng: B. Hai từ khoá quyết định là "chia thành 4 phần, xây từng phần một" và "hoàn thiện mỗi phần với độ đầy đủ tính năng cao". Xây trọn từng mảnh chức năng rồi bàn giao chính là Incremental. Iterative thì ngược lại: làm cả sản phẩm ở mức thô rồi lặp lại để tinh chỉnh dần cùng một phạm vi. A "Iterative and Incremental" chỉ đúng nếu nhóm vừa chia phần vừa quay lại nâng cấp phần đã làm, nhưng đề nói rõ mỗi phần làm một lần cho xong với độ hoàn thiện cao — không có vòng quay lại. C Iterative sai vì đề không mô tả việc tinh chỉnh lặp lại.
Đáp án đúng: B. Attack tree là công cụ mô hình hoá mối đe doạ: nút gốc là mục tiêu của kẻ tấn công đối với một tài nguyên, các nhánh con là những con đường khác nhau để đạt mục tiêu đó, tiếp tục phân rã tới các bước tấn công cụ thể. Nó tổ chức có hệ thống mọi hướng tấn công vào một tài nguyên để đội phát triển biết cần phòng thủ ở đâu. A nhầm với danh sách lỗi phần mềm thông thường — attack tree quan tâm ý đồ tấn công, không phải bug. C và D hoàn toàn lệch lĩnh vực.
Đáp án đúng: D. Một design pattern được mô tả đầy đủ luôn gồm ba phần: bối cảnh và vấn đề nó giải quyết (problem description), cấu trúc giải pháp gồm các lớp và quan hệ (solution description), và hệ quả khi áp dụng — được gì, đánh đổi gì (consequences). Thiếu phần hệ quả thì người đọc không biết khi nào KHÔNG nên dùng mẫu đó. A, B, C mỗi phương án chỉ nêu một phần trong ba, nên đều thiếu; chỉ D bao trọn.
Đá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: B. Instability là chỉ số của Robert Martin, tính bằng số phụ thuộc đi ra chia cho tổng phụ thuộc đi ra và đi vào (I = Ce / (Ca + Ce)), cho giá trị từ 0 tới 1. Nó đo mức độ một lớp hoặc gói dễ bị tác động khi thứ nó phụ thuộc thay đổi: I gần 1 nghĩa là phụ thuộc nhiều ra bên ngoài nên rất dễ bị thay đổi bên ngoài làm ảnh hưởng. A, C, D đều không liên quan: đếm số lớp là quy mô hệ thống, tốc độ thực thi là hiệu năng, lượng dữ liệu lưu trong lớp là chuyện bộ nhớ. Không cái nào đo được sự phụ thuộc.
Đáp án đúng: D. Kiểm thử thủ công hoàn toàn có thể dùng đầu vào chọn ngẫu nhiên: chọn ngẫu nhiên giúp chạm tới những vùng dữ liệu mà người viết test khó nghĩ ra, nhờ đó tăng khả năng phát hiện khiếm khuyết. Đây là phát biểu đúng. A sai: mục tiêu chọn test không phải tìm nhiều phép kiểm thử chạy THÀNH CÔNG nhất, mà tìm phép kiểm thử có khả năng làm lộ lỗi cao nhất. B sai: kiểm thử ngẫu nhiên là một kỹ thuật hợp lệ và hữu ích, không phải hình thức tệ nhất. C sai: chính tác giả đoạn mã là người kém khách quan nhất để kiểm thử nó, vì cùng một hiểu lầm sinh ra bug sẽ sinh ra cả test sai.
Đáp án đúng: E. Cả bốn phát biểu đều đúng: coupling đúng là thước đo độ mạnh của các kết nối giữa các thành phần; coupling lỏng khiến thay đổi ít lan sang thành phần khác; chia sẻ biến chung và thông tin điều khiển chính là common coupling và control coupling, tức nhóm chặt; và truyền thông điệp là một trong những cách chính để đạt coupling lỏng. Không phát biểu nào sai, nên chọn "All of the answers". Mẹo làm bài: khi có phương án bao trùm, hãy kiểm tra từng phát biểu con — chỉ cần một phát biểu sai là phương án bao trùm bị loại.
Đáp án đúng: B. Khi hai module cùng phụ thuộc vào một cấu trúc dữ liệu tổng hợp (record, struct, object nhiều trường), ta có data-structure coupling — trong thang này gọi là medium data structure coupling. Nó chặt hơn data coupling vì module nhận nguyên cả cấu trúc dù chỉ dùng vài trường, nên bất kỳ thay đổi nào của cấu trúc cũng có nguy cơ lan sang cả hai. A control coupling là khi một module điều khiển luồng thực thi của module kia bằng cờ hoặc tham số điều khiển — không phải tình huống được mô tả.
Đá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: A. Sashimi Model là biến thể của Waterfall với các pha CHỒNG LẤN nhau (lấy hình ảnh những lát cá sống xếp đè lên nhau): thiết kế bắt đầu khi phân tích chưa xong hẳn, lập trình bắt đầu khi thiết kế còn dở. Nhờ vậy tổng thời gian dự án ngắn lại và thông tin được chia sẻ sớm giữa các pha. B mô tả Waterfall thuần, tức thứ Sashimi phá bỏ. C sai: chồng lấn pha không làm giảm thời gian kiểm thử. D sai: chồng lấn pha không loại bỏ vòng phản hồi nhưng cũng không phải mô hình lấy phản hồi liên tục làm trọng tâm — đó là Agile.
Đáp án đúng: A. Coupling đo mức độ các module PHỐI HỢP và phụ thuộc lẫn nhau — tức nhìn ra bên ngoài, xét quan hệ giữa module này với module khác. B cohesion nhìn vào bên trong: các phần tử trong CÙNG một module gắn bó tới đâu. C data encapsulation và D information hiding là hai khía cạnh về việc che giấu chi tiết cài đặt sau một giao diện. Cặp coupling / cohesion rất hay bị đảo: nhớ "coupling = giữa các module, cohesion = trong một module".
Đá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: D. Không có mô hình vòng đời nào tốt nhất cho mọi trường hợp. Việc chọn mô hình phải cân nhắc đồng thời: yêu cầu rõ tới đâu và ổn định tới đâu; đội ngũ và người dùng ra sao (kinh nghiệm, khả năng tham gia thường xuyên); loại dự án và mức rủi ro đi kèm (dự án đời sống con người, dự án khám phá thị trường mới). A, B, C mỗi phương án chỉ nêu một trong ba nhóm yếu tố, đều thiếu. Chỉ D bao trọn.
Đáp án đúng: A. Subsystem là một hệ thống con độc lập: nó tự nó đã gói trọn một mảng logic nghiệp vụ và về nguyên tắc có thể vận hành riêng. Module là đơn vị phân rã nhỏ hơn, cung cấp dịch vụ cho các thành phần khác và không đứng một mình được. B sai vì phát biểu vế sau: các module HOÀN TOÀN giao tiếp được với nhau — đó chính là bản chất của phân rã module, và cường độ giao tiếp ấy được đo bằng coupling. Vì B sai nên C ("all of the answers") cũng sai.
Đáp án đúng: B. Lập trình đòi hỏi giữ trong đầu một mô hình tinh thần khá lớn về trạng thái chương trình, luồng dữ liệu và các trường hợp biên. Mô hình này mất khá lâu để dựng lên và tan rất nhanh khi bị ngắt quãng — sau một lần gián đoạn, người viết mã phải tốn nhiều phút để lấy lại ngữ cảnh. Giảm phân tâm chính là để bảo vệ mô hình tinh thần đó. A, C, D đều lệch: nghỉ ngơi hợp lý là chuyện khác, số dòng mã viết ra không phải thước đo, và giảm phân tâm không liên quan gì tới nhu cầu tài liệu.
Đá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: D. Coincidental cohesion là mức gắn kết YẾU NHẤT: các phần tử nằm chung một module thuần tuý vì ngẫu nhiên, không có quan hệ nghĩa nào. "Các phần của module nằm chung một tệp" đúng là lý do ngẫu nhiên — chung chỗ lưu trữ chứ không chung mục đích. B logical association cohesion cần các phần tử ít nhất phải cùng MỘT LOẠI công việc (ví dụ gom tất cả hàm xử lý đầu vào). C temporal cohesion cần chúng cùng chạy trong một khoảng thời gian (ví dụ nhóm khởi tạo). A procedural cohesion cần chúng theo một trình tự thực thi. Ở đây không có cả ba mối liên hệ đó.
Đáp án đúng: C. Message coupling là mức lỏng nhất trong thang coupling có thực: các thành phần không chạm vào dữ liệu của nhau mà chỉ trao đổi qua tham số hoặc thông điệp qua một giao diện công khai — đúng nguyên văn mô tả trong đề. A "loose no coupling" nghĩa là hoàn toàn không có kết nối, nhưng đề nói rõ các thành phần CÓ giao tiếp với nhau, nên không phải trường hợp này. B loose data coupling chặt hơn một bậc: các module truyền dữ liệu thật cho nhau qua tham số, còn message coupling nhấn mạnh việc giao tiếp qua thông điệp mà không phụ thuộc dữ liệu nội bộ của nhau.
Đá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: B. WRSPM là mô hình tham chiếu về yêu cầu, viết tắt của World, Requirements, Specification, Program, Machine. Nó xếp năm khái niệm này theo trục từ thế giới thực sang máy tính, giúp phân biệt rạch ròi đâu là hiện tượng của thế giới, đâu là của máy, và đâu là phần giao nhau mà cả hai cùng nhìn thấy. A là chuỗi từ bịa cho có vần. C sai vì B đã đúng. Mẹo nhớ: chữ W đầu tiên là World (thế giới), không phải Wide.
Đá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: A. Data coupling là khi các module chỉ trao đổi với nhau bằng dữ liệu đơn giản truyền qua tham số, mỗi tham số đều là thứ module nhận thực sự cần dùng. Đây là mức coupling lỏng và được coi là chấp nhận được trong hầu hết thiết kế. B "loose no coupling" nghĩa là không có kết nối nào, mâu thuẫn với việc chúng đang chia sẻ tham số. C loose message coupling nhấn mạnh việc giao tiếp bằng thông điệp qua giao diện công khai, lỏng hơn một bậc so với việc truyền thẳng tham số dữ liệu.
Đá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.
Đáp án đúng: C. Acceptance test được viết cho và cùng với khách hàng, nên phải dùng ngôn ngữ của NGƯỜI DÙNG và nghiệp vụ, không dùng ngôn ngữ hệ thống. Vì vậy "system-centric language" không thuộc các thành phần then chốt — nó là thứ cần tránh. A các bước trình diễn, B các điều kiện lỗi cần xử lý, và D tiêu chí chấp nhận rõ ràng đều là thành phần thật: có bước để diễn lại, có tình huống lỗi để chắc hệ thống không vỡ, và có tiêu chí để phán xét đạt hay không đạt.
Đáp án đúng: B. Đây là nghịch lý đặc trưng của XP: khi thứ gì đó gây đau thì hãy làm nó thường xuyên hơn cho tới khi hết đau. Phản hồi tới nhiều hơn khả năng xử lý thường là dấu hiệu mỗi lô phản hồi quá lớn vì khoảng cách giữa các lần quá dài; tăng tần suất khiến mỗi lô nhỏ lại và xử lý được ngay, đồng thời buộc nhóm cải tiến quy trình tiếp nhận. A giảm tần suất chỉ dồn phản hồi thành lô to hơn, khiến vấn đề trầm trọng thêm. C bỏ qua phản hồi là vứt đi thông tin quý nhất. D tăng ca không giải quyết nguyên nhân và tạo lãng phí kiểu Lean.
Đáp án đúng: C. Phần thứ hai của Sprint Planning trả lời câu "làm thế nào": nhóm phân rã từng hạng mục backlog đã chọn thành các đầu việc kỹ thuật cụ thể và ước lượng chúng, để kiểm chứng lại rằng khối lượng cam kết thực sự vừa với năng lực sprint. A sắp xếp ưu tiên là việc của Product Owner với Product Backlog, làm TRƯỚC buổi planning. B giao việc cho quản lý đi ngược nguyên tắc nhóm tự tổ chức — thành viên tự nhận việc. D dự báo ngày phát hành là bài toán ở tầm release, không phải mục đích của việc chia task.
Đáp án đúng: B. Sprint Backlog được nhóm phát triển tạo ra ngay trong buổi Sprint Planning: chọn hạng mục từ Product Backlog theo thứ tự ưu tiên và năng lực, rồi phân rã thành các đầu việc. Nó là sản phẩm đầu ra của buổi họp đó. A sai vì sprint backlog gắn với từng sprint chứ không lập một lần cho cả dự án. C backlog refinement là nơi làm mịn PRODUCT Backlog, không tạo Sprint Backlog. D sai: sprint backlog được CẬP NHẬT hằng ngày trong sprint, nhưng thời điểm TẠO thì cố định là buổi planning.
Đáp án đúng: B. Scrum không cấm tài liệu; nó yêu cầu tài liệu vừa đủ để hỗ trợ việc phát triển và việc sử dụng sản phẩm. Tiêu chí là công dụng, không phải độ dày. A là cách hiểu cực đoan sai lệch về Agile. C viết tài liệu để chứng minh thành tích — làm vì hình thức, không phục vụ ai. D làm nhiều tài liệu hơn bình thường vì cho rằng Agile rủi ro, đi ngược hẳn tinh thần Scrum vốn giảm rủi ro bằng vòng lặp ngắn và sản phẩm chạy được, không bằng giấy tờ.
Đáp án đúng: A. Ba chữ C của user story do Ron Jeffries đặt ra: Card (tấm thẻ ghi ngắn gọn story, chỉ vừa đủ để nhớ), Conversation (cuộc trao đổi giữa nhóm và khách hàng để làm rõ chi tiết — phần quan trọng nhất), và Confirmation (tiêu chí chấp nhận để xác nhận story đã xong). B, C, D đều là các bộ ba chữ C bịa ra để gây nhiễu. Ý nghĩa của mô hình này là user story không phải một đặc tả viết sẵn mà là lời hứa cho một cuộc trò chuyện.
Đáp án đúng: A. Nguyên tắc "Working software is the primary measure of progress" chỉ tính tiến độ bằng phần mềm CHẠY ĐƯỢC và giao được. Năm tính năng đã hoàn thiện trên mười là tiến độ thật, đo được, dùng được. B chỉ mới xong yêu cầu và thiết kế cho năm story — chưa có dòng phần mềm nào chạy, theo nguyên tắc này thì tiến độ vẫn là 0%. C lấy thời gian trôi qua làm thước đo (5 tháng trên 10 tháng nên xong 50%) — đây đúng là kiểu đo mà Agile bác bỏ, vì thời gian tiêu tốn không nói lên giá trị đã giao.
Đáp án đúng: C. Burndown Chart trong sprint thể hiện lượng công việc CÒN LẠI đối chiếu với thời gian: trục tung là phần chưa xong (giờ hoặc story point), trục hoành là các ngày của sprint, đường thực tế so với đường lý tưởng cho biết nhóm đang bám kịp hay tụt lại. A mô tả biểu đồ burn-up (công việc tích luỹ đã hoàn thành). B danh sách tính năng đề xuất là Product Backlog. D số bug chưa xử lý là chỉ số chất lượng riêng, có thể vẽ biểu đồ riêng nhưng không phải nội dung của burndown.
Đáp án đúng: A. Sprint Retrospective là sự kiện cuối sprint dành riêng cho việc nhóm tự soi lại CÁCH LÀM VIỆC của mình: điều gì chạy tốt, điều gì vướng, và chọn ra cải tiến cụ thể áp dụng ngay ở sprint sau. Nó tập trung vào quy trình và con người, không vào sản phẩm. B lập kế hoạch sprint kế tiếp là việc của Sprint Planning. C thảo luận phản hồi về sản phẩm với Product Owner và các bên liên quan là việc của Sprint Review. D tăng gắn kết các bên liên quan không phải mục đích của một sự kiện nội bộ nhóm. ⚠ Bản đề in đáp án C. Chốt A vì C mô tả đúng Sprint Review chứ không phải Retrospective — hai sự kiện này khác nhau ở đối tượng soi xét: Review soi sản phẩm, Retrospective soi quy trình.