Mở đầu
Các phương pháp phát triển như Waterfall, Agile, Scrum, Kanban ra đời trong bối cảnh viết code là khâu tốn nhiều thời gian nhất. Khi AI tham gia viết code, một số giả định nền tảng của các phương pháp này thay đổi.
Bài viết tổng hợp số liệu và nghiên cứu công khai để so sánh ba khía cạnh: số liệu về tỷ lệ thành công, mối liên hệ giữa loại hợp đồng và phương pháp, và tác động của AI lên từng phương pháp so với cách làm truyền thống.
Dữ liệu nói gì, và không nói gì
Con số được trích nhiều nhất: theo báo cáo CHAOS của Standish Group, dự án Agile thành công gấp khoảng 3 lần Waterfall (39% so với 11%). Với dự án lớn, khoảng cách còn rõ hơn: 18% so với 3% (PM Essentials).
Nhưng cần đọc kỹ định nghĩa "thành công". CHAOS đo thành công bằng đúng hạn, đúng ngân sách, đủ tính năng so với dự toán ban đầu. Hai nhà nghiên cứu Eveleens và Verhoef (Đại học VU Amsterdam) đã áp cách đo này lên 1.211 dự án thật với 5.457 lần dự toán. Kết luận của họ: con số của Standish không phản ánh thực tế, vì nó chỉ đo độ chính xác của dự toán và gộp nhiều cách dự toán khác nhau vào một trung bình (IEEE Software, 2010).
Những điểm cần lưu ý khi đọc số liệu:
- Khác biệt rõ nhất xuất hiện ở dự án lớn và nhiều bất định.
- Agile được điều chỉnh phạm vi trong quá trình làm, còn Waterfall được đo theo phạm vi cam kết từ đầu. Tiêu chí "thành công" vì vậy không hoàn toàn tương đương giữa hai cách.
- Nghiên cứu phản biện cho thấy tỷ lệ thành công phụ thuộc nhiều vào cách dự toán ban đầu.
Một khảo sát liên quan: theo DX白書2021 của IPA, 19,3% doanh nghiệp được khảo sát áp dụng phát triển Agile (@IT). Một yếu tố liên quan đến tỷ lệ này là cấu trúc hợp đồng, trình bày ở phần tiếp theo.
Hợp đồng và phương pháp
Trong phát triển thuê ngoài, phương pháp thường gắn với loại hợp đồng được ký từ đầu.
Có hai loại hợp đồng chính:
| 請負 (Ukeoi) — khoán sản phẩm | 準委任 (Jun-inin) — ủy thác công việc | |
|---|---|---|
| Bên cung cấp cam kết | Giao sản phẩm hoàn chỉnh theo spec | Làm việc tận tâm, đúng chuyên môn |
| Ai chịu rủi ro phạm vi | Bên cung cấp | Bên đặt hàng |
| Điều kiện cần | Spec rõ và cố định từ đầu | Khách tham gia sâu, quyết định liên tục |
| Phương pháp tự nhiên | Waterfall | Agile, Scrum, Kanban |
Năm 2020, IPA công bố hợp đồng mẫu cho phát triển Agile và chọn 準委任 làm tiền đề. Lý do: tính năng và ưu tiên sẽ thay đổi trong quá trình làm. IPA cũng nhấn mạnh bên đặt hàng phải tham gia chủ động và đáng kể, không thể thuê xong rồi đứng ngoài (Publickey, IPA).
Liên hệ với tỷ lệ áp dụng: hợp đồng 請負 cho bên đặt hàng một con số ngân sách cố định, thuận lợi cho quy trình phê duyệt nội bộ (稟議). Hợp đồng 準委任 đòi hỏi bên đặt hàng chịu rủi ro phạm vi và bố trí người ra quyết định thường xuyên.
Các mô hình kết hợp thường gặp: chia hợp đồng theo giai đoạn (làm rõ yêu cầu theo 準委任, phát triển theo 請負 khi spec đã rõ), hoặc mô hình team chuyên trách (ラボ型) cho sản phẩm dài hạn.
AI đảo ngược bài toán: code nhanh hơn, spec quan trọng hơn
Agile ra đời dựa trên giả định: sửa phần mềm ở giai đoạn cuối rất khó, vì vậy làm từng phần nhỏ giúp phát hiện sai sớm. AI tác động trực tiếp lên giả định này.
1. Code nhanh hơn, nhưng hệ thống kém ổn định hơn. Báo cáo DORA 2025 của Google cho thấy 90% người làm phần mềm đã dùng AI, và hơn 80% thấy năng suất tăng. AI có tương quan tích cực với tốc độ giao hàng, nhưng tương quan tiêu cực với độ ổn định. 30% vẫn ít hoặc không tin code do AI viết (Google Cloud).
2. AI là bộ khuếch đại. Kết luận trung tâm của DORA: AI không sửa một team yếu, nó khuếch đại những gì đã có. Theo logic này, quy trình có yêu cầu chưa rõ ràng khi kết hợp AI có thể tạo ra nhiều code lệch yêu cầu hơn.
3. Spec quay lại vị trí trung tâm. Khi AI agent viết code dựa trên mô tả mơ hồ, nó tạo ra code trông đúng, chạy được, nhưng lệch ý định thật. Vì vậy trong năm 2026, xu hướng spec-driven development nổi lên. GitHub Spec Kit là ví dụ: nó chia quy trình thành Constitution → Specify → Plan → Tasks → Implement (MarkTechPost).
Nhìn kỹ, chuỗi này rất giống Waterfall thu nhỏ: yêu cầu → thiết kế → chia việc → làm. Khác biệt là mỗi vòng chỉ mất vài giờ hoặc vài ngày thay vì vài tháng.
Xu hướng chung: các nguồn trên cho thấy ranh giới Agile–Waterfall đang mờ dần theo hướng spec chi tiết như Waterfall, vòng lặp ngắn như Agile. Trọng tâm công việc dịch chuyển từ viết code sang xác định yêu cầu và review, tức vai trò của Business Analyst và Product Owner.
Hai biến số: độ rõ yêu cầu và mức tham gia của khách
Tổng hợp từ các phần trên, mỗi phương pháp phù hợp với một tổ hợp khác nhau của hai biến số: độ rõ của yêu cầu và mức tham gia của bên đặt hàng.
Ô "yêu cầu chưa rõ, khách tham gia ít" là trường hợp khó nhất. Không phương pháp nào trong năm phương pháp giải quyết trực tiếp tình huống này; các dự án thường bổ sung một giai đoạn Business Analysis hoặc prototype trước. Với vận hành, bảo trì, Kanban thường được dùng bất kể dự án nằm ở ô nào.
Ưu, khuyết điểm của 5 phương pháp — nhìn lại trong thời AI
Cột cuối tóm tắt tác động của AI lên từng phương pháp, dựa trên các nguồn ở phần trước.
| Phương pháp | Ưu điểm | Khuyết điểm | Hợp đồng phù hợp | AI thay đổi gì |
|---|---|---|---|---|
| Waterfall | Dễ dự toán chi phí, tiến độ; tài liệu đầy đủ, dễ bàn giao | Sợ đổi spec; cuối dự án mới thấy sản phẩm | 請負 | Spec chi tiết trở thành đầu vào tốt cho AI agent; AI còn giúp dựng prototype sớm để kiểm tra spec |
| Agile | Linh hoạt; sớm có sản phẩm chạy được | Khó chốt phạm vi, ngân sách; khách phải tham gia liên tục | 準委任 | Code nhanh hơn nên để lại nợ kỹ thuật nhanh hơn; cần test tự động mạnh để không mất ổn định |
| Scrum | Nhịp độ rõ; minh bạch tiến độ; cải tiến liên tục | Thiếu Product Owner thì hỏng; họp dễ thành hình thức | 準委任 / ラボ型 | Sprint 2 tuần có thể quá dài khi AI làm xong việc trong vài ngày; nút thắt chuyển sang PO và khâu review |
| Kanban | Dễ áp dụng; xử lý việc đột xuất tốt; thấy rõ nút thắt | Dễ mất mục tiêu dài hạn và deadline | 準委任 | Hợp với AI nhất cho bảo trì: việc nhỏ chảy liên tục, cột "chờ review" thành cột quan trọng nhất |
| Hybrid | Giữ ngân sách cố định mà vẫn linh hoạt; hợp quy trình 稟議 | Ranh giới mơ hồ thì dính cả hai nhược điểm | 準委任 (yêu cầu) + 請負 (phát triển) | Gần với spec-driven development nhất: spec kỹ, vòng lặp ngắn |
Tóm tắt
- Số liệu "Agile thành công gấp 3 lần" đo độ khớp với dự toán ban đầu, không đo trực tiếp giá trị kinh doanh.
- Loại hợp đồng và mức tham gia của bên đặt hàng gắn chặt với phương pháp khả thi.
- Theo DORA 2025, AI tăng tốc độ giao hàng nhưng đi kèm giảm độ ổn định. Điểm nghẽn dịch chuyển sang khâu xác định yêu cầu và review.
Nguồn tham khảo
- Successful Projects: What We Really Know — PM Essentials (số liệu CHAOS)
- Eveleens & Verhoef, The Rise and Fall of the Chaos Report Figures — IEEE Software, 2010
- DX白書2021: アジャイル開発の活用状況 — @IT
- 情報システム・モデル取引・契約書（アジャイル開発版） — IPA
- アジャイル開発の契約は「準委任」が適切 — Publickey
- Announcing the 2025 DORA Report — Google Cloud
- Meet GitHub Spec-Kit — MarkTechPost
