Waterfall (thác nước) là cách quản lý dự án theo trình tự: xác định yêu cầu, thiết kế, thực hiện, kiểm tra rồi bàn giao, mỗi giai đoạn xong mới chuyển sang giai đoạn sau; agile là cách làm theo các vòng lặp ngắn, mỗi vòng bàn giao một phần dùng được và điều chỉnh kế hoạch theo phản hồi. Khác biệt sâu nhất không nằm ở công cụ mà ở giả định: waterfall giả định có thể biết khá đủ từ đầu, agile giả định phải làm mới biết.
Không phương pháp nào tốt hơn tuyệt đối. Bài này giải thích nguồn gốc của hai cách tiếp cận (kể cả việc bài báo thường được coi là khai sinh waterfall thực ra cảnh báo chống lại nó), so sánh theo từng tiêu chí, chỉ ra hiểu lầm phổ biến và đưa ra khung chọn phương pháp theo đặc điểm dự án, kèm cách kết hợp hai bên.
Nguồn gốc: Royce 1970 và Tuyên ngôn Agile 2001
Bài báo hay được dẫn làm gốc của waterfall là Managing the Development of Large Software Systems của Winston Royce năm 1970. Điều trớ trêu là Royce trình bày mô hình tuần tự thuần tuý như một cách làm “rủi ro và dễ thất bại”, rồi đề xuất bổ sung các vòng phản hồi, làm thử bản sơ bộ và cho khách hàng tham gia. Tên gọi “waterfall” xuất hiện về sau, và phiên bản tuần tự cứng nhắc được phổ biến một phần qua các tiêu chuẩn mua sắm phần mềm quốc phòng.
Trong ngành xây dựng và chế tạo, cách làm theo giai đoạn đã có từ lâu trước đó vì lý do vật lý: không thể đổ móng lại sau khi đã xây tầng. Vấn đề nảy sinh khi mô hình này được áp vào phần mềm và sản phẩm mới, nơi yêu cầu thay đổi liên tục và chi phí thử nghiệm thấp.
Tháng 2 năm 2001, mười bảy người làm phần mềm họp ở Snowbird, bang Utah, và công bố Tuyên ngôn Agile gồm bốn giá trị và mười hai nguyên tắc. Bốn giá trị ưu tiên: 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 đủ; cộng tác với khách hàng hơn đàm phán hợp đồng; phản hồi thay đổi hơn bám theo kế hoạch. Tuyên ngôn nói rõ vế sau vẫn có giá trị, chỉ là vế trước được coi trọng hơn. Các phương pháp như Scrum (Ken Schwaber và Jeff Sutherland trình bày năm 1995) và Extreme Programming đã có trước đó; tuyên ngôn là điểm hội tụ chung.
So sánh theo từng tiêu chí
Bảng dưới so sánh hai cách tiếp cận ở dạng điển hình. Trong thực tế, phần lớn dự án nằm đâu đó giữa hai cực:
| Tiêu chí | Waterfall (dự đoán) | Agile (thích ứng) |
|---|---|---|
| Giả định nền | Yêu cầu biết được và ổn định từ đầu | Yêu cầu sẽ thay đổi khi người dùng thấy sản phẩm |
| Lập kế hoạch | Chi tiết từ đầu cho toàn dự án | Khái quát cho dài hạn, chi tiết cho vòng lặp kế tiếp |
| Cố định gì | Phạm vi cố định; thời gian và chi phí được ước tính theo phạm vi | Thời gian và đội cố định; phạm vi linh hoạt theo ưu tiên |
| Bàn giao | Một lần hoặc vài lần lớn ở cuối | Thường xuyên, từng phần dùng được |
| Thay đổi | Qua quy trình kiểm soát thay đổi chính thức | Được đón nhận, sắp lại thứ tự trong danh sách việc |
| Vai trò khách hàng | Tham gia nhiều ở đầu và cuối | Tham gia liên tục, thường có đại diện trong nhóm |
| Đo tiến độ | Theo kế hoạch và đường cơ sở | Theo phần sản phẩm hoàn thành và giá trị đã giao |
| Rủi ro điển hình | Phát hiện sai yêu cầu quá muộn | Phạm vi trôi, khó cam kết ngày và ngân sách tổng |
Hàng “cố định gì” là chỗ quan trọng nhất để giải thích cho ban giám đốc. Waterfall hỏi “làm đủ những thứ này thì mất bao lâu, bao nhiêu tiền”; agile hỏi “với đội này trong từng này thời gian, ta giao được những thứ giá trị nhất nào”. Hai câu hỏi dẫn tới cách lập ngân sách và hợp đồng khác nhau.
Những hiểu lầm phổ biến về agile và waterfall
Phần lớn tranh luận “agile hay waterfall” trong doanh nghiệp xuất phát từ hiểu lầm về một trong hai bên:
- “Agile là không lập kế hoạch.” Agile lập kế hoạch thường xuyên hơn, ở nhiều tầng: tầm nhìn sản phẩm, lộ trình, kế hoạch đợt phát hành, kế hoạch vòng lặp. Cái khác là kế hoạch được coi là giả thuyết cần kiểm chứng.
- “Agile là không có tài liệu.” Tuyên ngôn ưu tiên sản phẩm chạy được hơn tài liệu đầy đủ, không phải bỏ tài liệu. Tài liệu cần cho vận hành, kiểm toán, pháp lý vẫn phải có.
- “Agile chỉ dùng cho phần mềm.” Các nguyên lý vòng lặp ngắn và phản hồi sớm được dùng trong phát triển sản phẩm, tiếp thị, thậm chí một phần dự án phần cứng. Nhưng không phải mọi bối cảnh đều thử nghiệm rẻ được như phần mềm.
- “Waterfall là lỗi thời.” Với dự án có yêu cầu pháp lý chặt, thiết kế phải duyệt trước khi thi công, chi phí làm lại cực cao, kế hoạch dự đoán vẫn là lựa chọn hợp lý.
- “Họp đứng mỗi sáng là đã agile.” Nghi thức không tạo ra tính thích ứng nếu sản phẩm không được bàn giao thường xuyên và phản hồi không làm thay đổi kế hoạch. Cách làm này hay được gọi mỉa là “agile hình thức”.
- “Agile luôn nhanh hơn và rẻ hơn.” Agile giúp giảm rủi ro làm sai thứ cần làm và đưa giá trị đến sớm; tổng thời gian để làm một phạm vi cố định không nhất thiết ngắn hơn.
Về bằng chứng, các khảo sát ngành thường được dẫn để nói agile “thành công hơn” có phương pháp chọn mẫu và định nghĩa thành công gây tranh cãi, nên cần đọc thận trọng. Điều có cơ sở vững hơn là phản hồi sớm làm giảm chi phí sửa sai, một nguyên lý đã được ghi nhận trong kỹ nghệ phần mềm từ lâu.
Khung chọn phương pháp theo đặc điểm dự án
Mức độ rõ ràng của yêu cầu. Nếu người đặt hàng mô tả được kết quả cụ thể và ít khả năng đổi, ví dụ lắp thêm một dây chuyền giống dây chuyền hiện có, kế hoạch dự đoán phù hợp. Nếu kết quả chỉ được hiểu khi người dùng dùng thử, ví dụ ứng dụng bán hàng mới, cách làm thích ứng phù hợp hơn.
Chi phí làm lại. Phần mềm, nội dung, quy trình nội bộ có chi phí sửa tương đối thấp; kết cấu xây dựng, khuôn đúc, thiết bị đặt riêng có chi phí sửa rất cao. Chi phí làm lại càng cao, càng cần chốt thiết kế trước.
Khả năng bàn giao từng phần. Nếu sản phẩm chia được thành phần có giá trị độc lập, như từng phân hệ hoặc từng cửa hàng, có thể làm vòng lặp. Một cây cầu không có giá trị khi mới xong một nửa.
Mức tham gia của người dùng. Agile cần đại diện phía đặt hàng có thời gian và quyền quyết định thường xuyên. Nếu bên đặt hàng chỉ dành được vài buổi duyệt, cách làm thích ứng sẽ thiếu nguyên liệu chính.
Ràng buộc hợp đồng và pháp lý. Đấu thầu theo phạm vi cố định, phê duyệt của cơ quan quản lý theo hồ sơ thiết kế đẩy dự án về phía dự đoán. Hợp đồng theo thời gian và vật tư hoặc theo khung năng lực tạo điều kiện cho agile.
Văn hoá tổ chức. Agile đòi hỏi trao quyền cho nhóm và chấp nhận kế hoạch thay đổi. Tổ chức quen phê duyệt nhiều tầng có thể bắt đầu bằng cách kết hợp thay vì chuyển hẳn.
Cách kết hợp: khung giai đoạn bên ngoài, vòng lặp bên trong
Trong khảo sát của PMI và kinh nghiệm thực tế, cách tiếp cận kết hợp (hybrid) rất phổ biến. Bản thân PMBOK bản thứ bảy và các hướng dẫn agile đi kèm của PMI đều thừa nhận người quản lý dự án nên chọn và điều chỉnh phương pháp theo bối cảnh thay vì theo một trường phái. Có ba mẫu kết hợp thường gặp.
Thứ nhất, cổng giai đoạn bên ngoài, vòng lặp bên trong: dự án có các cổng phê duyệt đầu tư theo kiểu dự đoán, nhưng mỗi giai đoạn được thực hiện theo vòng lặp hai đến bốn tuần. Phù hợp với doanh nghiệp cần kiểm soát ngân sách theo đợt. Thứ hai, chia theo cấu phần: phần cứng, hạ tầng, xây dựng theo kế hoạch dự đoán; phần mềm, nội dung, quy trình theo vòng lặp; hai bên đồng bộ qua các mốc tích hợp cố định. Thứ ba, dự đoán ở đầu, thích ứng ở cuối: chốt kiến trúc và những quyết định khó đảo ngược trước, phần chi tiết làm theo vòng lặp.
Ví dụ: một doanh nghiệp bán lẻ mở mô hình cửa hàng mới. Thuê mặt bằng, thi công, lắp thiết bị đi theo lịch Gantt với đường găng rõ. Bố trí quầy, danh mục hàng, quy trình phục vụ được thử nghiệm tại cửa hàng đầu tiên theo vòng hai tuần, đo phản hồi khách rồi điều chỉnh trước khi nhân rộng. Rủi ro của cách kết hợp là lấy phần nặng nề của cả hai: vừa hồ sơ dày, vừa họp nhiều. Cần thiết kế có chủ đích, ghi rõ phần nào theo quy tắc nào.
Chuyển một nhóm sang làm agile: các bước thận trọng
Nếu quyết định thử agile cho một dự án hoặc một nhóm, các bước sau giúp tránh biến nó thành phong trào hình thức:
- Chọn một dự án thí điểm có yêu cầu chưa rõ, chia được thành phần nhỏ, và có người đặt hàng sẵn sàng tham gia thường xuyên.
- Chỉ định một người phía đặt hàng có quyền quyết định thứ tự ưu tiên; thiếu vai trò này thì danh sách việc sẽ do người to tiếng nhất quyết định.
- Chọn một khung cụ thể như Scrum hoặc Kanban và làm đúng theo hướng dẫn gốc trong vài tháng trước khi tuỳ biến.
- Định nghĩa thế nào là “xong” cho một phần việc, gồm kiểm thử và tài liệu tối thiểu, để tránh tích luỹ phần dở dang.
- Thống nhất với phòng tài chính cách cấp ngân sách theo đội và theo thời gian thay vì theo phạm vi chi tiết.
- Đo kết quả bằng giá trị bàn giao và phản hồi người dùng, không đo bằng số cuộc họp hay số điểm hoàn thành.
- Sau ba đến sáu tháng, đánh giá nghiêm túc: điều gì tốt hơn, điều gì tệ hơn, rồi mới quyết định mở rộng.
Câu hỏi thường gặp
Scrum và agile có phải là một không?
Không. Agile là tập giá trị và nguyên tắc; Scrum là một khung làm việc cụ thể theo tinh thần agile, với vai trò, sự kiện và sản phẩm xác định. Kanban, Extreme Programming cũng là cách làm agile. Một nhóm có thể agile mà không dùng Scrum.
Dự án xây dựng có áp dụng agile được không?
Phần thiết kế, chuẩn bị và hoàn thiện nội thất có thể áp dụng một số nguyên lý như lập kế hoạch cuốn chiếu và họp điều phối ngắn. Phần kết cấu chịu ràng buộc vật lý và pháp lý nên vẫn theo trình tự. Ngành xây dựng có hướng tiếp cận riêng như Last Planner System, gần với tinh thần này.
Agile có lập được ngân sách cố định không?
Có, theo cách cố định đội và thời gian, từ đó ra ngân sách, còn phạm vi linh hoạt. Ban giám đốc cần chấp nhận rằng ngân sách cố định đi kèm phạm vi được ưu tiên lại liên tục, không phải phạm vi cố định với ngân sách cố định.
Hợp đồng thuê ngoài nên chọn kiểu nào khi làm agile?
Hợp đồng theo thời gian và vật tư hoặc theo đội có trần chi phí thường phù hợp hơn hợp đồng trọn gói với phạm vi chi tiết. Một số bên dùng hợp đồng khung kèm các đơn đặt hàng theo từng đợt phát hành để vừa linh hoạt vừa kiểm soát.
Làm sao biết dự án của mình đang agile hình thức?
Dấu hiệu thường gặp: có họp hằng ngày và vòng lặp nhưng không bàn giao gì dùng được trong nhiều tháng, phản hồi người dùng không làm đổi danh sách việc, và kế hoạch vẫn được duyệt một lần từ đầu. Khi đó chỉ có nghi thức mà không có tính thích ứng.