Giới thiệu các mô hình phát triển phần mềm: Waterfall, Agile, Scrum

Vai trò cụ thể của BA trong từng mô hình được tách thành hai bài riêng ngay sau bài này, vì mỗi bên có đủ thứ để nói.

1. Mô hình phát triển phần mềm là gì?

Khái niệm

Mô hình phát triển phần mềm (Software Development Model), hay vòng đời phát triển phần mềm (Software Development Life Cycle — SDLC), là khung sườn mô tả các giai đoạn trong quá trình xây dựng và bảo trì một sản phẩm phần mềm. Nó chia một quá trình phức tạp thành các bước rõ ràng, để cả đội biết mình đang ở đâu và việc gì phải xong trước việc gì.

Các giai đoạn phổ biến: thu thập yêu cầu, phân tích, thiết kế, lập trình, kiểm thử, triển khai và bảo trì.

Cần tách bạch hai khái niệm hay bị dùng lẫn: SDLC là vòng đời — tập hợp các giai đoạn phải đi qua. Còn Waterfall, Iterative, Spiral… là cách tổ chức vòng đời đó. Nói cách khác, những giai đoạn trên gần như mô hình nào cũng có; cái khác nhau là thứ tự, độ dài, và lặp lại bao nhiêu lần — chứ không phải mô hình này có giai đoạn mà mô hình kia không có.

Vì sao BA cần biết?

• Biết dự án đang ở giai đoạn nào, đang cần gì ở bạn.
• Biết loại tài liệu nào là phù hợp. Viết một bản SRS 80 trang cho đội Scrum chạy sprint hai tuần là lãng phí; ngược lại, đưa vài User Story rời rạc cho một dự án đấu thầu nhà nước thì không qua nổi vòng nghiệm thu.
• Giao tiếp trơn tru với Developer, Tester và các bên liên quan, vì mọi người đang chơi chung một "luật chơi".
• Thích ứng nhanh khi đổi công ty hoặc đổi dự án.

Bài này đi sâu vào hai trường phái cốt lõi — Waterfall và Agile/Scrum — vì đó là hai thứ bạn gần như chắc chắn sẽ gặp. Các mô hình còn lại sẽ điểm qua ở cuối bài, sau khi bạn đã có hai cái mốc này để đối chiếu.

2. Mô hình Waterfall (thác nước)

Waterfall là một trong những mô hình lâu đời nhất, tiếp cận theo trình tự tuyến tính — như dòng nước của thác, chỉ chảy một hướng đi xuống.

Các giai đoạn

Các giai đoạn chủ yếu diễn ra tuần tự, giai đoạn sau bắt đầu khi giai đoạn trước đã được phê duyệt:

1. Requirement Gathering & Analysis — thu thập và làm rõ toàn bộ yêu cầu từ khách hàng và các bên liên quan.
2. Design — thiết kế kiến trúc hệ thống, cơ sở dữ liệu, giao diện người dùng.
3. Implementation — viết code dựa trên bản thiết kế.
4. Testing — kiểm tra phần mềm, tìm lỗi, đảm bảo đáp ứng yêu cầu.
5. Deployment — bàn giao và cài đặt cho người dùng.
6. Maintenance — hỗ trợ, sửa lỗi phát sinh, cập nhật nhỏ sau khi chạy thật.

Đặc điểm chính

• Tuần tự nghiêm ngặt: quay lại giai đoạn trước vẫn được, nhưng phải đi qua quy trình quản lý thay đổi — tốn thời gian và thường tốn tiền, nên trên thực tế ít ai muốn quay lại.
• Yêu cầu được chốt sớm: yêu cầu được phân tích, lập baseline và phê duyệt ở giai đoạn đầu. Không có nghĩa là không bao giờ đổi — đổi thì phải đi qua quy trình kiểm soát thay đổi.
• Tài liệu chi tiết ngay từ đầu: sản phẩm của mỗi giai đoạn là tài liệu đầy đủ, được ký duyệt.
• Ít chỗ cho thay đổi: yêu cầu đổi ở giai đoạn sau vừa khó vừa tốn kém.

Khi nào Waterfall phù hợp?

Waterfall không lỗi thời. Nó vẫn là lựa chọn đúng trong những bối cảnh sau:

