Nói về Waterfall trước
Waterfall là phương pháp phát triển phần mềm truyền thống, mà trong đó để release được sản phẩm ta phải trải qua đầy đủ các công đoạn: Định nghĩa yêu cầu –> Thiết kế –> Lập trình –> Kiểm thử –> Triển khai. Trong Waterfall, khâu lập kế hoạch là khâu quan trọng nhất. Lập kế hoạch sai có thể làm hỏng 50% dự án.
Vấn đề với Waterfall
Về bản chất, Waterfall là cách tiếp cận sai lầm.
Phát triển phần mềm chưa bao giờ là 1 công việc đơn giản tới mức mà có thể dự đoán trước được kịch bản của hàng tháng hay hàng năm trời. Không giống như 1 số việc mang tính chất chân tay lặp đi lặp lại, cứ ốp công thức nhân số người sẽ ra số thành phẩm. Làm phần mềm là công việc có tính chất sáng tạo.
Trong Waterfall, người ta tự tin rằng có thể dự đoán trước tương lai thông qua việc ước lượng (estimate) dự án. Kịch bản thường thấy là: với 1 team X người, sau khoảng thời gian Y tháng sẽ tạo ra được sản phẩm với yêu cầu Z. Căn cứ để tạo nên ước lượng này là dựa trên kinh nghiệm quá khứ với những sản phẩm tương tự. Tuy nhiên
- Rất hiếm có sản phẩm nào giống hệt 1 sản phẩm nào. Ngoài ra yêu cầu và công nghệ luôn luôn thay đổi rất nhanh.
- Con người khác nhau sinh ra những output khác nhau.
- Lập trình gần về phía nghệ thuật hơn là cày cuốc. Tức là nó sẽ giống việc bạn vẽ 1 bức tranh: cần cảm hứng, cần suy nghĩ, output tương đối khó dự đoán – hơn là việc đóng gạch: cứ đóng là sẽ ra gạch, X người đóng trong Y tháng chắc chắn sẽ ra Z gạch.
- Quan trọng nhất: thế giới và thị trường đang thay đổi chóng mặt. Ý tưởng mà 6 tháng trước bạn cho là hay, là đi trước thời đại có thể bị ai đó thực hiện từ trước. Những gì bạn cho là đúng, là xịn sò khi đưa ra thị trường lại không được người dùng đón nhận. Vì thế việc phát hành sản phẩm sớm, nhận phản hồi sớm và tích cực thay đổi cải thiện mới là chìa khóa thành công.
Lập trình cần đầu tư suy nghĩ và cảm hứng làm việc
Hướng đi với Agile
Khác với Waterfall, Agile tập trung vào việc release sớm và đón nhận những thay đổi. Agile không tập trung việc giữ khư khư 1 kế hoạch để rồi “mắc kẹt” với chính kế hoạch đó. Theo survey năm 2018 từ StackOverflow, các dự án áp dụng Agile đang ở mức 85%, 1 con số rất cao. Ngược lại Waterfall chỉ còn 15%.
Agile không phải là xu hướng nhất thời
Tuy nhiên, Nhật Bản lại là câu chuyện khác
Nếu như ở Âu Mỹ, việc áp dụng Agile là tương đối phổ biến thì ở Nhật Bản các dự án áp dụng Waterfall vẫn còn rất nhiều.
Các khách hàng mới tiếp cận, hầu hết sẽ muốn chọn Waterfall thay vì Agile. Đứng từ quan điểm khách hàng thì Waterfall vẫn có 1 số ưu điểm nhất định
- Cảm giác an toàn: Biết chắc rằng khi mình bỏ ra X tiền sẽ thu về được sản phẩm Z. Có thể trễ deadline, có thể có bug, nhưng ít ra trên giấy tờ, khách hàng có thể đo đếm được sản phẩm này có “đắt” hay không?
- Bản thân phía các công ty Nhật Bản vẫn còn chuộng hình thức thầu khoán 下請け: đưa 1 budget X và nhận về sản phẩm Z, thậm chí là thầu khoán nhiều lớp 多重下請け: công ty nhận làm sản phẩm lại giao cho 1 công ty khác. Với hình thức này thì Agile không áp dụng được, do Agile yêu cầu phải có tương tác liên tục giữa người sở hữu sản phẩm và đội phát triển. Tương tác này sẽ dẫn tới các thay đổi, mỗi thay đổi lại ảnh hưởng tới budget đã được hợp đồng trước giữa nhiều công ty.
Chúng ta nên làm gì?
- Nắm chắc ưu điểm của Agile so với Waterfall truyền thống, và nói với khách hàng điều đó. Một thực tế là trong môi trường outsourcing, mục tiêu của đội Sales là lấy về dự án, càng nhiều càng tốt. Chuyện phát triển như thế nào thì đấy là vấn đề của đội Dev.
- Nhưng để có mối quan hệ Win-Win giữa khách hàng và phía thực hiện dự án thì tiền đề là sản phẩm phần mềm tạo ra phải đạt được thành công. Thành công thế nào khi vẫn sử dụng cách dự đoán tương lai trong 1 môi trường thay đổi liên tục?
- Vì thế, chúng ta, mà cụ thể ở đây là đội Sales làm việc trực tiếp với khách hàng nên trang bị đầy đủ kiến thức về Agile, về phát triển phần mềm để có thể tư vấn tốt nhất cho khách hàng.