Thông thường mô hình waterfall truyền thống để phát triển phần mềm gồm một số giai đoạn tách biệt: Phân tích Nhu cầu > Kiến trúc và Thiết kế > Xây dựng > Kiểm thử > Chuyển giao và Phản hồi.

• Phân tích Nhu cầu: trong bước này, toàn bộ nhu cầu phần mềm được nhận biết, phạm vi được xác định. Trong các quy trình chặt chẽ, những yêu cầu đó được thể hiện chi tiết, văn bản hóa, theo tiêu chuẩn hoặc không, cần người có trách nhiệm phê chuẩn (approve) trước khi được tiến hành bước tiếp theo, và khi đã sang bước tiếp theo, hạn chế sự thay đổi.
• Kiến trúc và Thiết kế: Trước khi bước sang giai đoạn mã hóa, toàn bộ giải pháp của hệ thống cũng như kiến trúc của nó cần được xác định, văn bản hóa và được phê chuẩn bởi người có trách nhiệm.
• Xây dựng (Development, hay còn gọi là Triển khai-Implementation, hoặc Mã hóa-Coding): đây là giai đoạn hiện thực hóa giải pháp đã được đưa ra (từ bước 2) thành ra các mã nguồn và những chương trình thực thi được.
• Kiểm thử: Trước khi phần mềm được chuyển giao tới khách hàng hay người dùng cuối, nó cần được kiểm thử để bảo đảm về chất lượng. Các lỗi tìm được và những đoạn mã nguồn không đạt chuẩn được đưa trở lại các lập trình viên xử lí (bước 4) cho tới khi nào “hết lỗi”.
• Chuyển giao và phản hồi: khi chất lượng phần mềm được “bảo đảm”, toàn bộ phần mềm được chuyển giao tới người dùng. Có thể có hoặc không các công đoạn tiếp theo để nhận phản hồi như lỗi, hỗ trợ kĩ thuật, các việc “vá lỗi”, bảo trì v.v.

Đặc điểm nổi bật của waterfall truyền thống là các công đoạn được xếp tuần tự (sequential), dựa trên kế hoạch (plan-driven). Các giai đoạn tách rời nhau, phải hết giai đoạn “Nhu cầu” mới được chuyển sang giai đoạn “Thiết kế”, không thể thực hiện “Mã hóa” mà chưa làm “Design”. Mặc dù các quy trình hiện tại theo mô hình waterfall đã có những cải biên cho phép những phản hồi (feedback) tới các bước trước đó, nhằm giúp quy trình linh hoạt hơn, nhưng về bản chất, chúng vẫn tách rời nhau như vậy. Hơn thế nữa, các hoạt động trong đội ngũ phát triển phải dựa vào kế hoạch. Quản lí sẽ lập kế hoạch, rồi giao việc, rồi kiểm soát (tiến độ, năng suất, chất lượng v.v.) dựa theo kế hoạch; nhân viên làm việc theo tinh thần tuân thủ kế hoạch, ít phản hồi. Cách làm việc tách biệt và tuần tự này được phản ánh rõ nét trong cơ cấu các phòng ban chức năng (test, development, management), các vai trò của cá nhân (tester, developer, QA, PM, BA ...) – mỗi người có mô tả công việc rõ rệt, không ai giẫm chân lên công việc của người khác; và các quy trình nghiệp vụ chặt chẽ được văn bản hóa (hay pháp chế hóa) trong phạm vi tổ chức.

Khác với waterfall truyền thống, Agile không làm việc theo kiểu tuân thủ kế hoạch (plan-driven) mà lựa chọn việc “thích ứng với sự thay đổi”. Nó hầu như không tiếp cận tuần tự, mà là chồng lấp (overlapping - tức là các công việc được tiến hành không tuần tự, có thể song song, có thể đồng thời với sự cộng tác chặt chẽ hướng đến mục tiêu chung) để xây dựng phần mềm.

Phát triển tuần tự (Type A) và chồng lấp (B, C), theo Nonaka & Takeuchi (Havard Business Review)

Theo khảo sát mới đây (2011) của Forrester Research, các cách tiếp cận phổ biến trong phát triển phần mềm có thể kể đến gồm Scrum, Iterative (Iterative Development - phát triển lặp), Waterfall, TDD, Kanban, XP.

Bảng thống kê một phần này cho thấy phần lớn các công ty hiện nay đã bắt đầu sử dụng Scrum như là cách tiếp cận cơ bản. Bên cạnh đó, nhiều công ty đã kết hợp các phương pháp lại với nhau trong thực tiễn. Ví dụ 44.4 % các công ty có sử dụng Waterfall, như vậy có nghĩa là một tỉ lệ nhất định nào đó vừa dùng waterfall, vừa sử dụng Scrum trong hoạt động của mình. Điều này có thể do các nguyên nhân lịch sử, hoặc các ràng buộc về chính sách, luật pháp hoặc văn hóa. Đó cũng là một tình huống khá phổ biến đối với các công ty mới lần đầu “bước chân” vào “ma trận các phương pháp Agile”.

Bảng dưới đây của VersionOne khảo sát trên các công ty Agile, cho thấy những phương pháp phổ biến được sử dụng:

Bây giờ là lúc ta tìm hiểu từng cái tên trong bảng trên có điều gì đặc biệt.

Hãy bắt đầu với phương pháp được dùng phổ biến nhất: Scrum là gì?

Bài tiếp: Phương pháp eXtreme Programming