• Yêu cầu rõ ràng và cố định ngay từ đầu, gần như không được phép đổi — ví dụ xây lại một hệ thống cũ đã có đặc tả chi tiết và đã chạy tốt nhiều năm.
• Công nghệ và công cụ đã quen thuộc với đội, ít rủi ro kỹ thuật bất ngờ.
• Dự án tương tự những dự án đội đã làm thành công trước đó.
• Bối cảnh đòi hỏi tuân thủ cao, phê duyệt từng giai đoạn, cần hồ sơ pháp lý hoặc hợp đồng chi tiết cố định từ đầu — dự án với cơ quan nhà nước, hoặc các ngành được quản lý chặt như y tế, hàng không.

Nói thêm cho đúng: môi trường tuân thủ cao không bắt buộc phải dùng Waterfall. Vẫn có đội chạy Agile trong ngành y tế hay tài chính, miễn là họ chứng minh được tài liệu, truy vết và kiểm soát đầy đủ. Waterfall chỉ là cách dễ nhất để đáp ứng những đòi hỏi đó, không phải cách duy nhất. Đừng rút ra công thức "nhà nước thì Waterfall, startup thì Scrum" — đó là định kiến, không phải quy tắc.

Ví dụ

Công ty trúng thầu dự án Hệ thống Quản lý Hồ sơ Nhân viên cho một cơ quan nhà nước. Đặc tả yêu cầu nằm sẵn trong hồ sơ mời thầu, rất chi tiết, và không được đổi trong quá trình thực hiện hợp đồng.

Đội sẽ dồn sức ở giai đoạn đầu: nghiên cứu kỹ hồ sơ, làm rõ những chỗ còn mơ hồ, rồi tài liệu hoá toàn bộ yêu cầu vào bản SRS theo đúng quy chuẩn. Tài liệu này phải được phê duyệt chính thức trước khi bước sang thiết kế và lập trình. Mọi thay đổi sau đó phải đi qua quy trình quản lý thay đổi chặt chẽ, mất thời gian và thường tốn tiền — giống như bơi ngược dòng thác.

3. Agile và Scrum

Agile tiếp cận vấn đề từ một giả định khác hẳn Waterfall: thay vì tin rằng có thể biết đúng mọi thứ ngay từ đầu, nó chấp nhận rằng hiểu biết sẽ thay đổi trong quá trình làm, và tổ chức công việc sao cho thay đổi đó ít tốn kém nhất.

Agile là một triết lý, không phải một quy trình

Agile không phải quy trình cố định mà là tập hợp giá trị và nguyên tắc, được ghi trong Tuyên ngôn Agile (Agile Manifesto) năm 2001, nhằm giúp đội dự án phản ứng nhanh với thay đổi và mang lại giá trị cho khách hàng liên tục.

Bốn giá trị cốt lõi:

• Cá nhân và sự tương tác hơn là quy trình và công cụ.
• Phần mềm chạy được hơn là tài liệu đầy đủ.
• Hợp tác với khách hàng hơn là đàm phán hợp đồng.
• Phản hồi với thay đổi hơn là bám sát kế hoạch ban đầu.

Đây là chỗ rất nhiều người hiểu sai. Tuyên ngôn Agile có một câu kết thường bị bỏ quên: "Nghĩa là, tuy những mục bên phải vẫn có giá trị, chúng tôi đánh giá cao hơn những mục bên trái." Agile không nói "không cần tài liệu", cũng không nói "không cần kế hoạch". Nó nói khi phải chọn, hãy ưu tiên vế trái. Một BA lấy Agile ra để biện minh cho việc không viết gì cả là đang hiểu ngược tinh thần của nó.

Scrum — framework Agile phổ biến nhất

Cần phân biệt ba tầng, vì rất nhiều người mới gộp chúng làm một:

• Agile là tư duy — bộ giá trị và nguyên tắc.
• Scrum, Kanban, XP… là các framework hiện thực hoá tư duy đó theo những cách khác nhau. Scrum chạy theo Sprint có độ dài cố định; Kanban thì không chia Sprint mà tập trung vào giới hạn số việc đang làm dở và làm cho dòng công việc chảy đều.
• User Story, Daily Scrum, retrospective… là các thực hành cụ thể.

Nói "công ty tôi làm Agile" là chưa đủ thông tin — phải hỏi thêm framework nào và thực hành nào.

Scrum là một framework (khung làm việc), không phải một quy trình chi tiết hay một phương pháp luận đầy đủ. Nó cố ý để trống nhiều chỗ cho đội tự quyết định cách làm. Scrum tập trung vào hợp tác nhóm, làm việc theo chu kỳ lặp và cải tiến liên tục.

