Khi bắt đầu chuẩn bị một dự án nghiêm túc, một trong những quyết định quan trọng đầu tiên là lựa chọn phương pháp quản lý mà bạn sẽ áp dụng. Đây không phải là chi tiết nhỏ: việc lập kế hoạch, cách bạn làm việc với khách hàng, tài liệu, thời hạn và thậm chí cả những loại sai lầm bạn sẽ gặp phải trong suốt quá trình đều phụ thuộc vào sự lựa chọn này.
Trong số các phương pháp này, Waterfall vẫn là một trong những phương pháp được biết đến rộng rãi nhất. Mặc dù Agile, Scrum và Kanban được thảo luận nhiều, Waterfall vẫn rất phổ biến trong các lĩnh vực mà sự ổn định, khả năng dự đoán và tài liệu đầy đủ quan trọng hơn sự linh hoạt tuyệt đối. Trong hướng dẫn toàn diện này, tôi sẽ giải thích từng bước Waterfall là gì, nguồn gốc của nó, cấu trúc của nó, khi nào nên sử dụng nó, sự khác biệt giữa nó và Agile, và cách nó phù hợp với quản lý dự án hiện đại.
Phương pháp Waterfall là gì?
Phương pháp Waterfall là một mô hình phát triển tuyến tính và tuần tự, trong đó dự án tiến triển từng giai đoạn một, không có sự gián đoạn có hệ thống. Cái tên "thác nước" xuất phát chính xác từ hình ảnh này: mỗi giai đoạn đổ kết quả của nó vào giai đoạn tiếp theo, giống như nước chảy từ bậc thang này sang bậc thang khác, và một khi bạn đã xuống một bậc, rất khó để quay trở lại.
Trên thực tế, điều này có nghĩa là vòng đời dự án chỉ được hoàn thành một lần duy nhất, từ đầu đến cuối : đầu tiên, tất cả các yêu cầu được thu thập; sau đó, giải pháp được thiết kế; tiếp theo, nó được triển khai, kiểm chứng và cuối cùng, đưa vào sử dụng và bảo trì. Mỗi giai đoạn phải được hoàn thành đầy đủ và được phê duyệt trước khi bắt đầu giai đoạn tiếp theo, với các sản phẩm bàn giao chính thức và các tiêu chí kết thúc được xác định rõ ràng.
Cách tiếp cận này dựa trên một tiền đề rất rõ ràng: các yêu cầu của dự án có thể được biết và ghi lại trước với độ chính xác đủ để thiết lập một nền tảng tương đối không thể thay đổi. Nền tảng này hướng dẫn tất cả các hoạt động thiết kế, phát triển và kiểm chứng, và bất kỳ sửa đổi nào sau đó đều được coi là những thay đổi ngoại lệ, tốn kém và phải chịu sự kiểm soát chính thức.
Nguồn gốc và sự phát triển của mô hình Thác nước
Ý tưởng tổ chức công việc thành các giai đoạn tuần tự không bắt nguồn từ ngành phần mềm. Nó xuất phát từ các lĩnh vực kỹ thuật truyền thống như xây dựng, kỹ thuật dân dụng và công nghiệp nặng, nơi việc lặp đi lặp lại trên một sản phẩm đã hoàn thiện có thể không thực tế hoặc cực kỳ nguy hiểm. Nếu bạn đang xây dựng một cây cầu hoặc một con đập, bạn cần phải hoàn toàn rõ ràng về những gì bạn sẽ làm trước khi đặt viên gạch đầu tiên.
Trong lĩnh vực phát triển phần mềm, một trong những ví dụ sớm nhất có từ tháng 6 năm 1956, khi Herbert D. Benington trình bày mô hình theo từng giai đoạn cho các hệ thống lớn. Tuy nhiên, mô tả được coi là kinh điển về mô hình thác nước được cho là của Winston W. Royce trong một bài báo năm 1970 về quản lý các dự án phát triển phần mềm lớn. Nhiều năm sau, vào năm 1976, Bell và Thayer đã phổ biến thuật ngữ "thác nước" và trích dẫn Royce như một nguồn tham khảo.
Điều kỳ lạ là chính Royce đã cảnh báo rằng một mô hình tuần tự nghiêm ngặt, không có phản hồi, là rủi ro. Ông đề xuất bao gồm các bước lặp lại giữa các giai đoạn liền kề và các nguyên mẫu để giảm thiểu rủi ro đó. Theo thời gian, điều được chấp nhận trong ngành là một phiên bản đơn giản hóa, gần như cứng nhắc, trong đó mỗi giai đoạn được hoàn thành đầy đủ trước khi chuyển sang giai đoạn tiếp theo, và do đó, hình ảnh rập khuôn mà chúng ta liên tưởng đến mô hình thác nước ngày nay đã được củng cố.
Nhờ logic rõ ràng và dễ lập kế hoạch , mô hình Waterfall nhanh chóng được áp dụng không chỉ trong lĩnh vực phần mềm mà còn trong các lĩnh vực như xây dựng, kỹ thuật, hoặc bất kỳ môi trường được quản lý chặt chẽ nào mà phạm vi được xác định rõ ràng và không có nhiều chỗ cho sự tùy hứng.
Cách thức hoạt động của phương pháp Waterfall
Trong một dự án được quản lý theo phương pháp thác nước, các giai đoạn diễn ra theo trình tự tuyến tính rất nghiêm ngặt. Một giai đoạn không bắt đầu cho đến khi giai đoạn trước đó hoàn thành , và về lý thuyết, không thể quay lại trừ khi phát sinh vấn đề nghiêm trọng hoặc có sự thay đổi về hợp đồng.
Trong phiên bản kinh điển nhất, chu trình Waterfall bao gồm năm, sáu, hoặc thậm chí bảy giai đoạn. Sự khác biệt thường nằm ở việc triển khai và bảo trì được tách biệt hay gộp chung, nhưng logic cơ bản là giống nhau: tiến triển mà không có các giai đoạn chồng chéo và với các sản phẩm bàn giao chính thức ở mỗi bước.
Các giai đoạn của phương pháp thác nước
Để hiểu đầy đủ về mô hình Waterfall, cần xem xét kỹ lưỡng từng giai đoạn của nó. Chúng không phải là các phần riêng biệt, mà hoạt động như những mắt xích trong một chuỗi , nơi đầu ra của giai đoạn này sẽ cung cấp đầu vào cho giai đoạn tiếp theo.
1. Yêu cầu
Giai đoạn xác định yêu cầu là cốt lõi của bất kỳ dự án theo mô hình thác nước nào. Mục tiêu ở đây là nắm bắt tất cả các nhu cầu và ràng buộc của khách hàng và doanh nghiệp, cả về chức năng (những gì hệ thống phải làm) và phi chức năng (hiệu suất, bảo mật, quy định, v.v.).
Giai đoạn này bao gồm các cuộc phỏng vấn, hội thảo và phân tích với người dùng và các chuyên gia trong lĩnh vực để đảm bảo không bỏ sót bất cứ điều gì. Kết quả là một tài liệu đặc tả yêu cầu chi tiết cao, được xem xét và ký bởi tất cả các bên . Tài liệu này trở thành cơ sở hợp đồng và kỹ thuật sẽ chi phối phần còn lại của dự án.
Trong phương pháp Waterfall cổ điển, khách hàng chủ yếu tham gia vào giai đoạn ban đầu này . Sau đó, sự tham gia của họ giảm đi đáng kể cho đến giai đoạn xác nhận hoặc nghiệm thu. Chính vì vậy, việc thu thập yêu cầu phải thật kỹ lưỡng và rõ ràng: bất kỳ thiếu sót hoặc sự mơ hồ nào cũng sẽ bị phóng đại trong các giai đoạn tiếp theo và sẽ rất tốn kém để khắc phục.
2 Phân tích
Sau khi xác định các yêu cầu, nhóm sẽ bước vào giai đoạn phân tích, trong đó tính khả thi về mặt kỹ thuật và chức năng của mọi thứ được yêu cầu sẽ được nghiên cứu. Một mô hình khái niệm của hệ thống được xây dựng, các mối phụ thuộc được xác định, các quy tắc nghiệp vụ phức tạp được làm rõ và nền tảng được đặt ra cho thiết kế tiếp theo.
Giai đoạn này cho phép chuyển đổi ngôn ngữ kinh doanh sang ngôn ngữ kỹ thuật hơn mà chưa đạt đến mức độ chi tiết kiến trúc. Trong nhiều dự án, phân tích và yêu cầu thường chồng chéo nhau về thời gian, nhưng trong mô hình thác nước, chúng thường được thể hiện như một giai đoạn riêng biệt với các sản phẩm đầu ra riêng.
3. Thiết kế hoặc ý tưởng
Giai đoạn thiết kế chuyển đổi "cái gì" thành "làm thế nào". Bắt đầu từ các yêu cầu đã được xác định, nhóm kiến trúc và thiết kế sẽ định nghĩa cấu trúc giải pháp hoàn chỉnh . Trong phần mềm, điều này thường được chia thành thiết kế cấp cao (kiến trúc, mô-đun, giao diện, công nghệ) và thiết kế chi tiết (thuật toán, cơ sở dữ liệu, lược đồ giao diện, v.v.).
Trong các lĩnh vực khác, giai đoạn này tương đương với bản vẽ xây dựng, tính toán kết cấu, sơ đồ điện hoặc bảng kê vật tư. Mục tiêu là để quá trình thực hiện tiếp theo về cơ bản là sự chuyển thể trung thực của thiết kế , mà không cần phải diễn giải lại các yêu cầu.
Trong các dự án phức tạp, kế hoạch dự án và các mối quan hệ phụ thuộc được thể hiện qua các công cụ như biểu đồ Gantt và các công cụ quản lý thời gian khác , rất phù hợp với tư duy tuần tự của mô hình thác nước: các nhiệm vụ được xâu chuỗi, các mốc thời gian rất rõ ràng và lịch trình giao hàng được xác định rõ ràng.
4. Thực hiện hoặc phát triển
Sau khi giai đoạn thiết kế hoàn tất, giai đoạn triển khai bắt đầu. Đây là lúc nhóm phát triển, xây dựng hoặc tích hợp tập trung vào việc xây dựng sản phẩm chính xác như thiết kế . Ví dụ, trong lĩnh vực phần mềm, đây là thời điểm để viết mã, cấu hình hệ thống, thiết lập cơ sở hạ tầng, v.v.
Nghịch lý thay, trong nhiều dự án theo mô hình thác nước, giai đoạn này lại ngắn hơn giai đoạn xác định yêu cầu và thiết kế vì phần lớn công sức đã được đầu tư vào việc lập kế hoạch và lập tài liệu . Ý tưởng là để giảm thiểu sự ứng biến: các quyết định quan trọng đã được đưa ra, và bây giờ là lúc thực hiện.
Mặc dù có thể có các đánh giá nội bộ và kiểm thử đơn vị, phương pháp Waterfall truyền thống vẫn dành việc xác minh chính thức cho giai đoạn tiếp theo, sau khi toàn bộ hệ thống được tích hợp.
5. Xác minh, kiểm thử và thẩm định
Sau khi hệ thống được xây dựng xong, bước tiếp theo là xác minh xem nó có thực sự hoạt động như mong đợi hay không. Ở đây, điều quan trọng là phải phân biệt giữa xác minh và thẩm định , hai khái niệm được xử lý khá nghiêm ngặt trong quy trình xếp tầng.
Quá trình xác minh bao gồm việc đảm bảo sản phẩm được xây dựng chính xác: hệ thống được so sánh với các thông số kỹ thuật thiết kế, và các bài kiểm tra đơn vị, tích hợp và hệ thống được thực hiện để tìm ra các lỗi kỹ thuật. Khi có liên quan đến API, các công cụ như hướng dẫn kiểm thử API của Postman được sử dụng . Câu trả lời là: "Chúng ta đã xây dựng hệ thống theo đúng thiết kế chưa?"
Mặt khác, quá trình thẩm định tập trung vào việc xác minh sản phẩm có chính xác hay không : sản phẩm có đáp ứng được các yêu cầu và nhu cầu của người dùng như đã được xác định ban đầu hay không. Nó trả lời câu hỏi: "Hệ thống này có thực sự giải quyết được vấn đề kinh doanh hay không?"
Trong giai đoạn này, việc kiểm thử nghiệm thu được thực hiện với khách hàng. Nếu phát hiện lỗi, chúng sẽ được sửa chữa; nếu có sự sai lệch so với kỳ vọng của khách hàng, một số công việc có thể cần phải làm lại. Vì những vấn đề này được phát hiện muộn, chi phí sửa chữa thường rất cao cả về thời gian và tiền bạc , đây là một trong những nhược điểm chính của mô hình thác nước trong môi trường thay đổi.
6. Triển khai hoặc khởi động
Sau khi hoàn tất quá trình thử nghiệm chính thức và được khách hàng chấp nhận, sản phẩm sẽ chuyển sang giai đoạn triển khai hoặc sản xuất . Trong lĩnh vực phần mềm, điều này có thể bao gồm việc cài đặt hệ thống trong môi trường cuối cùng, di chuyển dữ liệu, đào tạo người dùng và tích hợp hệ thống mới với các hệ thống hiện có, và kiến thức về quản lý API là rất hữu ích cho công việc này.
Trong các lĩnh vực khác, nó đánh dấu thời điểm khánh thành một cơ sở, bàn giao một nhà máy công nghiệp hoặc đưa vào vận hành một công trình hạ tầng. Theo trình tự, cột mốc này báo hiệu sự kết thúc của dự án phát triển và bắt đầu giai đoạn bảo trì.
KHAI THÁC. Thần chú
Sau khi khởi động, giai đoạn bảo trì bắt đầu, và trong nhiều trường hợp, đây là giai đoạn dài nhất trong vòng đời của hệ thống . Giai đoạn này bao gồm việc sửa chữa các lỗi phát sinh, điều chỉnh hệ thống cho phù hợp với những thay đổi cụ thể trong môi trường (quy định, hệ thống bên ngoài, phần cứng) và thực hiện các cải tiến nhỏ.
Theo triết lý Waterfall thuần túy, những thay đổi lớn ảnh hưởng đáng kể đến kiến trúc hoặc yêu cầu thường được tiếp cận như những dự án Waterfall mới , với chu trình riêng gồm yêu cầu, thiết kế, triển khai và kiểm định. Tài liệu được tạo ra trong các giai đoạn trước trở thành nguồn hỗ trợ quan trọng cho nhóm hỗ trợ, nhóm này có thể không phải là nhóm đã thiết kế hệ thống ban đầu.
Vai trò trung tâm của tài liệu trong mô hình Waterfall
Nếu có một điều định nghĩa phương pháp thác nước, ngoài trình tự các giai đoạn, đó là tầm quan trọng của tài liệu như xương sống của dự án. Mỗi giai đoạn tạo ra các sản phẩm bàn giao chính thức để xem xét và phê duyệt: đặc tả yêu cầu, thiết kế, kế hoạch thử nghiệm, báo cáo xác minh, hướng dẫn vận hành, v.v.
Việc lập tài liệu này không phải là một thủ tục hành chính tùy tiện; trong nhiều lĩnh vực, đây là một yêu cầu pháp lý hoặc hợp đồng . Nó cho phép bạn chứng minh những gì đã được thỏa thuận, cách thức thiết kế, cách thức triển khai và cách mọi thứ đã được kiểm chứng. Hơn nữa, nó tạo điều kiện thuận lợi cho việc truy xuất nguồn gốc hoàn toàn từ yêu cầu đến mã nguồn thực hiện yêu cầu đó và bài kiểm thử xác nhận tính hợp lệ của nó.
Kế hoạch dự án và cơ sở ban đầu
Kế hoạch dự án trong môi trường Waterfall thực sự là một bản đồ chỉ đường . Nó xác định phạm vi, lịch trình chi tiết, nguồn lực, các mốc quan trọng, rủi ro và tiêu chí chấp nhận cho mỗi giai đoạn. Kế hoạch này thường được thể hiện bằng biểu đồ Gantt rất chi tiết và lịch trình các cuộc đánh giá chính thức vào cuối mỗi giai đoạn.
Sau khi được phê duyệt, kế hoạch sẽ được giữ nguyên làm cơ sở. Bất kỳ sự sai lệch đáng kể nào (về phạm vi, chi phí hoặc tiến độ) đều được quản lý thông qua các yêu cầu thay đổi và quy trình kiểm soát , thường được xem xét bởi một ủy ban dự án. Sự chặt chẽ này mang lại mức độ dự đoán cao, điều rất được đánh giá cao trong các hợp đồng giá cố định hoặc các chương trình có điều khoản phạt đối với sự chậm trễ.
Bản đặc tả yêu cầu là một tài liệu quan trọng.
Trong tất cả các tài liệu, bản đặc tả yêu cầu thường là tài liệu có giá trị pháp lý cao nhất . Nó nêu rõ hệ thống phải làm gì, trong những ràng buộc nào, ở mức chất lượng nào và cách thức tương tác với các yếu tố khác.
Trong phương pháp tiếp cận theo tầng, giai đoạn này thường tiêu tốn từ 20% đến 30% tổng nỗ lực của dự án. Con số này có vẻ nhiều, nhưng khi chi phí mắc sai lầm cao, việc đầu tư thời gian vào việc làm rõ kết quả mong muốn sẽ rẻ hơn so với việc phải xây dựng lại một nửa hệ thống vào phút cuối.
Khả năng truy xuất nguồn gốc và hồ sơ thử nghiệm
Một đặc điểm điển hình khác của mô hình Waterfall là việc sử dụng ma trận truy vết, liên kết từng yêu cầu với các yếu tố thiết kế thực hiện nó và các trường hợp kiểm thử xác minh nó . Việc duy trì các ma trận này đòi hỏi sự kỷ luật, nhưng chúng vô cùng quan trọng trong các cuộc kiểm toán và chứng nhận.
Kế hoạch thử nghiệm, kịch bản, kết quả và báo cáo đánh giá tạo thành một tập hợp bằng chứng chứng minh rằng hệ thống đã được thử nghiệm một cách có hệ thống . Trong các lĩnh vực như dược phẩm, hàng không vũ trụ và đường sắt, những hồ sơ này là bắt buộc và phải được lưu giữ trong nhiều năm.
Giấy tờ thì có, thủ tục hành chính thì không.
Một lời chỉ trích phổ biến đối với mô hình thác nước là nó tạo ra vô số giấy tờ mà chẳng ai đọc. Và đôi khi điều đó đúng, chúng ta đừng tự lừa dối mình. Đó là lý do tại sao điều quan trọng là phải phân biệt giữa tài liệu tạo ra giá trị (loại tài liệu giúp hiểu các quyết định, chứng minh sự tuân thủ hoặc duy trì hệ thống) và thủ tục hành chính chỉ để điền vào các biểu mẫu.
Người quản lý dự án theo mô hình thác nước cần có khả năng phân biệt để loại bỏ thông tin không cần thiết và tập trung vào các tài liệu trả lời các câu hỏi quan trọng: ai yêu cầu điều gì , tại sao nó được thiết kế như vậy và chức năng của nó đã được kiểm chứng như thế nào. Nếu một tài liệu không giúp trả lời bất kỳ câu hỏi nào trong số này hoặc không cần thiết để vượt qua cuộc kiểm toán, thì có lẽ nó là dư thừa.
Ưu điểm của phương pháp thác nước
Thác nước không phải là phương thuốc vạn năng, nhưng trong những bối cảnh phù hợp, nó sở hữu một số ưu điểm khó có thể sánh kịp. Dưới đây là những ưu điểm nổi bật nhất.
Thứ nhất, phương pháp này cung cấp một cấu trúc rõ ràng, logic và được tổ chức rất tốt . Dự án được hoàn thành theo trình tự, với các giai đoạn không chồng chéo và các mốc thời gian được xác định rõ ràng. Điều này tạo điều kiện thuận lợi rất lớn cho việc phân bổ nguồn lực và theo dõi tiến độ, bởi vì luôn rõ ràng bạn đang ở giai đoạn nào.
Thứ hai, phương pháp này cho phép lập kế hoạch và ước tính rất chính xác khi các yêu cầu đã ổn định. Vì mọi thứ được xác định trước khi bắt đầu, việc tính toán chi phí, thời gian và nhu cầu nhân sự trở nên dễ dàng hơn. Điều này rất lý tưởng cho các hợp đồng giá cố định, đấu thầu công khai và các dự án mà khách hàng cần biết ngay từ đầu họ sẽ phải trả bao nhiêu và khi nào họ sẽ nhận được kết quả.
Thứ ba, mô hình thác nước tạo ra tài liệu toàn diện và khả năng truy xuất nguồn gốc đầy đủ . Mỗi giai đoạn đều để lại dấu vết của các sản phẩm đã được xem xét và phê duyệt, điều này được đánh giá cao trong các môi trường được quản lý chặt chẽ và quan trọng, nơi việc thiếu giấy tờ có thể gây ra rủi ro pháp lý hoặc an ninh.
Hơn nữa, với các giai đoạn được xác định rõ ràng như vậy, việc đo lường tiến độ dự án và báo cáo cho ban quản lý trở nên dễ dàng hơn. Các kỹ thuật như giá trị thu được có thể được sử dụng và so sánh với mốc cơ sở một cách khá khách quan.
Cuối cùng, một số khách hàng thấy thuận tiện khi sau giai đoạn xác định yêu cầu ban đầu, họ không cần phải tham gia liên tục . Trong mô hình Waterfall, sự tham gia của họ thường tập trung vào giai đoạn đầu (để xác định những gì họ muốn) và giai đoạn cuối (để xác nhận những gì đã được bàn giao). Đối với các tổ chức có thời gian hạn chế hoặc không có văn hóa hợp tác liên tục, đây có thể là một lợi thế.
Những hạn chế và rủi ro của phương pháp thác nước
Nhược điểm của tất cả những điều trên là mô hình Waterfall gặp rất nhiều khó khăn khi bối cảnh đòi hỏi sự linh hoạt và khả năng thích ứng với sự thay đổi . Những bất lợi chính của nó đã được biết đến rộng rãi.
Nhược điểm rõ ràng nhất là thiếu tính linh hoạt . Việc cố định các yêu cầu ngay từ đầu và tiến hành mà không xem xét lại khiến việc đưa ra những thay đổi hợp lý giữa chừng dự án trở nên rất khó khăn. Bất kỳ điều chỉnh đáng kể nào cũng có thể dẫn đến việc sửa đổi thiết kế, lập trình lại và thử nghiệm lặp đi lặp lại, gây ảnh hưởng đến thời gian và ngân sách.
Một vấn đề khác là sự chậm trễ trong việc cung cấp giá trị . Trong mô hình thác nước, khách hàng không thấy sản phẩm hoạt động được cho đến giai đoạn cuối cùng. Nếu, khi đến giai đoạn đó, họ phát hiện ra rằng những gì đã được cung cấp không phù hợp với nhu cầu thực tế của họ (vì bối cảnh đã thay đổi, đối thủ cạnh tranh mới xuất hiện hoặc có những ý tưởng tốt hơn), thì rất khó để làm gì mà không phải quay lại đáng kể.
Ngoài ra, chất lượng của các yêu cầu ban đầu cũng đóng vai trò rất quan trọng . Nếu khách hàng không rõ ràng về những gì họ muốn, hoặc nếu nhóm không thể nắm bắt được điều đó một cách hiệu quả, mô hình thác nước sẽ trở thành một cái bẫy tốn kém: rất nhiều tiền được đầu tư vào việc lập kế hoạch cho một thứ mà sau đó lại phải làm lại.
Vấn đề này càng trở nên trầm trọng hơn do thiếu phản hồi liên tục . Vì sự tham gia của khách hàng bị hạn chế trong quá trình phát triển, nên các cơ hội điều chỉnh giải pháp ngay lập tức và phát hiện sớm các vấn đề về khả năng sử dụng hoặc tính phù hợp với kinh doanh đã bị bỏ lỡ.
Cuối cùng, khi được sử dụng ngoài ngữ cảnh, mô hình thác nước có thể tạo ra cảm giác kiểm soát sai lầm . Việc có một biểu đồ Gantt đẹp mắt và hàng loạt tài liệu đã được phê duyệt không đảm bảo rằng hệ thống sẽ tích hợp tốt hoặc hoạt động như mong đợi. Nhiều vấn đề chỉ xuất hiện ở giai đoạn cuối, khi việc khắc phục trở nên tốn kém hơn.
Mô hình thác nước trong phát triển phần mềm
Trong lĩnh vực phần mềm, mô hình Waterfall từng thống trị nhiều năm , đặc biệt là trong các hệ thống lớn dành cho chính phủ, quốc phòng, ngân hàng và viễn thông. Trình tự "yêu cầu - thiết kế - lập trình - kiểm thử - bảo trì" phù hợp với tư duy kỹ thuật thời bấy giờ.
Theo thời gian, rõ ràng là các yêu cầu đối với hầu hết các sản phẩm kỹ thuật số liên tục thay đổi . Thị trường biến động nhanh chóng, công nghệ không ngừng phát triển, và người dùng chỉ khám phá ra những gì họ thực sự muốn khi bắt đầu sử dụng một sản phẩm cụ thể. Trong môi trường này, việc phát hiện ra lỗi về mặt khái niệm trong giai đoạn thử nghiệm cuối cùng đồng nghĩa với việc phải bỏ phí rất nhiều công sức.
Đó là lý do tại sao hầu hết các nhóm phát triển phần mềm hướng đến sản phẩm đều áp dụng các phương pháp linh hoạt và lặp đi lặp lại (Scrum, Kanban, Lean, v.v.), cho phép tăng dần sản phẩm thường xuyên, xác thực các giả thuyết kinh doanh và điều chỉnh hướng đi nhanh chóng.
Tuy nhiên, mô hình thác nước vẫn có chỗ đứng trong phát triển phần mềm khi phạm vi rất hạn chế và tính ổn định là ưu tiên hàng đầu: các hệ thống quan trọng (y tế, quân sự, hàng không), tích hợp với các hợp đồng đã ký kết, phát triển cho các môi trường được quản lý chặt chẽ, hoặc chuyển đổi các hệ thống rất cũ mà các quy tắc kinh doanh được ghi chép đầy đủ.
Khi nào thì nên sử dụng phương pháp thác nước?
Việc lựa chọn giữa Waterfall và Agile không phải là vấn đề xu hướng, mà là vấn đề bối cảnh. Có những trường hợp Waterfall là lựa chọn rất hợp lý , và cũng có những trường hợp nó hoàn toàn là một sai lầm về mặt phương pháp luận.
Các dự án có yêu cầu ổn định và đã được biết rõ.
Kịch bản lý tưởng cho mô hình Waterfall là khi các yêu cầu rõ ràng, đầy đủ và ít có khả năng thay đổi . Ví dụ: chuyển đổi một hệ thống cũ sang nền tảng mới trong khi vẫn duy trì chức năng tương tự, sao chép một nhà máy công nghiệp đã được chứng minh hiệu quả ở một địa điểm khác, hoặc triển khai một hệ thống ERP với phạm vi được xác định bởi hợp đồng.
Trong những trường hợp này, tổ chức thường có sự hiểu biết rất tốt về lĩnh vực và các rủi ro. Mô hình thác nước cho phép họ tận dụng kinh nghiệm đó, lập kế hoạch chi tiết và tối ưu hóa việc sử dụng nguồn lực với rất ít bất ngờ.
Môi trường được quản lý và có tính chất cực kỳ quan trọng
Hàng không vũ trụ, đường sắt, năng lượng hạt nhân, thiết bị y tế… Đây là những lĩnh vực mà việc truy xuất nguồn gốc tuyệt đối và tài liệu đầy đủ là bắt buộc. Các cơ quan quản lý yêu cầu quyền truy cập vào các kế hoạch tuần tự, đánh giá thiết kế, hồ sơ thử nghiệm và lý giải đầy đủ cho mọi quyết định kỹ thuật.
Trong các lĩnh vực này, việc lập tài liệu sơ sài và liên tục thử nghiệm một số phương pháp linh hoạt không phù hợp với các yêu cầu chứng nhận. Phương pháp thác nước cung cấp khung tài liệu cần thiết để vượt qua các cuộc kiểm toán chính thức và các mốc xác nhận theo quy định.
Hợp đồng giá cố định và thuê ngoài
Khi nhà cung cấp ký hợp đồng giá cố định, họ cần giảm thiểu sự không chắc chắn. Mô hình thác nước rất phù hợp với điều này vì phạm vi công việc được đàm phán, ghi lại và cố định trước khi có bất kỳ cam kết nào được đưa ra. Bất kỳ thay đổi nào sau đó đều có quy trình chính thức riêng và thường liên quan đến việc đàm phán lại chi phí và thời hạn.
Trong các dự án thuê ngoài mà các nhóm làm việc phân tán và giao tiếp không chính thức bị hạn chế, mô hình thác nước giúp giảm thiểu sự mơ hồ bằng cách thay thế các cuộc trò chuyện liên tục bằng các bản đặc tả chi tiết.
Văn hóa tổ chức ít khoan dung với sự không chắc chắn
Có những tổ chức có cấu trúc phân cấp cao, ngân sách hàng năm cố định và ám ảnh về tính dự đoán. Trong môi trường này, việc cố gắng triển khai Agile theo đúng sách vở thường dẫn đến một "mô hình lai kỳ lạ", trong đó cả hai mô hình đều không tận dụng được ưu điểm của nhau.
Mô hình thác nước phù hợp nhất với những cấu trúc mà việc lập kế hoạch vững chắc ngay từ đầu được coi trọng, với các báo cáo tiến độ tuyến tính và các đánh giá chính thức. Ở đây, người quản lý dự án đóng vai trò là người bảo vệ đường cơ sở , chứ không phải là người tạo điều kiện cho các lần lặp lại.
Tích hợp nhiều nhà cung cấp và các chương trình quy mô lớn
Trong các dự án quy mô lớn với nhiều nhà thầu (ví dụ: ô tô, đóng tàu hoặc cơ sở hạ tầng lớn), mô hình thác nước đóng vai trò là ngôn ngữ chung để phối hợp các giao diện . Mỗi nhà cung cấp phát triển hệ thống con của họ dựa trên các thông số kỹ thuật giao diện cố định, và việc kiểm thử tích hợp được lên kế hoạch từ rất sớm.
Nếu mỗi nhóm làm việc với các ưu tiên thay đổi và các chu kỳ phát triển độc lập mà không có một khuôn khổ tổng thể, quá trình tích hợp sẽ trở nên hỗn loạn. Cách tiếp cận tuần tự giúp dễ dàng xác định các điểm tích hợp rõ ràng và kiểm soát chuỗi cung ứng tốt hơn.
Khi nào thì KHÔNG nên áp dụng mô hình Waterfall?
Việc biết được thác nước tỏa sáng ở đâu cũng quan trọng như việc xác định những tình huống mà bạn nên loại bỏ nó ngay lập tức mà không cần do dự . Một số tình huống điển hình:
Khi khách hàng chưa thực sự biết mình cần gì và được kỳ vọng sẽ học hỏi thông qua thử và sai, việc áp đặt mô hình tuần tự chỉ dẫn đến sự thất vọng và vượt chi phí. Rất nhiều thời gian sẽ bị lãng phí vào việc lập tài liệu cho thứ mà chẳng mấy chốc sẽ thay đổi.
Nếu thị trường thay đổi trong vòng vài tuần hoặc vài tháng (các công ty khởi nghiệp, sản phẩm kỹ thuật số đột phá, dự án trải nghiệm người dùng), việc chờ đến phút cuối mới xác nhận giải pháp là thiếu thận trọng. Trong những trường hợp này, các phương pháp lặp đi lặp lại và tăng dần , cho phép thử nghiệm, đo lường và điều chỉnh sẽ phù hợp hơn.
Hơn nữa, nếu thời hạn quá gấp gáp đến mức không cho phép giai đoạn xác định yêu cầu kỹ lưỡng, việc cố gắng tuân theo mô hình Waterfall chắc chắn sẽ dẫn đến một phiên bản của mô hình Waterfall mà không có sự kiểm soát thực sự , nơi việc lập tài liệu bị vội vàng chỉ để "hoàn thành thủ tục". Đó là điều tồi tệ nhất của cả hai phương pháp.
Phương pháp Agile so với Waterfall: Những điểm khác biệt chính
Việc so sánh giữa Waterfall và Agile xuất hiện trong hầu hết mọi cuộc thảo luận về quản lý dự án. Chúng không tốt hơn hay xấu hơn hẳn; chúng chỉ đơn giản phản ánh những triết lý khác nhau.
Mô hình Waterfall đề xuất một cách tiếp cận tuyến tính và tuần tự: trước tiên mọi thứ được định nghĩa, sau đó được thiết kế, triển khai, kiểm thử và bàn giao. Mặt khác, mô hình Agile chia công việc thành các chu kỳ ngắn, lặp đi lặp lại (sprint), trong đó một tập hợp nhỏ các chức năng được lên kế hoạch, thiết kế, phát triển và kiểm thử trong mỗi lần lặp.
Trong mô hình thác nước, phạm vi được cố định ngay từ đầu và những thay đổi là những ngoại lệ tốn kém. Trong Agile, thay đổi được coi là điều bình thường và sản phẩm phát triển qua từng sprint , điều chỉnh backlog dựa trên phản hồi của người dùng và doanh nghiệp.
Về sự tham gia của khách hàng, phương pháp Waterfall tập trung vào giai đoạn đầu và cuối dự án. Phương pháp Agile phân bổ sự tham gia này xuyên suốt toàn bộ vòng đời dự án, với các đánh giá thường xuyên và sản phẩm có thể được bàn giao vào cuối mỗi sprint.
Về thời gian đưa sản phẩm ra thị trường, các dự án theo mô hình thác nước thường mang lại giá trị vào cuối quy trình. Mô hình Agile cho phép phát hành các phiên bản ban đầu (MVP) và được tinh chỉnh theo thời gian.
Trên thực tế, nhiều tổ chức lựa chọn các phương pháp kết hợp , chẳng hạn như mô hình "Waterfall" nổi tiếng: lập kế hoạch và thiết kế tổng thể theo mô hình thác nước, phát triển hàng ngày với Scrum, và triển khai/phân phối lại dưới một khuôn khổ mang tính dự đoán hơn.
Vai trò của người quản lý dự án trong mô hình Waterfall
Trong môi trường mô hình thác nước, người quản lý dự án có vai trò khác với Scrum Master hay Agile Coach. Ở đây, họ được kỳ vọng là người lập kế hoạch tỉ mỉ và kiểm soát tiến độ , chứ không phải là người hỗ trợ các nhóm tự tổ chức.
Các trách nhiệm chính bao gồm duy trì tiến độ dự án, điều phối các cuộc đánh giá giai đoạn, quản lý rủi ro, kiểm soát thay đổi, đảm bảo tuân thủ thời hạn và ngân sách, và báo cáo tình trạng dự án cho ban quản lý thông qua các báo cáo chính thức. Đối với các dự án lớn, vai trò này thường liên quan đến sự hợp tác chặt chẽ với trưởng nhóm kỹ thuật để đảm bảo chất lượng của các quyết định thiết kế và kiến trúc.
Đối với những người muốn chuyên sâu vào loại hình quản lý này, các chứng chỉ như PMP của PMI hoặc các tiêu chuẩn cụ thể của các lĩnh vực được quản lý (ví dụ: DO-178C trong ngành hàng không vũ trụ) sẽ củng cố chính xác những kỹ năng hướng tới vòng đời dự đoán và được ghi chép đầy đủ.
Các phương pháp kết hợp và sự cùng tồn tại với các phương pháp linh hoạt
Thực tế là hiện nay hầu như không có dự án nghiêm túc nào hoàn toàn theo mô hình thác nước (waterfall) hoặc hoàn toàn theo mô hình linh hoạt (agile). Thường thì người ta sẽ thấy các sự kết hợp trong đó mô hình thác nước đóng vai trò như một khuôn khổ hợp đồng , trong khi các chu kỳ lặp lại được áp dụng nội bộ để giảm thiểu rủi ro ở các lĩnh vực cụ thể.
Ví dụ, kiến trúc tổng thể và giao diện có thể được định nghĩa bằng phương pháp thác nước, nhưng một số hệ thống con có thể được phát triển bằng các chu kỳ ngắn và tạo mẫu thử nghiệm . Miễn là các mốc giao diện và tích hợp được tuân thủ, sự kết hợp này có thể hoạt động rất tốt.
Điều tương tự cũng xảy ra trong các quy trình chuyển đổi số: một tổ chức có thể di chuyển hệ thống cốt lõi giao dịch (ổn định và được quản lý) bằng mô hình Waterfall, trong khi phát triển các ứng dụng giao diện người dùng cho khách hàng cuối cùng bằng các nhóm linh hoạt. Điều này không hề mâu thuẫn, mà là một cách thông minh để lựa chọn công cụ phù hợp cho từng vấn đề.
Cũng có những quá trình chuyển đổi từ mô hình Waterfall sang Agile, trong đó việc quản lý nguồn lực và kỹ năng của nhóm đòi hỏi một sự thay đổi văn hóa đáng kể . Bắt đầu với các phương pháp Agile trên các dự án nhỏ cho phép các nhóm làm quen với việc lập kế hoạch năng động và phản hồi liên tục mà không gây nguy hại đến các chương trình quan trọng.
Tóm lại, phương pháp Waterfall vẫn là một công cụ rất hữu ích trong quản lý dự án, miễn là những ưu điểm của nó — khả năng dự đoán, cấu trúc và khả năng truy vết— được hiểu rõ . Khi áp dụng cho các lĩnh vực có yêu cầu ổn định, quy định nghiêm ngặt hoặc hợp đồng giá cố định, nó có thể là lựa chọn an toàn và hiệu quả nhất, đặc biệt khi kết hợp với mức độ lặp lại hợp lý và sự nhạy bén.
