So sánh phương pháp phát triển thác nước (Waterfall) và Agile

1. Tổng quan

A. Định nghĩa

Mô hình thác nước (Waterfall) là phương pháp phát triển truyền thống hướng kế hoạch (Plan-driven) và lấy tài liệu làm trung tâm, trong đó các giai đoạn phân tích yêu cầu→thiết kế→hiện thực→kiểm thử→vận hành được tiến hành tuần tự, một chiều như thác nước đổ từ trên xuống, và mỗi giai đoạn phải hoàn thành, được phê duyệt thì mới chuyển sang giai đoạn tiếp theo.

Agile là phương pháp thích ứng với thay đổi (Change-adaptive) và dựa trên kinh nghiệm thực nghiệm (Empirical), bàn giao dần dần 'phần mềm chạy được (Working Software)' qua các vòng lặp ngắn (Iteration/Sprint) từ 2~4 tuần, nhận phản hồi của khách hàng ở mỗi vòng lặp để điều chỉnh hướng đi.

Sự đối lập giữa hai phương pháp bề ngoài trông như khác biệt về quy trình 'tuần tự so với lặp', nhưng gốc rễ của nó nằm ở sự khác biệt về triết lý 'nhìn nhận thay đổi (Change) như thế nào'. Thác nước coi thay đổi là nguồn gốc của chi phí và rủi ro. Vì vậy, mô hình này cố gắng xác định yêu cầu đầy đủ nhất có thể ở giai đoạn đầu, và kiểm soát, tối thiểu hóa các thay đổi phát sinh sau đó thông qua quản lý cấu hình (Configuration Management) và Ủy ban kiểm soát thay đổi (CCB) để bảo đảm khả năng dự đoán (Predictability). Theo góc nhìn này, dự án tốt là 'dự án diễn ra đúng kế hoạch'.

Ngược lại, Agile chấp nhận thay đổi là điều không thể tránh và thậm chí là giá trị tạo ra lợi thế cạnh tranh. Trên tiền đề rằng thị trường, công nghệ và yêu cầu khách hàng chắc chắn sẽ thay đổi trong thời gian dự án, ở mỗi vòng lặp Agile cho khách hàng xem sản phẩm thực sự chạy được và dùng phản hồi đó để điều chỉnh lại kế hoạch tiếp theo. Theo góc nhìn này, dự án tốt không phải là 'dự án tuân thủ tốt kế hoạch' mà là 'dự án bàn giao nhanh nhất những gì có giá trị nhất'. Cốt lõi khi so sánh hai phương pháp là hiểu rằng sự khác biệt về quan điểm gốc rễ này sinh ra mọi khác biệt về thực hành (Practice) sau đó như mức độ tài liệu hóa, thời điểm khách hàng tham gia, cách quản lý rủi ro và chiến lược bảo đảm chất lượng.

B. Bối cảnh ra đời và sự cần thiết

Mô hình thác nước bắt nguồn từ mô hình tuần tự được Winston Royce trình bày trong bài báo năm 1970. Điều thú vị là Royce đã cảnh báo về nguy cơ của mô hình tuyến tính này và nhấn mạnh vòng phản hồi, nhưng trong thực tế chỉ dạng một chiều — dễ quản lý và ký hợp đồng — được áp dụng rộng rãi. Với các hệ thống lớn, ổn định của thập niên 1970~80 (quốc phòng, hàng không, điều khiển sản xuất), yêu cầu tương đối rõ ràng và ít thay đổi, nên mô hình thác nước quản lý tiến độ bằng sản phẩm đầu ra theo từng giai đoạn và các cổng phê duyệt rất phù hợp. Khi các tiêu chuẩn như tiêu chuẩn của Bộ Quốc phòng Hoa Kỳ (DoD-STD-2167A) thể chế hóa cách làm này, thác nước trở thành tiêu chuẩn công nghiệp trên thực tế.