Sprint là trái tim của Scrum: một chu kỳ có độ dài cố định, một tháng hoặc ngắn hơn (thực tế phổ biến nhất là 2 tuần). Mỗi Sprint tạo ra một phần sản phẩm dùng được.

Ba trách nhiệm trong một Scrum Team:

Lưu ý về thuật ngữ: Scrum Guide bản 2020 đã bỏ khái niệm "Development Team" tách rời. Giờ chỉ có một Scrum Team duy nhất gồm Product Owner, Scrum Master và Developers — thay đổi này nhằm xoá cảm giác "đội trong đội". Bạn vẫn sẽ nghe nhiều người dùng từ cũ, đừng ngạc nhiên.

Năm sự kiện:

• Sprint — khung chứa tất cả các sự kiện còn lại.
• Sprint Planning — đầu Sprint, cả đội thống nhất Sprint Goal và chọn việc sẽ làm.
• Daily Scrum — 15 phút mỗi ngày, Developers đồng bộ tiến độ và điều chỉnh kế hoạch trong ngày.
• Sprint Review — cuối Sprint, trình bày kết quả cho các bên liên quan và lấy phản hồi. Đây là buổi làm việc để điều chỉnh hướng đi, không phải buổi báo cáo thành tích.
• Sprint Retrospective — sau Review, cả đội nhìn lại cách làm việc của chính mình và chọn một vài điều cải thiện.

Mỗi sự kiện đều có timebox. Với Sprint dài một tháng: Sprint Planning tối đa 8 giờ, Sprint Review 4 giờ, Retrospective 3 giờ, Daily Scrum 15 phút. Sprint ngắn hơn thì các buổi này ngắn theo.

Ba artifact, mỗi cái gắn với một cam kết:

Definition of Done là thứ fresher hay bỏ qua nhưng lại gây tranh cãi nhiều nhất trong thực tế. Nó là bản thoả thuận của cả đội về việc một hạng mục phải đạt những gì mới được tính là xong: đã code xong? đã test? đã review? đã cập nhật tài liệu? Không có nó, mỗi người hiểu "xong" một kiểu, và đến cuối Sprint mới phát hiện ra.

Khi nào Agile/Scrum phù hợp?

• Yêu cầu ban đầu chưa rõ, hoặc thị trường và nhu cầu kinh doanh còn thay đổi nhiều — điển hình là phát triển sản phẩm mới.
• Cần đưa sản phẩm chạy được tới người dùng sớm để lấy phản hồi rồi điều chỉnh.
• Khách hàng hoặc người đại diện của họ sẵn sàng tham gia và phản hồi liên tục. Đây là điều kiện hay bị bỏ qua nhất: Scrum không chạy được nếu Product Owner vắng mặt.
• Văn hoá tổ chức khuyến khích hợp tác, giao tiếp trực tiếp và đội tự quản.

Ví dụ

Vẫn là Hệ thống Quản lý Hồ sơ Nhân viên, nhưng lần này là dự án nội bộ của một công ty đang lớn nhanh, cần dùng sớm và yêu cầu còn thay đổi.

Đội lập Product Backlog ban đầu với những thứ ưu tiên cao nhất: lưu tên, số điện thoại, email, phòng ban.

Sprint 1 (2 tuần) — làm xong thêm, sửa, xoá thông tin cơ bản. Cuối Sprint demo cho phòng HR. HR bắt đầu nhập liệu thật và phản hồi: "Tốt, nhưng cần thêm ảnh đại diện và thông tin liên lạc khẩn cấp."

Sprint 2 — hai yêu cầu đó được đưa vào backlog với ưu tiên cao và làm luôn. Demo xong, HR lại nói: "Cần tìm nhân viên theo mã số chứ không chỉ theo tên."

Cứ thế, hệ thống lớn dần qua từng Sprint. Điểm mấu chốt không phải là "làm nhanh hơn", mà là sai sớm và sửa rẻ: yêu cầu tìm kiếm theo mã số được phát hiện ở tuần thứ tư, không phải ở tháng thứ sáu khi mọi thứ đã đóng băng.

4. So sánh Waterfall và Agile/Scrum

Không có mô hình nào "tốt nhất". Chỉ có mô hình phù hợp với bối cảnh.

