Waterfall
Mô hình phát triển đi tuần tự qua từng pha, mỗi pha ký duyệt xong mới sang pha sau. Bị chê nhiều nhưng vẫn là cách chạy phổ biến ở dự án ngân hàng, nhà nước và các hợp đồng trọn gói tại Việt Nam.
Định nghĩa
Bị chê nhiều nhất, mà vẫn chạy nhiều nhất. Waterfall xếp các pha thành một hàng dọc: xong phân tích mới thiết kế, xong thiết kế mới code, xong code mới test. Giữa hai pha là một cửa ký duyệt. Ý tưởng gốc là mỗi pha khoá lại thì pha sau có nền chắc để đứng.
Waterfall đánh cược rằng bạn hiểu đúng vấn đề ngay từ đầu. Khi vụ cược đó thắng, nó là mô hình rẻ và gọn nhất.
Waterfall và Agile
| Waterfall | Agile | |
|---|---|---|
| Yêu cầu | Chốt trọn gói ở đầu, đổi thì mở CR | Làm rõ dần, ưu tiên lại mỗi sprint |
| Bàn giao | Một lần vào cuối, hoặc vài mốc lớn | Từng phần chạy được, đều đặn |
| Tài liệu | Nặng, ký duyệt từng bản | Vừa đủ, sống theo backlog |
| Khách tham gia | Đầu và cuối là chính | Liên tục, tốt nhất là hằng ngày |
| Phát hiện hiểu sai | Ở UAT, lúc sửa đắt nhất | Sau vài tuần, lúc sửa còn rẻ |
| Cái cố định | Phạm vi. Thời gian và chi phí co giãn | Thời gian và nguồn lực. Phạm vi co giãn |
Dòng cuối là điểm khác biệt gốc, và cũng là chỗ nhiều dự án Việt Nam gãy: cố định cả ba thứ cùng lúc rồi gọi tên là agile.
Khi nào waterfall là lựa chọn đúng
Có những tình huống chạy waterfall hợp lý hơn hẳn:
- Yêu cầu do luật hoặc quy định định sẵn. Một báo cáo bắt buộc nộp cơ quan quản lý có mẫu cố định, ngày hiệu lực cố định. Chẳng có gì để khám phá dần.
- Hợp đồng trọn gói, chấm thầu theo hồ sơ. Bên mời thầu cần biết chính xác mua cái gì với giá nào trước khi ký. Phạm vi buộc phải chốt.
- Chi phí sửa sai sau triển khai cực cao. Phần mềm gắn với thiết bị, thẻ, máy in chuyên dụng, hoặc thứ đã đưa tới 200 điểm ở tỉnh.
- Một lần cắt chuyển duy nhất. Thay hệ thống lõi, chuyển dữ liệu một phát, không có đường lùi thì kế hoạch phải rất chi tiết từ trước.
- Bên thứ ba khoá lịch. Đối tác chỉ mở môi trường tích hợp trong hai tuần cố định của quý.
Ở Việt Nam nó chưa chết, nói thẳng
Dự án cho khối nhà nước gần như luôn có hình dạng waterfall, vì hồ sơ mời thầu và biên bản nghiệm thu theo giai đoạn buộc phải vậy. Dự án ngân hàng thì hỗn hợp: phần lõi và phần liên quan tuân thủ chạy theo pha có ký duyệt, phần kênh số chạy sprint. Nhiều công ty outsourcing bán hợp đồng fixed-price rồi bảo team "làm agile bên trong" — bên trong thì lặp, nhưng cam kết với khách vẫn là một danh sách chức năng đóng khung.
Cách sống chung khoẻ nhất là thừa nhận nó ngay từ đầu và cài sẵn hai thứ: một quy trình CR gọn để thay đổi có đường đi hợp lệ, và ít nhất một lần cho khách xem bản chạy được ở giữa chặng, dù hợp đồng không bắt. Bản demo giữa chặng là thứ rẻ nhất bạn có thể làm để giảm rủi ro của cả mô hình.
Ví dụ thực tế
Dự án bổ sung mẫu báo cáo mới cho một công ty tài chính tiêu dùng, hạn nộp bản đầu tiên là ngày 15 của tháng sau khi quy định có hiệu lực, không xê dịch.
Đội chạy waterfall thuần: hai tuần đọc quy định và dựng bảng ánh xạ 84 chỉ tiêu về nguồn dữ liệu, một tuần chốt và ký, ba tuần code, hai tuần test với dữ liệu ba tháng gần nhất, một tuần đối chiếu tay với báo cáo cũ.
Chỗ đau nằm ở bảng ánh xạ: 11 chỉ tiêu không có nguồn dữ liệu nào trong hệ thống hiện tại. Phát hiện được ở tuần thứ hai nên còn kịp mở một luồng nhập tay tạm thời. Nếu chạy kiểu vừa làm vừa khám phá, 11 chỉ tiêu đó có thể lòi ra ở tuần thứ bảy, và không còn cửa nào để xoay.
BA trong dự án waterfall làm khác chỗ nào
Bạn không có sprint để sửa dần, nên chất lượng của tài liệu là thứ duy nhất bảo vệ bạn. Ba thói quen đáng giữ:
- Viết một mục "những gì nằm ngoài phạm vi" dài bằng mục phạm vi. Tranh cãi về sau gần như luôn nằm ở vùng xám giữa hai mục này.
- Ghi rõ giả định và ràng buộc, kèm ngày. Giả định "dữ liệu khách hàng cũ đã chuẩn hoá số điện thoại" mà sai thì cả lịch trình sập, và bạn cần bằng chứng là mình đã hỏi.
- Xin demo giữa chặng, dù hợp đồng không có mục đó. Nửa ngày ngồi với người dùng cuối ở tuần thứ sáu tiết kiệm nhiều tuần sửa sau UAT.