Tuy nhiên, cuối thập niên 1990, sự lan rộng của web và Internet đã thay đổi tình hình. Yêu cầu thay đổi thường xuyên ngay trong quá trình phát triển, tốc độ ra thị trường (Time-to-Market) trở nên quan trọng không kém chất lượng, và nhận thức rằng 'không thể có kế hoạch trước hoàn hảo' lan rộng. Trong bối cảnh đó, năm 2001, 17 chuyên gia phần mềm đã cùng công bố Tuyên ngôn Agile (Agile Manifesto). Bốn giá trị của nó là: ① cá nhân và sự tương tác hơn quy trình và công cụ, ② phần mềm chạy được hơn tài liệu đầy đủ, ③ cộng tác với khách hàng hơn đàm phán hợp đồng, ④ phản hồi với thay đổi hơn làm theo kế hoạch. Tuyên ngôn này không phải là một kỹ thuật cụ thể mà là hệ giá trị chung bao trùm nhiều phương pháp nhẹ (Lightweight) như XP, Scrum, Kanban, FDD, và ngày nay đã trở thành mô hình (paradigm) chủ đạo của phát triển phần mềm.

2. So sánh cấu trúc quy trình

Khác biệt dễ nhận thấy nhất giữa thác nước và Agile là 'khi nào có thể nhìn thấy sản phẩm hoàn chỉnh'. Sơ đồ dưới đây là sơ đồ cấu trúc đối chiếu luồng tổng thể của hai phương pháp.

flowchart LR
  subgraph W["Thác nước (tuần tự·một chiều)"]
    direction LR
    W1["Phân tích yêu cầu"] --> W2["Thiết kế"] --> W3["Hiện thực"] --> W4["Kiểm thử"] --> W5["Vận hành"]
  end
  subgraph A["Agile (lặp·tăng dần)"]
    direction LR
    A1["Lập kế hoạch (Sprint Planning)"] --> A2["Phát triển (Develop)"] --> A3["Phát hành (Increment)"] --> A4["Nhìn lại·phản hồi"] --> A1
  end
  style A fill:#e8f0fe,stroke:#2f6fed

Trong thác nước, mỗi giai đoạn phải hoàn thành mới chuyển sang giai đoạn sau, nên sản phẩm hoàn chỉnh có thể chạy chỉ xuất hiện ở nửa sau dự án (sau giai đoạn kiểm thử). Điểm yếu chí mạng của cấu trúc này là lỗi hoặc hiểu sai yêu cầu càng được phát hiện muộn thì chi phí sửa càng tăng theo cấp số nhân. Theo nghiên cứu về đường cong tăng chi phí của Barry Boehm, một lỗi nếu phát hiện ở giai đoạn yêu cầu có chi phí sửa là 1, thì ở giai đoạn thiết kế cần gấp nhiều lần, và ở giai đoạn vận hành cần chi phí gấp hàng chục đến hàng trăm lần. Tình huống khách hàng nói "không phải cái này" sau khi đã phát triển 6 tháng với yêu cầu bị hiểu sai là kịch bản thất bại điển hình của thác nước.

Ngược lại, Agile tạo ra 'phần tăng sản phẩm có tiềm năng phát hành (Potentially Shippable Increment)' sau mỗi sprint. Nhờ đó, vấn đề và sự hiểu sai yêu cầu được phát hiện sớm và thường xuyên, làm giảm chi phí sửa. Tuy nhiên, điều này không miễn phí. Vì lặp lại lập kế hoạch, phát triển, tích hợp và kiểm thử ở mỗi vòng, phát sinh chi phí phụ trội cho họp hành và phối hợp, đồng thời cần tái cấu trúc mã (refactoring) liên tục và quản lý nợ kỹ thuật để các phần tăng tích lũy duy trì được kiến trúc nhất quán.

Để đối chiếu cụ thể, giả sử xây dựng cổng thông tin khách hàng trong 12 tháng với quy mô 10 người. Nếu theo thác nước, 4 tháng đầu dành cho yêu cầu và thiết kế, tháng 5~~10 hiện thực, tháng 11~~12 kiểm thử tích hợp, nên đến tháng thứ 11 khách hàng mới lần đầu thấy màn hình thực tế. Khi đó nếu có phản hồi "không ngờ chức năng tìm kiếm lại hoạt động như thế này", thì phải quay lại thiết kế, và 1 tháng còn lại không đủ để xử lý, dẫn đến vượt tiến độ và ngân sách. Nếu cùng dự án đó được chia thành 24 sprint 2 tuần theo Agile, thì ngay trong tháng đầu đã có thể trình diễn phiên bản ban đầu của đăng nhập và tìm kiếm, nhận phản hồi và chỉnh hướng ngay ở sprint thứ hai. Cùng một sự hiểu sai, nhưng tùy thời điểm phát hiện là tháng thứ 11 hay tháng thứ 1 mà chi phí sửa chênh nhau hàng chục lần — điều này thể hiện cô đọng sự khác biệt bản chất giữa hai cấu trúc.

