Agile vs. Waterfall — không phải tôn giáo, là trade-off

Ngày nào đó trong sự nghiệp, bạn sẽ ngồi trong một buổi họp mà ai đó phát biểu với giọng rất tự tin: “Chúng ta phải đi theo Agile — Waterfall đã chết rồi.”

Hoặc ngược lại, một ông senior hơn ngồi bên cạnh gật gù: “Mấy cái Agile này xàm lắm. Làm spec cho đàng hoàng đi đã.”

Và bạn ngồi đó, không biết ai đúng ai sai, nhâm nhi ly cà phê nguội và tự hỏi: ủa sao hai người này đều có kinh nghiệm mà cãi nhau vậy?

Câu trả lời ngắn: cả hai đều đúng trong ngữ cảnh của họ. Và vấn đề thật sự không phải chọn một cái “đúng” — mà là hiểu khi nào thì cái nào phù hợp.

Hai triết lý, hai cái nhìn về thế giới

Waterfall và Agile không chỉ khác về quy trình. Họ khác về giả định căn bản về độ chắc chắn của thông tin.

Waterfall / Traditional giả định: yêu cầu có thể được hiểu đầy đủ từ đầu. Bạn thu thập spec, phân tích, thiết kế, code, test, triển khai — rồi xong. Mỗi phase hoàn thành trước khi phase sau bắt đầu. Giống như xây một cái cầu: không ai xây xong nhịp cầu rồi hỏi “ừ thì thật ra bạn muốn cầu đi đâu?”

Agile giả định ngược lại: yêu cầu sẽ thay đổi — và thay đổi sớm hơn bạn nghĩ. Thay vì cố bắt một cái “đúng” từ đầu, Agile chấp nhận điều đó bằng cách chia nhỏ delivery thành sprint, lấy feedback liên tục, và điều chỉnh theo thực tế.

Hình 1. Waterfall chảy một chiều từ trên xuống — thay đổi ở giữa đường rất đắt. Agile vòng tròn liên tục — mỗi sprint là một cơ hội điều chỉnh.

Hai giả định khác nhau → hai cách làm khác nhau → hai loại rủi ro khác nhau.

Không có cái nào “đúng”. Có cái nào phù hợp với hoàn cảnh của bạn.

Vấn đề của Big Bang delivery

Hãy tưởng tượng: team code 12 tháng. Spec viết từ tháng 1. Xong, gói vào một “Version 1.0” khổng lồ, đi giao cho khách.

Khách nhìn thấy cái gì? Một sản phẩm đúng như spec tháng 1 — nhưng thị trường đã thay đổi từ tháng 6.

Hình 2. “Big Bang delivery” — giao hàng một lần sau 12 tháng. Post-it “Requirements from 1 year ago” rơi khỏi hộp vì chẳng ai nhớ nữa.

Đây là điểm yếu cổ điển của Waterfall khi dùng sai chỗ: rủi ro tích lũy suốt dự án và chỉ lộ ra lúc bàn giao. Phát hiện bug ở phase testing tốn gấp 10-15 lần so với phát hiện lúc code (dữ liệu từ IBM Systems Science Institute — không phải mình bịa). Phát hiện sai requirement sau khi đã code xong thì… thôi khỏi tính.

Agile giải quyết cái này bằng cách fail fast và fail cheap: thay vì chờ 12 tháng mới biết “ừa không đúng”, thì 2 tuần sau sprint 1 đã có người dùng test thử và nói “ủa tôi muốn cái này không phải cái kia.”

Nhưng Waterfall không phải đồ bỏ

Nói chuyện thẳng một chút: Agile bị oversell khá nhiều.

Có những dự án mà Waterfall không chỉ “chấp nhận được” — mà còn phù hợp hơn hẳn:

• Xây dựng, hạ tầng vật lý: không ai Agile việc xây cầu hay lắp đặt đường ống. “Sprint 1: xây 30% cái cầu. Sprint 2: dựa trên feedback của người đi đường, chúng ta sẽ thay đổi thiết kế.” Nghe vui không?
• Regulatory / compliance: y tế, hàng không, ngân hàng có khi yêu cầu phase-gate validation. Không thể “ship fast and iterate” với phần mềm điều khiển máy bay.
• Hợp đồng cố định: nếu khách đã ký fixed-price fixed-scope, Waterfall cho phép bạn kiểm soát phạm vi. Agile mà không có khung contractual rõ ràng → scope creep vô tận.
• Team nhỏ, yêu cầu rõ: startup 3 người build tool nội bộ với spec viết trong 2 tiếng. Overhead của Scrum (ceremony, backlog, velocity tracking) sẽ tốn hơn lợi ích nó mang lại.

