NỘI DUNG BÀI VIẾT
Mô hình Waterfall là gì?
Phương pháp mô hình thác nước còn được gọi là mô hình vòng tuần hoàn dạng lặp. Mô hình thác nước theo thứ tự tuần tự và do đó nhóm phát triển dự án chỉ chuyển sang gian đoạn phát triển hoặc thử nghiệm tiếp theo nếu bước trước đó hoàn thành thành công.
Xem thêm: Mô hình Waterfall
Mô hình Agile là gì?
Phương pháp nhanh là phương pháp lặp liên tục giai đoạn phát triển và thử nghiệm trong quá trình phát triển phần mềm. Trong phương pháp này, quá trình phát triển và thử nghiệm là đồng thời, không giống như mô hình thác nước. Quá trình này cho phép giao tiếp nhiều hơn giữa khách hàng, nhà phát triền, người quản lý và người nghiệm thu.
Nguồn video: Học viện Agile
Xem thêm Mô hình Agile
Ưu điểm và nhược điểm của mô hình Waterfall
Ưu điểm
- Là một trong những mô hình dễ nhất để quản lý. Về bản chất, mỗi giai đoạn có quá trình cụ thể, có điểm bắt đầu và điểm kết thúc. Điểm kết thúc của giai đoạn này là điểm đầu vào của giai đoạn kế tiếp và cứ thế “cuốn chiếu” cho đến hết dự án.
- Hoạt động tốt cho các dự án có kích thước nhỏ, các yêu cầu dễ hiểu.
- Quá trình và kết quả được ghi nhận một cách “hữu hình” hơn là các kết quả nhỏ nhưng thiếu tính hoàn thiện tổng thể. Đa phần khách hàng không muốn tham gia review một tính năng dở dang.
- Phương pháp dễ điều chỉnh cho các đội chuyển dịch
- Phương pháp quản lý dự án này có lợi cho việc quản lý các phụ thuộc.
Nhược điểm
- Không phải là một mô hình lý tưởng cho một dự án kích thước lớn.
- Nếu yêu cầu không rõ ràng ngay từ đầu thì đó là phương pháp kém hiệu quả hơn.
- Rất khó di chuyển trở lại giai đoạn trước đó để thay đổi.
- Quá trình thử nghiệm bắt đầu khi quá trình phát triển kết thúc. Do đó, có nguy cơ rất lớn là các lỗi về sai nghiệp vụ, sai luồng thiết kế, sai cấu trúc dữ liệu… được phát hiện “muộn màng” sau khi giai đoạn phát triển đã hoàn thành, do đó rất tốn kém để sửa chữa sai lầm.
Ưu điểm và nhược điểm của mô hình Agile
Ưu điểm
- Nó là quá trình khách hàng tập trung. Vì vậy, nó đảm bảo rằng khách hàng liên tục tham gia trong mọi giai đoạn.
- Các nhóm Agile được tạo động lực và tự tổ chức để có khả năng cung cấp kết quả tốt hơn từ các dự án phát triển.
- Phương pháp phát triển phần mềm theo cách tiếp cận nhanh, chia nhỏ (rapid development) đảm bảo rằng chất lượng của sự phát triển được duy trì liên tục.
- Quá trình này hoàn toàn dựa trên tiến trình gia tăng (incremental development). Vì vậy, khách hàng, những người liên quan (stakeholder) và nhóm phát triển biết chính xác những gì được hoàn thành và những gì không. Ngoài ra cách tiếp cận tăng dần sẽ kích hoạt công cụ phòng ngừa rủi ro từ sớm.
- Agile cũng giúp nhóm dự án “deliver” kết quả nhanh hơn, dễ dàng chia nhỏ và lượng hóa bằng kết quả cụ thể (deliverable). Nhờ đó các công cụ hỗ trợ phản hồi như Feedback360 có thể dễ dàng phát huy hiệu quả tốt nhất.
Nhược điểm
- Không phải là phương pháp hữu ích cho các dự án phát triển nhỏ.
- Đòi hỏi có các chuyên gia về Agile/Scrum để có những quyết định quan trọng trong cuộc họp.
- Đòi hỏi một người quản lý dự án dày dạn kinh nghiệm, từng tham gia phát triển nhiều mô hình khác nhau, bao gồm cả mô hình Waterfall.
- Dự án có thể dễ dàng đi theo chiều hướng xấu nếu người quản lý dự án không rõ ràng kết quả họ muốn, không có khả năng quản lý nhân sự để thích ứng với các thay đổi diễn biến nhanh.
Thời điểm sử dụng mỗi mô hình?
Agile và Waterfall là các phương pháp phát triển phần mềm rất khác nhau, thậm chí là trái ngược, được ứng dụng trong các hoàn cảnh khác nhau.
| Agile | Waterfall |
|---|---|
| Nó tách vòng đời phát triển dự án thành chạy nước rút. | Quá trình phát triển phần mềm được chia thành các giai đoạn riêng biệt. |
| Nó theo một cách tiếp cận gia tăng | Phương pháp thác nước là một quá trình thiết kế tuần tự. |
| Phương pháp nhanh được biết đến với tính linh hoạt của nó. | Thác là một phương pháp phát triển phần mềm có cấu trúc nên hầu hết thời gian nó có thể khá cứng nhắc. |
| Agile có thể được coi là một bộ sưu tập của nhiều dự án khác nhau. | Phát triển phần mềm sẽ được hoàn thành như một dự án duy nhất. |
| Agile là một phương pháp khá linh hoạt cho phép thay đổi được thực hiện trong các yêu cầu phát triển dự án ngay cả khi kế hoạch ban đầu đã được hoàn thành. | Không có phạm vi thay đổi các yêu cầu khi phát triển dự án bắt đầu. |
| Phương pháp nhanh , theo một cách tiếp cận phát triển lặp lại vì quy hoạch, phát triển, tạo mẫu và các giai đoạn phát triển phần mềm khác có thể xuất hiện nhiều lần. | Tất cả các giai đoạn phát triển dự án như thiết kế, phát triển, thử nghiệm, vv được hoàn thành một lần trong mô hình Thác |
| Kế hoạch kiểm tra được xem xét sau mỗi lần chạy nước rút | Kế hoạch kiểm tra hiếm khi được thảo luận trong giai đoạn thử nghiệm. |
| Phát triển nhanh là một quá trình trong đó các yêu cầu được dự kiến sẽ thay đổi và phát triển. | Phương pháp này là lý tưởng cho các dự án có yêu cầu nhất định và thay đổi không được mong đợi. |
| Trong phương pháp Agile, thử nghiệm được thực hiện đồng thời với phát triển phần mềm. | Trong phương pháp này, giai đoạn “Thử nghiệm” xuất hiện sau giai đoạn “Xây dựng” |
| Agile giới thiệu tư duy sản phẩm, nơi sản phẩm phần mềm đáp ứng nhu cầu của khách hàng cuối cùng và thay đổi chính nó theo nhu cầu của khách hàng. | Mô hình này cho thấy một tư duy dự án và đặt trọng tâm của nó hoàn toàn vào việc hoàn thành dự án. |
| Agat methdology hoạt động đặc biệt tốt với Time & Materials hoặc tài trợ không cố định. Nó có thể làm tăng căng thẳng trong các kịch bản giá cố định. | Giảm rủi ro trong các hợp đồng giá cố định của công ty bằng cách nhận được thỏa thuận rủi ro vào đầu quá trình. |
| Thích các nhóm nhỏ nhưng chuyên dụng với mức độ phối hợp và đồng bộ hóa cao. | Phối hợp / đồng bộ hóa nhóm rất hạn chế. |
| Chủ sở hữu sản phẩm với nhóm chuẩn bị các yêu cầu chỉ là về mỗi ngày trong một dự án. | Phân tích kinh doanh chuẩn bị các yêu cầu trước khi bắt đầu dự án. |
| Đội kiểm tra có thể tham gia vào các yêu cầu thay đổi mà không có vấn đề gì. | Thật khó để thử nghiệm bắt đầu bất kỳ thay đổi nào về yêu cầu. |
| Mô tả chi tiết dự án có thể được thay đổi bất cứ lúc nào trong quá trình SDLC. | Mô tả chi tiết cần thực hiện phương pháp tiếp cận phát triển phần mềm thác nước. |
| Các thành viên của Nhóm Agile có thể hoán đổi cho nhau, do đó, chúng hoạt động nhanh hơn. Cũng không cần thiết cho các nhà quản lý dự án vì các dự án được quản lý bởi toàn bộ nhóm | Trong phương pháp thác nước, quy trình luôn đơn giản như vậy, người quản lý dự án đóng một vai trò thiết yếu trong mọi giai đoạn của SDLC. |
Kết luận
- Mô hình Waterfall lý tưởng cho các dự án đã xác định được yêu cầu và không có thay đổi nào trong quá trình phát triển. Trong khi đó, Agile là phù hợp nhất với các dự án hoặc giai đoạn có yêu cầu thường xuyên thay đổi hơn.
- Thác nước dễ quản lý, mặc dù mọi công đoạn theo quy trình tuần tự và cứng nhắc.
- Agile rất linh hoạt và có thể thay đổi trong bất kỳ giai đoạn nào.
- Trong quá trình Agile, các yêu cầu có thể thay đổi thường xuyên. Tuy nhiên, trong mô hình Waterfall, các yêu cầu được xác định rõ ràng từ đầu và thống nhất bởi tất cả các bên. Có rất nhiều mô hình dự án “bắt buộc” phải triển khai Waterfall, thí dụ dự án xây dựng lại một hệ thống đã có bằng một giải pháp công nghệ mới, tiên tiến nhưng nghiệp vụ về cơ bản không không thay đổi nhiều.
- Trong mô tả Agile của dự án, các chi tiết có thể được thay đổi bất cứ lúc nào trong quá trình SDLC mà không thể thực hiện được trong phương thức Waterfall.
Mong rằng những kiến thức trên giúp bạn áp dụng vào dự án thực tế. Chúc bạn học tốt!