A. Luồng bên trong một vòng lặp Agile (Sprint)

Để hiểu Agile thực sự vận hành ra sao, cần nhìn vào bên trong một vòng lặp. Dưới đây là luồng sự kiện và sản phẩm đầu ra bên trong một sprint theo Scrum.

flowchart TD
  PB["Product Backlog (tồn đọng sản phẩm)"] --> SP["Lập kế hoạch sprint (Sprint Planning)"]
  SP --> SB["Sprint Backlog (tồn đọng sprint)"]
  SB --> DS["Họp Scrum hằng ngày (Daily Scrum)"]
  DS --> DEV["Phát triển·kiểm thử (hiện thực Increment)"]
  DEV --> DS
  DEV --> INC["Phần tăng sản phẩm (Increment)"]
  INC --> REV["Sprint Review (demo cho khách hàng·phản hồi)"]
  REV --> RETRO["Nhìn lại (Retrospective)"]
  RETRO --> PB

Trong luồng này, mỗi yếu tố có vai trò riêng. Product Backlog là danh sách yêu cầu đã được xếp thứ tự ưu tiên, khác với 'bản đặc tả yêu cầu' của thác nước ở chỗ không cố định mà liên tục được tinh chỉnh (Grooming). Trong lập kế hoạch sprint, nhóm tự chọn (Pull) các hạng mục đưa vào vòng lặp này, và chính sự lựa chọn tự chủ đó tạo nên cam kết (Commitment) của nhóm. Daily Scrum là cuộc họp đồng bộ ngắn khoảng 15 phút, chia sẻ tiến độ và trở ngại (Impediment) hằng ngày để phơi bày vấn đề sớm theo đơn vị ngày. Trong Sprint Review, phần tăng thực sự chạy được được trình diễn cho khách hàng để nhận phản hồi, còn trong buổi nhìn lại, thứ được cải tiến không phải sản phẩm mà là 'cách làm việc của nhóm'. Như vậy, Agile hiện thực hóa cơ chế kiểm soát quy trình thực nghiệm 'kiểm tra và thích ứng (Inspect & Adapt)' bằng các vòng phản hồi dày đặc.

3. So sánh đặc điểm, ưu và nhược điểm

A. Điểm mạnh và điểm yếu của thác nước

Điểm mạnh cốt lõi của thác nước là dễ quản lý, dễ giám định và có khả năng dự đoán. Vì sản phẩm đầu ra rõ ràng (bản đặc tả yêu cầu, bản thiết kế, kế hoạch kiểm thử) và tiêu chí hoàn thành được định nghĩa cho từng giai đoạn, tiến độ có thể đo khách quan và dễ ứng phó với giám định, kiểm toán bên ngoài. Trong những tình huống phải xác định trước 'làm gì, đến khi nào, giá bao nhiêu' như hợp đồng giá cố định (Fixed-price) hay mua sắm công, khả năng dự đoán này trở thành lợi thế quyết định. Với các hệ thống quy mô lớn có yêu cầu ổn định, cách này vẫn hợp lý.

Điểm yếu là mặt trái của điểm mạnh đó. Tiền đề xác định yêu cầu từ đầu thường xuyên bị phá vỡ trong thực tế, và khi có thay đổi phải quay ngược lên giai đoạn trước nên chi phí lớn. Trên hết, việc khách hàng chỉ lần đầu nhìn thấy sản phẩm ở nửa sau dự án làm tăng nguy cơ đi sai hướng. 'Hệ thống hoàn hảo trên giấy nhưng khi làm ra lại vô dụng' là dạng thất bại tiêu biểu của thác nước.

B. Điểm mạnh và điểm yếu của Agile

Điểm mạnh của Agile là khả năng ứng phó với thay đổi, bàn giao giá trị nhanh và phát hiện rủi ro sớm. Vì bàn giao từ chức năng có ưu tiên cao trước, khách hàng cảm nhận được giá trị ngay từ đầu dự án, và nếu đi sai hướng thì có thể điều chỉnh trước khi tổn thất lớn. Ngay cả khi thất bại, cũng 'thất bại nhanh, rẻ (Fail Fast)' và chuyển hóa thành bài học.

