Other posts

• Phần 1: Agile là gì?
• Phần 2: Waterfall là gì?
• Phần 3: Scrum là gì?
• Phần 4: So sánh Agile, Scrum và Water? Con đường nào phù hợp với bạn
• Phần 5: Agile có thực hiện phù hợp với outsource và các dự án offshore
• Phần 6: Kết hợp mô hình waterfall và scrum để thích nghi với các dự án offshore nói chung, Framgia nói riêng

1. Waterfall Methodology

Waterfall là gì?

Phương pháp luận của mô hình Waterfall tuân theo 1 quy trình tuần tự, tuyến tính. Đây là mô hình phổ biến nhất của vòng đời phát triển hệ thống (SDLC) dành cho phát triển phần mềm và các dự án IT. Để lên kế hoạch cho các dự án sử dụng mô hình này, đôi khi có thể dùng Gantt chart, 1 loại chart thể hiện được ngày bắt đầu và ngày kết thúc của mỗi task. Khi đã hoàn thành 1 công đoạn, team phát triển sẽ thực hiện các bước tiếp theo. Team sẽ không thể quay lại công đoạn ngay trước đó, trừ khi bắt đầu lại từ công đoạn đầu tiên. Trước khi team thực hiện công đoạn tiếp theo, các yêu cầu của dự án cần được khách hàng review và approve.

Mô hình Waterfall có nguồn gốc từ ngành sản xuất và công nghiệp xây dựng, cả 2 môi trường đều có đặc trưng là bất kỳ thay đổi nào cũng rất đắt đỏ và đôi khi là không thể. Mô tả chính thức đầu tiên về Waterfall được viết trong bài báo của Winston W. Royce năm 1970, ông đã mô tả đây là 1 mô hình phát triển phần mềm sai lầm.

Advantages of Waterfall

Mô hình Waterfall phù hợp nhất với các dự án đơn giản, không có thay đổi. Các bước tuần tự khiến cho việc áp dụng mô hình dễ dàng hơn và các tài liệu trong dự án cũng sẽ được mô tả chi tiết hơn.

Những ưu điểm của việc sử dụng mô hình Waterfall bao gồm các điểm sau:

Dễ sử dụng và quản lý: Mô hình Waterfall thực hiện theo các công đoạn tuần tự, giống nhau cho mỗi dự án, vì thế dễ hiểu và dễ áp dụng. Đối với các dự án tương tự nhau, team không cần được training trước khi bắt đầu làm việc trong dự án. Waterfall cũng tương đối cứng nhắc, mỗi công đoạn sẽ có 1 danh sách các sản phẩm, nhờ vậy sẽ dễ dàng hơn trong việc quản lý các sản phẩm và việc review sản phẩm.

Mô hình có kỷ luật: Mỗi công đoạn trong mô hình Waterfall đều có điểm bắt đầu và điểm kết thúc, từ đó dễ dàng chia sẻ tiến độ công việc với các bên liên quan. Nếu team tập trung và công đoạn tìm hiểu yêu cầu khách hàng và thiết kế trước khi tiến hành coding thì có thể giảm được các rủi ro không kịp deadline.

Đòi hỏi cao về tài liệu: Waterfall yêu cầu cần có tài liệu cho mỗi công đoạn, nhờ vậy đảm bảo được việc hiểu yêu cầu và logic của chương trình tốt hơn. Ngoài ra các tài liệu của dự án có thể được sử dụng tiếp trong các dự án khác, hoặc cung cấp cho các bên liên quan khi cần confirm chi tiết về 1 công đoạn nào đó.

Disadvantages of Waterfall

Điểm yếu lớn nhất của Waterfall chính là làm thế nào để quản lý các thay đổi. The biggest drawback of Waterfall is how it handles change. Team không thể đảo giữa các công đoạn, ngay cả khi có thay đổi xảy ra.
Khi dự án đi đến công đoạn chạy test và phát hiện ra việc bị thiếu 1 chức năng trong yêu cầu của khách hàng, thì việc quay lại để sửa rất đắt đỏ và khó thực hiện.

