Chủ đề của SWE201c - Nhập môn Kỹ thuật phần mềm

SWE201c - Phần 2: Agile Software Development

Ứng với CLO2, trải buổi 5 và buổi 6. Buổi 5 gồm phần nền tảng agile và phần yêu cầu cùng lập kế hoạch: bốn giá trị của Tuyên ngôn Agile và mười hai nguyên tắc đi kèm, cách viết user story theo tiêu chí INVEST, các kỹ thuật ước lượng, lập kế hoạch phát hành và kế hoạch cho từng vòng lặp. Buổi 6 gồm Scrum và Extreme Programming: Scrum với ba vai trò, bốn sự kiện gồm họp kế hoạch sprint, họp hằng ngày, họp rà soát và họp cải tiến, các tạo tác gồm product backlog, sprint backlog và phần tăng trưởng, cùng biểu đồ burndown theo dõi tiến độ; XP với lập trình cặp, đội hình toàn diện, phát hành nhỏ và vòng phản hồi ngắn. Chuẩn đầu ra tương ứng là tham gia hiệu quả vào quy trình và thực hành agile.

40 câu hỏi100% có giải thích
Một câu trong chủ đề này
ACode reviews + CI + Automated Testing
BManual only + Parallel deploy
CNo docs + Big Bang
DIncremental + No rollback
Lời giải
Đáp án đúng: A. Chất lượng trong Agile được bảo đảm bằng vòng phản hồi ngắn và tự động hoá: code review bắt lỗi thiết kế và lỗi logic ngay khi mã còn mới, continuous integration hợp nhất liên tục để lỗi tích hợp lộ ra trong ngày thay vì cuối dự án, kiểm thử tự động tạo lưới an toàn cho phép refactor mà không sợ vỡ. B, C, D đều đi ngược: kiểm thử thủ công đơn thuần không theo kịp nhịp sprint; bỏ tài liệu và triển khai Big Bang làm rủi ro dồn về cuối; giao tăng dần mà không có đường lùi (rollback) thì mỗi lần phát hành đều là canh bạc.
Mở trang câu hỏi này →

Bắt đầu bằng Chế độ học nếu bạn muốn đáp án và giải thích hiện ngay sau mỗi câu — không bấm giờ, dừng lúc nào cũng được. Chọn Thi thử khi muốn biết mình đang ở đâu: có bấm giờ, chấm điểm ở cuối, và giải thích chỉ mở sau khi nộp.

Học ngân hàng câu hỏi của chủ đề

Luyện tập theo chủ đề này

40Câu hỏi hiện có

Câu hỏi trong chủ đề