Điểm yếu đến từ việc sản phẩm đầu ra và phạm vi mang tính linh động. Khó xác định trước toàn bộ phạm vi và thời điểm kết thúc nên khó áp dụng cho hợp đồng giá cố định và mua sắm quy mô lớn, và nếu nguyên tắc tối thiểu hóa tài liệu bị lạm dụng thì khả năng truy vết và khả năng bảo trì bị tổn hại. Ngoài ra, kết quả phụ thuộc lớn vào mức độ thành thạo, tính tự chủ và văn hóa cộng tác của nhóm, nên nếu cấy nguyên vào tổ chức kiểu chỉ huy-kiểm soát thì dễ biến thành 'Agile chỉ có tên (Fake Agile)'.

Khác biệt về cách bảo đảm chất lượng cũng đáng lưu ý. Nếu thác nước gần với 'kiểm soát chất lượng sau (Quality Control)' — tách kiểm thử thành giai đoạn riêng và kiểm chứng sau khi hoàn thành — thì Agile hướng tới 'chất lượng nội tại (Built-in Quality)' hòa trộn phát triển với hoạt động chất lượng như phát triển hướng kiểm thử (TDD), tích hợp liên tục (CI) và lập trình cặp. Ví dụ, trong môi trường CI chạy kiểm thử tự động ở mỗi commit, lỗi được phát hiện ngay trong ngày nó được đưa vào nên chi phí sửa được giảm tối thiểu. Đây là nền tảng kỹ thuật giúp Agile duy trì 'lặp nhanh', đồng thời cũng là lý do chất lượng sụp đổ nhanh chóng khi bắt chước Agile mà không có kiểm thử tự động.

Phân loại	Thác nước	Agile
Cách tiến hành	Tuần tự·hoàn tất từng giai đoạn	Lặp·tăng dần
Thay đổi yêu cầu	Khó (xác định sớm·kiểm soát)	Tiếp nhận linh hoạt
Tài liệu hóa	Chi tiết·coi trọng	Tối thiểu (ưu tiên phần mềm chạy được)
Sự tham gia của khách hàng	Tập trung ở đầu·cuối	Tham gia liên tục suốt quá trình
Kiểm tra kết quả	Một lần ở giai đoạn cuối	Kiểm tra ở mỗi vòng lặp
Hình thức hợp đồng	Phù hợp giá cố định (Fixed-price)	Phù hợp thời gian·vật tư (T&M)·hợp đồng tăng dần
Phơi nhiễm rủi ro	Tập trung ở cuối	Sớm·phân tán
Yếu tố thành công	Độ hoàn thiện kế hoạch·tài liệu	Năng lực nhóm·văn hóa cộng tác
Ưu điểm	Dễ quản lý·giám định, có khả năng dự đoán	Ứng phó thay đổi, giá trị nhanh·phát hiện rủi ro sớm
Nhược điểm	Yếu trước thay đổi, lỗi muộn chi phí cao	Khó quản lý phạm vi, phụ thuộc mức thành thạo

C. Quan hệ với mô hình chữ V và mô hình xoắn ốc

Thác nước không phải là một mô hình cô lập mà là nguyên mẫu của nhiều mô hình phái sinh. Mô hình chữ V là biến thể bố trí đối xứng trái-phải các giai đoạn kiểm thử (kiểm thử chấp nhận, kiểm thử tích hợp, kiểm thử đơn vị) tương ứng với từng giai đoạn phát triển của thác nước (yêu cầu, thiết kế cơ bản, thiết kế chi tiết), buộc phải lập kế hoạch kiểm chứng ngay từ đầu quá trình phát triển. Đây là nỗ lực khắc phục điểm yếu 'kiểm thử dồn về cuối' của thác nước, và được dùng rộng rãi trong các lĩnh vực coi trọng khả năng truy vết kiểm chứng như nhúng, y tế và quốc phòng. Mô hình xoắn ốc (Spiral) đặt phân tích rủi ro vào trung tâm của mỗi chu kỳ và lặp lại việc làm nguyên mẫu, có thể xem là tiền thân lý thuyết của Agile khi kết hợp tính kế hoạch của thác nước với quản lý rủi ro bằng vòng lặp.

Hiểu dòng phả hệ này sẽ thấy 'thác nước so với Agile' không phải là đối lập trắng-đen mà là một phổ liên tục. Dòng chảy thác nước thuần túy → chữ V → xoắn ốc → lặp tăng dần (RUP) → Agile là lịch sử trọng tâm dần chuyển từ 'tính hoàn chỉnh của kế hoạch' sang 'giải quyết rủi ro sớm và thích ứng'. Do đó, lựa chọn trong thực tế là vấn đề chọn điểm nào trên phổ này, chứ không phải chọn loại trừ một trong hai.