Sản phẩm được deliver muộn: Dự án sẽ cần hoàn thành 2 đến 4 công đoạn trước khi công đoạn coding thực sự bắt đầu, vì thế các bên liên quan sẽ phải đợi đến các giai đoạn cuối để thể thấy được sản phẩm.

Việc thu thập chính xác các yêu cầu ngay từ đầu là 1 thử thách. Ở 1 trong số các công đoạn đầu tiên trong dự án, team cần trao đổi với khách hàng và các bên liên quan để làm rõ các yêu cầu. Tuy nhiên, sẽ rất khó khăng để xác định chính xác họ muốn gì ngay từ đầu dự án. Trong nhiều trường hợp, khách hàng thậm chí vẫn chưa biết họ muốn gì ở giai đoạn này.

Stages of Waterfall

Có 8 công đoạn cơ bản khi áp dụng mô hình Waterfall. Các công đoạn này phải được thực hiện lần lượt. Ví dụ khi đã ở giai đoạn test thì sẽ không thể quay lại công đoạn phân tích dự án.

Conception: Công đoạn này có thể bắt đầu với 1 ý tưởng. Đây là giai đoạn đánh giá ban đầu của dự án: tại sao cần phát triển dự án? lợi ích đem lại là gì? và các ước lượng ban đầu về cost.

Initiation: Khi ý tưởng đã thành hình, bạn cần thuê team dự án, định nghĩa mục tiêu, phạm vị, mục đích và sản phẩm của dự án.

Requirement Gathering and Analysis: Các yêu cầu được tập hợp và phân tích để đánh giá tính khả thi. Tất cả thông tin cần được lưu và tài liệu requirement specification document.

Design: Các thiết kế tạo trong công đoạn này được dùng làm input cho công đoạn coding. Các yêu cầu của dự án cần được study, phân tích và thiết kế xem sẽ xử lý thế nào trong hệ thống. Mục tiêu của team là để hiểu những action cần thực hiện và sản phẩm sẽ có hình dung như thế nào.

Implementation/Coding: Giai đoạn tạo coding, tất cả các nội dung trong công đoạn design cần được chuyển đổi thành ngôn ngữ lập trình.

Testing: Sau khi coding kêt thúc, phần mềm cần được test xem có lỗi không. Sau khi việc test kết thúc, chương trình được chuyển cho khách hàng. Ở 1 số dự án sẽ thực hiện user acceptance testing (UAT) trước khi chương trình được deploy lên môi trường hoạt động thực sự.

Maintenance: Khi khách hàng sử dụng hệ thống, họ có thể tìm thấy những vấn đề chưa ổn. Team phát triển cần thay đổi chương trình để chương trình chạy hiệu quả.

Iterative Waterfall Development

In the traditional Waterfall model, the team goes through each phase for the entire project. For example, they do the analysis for the entire project, then they do the design for the entire project, etc.

In an iterative Waterfall model, there is still a lot of upfront planning required. Once the plan is in place, the team follows the same pattern as traditional Waterfall but does it for each story. They do the analysis for one story, then all the design for one story, then all the coding and testing for one story. Then they repeat the process for another story. The work is broken up into chunks that benefit the development team.

How Waterfall Deals with Software Requirements

Waterfall projects define all software requirements upfront. The project cannot proceed unless these requirements have been identified and documented.

Some Waterfall projects may have a dedicated team to capture, collect, and gather these requirements. They may use questionnaires, face-to-face or phone interviews, white boards, and modeling tools to capture stakeholder and customer requirements.

Once the initial requirements are defined, the team should produce a requirements specification document (sometimes they may create more than one). This document defines what needs to be delivered so everyone understands the scope of the project.

※Source

https://www.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban