Phát triển phần mềm Agile và Waterfall: Chọn phương pháp phù hợp cho dự án của bạn

Việc chọn cách đội của bạn lập kế hoạch, xây dựng và phát hành là một trong những quyết định quan trọng nhất trong giai đoạn đầu của phát triển phần mềm. Sự khác biệt giữa phương pháp agile và waterfall cũng như thời điểm nên dùng từng phương pháp không chỉ là vấn đề học thuật: chúng ảnh hưởng đến tốc độ giao hàng, vòng phản hồi về chất lượng, giao tiếp với các bên liên quan và mức độ thay đổi mà quy trình của bạn có thể hấp thụ mà không làm lệch hướng bản phát hành. Bài viết này giải thích cách mỗi cách tiếp cận hoạt động, thế mạnh của từng cách và cách đưa ra quyết định một cách tự tin.

Điều thực sự được tối ưu hóa bởi waterfall

Waterfall tổ chức công việc thành các giai đoạn tuần tự như yêu cầu, thiết kế, triển khai, kiểm thử và đưa vào vận hành. Mỗi giai đoạn dự kiến hoàn thành trước khi giai đoạn tiếp theo bắt đầu, tạo ra các sản phẩm được phê duyệt đóng vai trò như hợp đồng giữa các nhóm. Cấu trúc này tối ưu cho khả năng dự đoán, tuân thủ và việc bàn giao rõ ràng. Khi vấn đề được hiểu rõ và môi trường ổn định, waterfall có thể giảm sự mơ hồ vì mọi người đều biết phạm vi bao gồm và không bao gồm những gì.

Waterfall thường phù hợp với các dự án có ràng buộc pháp lý cố định, phụ thuộc vào phần cứng hoặc hợp đồng giá cố định, trong đó phạm vi, ngân sách và thời gian được đàm phán từ đầu. Cách này cũng phù hợp với các nhóm phải phối hợp nhiều phê duyệt bên ngoài hoặc phát hành lớn, không thường xuyên với khả năng lặp lại sau phát hành tối thiểu. Đổi lại, việc phát hiện lỗi muộn hoặc thay đổi giả định thị trường sẽ trở nên tốn kém, vì công việc sửa chữa cắt ngang nhiều giai đoạn đã hoàn thành.

Điều thực sự được tối ưu hóa bởi agile

Agile tổ chức công việc thành các vòng lặp ngắn tạo ra một增量 có thể phát hành. Thay vì đặc tả chi tiết nặng nề từ đầu, agile nhấn mạnh phần mềm hoạt động, phản hồi liên tục và lập kế hoạch thích ứng. Product backlog được tinh chỉnh thường xuyên, các ưu tiên thay đổi khi việc học hỏi tích lũy, và các nhóm đa chức năng chịu trách nhiệm về kết quả từ thiết kế đến triển khai.

Agile tối ưu cho tốc độ học hỏi và giảm rủi ro. Bằng cách phát hành các lát mỏng giá trị nhỏ hơn và đo lường chúng, các nhóm xác thực giả định sớm và thay đổi hướng đi mà không cần sửa chữa lớn. Chi phí là gánh nặng giao tiếp cao hơn và nhu cầu có quyền sở hữu sản phẩm mạnh mẽ. Agile không loại bỏ kỷ luật; nó chuyển kỷ luật từ kế hoạch chi tiết từ đầu sang thực thi có kỷ luật, kiểm tra thường xuyên và ưu tiên không ngừng.

Những khác biệt chính mà các nhóm thực sự cảm nhận

• Horizon lập kế hoạch: Waterfall lập kế hoạch cho hầu hết công việc từ đầu; agile lập kế hoạch chi tiết cho giai đoạn gần và giữ các chủ đề dài hạn linh hoạt.
• Nhịp phản hồi: Waterfall thu thập phản hồi tại các cột mốc; agile tìm phản hồi mỗi vòng lặp.
• Hồ sơ rủi ro: Waterfall tập trung rủi ro vào tích hợp và chấp nhận; agile phân tán rủi ro trên các increments thường xuyên.
• Khả năng chịu thay đổi: Waterfall coi thay đổi là một sự kiện chính thức; agile dự đoán và dự trữ ngân sách cho thay đổi.
• Tài liệu: Waterfall nhấn mạnh đặc tả toàn diện; agile ưu tiên tài liệu vừa đủ hỗ trợ giao hàng.
• Cấu trúc nhóm: Waterfall thường dùng bàn giao giữa các chuyên gia; agile ưu tiên nhóm đa chức năng với quyền sở hữu chung.

Khi nào waterfall phù hợp hơn

Chọn cách tiếp cận giống waterfall khi yêu cầu ổn định và có thể xác minh, khi các ràng buộc bên ngoài yêu cầu thiết kế chi tiết từ đầu, hoặc khi chi phí thay đổi muộn là cực lớn. Tích hợp hệ thống dạng xây dựng, các thành phần liên quan đến an toàn với tiêu chuẩn cố định và các dự án bị ràng buộc bởi mua sắm thường được hưởng lợi từ các cổng giai đoạn và phê duyệt chính thức. Waterfall cũng có thể thực tế khi bạn phải cam kết với phạm vi và giá cố định, và khi các bên liên quan yêu cầu kế hoạch chi tiết trước khi tiếp tục tài trợ.