Chỉ riêng bảng thì không thể biết 'vì sao' có những khác biệt này. Ví dụ, khác biệt ở hạng mục 'tài liệu hóa' không đơn thuần là sở thích, mà vì thác nước đứng trên tiền đề 'chuyển giao tri thức giữa các giai đoạn bằng tài liệu', còn Agile đứng trên tiền đề 'chuyển giao tri thức bằng đối thoại trực tiếp trong cùng một nhóm'. Khác biệt về mức độ tài liệu hóa chính là hệ quả tất yếu bắt nguồn từ khác biệt về cơ chế chuyển giao tri thức.

4. Tiêu chí lựa chọn và chiến lược lai

A. Tiêu chí lựa chọn theo tình huống

Phương pháp không có hơn kém mà chỉ có mức độ phù hợp (Fit) với đặc tính dự án. Các biến số cốt lõi của lựa chọn là ① độ bất định của yêu cầu, ② mức độ quy định và an toàn, ③ tốc độ đáp ứng thị trường, ④ hình thức hợp đồng, ⑤ mức độ trưởng thành của nhóm. Các hệ thống nhúng, công và an toàn trọng yếu có yêu cầu rõ ràng và coi trọng quy định, chứng nhận (ví dụ: thiết bị y tế IEC 62304, hàng không DO-178C, lõi ngân hàng) phù hợp với thác nước (hoặc mô hình chữ V tăng cường kiểm chứng). Ngược lại, các dịch vụ web, di động và startup có yêu cầu bất định và coi trọng thử nghiệm, phát hành nhanh thì Agile có lợi hơn.

Nếu chọn ra biến số đơn lẻ mang tính quyết định nhất thì đó là độ bất định của yêu cầu. Khi yêu cầu ổn định, độ chính xác của kế hoạch trước cao nên khả năng dự đoán của thác nước trở thành lợi thế nguyên vẹn; nhưng khi yêu cầu bất định, kế hoạch dù tinh vi đến đâu cũng sớm mất hiệu lực và công sức lập kế hoạch trở thành chi phí chìm. Vì thế, chẩn đoán tỉnh táo 'yêu cầu đã xác định đến mức nào' trước khi khởi động là điểm xuất phát của việc chọn phương pháp, và việc chọn thác nước vì sự tiện lợi trong quản lý dù độ bất định cao là phán đoán sai thường gặp nhất tại hiện trường.

B. Lai ghép và Agile quy mô lớn

Các dự án quy mô lớn trong thực tế chọn cách dung hòa giữa hai cực. Tiêu biểu là Water-Scrum-Fall, trong đó quản trị, ngân sách và cột mốc cấp trên được lập kế hoạch như thác nước, còn phát triển thực tế lặp theo Agile. Khi mở rộng Agile ra toàn tổ chức, các khung quy mô lớn như SAFe (Scaled Agile Framework), LeSS (Large-Scale Scrum) và mô hình Spotify (Squad·Tribe·Chapter·Guild) được sử dụng. Ví dụ, SAFe gom nhiều nhóm thành một 'Agile Release Train (ART)' và đồng bộ kế hoạch của nhiều nhóm bằng 'PI (Program Increment) Planning' theo chu kỳ 8~12 tuần, đồng thời theo đuổi tính linh hoạt của Agile và sự thống nhất (Alignment) của tổ chức lớn. Tuy nhiên, bản thân việc áp dụng khung không bảo đảm Agile, và cần cảnh giác với nghịch lý thủ tục trở nên nặng nề hơn.

C. Các phản mẫu (anti-pattern) khi áp dụng sai

Thất bại phổ biến hơn cả việc chọn sai phương pháp là trường hợp 'chọn đúng nhưng áp dụng sai'. Phản mẫu tiêu biểu phía thác nước là tài liệu vì tài liệu: tốn thời gian lẽ ra dành cho thiết kế và kiểm chứng để điền cho có những sản phẩm đầu ra không ai đọc. Nỗi ám ảnh xác định yêu cầu 'hoàn toàn' từ đầu dẫn đến tê liệt phân tích (Analysis Paralysis) làm chậm khởi động cũng là vấn đề cùng gốc rễ.