Điều đáng nhớ: chi phí của một quyết định sai không nằm ở chỗ bạn sai, mà ở chỗ bạn mất bao lâu mới biết mình sai. Waterfall đặt cược rằng bạn có thể biết đúng mọi thứ từ đầu. Agile đặt cược rằng bạn không thể, nên rút ngắn vòng phản hồi lại. Chọn mô hình chính là chọn xem cược nào đúng với dự án của bạn.

5. Còn những mô hình nào khác?

Giờ đã có Waterfall và Agile làm mốc, mấy cái tên còn lại dễ hình dung hơn nhiều:

• Lặp (Iterative) và tăng trưởng (Incremental): hai thứ hay bị gộp làm một. Lặp là làm rồi quay lại cải tiến chính phần đã làm; tăng trưởng là bàn giao sản phẩm theo từng phần, phần sau cộng thêm vào phần trước. Thực tế hai cách thường đi cùng nhau.
• Mô hình chữ V (V-Model): mở rộng của Waterfall, nhấn mạnh mối quan hệ giữa mỗi giai đoạn phát triển và giai đoạn kiểm thử tương ứng.
• Mô hình xoắn ốc (Spiral): kết hợp lặp và tuyến tính, tập trung mạnh vào quản lý rủi ro qua từng vòng xoắn.

Riêng DevOps hay bị xếp nhầm vào danh sách này. Nó không phải một mô hình vòng đời, mà là tập hợp thực hành và văn hoá nhằm gắn kết phát triển (Dev) với vận hành (Ops). Một đội chạy Scrum vẫn có thể áp dụng DevOps — hai thứ nằm ở hai tầng khác nhau, không thay thế nhau.

Trong thực tế đi làm, bạn sẽ thấy Waterfall và Agile/Scrum áp đảo về mức độ phổ biến. Những mô hình trên chủ yếu đáng biết để hiểu người khác đang nói gì, và để nhận ra rằng đội mình đang chạy một biến thể nào đó chứ không phải sách vở thuần tuý.

Từ 2025 trở đi còn xuất hiện một nhóm cách làm mới hẳn, sinh ra từ việc AI viết được code: vibe coding, spec-driven development, AI-DLC. Nhóm này có đủ thứ để nói nên khoá dành riêng hai bài kế tiếp cho nó.

6. Thực tế áp dụng ở Việt Nam

Agile và Scrum rất phổ biến trên giấy tờ, nhưng đội áp dụng đúng "by the book" thì hiếm — ở Việt Nam cũng như ở đâu.

Phần lớn chạy một phiên bản lai (hybrid): giữ nhịp Sprint và các buổi họp của Scrum, nhưng vẫn có tài liệu đặc tả dày, vẫn có mốc bàn giao cố định theo hợp đồng, vẫn có cấp trên duyệt phạm vi. Có nơi gọi là Scrum nhưng thực chất là Waterfall chia nhỏ thành từng đợt hai tuần.

Điều này không hẳn là sai — nhiều ràng buộc đến từ hợp đồng và quy định chứ không đến từ đội. Bản thân Scrum cũng cố ý được thiết kế chưa hoàn chỉnh: nó chỉ đưa ra bộ khung tối thiểu và để đội tự bổ sung kỹ thuật, công cụ phù hợp. Thêm vào thì được. Nhưng nếu bỏ đi các thành phần cốt lõi — bỏ Retrospective, bỏ Sprint Goal, PO không có quyền quyết ưu tiên — thì thứ còn lại không còn là Scrum nữa, dù vẫn gọi tên như vậy. Nhưng nó có nghĩa là bạn cần chuẩn bị tinh thần: thứ bạn học được ở đây là bản đồ, không phải địa hình. Vào công ty, việc đầu tiên nên làm là quan sát xem đội thực sự làm việc thế nào, chứ không phải sửa lưng người khác vì "làm vậy là không đúng Scrum".

Tóm lại

Hiểu SDLC là kiến thức nền của mọi Business Analyst. Waterfall mạnh ở tính tuần tự và hồ sơ chặt chẽ, hợp với dự án yêu cầu cố định và môi trường cần tuân thủ. Agile/Scrum mạnh ở khả năng thích ứng, hợp với dự án còn nhiều ẩn số và cần phản hồi liên tục.

Không mô hình nào tốt hơn mô hình nào — chỉ có phù hợp hay không với bối cảnh. Và vai trò của BA cũng thay đổi rõ rệt giữa hai bên: đó là nội dung của hai bài tiếp theo trong khoá.

Chúc bạn tự tin hơn khi bước vào dự án thật.