Vấn đề không phải Waterfall xấu. Vấn đề là nhiều team dùng Waterfall trong ngữ cảnh mà yêu cầu thay đổi liên tục — rồi đổ lỗi cho phương pháp.

Agile cũng không phải câu trả lời cho tất cả

Mình sẽ nói thẳng một điều mà ít người nói: “Agile” hay bị biến thành giải pháp cho mọi vấn đề, kể cả những vấn đề Agile không giải quyết được.

Một số misconception phổ biến:

• “Agile = không cần document”: Sai. Agile không cấm doc — chỉ ưu tiên working software hơn comprehensive documentation. Nhưng nếu bạn không có doc nào luôn, đó là vấn đề khác.
• “Agile = không cần plan”: Sai. Agile plan liên tục, chỉ là ở horizon ngắn hơn và sẵn sàng điều chỉnh khi thực tế thay đổi.
• “Chạy sprint = đang Agile”: Dùng Jira và đặt deadline “2 tuần” không có nghĩa là Agile. Nếu sprint không có retrospective thật, không có working software, không có feedback loop thật — thì bạn chỉ đang dùng Waterfall với tên gọi khác.

Cuối cùng, Agile vẫn cần kỷ luật. Kỷ luật của người viết code sạch để có thể thay đổi được. Kỷ luật của PO biết prioritize. Kỷ luật của team làm retro thật chứ không phải họp cho có.

Khi nào dùng cái nào?

Đây là câu hỏi thực tế nhất — và câu trả lời phụ thuộc vào một vài biến số:

Hình 3. Không phải “cái nào đúng” mà là “cái nào phù hợp ngữ cảnh của bạn”. Regulatory, physical constraints, fixed budget → nghiêng về Waterfall. Requirements evolve, software product, feedback loop critical → nghiêng về Agile.

Nếu muốn một rule of thumb:

Nếu bạn biết chắc mình muốn cái gì, và nó sẽ không thay đổi → Waterfall.
Nếu bạn biết mình muốn đi đến đâu, nhưng không chắc đường đi → Agile.

Thực tế, hầu hết dự án phần mềm rơi vào nhóm thứ hai — vì phần mềm là thứ duy nhất bạn có thể thay đổi sau khi đã xây xong.

Hybrid: không phải chọn một

Nhiều team đang làm điều thực dụng nhất: lấy điểm mạnh của cả hai.

• Giai đoạn discovery / inception: Waterfall-ish. Làm rõ scope, phân tích rủi ro, chốt kiến trúc cơ bản.
• Giai đoạn delivery: Agile. Sprint 2 tuần, demo liên tục, điều chỉnh theo feedback.
• Giai đoạn compliance / audit: phase-gate validation theo quy định.

SAFe, DAD, và nhiều framework khác thực chất đang làm điều này — cố gắng scale Agile lên dự án lớn mà vẫn giữ được governance.

Không hoàn hảo, nhưng thực dụng.

Takeaway

Agile và Waterfall không phải tôn giáo để tranh nhau ai đúng ai sai. Chúng là công cụ có constraint — và công cụ nào cũng có ngữ cảnh phù hợp của nó.

Câu hỏi thực tế bạn nên tự hỏi trước khi chọn:

• Yêu cầu có ổn định không? Nếu có → Waterfall an toàn hơn. Nếu không → Agile.
• Rủi ro lộ ra khi nào? Cuối dự án → Waterfall tệ. Mỗi sprint → Agile tốt hơn.
• Team có discipline để làm Agile thật không? Không có retrospective thật, không có PO thật, không có working software sau sprint → đừng gọi là Agile.
• Contract và stakeholder đòi gì? Fixed-price fixed-scope → cần khung Waterfall rõ hơn.

Lần sau ai nói “Agile tốt hơn Waterfall” hay ngược lại, bạn có thể hỏi lại một câu đơn giản: “Trong ngữ cảnh nào?” Câu đó đủ để biết người kia đang nói chuyện kinh nghiệm hay chỉ đang quote bài LinkedIn.