Phản mẫu tiêu biểu phía Agile là 'Agile chỉ có tên (Fake Agile)'. Đó là khi Daily Scrum biến chất thành buổi báo cáo tiến độ và khiển trách, phạm vi sprint bị cấp trên áp đặt thay vì nhóm tự chủ, hoặc các đề xuất cải tiến từ buổi nhìn lại không được thực hiện và cứ lặp lại. Một phản mẫu khác là lạm dụng việc tối thiểu hóa tài liệu, đến mức không để lại cả bản ghi quyết định kiến trúc (ADR) tối thiểu cần cho bảo trì và bàn giao, khiến nợ kỹ thuật tích tụ. Những phản mẫu này không phải khiếm khuyết của bản thân phương pháp mà là vấn đề văn hóa và lãnh đạo, nhắc nhở rằng khi chuyển đổi phương pháp phải thay đổi đồng thời cách làm việc của tổ chức cùng hệ thống đánh giá và khen thưởng.

5. Chuyên sâu: Xu hướng mới nhất và tình huống áp dụng thực tế

Cuộc tranh luận về phương pháp bước sang giai đoạn mới từ thập niên 2010 với sự kết hợp cùng DevOps và CI/CD. Nếu Agile xử lý câu hỏi 'làm gì, vì sao, theo thứ tự nào', thì DevOps xử lý câu hỏi 'triển khai những gì đã làm một cách ổn định và thường xuyên như thế nào'. Chỉ khi hai thứ kết hợp, 'bàn giao giá trị nhanh' của Agile mới đi tới môi trường vận hành thực tế chứ không dừng ở giai đoạn demo. Nghiên cứu DORA (DevOps Research and Assessment) của Google đo hiệu quả bàn giao phần mềm bằng bốn chỉ số: tần suất triển khai, thời gian dẫn thay đổi, tỷ lệ thất bại thay đổi và thời gian phục hồi trung bình (MTTR), và chỉ ra rằng các tổ chức hiệu quả cao triển khai nhiều lần mỗi ngày mà vẫn duy trì tỷ lệ thất bại thấp. Điều này dùng dữ liệu để củng cố nhận thức cốt lõi của Agile·DevOps: trái với quan niệm 'triển khai thường xuyên thì bất ổn', triển khai càng nhỏ và thường xuyên thì càng ổn định.

Xem các tình huống thực tế sẽ thấy rõ logic lựa chọn phương pháp. Các doanh nghiệp như Netflix và Amazon thực hành Agile·DevOps cực đoan, triển khai hàng nghìn lần mỗi ngày trên nền microservice và pipeline CI/CD, vì yêu cầu dịch vụ thay đổi nhanh và chi phí thất bại mang tính cục bộ. Ngược lại, phần mềm điều khiển bay của máy bay (đối tượng chứng nhận DO-178C) hay hệ thống điều khiển hạt nhân — nơi một thay đổi liên quan trực tiếp đến tính mạng con người — vẫn duy trì cách tiếp cận hướng kế hoạch đòi hỏi kiểm chứng trước rộng rãi và khả năng truy vết. Gần đây, ngay cả trong các ngành chịu quản lý, 'Agile có kỷ luật (Disciplined Agile, DA)' — nghiêm ngặt về tài liệu và kiểm chứng nhưng phát triển theo vòng lặp — đang lan rộng, cho thấy hai phương pháp không đối lập mà đang hội tụ theo hướng được kết hợp phù hợp với tình huống trên một phổ liên tục.

Cũng có những tình huống cho thấy bài học của quá trình chuyển đổi. Trong giai đoạn đầu Agile lan rộng, đã có báo cáo về các hệ thống công quy mô lớn, nhiều tổ chức, thời hạn nghiêm ngặt như cổng thông tin bảo hiểm y tế tuyên bố theo Agile mà không chuẩn bị, rồi thất bại khi vận hành ban đầu vì thiếu tích hợp và quản trị. Những kinh nghiệm này gạt bỏ kỳ vọng ngây thơ rằng 'Agile là vạn năng', và nhắc nhở rằng ở quy mô lớn nhất thiết phải song hành các kỷ luật như tích hợp giữa các nhóm, thống nhất kiến trúc và điều phối phát hành. Ngược lại, thất bại do khăng khăng dùng thác nước cho dịch vụ tiêu dùng có yêu cầu thay đổi nhanh, để rồi đến lúc ra mắt thì thị trường đã thay đổi, cũng rất phổ biến. Cả hai thất bại đều có điểm chung là bắt nguồn từ 'lựa chọn không phù hợp với đặc tính' chứ không phải từ 'bản thân phương pháp'.