Một quan niệm sai lầm phổ biến là waterfall có nghĩa là không kiểm thử cho đến cuối. Các nhóm trưởng thành vẫn kiểm thử trong mỗi giai đoạn. Sự khác biệt là kiểm thử được lập kế hoạch theo đặc tả hầu như đã đóng băng, và các thay đổi phạm vi lớn được xử lý thông qua kiểm soát thay đổi thay vì xếp lại ưu tiên backlog.

Khi nào agile phù hợp hơn

Agile mạnh nhất khi vấn đề phức tạp, thị trường thay đổi nhanh và phản hồi người dùng rất quan trọng đối với thành công. Các nhóm sản phẩm xây dựng ứng dụng hướng tới khách hàng, các tính năng dựa trên dữ liệu hoặc trải nghiệm phụ thuộc vào thông tin chi tiết về khả năng sử dụng được hưởng lợi từ các vòng lặp ngắn và phát hành thường xuyên. Agile cũng phù hợp với các tổ chức có thể đầu tư vào các thực hành giao hàng liên tục, vì phát hành thường xuyên khuếch đại giá trị của phản hồi nhanh.

Agile hoạt động tốt nhất khi quyền sở hữu sản phẩm tích cực, khi các bên liên quan có thể tham gia thường xuyên và khi nhóm có thể đưa ra quyết định kỹ thuật nhanh chóng. Nếu tổ chức của bạn có thể hỗ trợ công việc lô nhỏ, kiểm thử tự động và thiết kế theo từng bước, agile giảm rủi ro xây dựng sai thứ quá lâu.

Cách ra quyết định không theo ý thức hệ

Bắt đầu với bốn tín hiệu thực tế.

• Ổn định yêu cầu: Nếu các yêu cầu cốt lõi hiếm khi thay đổi và được hiểu rõ, waterfall có thể hiệu quả. Nếu yêu cầu xuất hiện dần dần, agile giảm lãng phí.
• Ràng buộc pháp lý và hợp đồng: Sản phẩm tuân thủ cố định và kiểm soát thay đổi chính thức thích waterfall. Phạm vi linh hoạt và hợp đồng dựa trên kết quả thích agile.
• Nhịp phát hành và vận hành: Phát hành lớn, không thường xuyên với kiểm tra chặt chẽ phù hợp với waterfall. Phát hành nhỏ, thường xuyên với pipeline tự động phù hợp với agile.
• Địa hình nhóm và kỹ năng: Các silo chuyên gia và phụ thuộc bên ngoài phù hợp với bàn giao waterfall. Các nhóm đa chức năng có năng lực DevOps phù hợp với dòng chảy agile.

Nhiều tổ chức kết hợp cả hai. Chẳng hạn, một chương trình có thể sử dụng lớp lập kế hoạch và quản trị theo phong cách waterfall ở cấp danh mục trong khi từng nhóm riêng thực hiện theo sprint hai tuần. Điều quan trọng là làm rõ cách kết hợp, với các quy tắc rõ ràng về phạm vi được chuẩn hóa cơ sở, cách thay đổi lan truyền và cách đo lường tiến độ.

Đưa cách tiếp cận đã chọn vào thực tế

Bất kể phương pháp nào, một số kỷ luật tạo ra kết quả. Định nghĩa một lát mỏng giá trị xuyên suốt từ đầu để bạn có thể tích hợp và học hỏi. Đầu tư vào kiểm thử tự động và tích hợp liên tục để chất lượng có thể lặp lại. Làm cho công việc trở nên hữu hình với backlog hoặc kế hoạch chung, và giới hạn công việc đang tiến hành để bảo vệ dòng chảy. Thống nhất nhịp cho đánh giá và nhìn lại, và sử dụng chúng để cải thiện chứ không phải để trình diễn.

Với waterfall, tăng cường quản lý rủi ro bằng các điểm kiểm tra tích hợp thường xuyên và việc học từ nguyên mẫu khi khả thi. Với agile, bảo vệ tính nhất quán của phạm vi bằng cách duy trì mục tiêu sản phẩm rõ ràng và sắp xếp các yếu tố hỗ trợ song song với tính năng. Trong cả hai trường hợp, align các chỉ số với kết quả: khả năng dự đoán giao hàng, tỷ lệ lỗi, thời gian chu trình và tác động đến khách hàng có nhiều thông tin hơn các chỉ số hoạt động.

Một quy tắc quyết định đơn giản

Nếu bạn có thể phát hành hàng tháng hoặc thường xuyên hơn, có quyền truy cập người dùng và kỳ vọng yêu cầu phát triển, agile có thể phục vụ bạn tốt. Nếu bạn phải cam kết với phạm vi cố định, đáp ứng các cổng chính thức và quản lý nhiều phụ thuộc bên ngoài, waterfall có thể an toàn hơn. Nếu bạn có các yếu tố của cả hai, áp dụng một cách kết hợp với các chính sách rõ ràng để các nhóm không bị mắc kẹt giữa hai bộ quy tắc.

Mục tiêu không phải là chọn một nhãn. Mục tiêu là chọn quy trình công việc giảm thiểu tốt nhất những rủi ro mà dự án của bạn thực sự phải đối mặt, đồng thời đưa ra cho đội của bạn một con đường rõ ràng từ ý tưởng đến giá trị.