Câu 1 – 12 trong 40 câu
ACode reviews + CI + Automated Testing
BManual only + Parallel deploy
CNo docs + Big Bang
DIncremental + No rollback
Lời giải
Đáp án đúng: A. Chất lượng trong Agile được bảo đảm bằng vòng phản hồi ngắn và tự động hoá: code review bắt lỗi thiết kế và lỗi logic ngay khi mã còn mới, continuous integration hợp nhất liên tục để lỗi tích hợp lộ ra trong ngày thay vì cuối dự án, kiểm thử tự động tạo lưới an toàn cho phép refactor mà không sợ vỡ. B, C, D đều đi ngược: kiểm thử thủ công đơn thuần không theo kịp nhịp sprint; bỏ tài liệu và triển khai Big Bang làm rủi ro dồn về cuối; giao tăng dần mà không có đường lùi (rollback) thì mỗi lần phát hành đều là canh bạc.
Mở trang câu hỏi này →
AThe Product Backlog is equal to the Sprint Backlog
BThe Product Backlog is based on the Sprint Backlog
CThe Sprint Backlog is a based on the Product Backlog
DThe Sprint Backlog is owned by the Product Owner
Lời giải
Đáp án đúng: C. Product Backlog là danh sách sống của toàn bộ hạng mục mong muốn cho sản phẩm, do Product Owner sở hữu và sắp theo độ ưu tiên. Ở mỗi buổi Sprint Planning, nhóm phát triển kéo phần trên cùng của Product Backlog vào và phân rã thành Sprint Backlog cho sprint đó. Quan hệ vì thế là một chiều: Sprint Backlog dựa trên Product Backlog. A sai vì hai danh sách khác hẳn phạm vi. B sai vì đảo ngược chiều phụ thuộc. D sai: Sprint Backlog thuộc sở hữu của nhóm phát triển, chỉ Product Backlog mới do Product Owner sở hữu.
Mở trang câu hỏi này →
AFacilitates easier comparison between tasks which improves estimation accuracy.
BProvides precise numerical values for tasks.
CReduces the variability in task completion time.
DSpeeds up task completion by reducing estimation time.
Lời giải
Đáp án đúng: A. Con người ước lượng tuyệt đối (bao nhiêu giờ) rất kém nhưng so sánh tương đối lại khá tốt: nói "việc này to gấp đôi việc kia" dễ và ổn định hơn nhiều so với nói "việc này mất 13 giờ". Relative sizing bằng story point khai thác đúng điểm mạnh đó, cho ước lượng nhất quán hơn và tránh tranh cãi về năng suất từng cá nhân. B nói ngược: story point cố tình KHÔNG mang giá trị số tuyệt đối. C sai: ước lượng không làm giảm độ biến thiên của thời gian thực hiện. D sai: nhanh hơn chỉ là hệ quả phụ, không phải lợi ích chính.
Mở trang câu hỏi này →
APair Programming
BTwin Programming
CPeer Programming
DBuddy Programming
Lời giải
Đáp án đúng: A. Pair Programming là một trong 12 thực hành cốt lõi của Extreme Programming: hai lập trình viên ngồi cùng một máy, một người cầm bàn phím (driver) viết mã, người kia (navigator) rà soát từng dòng và nghĩ trước một bước. Đây là hình thức review liên tục theo thời gian thực. B, C, D không phải tên thực hành nào của XP, chỉ là các biến thể chữ nghĩa dựng lên để gây nhiễu.
Mở trang câu hỏi này →
ATo track the number of user stories completed.
BTo visualize the remaining work in a sprint.
CTo estimate the total effort required for the project.
DTo prioritize the backlog items.
Lời giải
Đáp án đúng: B. Burndown chart vẽ khối lượng công việc CÒN LẠI theo thời gian, đường lý tưởng đi thẳng xuống 0 vào ngày cuối sprint. Nhóm nhìn khoảng lệch giữa đường thực tế và đường lý tưởng để biết mình đang bám kịp hay tụt lại, và điều chỉnh ngay trong sprint. A gần đúng nhưng lệch trọng tâm: biểu đồ đo khối lượng còn lại chứ không đếm số story đã xong. C sai: ước lượng tổng công sức diễn ra ở sprint planning, không phải việc của biểu đồ. D sai: sắp xếp ưu tiên backlog là việc của Product Owner.
Mở trang câu hỏi này →
ACapacity determination.
BBacklog grooming.
CUpdating the task board.
DGenerating new user stories.
Lời giải
Đáp án đúng: A. Sprint Planning trả lời hai câu: sprint này làm được bao nhiêu, và làm thế nào. Câu thứ nhất buộc nhóm phải xác định năng lực (capacity) của sprint — bao nhiêu người, bao nhiêu ngày làm việc thực, trừ nghỉ phép và họp — rồi mới cam kết được phạm vi. B backlog grooming là hoạt động refinement diễn ra TRƯỚC và ngoài buổi planning. C cập nhật task board là việc hằng ngày trong sprint. D sinh user story mới là việc của Product Owner khi nuôi backlog, không phải nội dung buổi planning.
Mở trang câu hỏi này →
ADon't do documentation on agile project
BCreate documentation when it provides value
CMust write documentation to fulfill company policy
Lời giải
Đáp án đúng: B. Giá trị "Working software over comprehensive documentation" là một phép so sánh ưu tiên, không phải phép phủ định — Agile Manifesto viết rõ vế bên phải vẫn có giá trị, chỉ là vế bên trái được coi trọng hơn. Vì vậy cách hiểu đúng là: vẫn làm tài liệu, nhưng làm khi nó mang lại giá trị thật. A hiểu thành phủ định hoàn toàn, đây là ngộ nhận phổ biến nhất về Agile. C thì làm tài liệu vì thủ tục nội bộ chứ không vì giá trị — đúng loại lãng phí Agile muốn cắt.
Mở trang câu hỏi này →
ADo no documentation because it is a waste of time
BDo the necessary documentation to support the development and use of the product
CDo sufficient documentation to prove you have done a good job
DDo more documentation than usual, because Agile is risky
Lời giải
Đá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ờ.
Mở trang câu hỏi này →
AProvide their best guess based on what they know.
BSkip that story and exclude that story from the release.
CNo action required; keep the story with no estimates
DCreate a spike story---a new story under which the team will do some research or other work to gain a better understanding of the original story.
Lời giải
Đáp án đúng: D. Trong XP, một story không ước lượng nổi nghĩa là nhóm còn thiếu hiểu biết chứ không phải thiếu can đảm. Cách xử lý chuẩn là tạo spike — một story riêng, đóng hộp thời gian, mục tiêu duy nhất là nghiên cứu hoặc dựng thử nghiệm để gỡ chỗ mù mờ, sau đó story gốc mới được ước lượng. A đoán bừa sẽ đưa con số sai vào kế hoạch. B bỏ story ra khỏi release là né vấn đề, nhu cầu vẫn còn đó. C giữ story không ước lượng khiến cả sprint mất khả năng dự báo.
Mở trang câu hỏi này →
ALow project visibility
BReduced team productivity
CAbility to manage changing priorities
DLack of business and IT alignment
Lời giải
Đáp án đúng: C. Lợi ích được ghi nhận nhiều nhất của Agile là khả năng thích ứng với ưu tiên thay đổi: backlog được sắp lại mỗi sprint nên hạng mục giá trị nhất tại thời điểm hiện tại luôn được làm trước, thay đổi không còn là sự cố cần kiểm soát mà là đầu vào bình thường. A, B, D đều là điều Agile khắc phục chứ không phải mang lại: sprint review và biểu đồ tiến độ làm TĂNG mức hiển thị dự án; nhóm tự tổ chức làm tăng năng suất; Product Owner ngồi cùng nhóm chính là để business và IT khớp nhau.
Mở trang câu hỏi này →
AWe MUST release software to actual users every couple weeks.
BWe should frequently deliver software in some environment (not necessarily to production always) to gather user/client feedback
CWe should NOT release software to a production environment on a shorter timeframe. We should ONLY release it in lower environment (e.g., a test environment).
Lời giải
Đáp án đúng: B. Nguyên tắc này nói về nhịp GIAO PHẦN MỀM CHẠY ĐƯỢC để lấy phản hồi, không bắt buộc mỗi lần đều đẩy lên production cho người dùng cuối. Giao vào một môi trường mà khách hàng hoặc người dùng có thể xem và góp ý (staging, demo, beta) đã thoả mãn tinh thần nguyên tắc. A đọc thành mệnh lệnh cứng "PHẢI phát hành cho người dùng thật mỗi vài tuần" — Manifesto không ép như vậy. C thì ngược lại, cấm phát hành lên production theo nhịp ngắn, cũng sai vì nhiều nhóm Agile trưởng thành làm continuous delivery hằng ngày.
Mở trang câu hỏi này →
AIf a team has delivered 5 features out of 10 features (or stories), team has made progress (they are more than 0% done)
BIf a team has written the requirements and done the design for 5 out of 10 stories, then the team has made some progress (they are more than 0% done)
COn a 10 month project, the team has been working for 5 months. Thus, the project is 50% complete.
Lời giải
Đá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.
Mở trang câu hỏi này →
Xem cả 40 câu của chủ đề

Đề có câu hỏi của chủ đề này

3 đề chứa ít nhất một câu thuộc chủ đề — mở đề để làm cả bộ, không chỉ từng câu.