Ngoài ra, gần đây khi trợ lý lập trình AI và AI tạo sinh lan rộng khiến chu kỳ lặp phát triển càng ngắn lại, tỷ trọng của 'khám phá kiểu Agile' — nhanh chóng tạo nguyên mẫu để kiểm chứng ngay cả ở giai đoạn yêu cầu và thiết kế — đang tăng lên. Điều này gợi ý rằng trọng tâm của phương pháp đang dịch chuyển mạnh hơn từ 'độ hoàn thiện của kế hoạch' sang 'tốc độ học hỏi và thích ứng' (tuy nhiên, do chênh lệch lớn giữa các ngành và tổ chức, cần thận trọng khi khái quát hóa).

6. Những điểm cần cân nhắc và hàm ý (góc nhìn Kỹ sư chuyên nghiệp)

Năng lực nhóm và văn hóa tổ chức quyết định thành công hơn là phương pháp. Agile sẽ thất bại thành 'Agile chỉ có tên' nếu không có tiền đề là văn hóa nhóm tự chủ, hợp tác và sự an toàn tâm lý coi thất bại là bài học. Trước khi áp dụng công cụ và quy trình, cần chẩn đoán mức độ trưởng thành của tổ chức và thực hiện quản lý thay đổi (Change Management) để chuyển đổi dần dần.
Phải thiết kế sự cân bằng trong tài liệu hóa. Tối thiểu hóa tài liệu của Agile nghĩa là 'loại bỏ tài liệu không cần thiết' chứ không phải 'loại bỏ tài liệu'. Xác định mức tài liệu 'vừa đủ (Barely Sufficient)' cần cho khả năng truy vết, bảo trì và ứng phó kiểm toán phù hợp với đặc tính dự án là vùng phán đoán của Kỹ sư chuyên nghiệp.
Phải bảo đảm tính nhất quán với hợp đồng và quản trị. Nếu áp dụng nguyên Agile cho hợp đồng giá cố định, phạm vi cố định, sẽ phát sinh xung đột trong kiểm soát phạm vi và thanh quyết toán. Chỉ khi thiết kế đồng thời mô hình hợp đồng phù hợp với bàn giao tăng dần (thanh toán theo giai đoạn, T&M dựa trên backlog, hợp đồng dựa trên kết quả) cùng hệ thống ngân sách và giám định thì phương pháp mới vận hành được.
Kết hợp với DevOps, CI/CD và kiểm thử tự động là bắt buộc. Vòng lặp nhanh của Agile không thể duy trì bằng triển khai và kiểm thử thủ công. Phải xây dựng đồng thời pipeline tích hợp và triển khai liên tục, kiểm thử tự động, hạ tầng dưới dạng mã (IaC) và khả năng quan sát (Observability) thì 'bàn giao giá trị nhanh' mới đi tới vận hành thực tế.
Lai ghép không phải là 'dung hòa' mà là đối tượng cần 'thiết kế'. Không chỉ đơn thuần chia cấp trên theo thác nước và cấp dưới theo Agile, mà phải thiết kế có chủ đích việc cố định kế hoạch ở tầng nào và cho phép thích ứng ở tầng nào, dựa trên rủi ro, quy định và tốc độ thị trường. Pha trộn vô nguyên tắc sẽ dẫn tới kết quả chỉ kết hợp nhược điểm của cả hai phương pháp.

Tài liệu tham khảo

Agile Manifesto, https://agilemanifesto.org/
Scrum Guide (2020), https://scrumguide.org/
Scaled Agile Framework (SAFe), https://scaledagileframework.com/
Google Cloud DORA / Nghiên cứu DevOps, https://dora.dev/

Tóm tắt một câu: Thác nước kiểm soát thay đổi để theo đuổi khả năng dự đoán, còn Agile tiếp nhận thay đổi để theo đuổi tính linh hoạt và bàn giao giá trị nhanh — hai phương pháp có triết lý trái ngược, được lựa chọn tùy theo độ ổn định yêu cầu, quy định, tốc độ thị trường và hình thức hợp đồng hoặc được dung hòa qua Water-Scrum-Fall, SAFe, và thành công cuối cùng phụ thuộc vào sự kết hợp với DevOps·CI/CD cùng năng lực nhóm và văn hóa tổ chức.