Bài 8.4 · Chương 8: Agile và Hybrid
Lập trình cực hạn (XP): năm giá trị và các thực hành kỹ thuật như phát triển hướng kiểm thử, lập trình cặp, tích hợp liên tục, tái cấu trúc, phát hành nhỏ; nợ kỹ thuật, spike, BDD và vai trò của PM trong việc tạo điều kiện cho kỹ thuật tốt.
| Thực hành |
|---|
| Nội dung |
|---|
| Lợi ích |
|---|
| Phát triển hướng kiểm thử (TDD) | Viết kiểm thử tự động trước, rồi viết mã cho nó qua, rồi làm sạch mã | Bộ kiểm thử hồi quy dày, thiết kế dễ thay đổi |
| Lập trình cặp | Hai người một máy, một người gõ, một người xem xét, đổi vai thường xuyên | Ít lỗi hơn, tri thức lan toả, giảm phụ thuộc một người |
| Tích hợp liên tục (CI) | Đưa mã vào nhánh chung nhiều lần mỗi ngày, tự động biên dịch và kiểm thử | Phát hiện lỗi tích hợp trong vài phút |
| Tái cấu trúc (refactoring) | Cải thiện cấu trúc mã, không đổi hành vi | Giữ mã sạch, trả nợ kỹ thuật dần |
| Thiết kế đơn giản | Chỉ thiết kế cho nhu cầu hiện tại | Ít phức tạp thừa |
| Phát hành nhỏ | Đưa sản phẩm ra thường xuyên với phần nhỏ | Phản hồi sớm, rủi ro mỗi lần nhỏ |
| Sở hữu mã tập thể | Ai cũng có thể sửa bất kỳ phần mã nào | Không tắc vì "chờ người phụ trách" |
| Chuẩn mã chung | Cùng quy ước đặt tên, định dạng | Mã dễ đọc với mọi người |
| Nhịp độ bền vững | Không làm thêm giờ kéo dài (thường gọi "tuần 40 giờ") | Giữ chất lượng và sức khoẻ |
| Cả đội cùng khách hàng | Đại diện khách hàng làm việc sát với đội | Làm rõ yêu cầu nhanh |
| Trò chơi lập kế hoạch | Khách hàng chọn ưu tiên, đội ước lượng | Kế hoạch dựa trên giá trị và năng lực thật |
Mỗi vòng chỉ vài phút. Sau vài tháng, đội có hàng nghìn kiểm thử tự động làm "lưới an toàn": dám thay đổi mà không sợ phá hỏng thứ cũ.
Phát triển hướng hành vi (BDD) mở rộng ý tưởng sang ngôn ngữ nghiệp vụ: tiêu chí chấp nhận viết theo dạng Given – When – Then ("Cho rằng tài khoản có 5 triệu, khi khách chuyển 6 triệu, thì giao dịch bị từ chối với thông báo số dư không đủ"), vừa là đặc tả vừa là kiểm thử tự động.
Nợ kỹ thuật (technical debt) — ẩn dụ do Ward Cunningham đưa ra — là chi phí làm lại trong tương lai khi chọn giải pháp nhanh thay cho giải pháp tốt. Như nợ tiền, nó có lãi: mỗi thay đổi sau chậm hơn, rủi ro hơn. Nợ có chủ đích (để kịp ra mắt) đôi khi hợp lý nếu được ghi nhận và trả; nợ vô tình (do kỹ năng kém, không review) thì nguy hiểm. Cách quản lý: làm nợ hiển thị trong backlog, dành một phần năng lực mỗi Sprint để trả, đưa tiêu chuẩn vào DoD để không phát sinh thêm.
Spike là một hạng mục nghiên cứu, thử nghiệm có khung thời gian cố định, nhằm giảm bất định kỹ thuật hoặc nghiệp vụ trước khi cam kết — ví dụ hai ngày thử tích hợp với API của đối tác. Kết quả của spike là tri thức (đủ để ước lượng, quyết định), không phải tính năng.
Mở rộng từ CI, chuyển giao liên tục (continuous delivery) giữ sản phẩm luôn ở trạng thái có thể phát hành; DevOps xoá ranh giới giữa phát triển và vận hành bằng tự động hoá (kiểm thử, triển khai, giám sát) và trách nhiệm chung. Kết quả: phát hành thường xuyên, an toàn, ít "đêm triển khai thức trắng".
PM không cần viết mã, nhưng cần tạo điều kiện cho thực hành kỹ thuật (liên quan task BE4 — gỡ trở ngại):
Đội tiếp nhận hệ thống cũ, không có kiểm thử tự động; mỗi lần sửa công thức phí mất hai tuần kiểm tra tay và vẫn có lỗi. Đội viết kiểm thử bao quanh các công thức hiện có, rồi tái cấu trúc dần; mọi thay đổi mới làm theo TDD; CI chạy 1.500 kiểm thử trong 6 phút. Sáu tháng sau, thay đổi công thức phí chỉ mất 3 ngày từ yêu cầu đến phát hành, lỗi sau phát hành giảm rõ. PM đã thuyết phục nhà tài trợ chấp nhận tốc độ chậm hơn trong hai tháng đầu để đổi lấy tốc độ bền vững về sau.
Task PR7 (chất lượng) và BE4 (gỡ trở ngại). Dấu hiệu đáp án đúng: chất lượng được xây vào từ đầu (TDD, CI, DoD), nợ kỹ thuật được làm hiển thị và quản lý, spike cho bất định, PM tạo điều kiện chứ không ép cắt chất lượng. Xem thêm Lồng ghép chất lượng.
5 câu · Đạt từ 70 %
Theo PMBOK® Guide – Ấn bản 8 (PMI, 2025): 6 nguyên tắc, 7 lĩnh vực hiệu suất, 5 nhóm trọng tâm với 40 quy trình không bắt buộc. PMBOK là nhãn hiệu đã đăng ký của Project Management Institute.