Waterfall vs Agile vs Scrum - Part 4: Agile vs Waterfall. Con đường nào phù hợp với bạn
Bài đăng này đã không được cập nhật trong 5 năm
Other posts
- Phần 1: Agile là gì?
- Phần 2: Waterfall là gì?
- Phần 3: Scrum là gì?
- Phần 4: Agile vs Waterfall. Con đường nào phù hợp với bạn
- Phần 5: Agile vs Scrum
- Phần 6: Agile có thực hiện phù hợp với outsource và các dự án offshore
- Phần 7: 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
Agile vs Waterfall
1. Sự khác nhau và giống nhau giữa Waterfall và Agile
Sự khác nhau về phương pháp luận giữa Waterfall và Agile có thể tổng kết trong 2 từ: cứng nhắc và linh hoạt. Trong khi Waterfall là 1 process khá cứng nhắc và nguyên tắc, thì Agile lại rất linh hoạt và không ngừng thay đổi. Chi tiết hơn về sự khác nhau như sau:
Waterfall là quy trình có cấu trúc, bạn không thể bắt đầu công đoạn mới cho đến khi công đoạn trước đấy được hoàn thành. Agile là quy trình linh hoạt, cho phép bạn chạy dự án theo cách mà bạn muốn. Waterfall là tuần tự, và Agile thì ép buộc vào 1 quy trình tuần tự nào. Các dự án theo quy trình Waterfall thường cần define cụ thể yêu cầu của dự án, trong khi các yêu cầu trong các dự án Agile có thể thay đổi và phát triển. Trong các dự án Waterfall, bạn không thể thay đổi những thứ bạn đã làm trong những công đoạn trước, tuy nhiên Agile rất phù hợp và có thể đáp ứng được các thay đổi.
Có không nhiều sự giống nhau giữa Waterfall và Agile; Agile có thể nói là trái ngược với Waterfall. Tuy nhiên, chúng ta có thể nói rằng cả Agile và Waterfall đề có mục tiêu chung. Cả 2 quy trình đều nhằm mục đích tạo ra và deliver những sản phẩm có chất lượng bằng cách hiệu quả nhất.
2. Khi nào nên dùng Waterfall, khi nào nên dùng Agile?
Bạn nên sử dụng Waterfall nếu:
Dự án không có nhiều thay đổi về phạm vi, và bạn đang làm 1 dự án có hợp đồng fixed-price. Dự án tương đối đơn giản hoặc bạn đã làm những dự án tương tự nhiều lần trước đó. Yêu cầu dự án được hiểu rõ, và cố định. Khách hàng biết chính xác họ muốn gì. Bạn đang làm ở những dự án có trật tự và có thể dự đoán trước được.
Và bạn nên dùng Agile nếu:
Sản phẩm cuối cùng chưa được định nghĩa rõ ràng. Khách hàng/stakeholder có khả năng thay đổi phạm vi công việc Bạn có thể dự đoán trước nhiều loại thay đổi trong suốt dự án Mục tiêu của dự án là phát triển nhanh.
Khi lựa chọn giữa Agile và Waterfall, bạn có thể tập trung vào: nêu bạn dự đoán trước hay mong đợi có những thay đổi trong suốt dự án, hãy dùng Agile. Nếu bạn biết dự án là cố định, không thể thay đổi thì Waterfall là lựa chọn tốt nhất cho bạn.
3. Agile hay Waterfall tốt hơn?
Bởi vì Agile và Waterfall gần như là đối ngược nhau nên rất khó để nói cái nào tốt hơn. Điều này phụ thuộc nhiều vào dự án, mức độ rõ ràng về yêu cầu, mức độ linh hoạt mà bạn cần cho dự án.\
Nếu bạn có 1 cái nhìn rõ ràng về sản phẩm cuối cùng của dự án, bạn cho rằng các yêu cầu sẽ không thay đổi và bạn đang thực hiện 1 dự án đơn giản, thì có ý kiến cho rằng Waterfall sẽ là lựa chọn tốt hơn. Nếu không cần đối ứng nhiều thay đổi, thì waterfall là 1 process đơn giản và hiệu quả. Vấn đề sẽ phát sinh khi bạn đối ứng các thay đổi.
Nếu bạn không có được 1 bức tranh rõ ràng về sản phẩm cuối cùng, bạn thấy những thay đổi và bạn đang làm trong 1 dự án phức tạp, Agile sẽ thích hợp hơn. Agile được thiết kế để đối ứng những thay đổi về tạo mới hay update yêu cầu trong bất kỳ thời điểm nào của dự án, trong khi Waterfall không cho phép bạn quay lại những công đoạn đã hoàn thành để thay đổi.
4. Sự kết hợp: Agifall hay WAgile
Nếu bạn vẫn băn khoăn giữa Waterfall và Agile, bạn có thể kết hợp những nguyên tắc của cả hai và sử dụng quy trình kết hợp này.
Agifall là 1 ví dụ, bạn có thể tăng tốc độ và chất lượng bằng cách đưa những phương pháp luận của Agile và quy trình waterfall. Trong dự án Agigall, bạn có thể chia việc tìm hiểu, đưa ra chiến lược và lên kế hoạch dự án thành các task và chia sprints để hoàn thành các task này. Công đoạn phát triển có thể giống như các dự án Agile khác, nhưng mọi thông tin sẽ được xác định rõ hơn từ trước. Bạn cũng có thể không cần đợi cho 1 công đoạn kết thúc mới bắt đầu công đoạn tiếp theo, theo cách mà Waterfall vẫn làm. Với Agifall, khi dự án bắt đầu, nó có thể bắt đầu khi dự án bắt đầu.
Wagile có ý nghĩa tiêu cực hơn so với Agifall. Thep Wikipedia thì định nghĩa của Wagile là , “1 nhóm các phương pháp luận được tạo nên bằng cách chuyển từ Agile sang Waterfall. thực hiện nhiều bước Waterfall trong thời gian ngắn và nghĩ đó là Agile, là sự giả mạo từ Waterfall sang Agile". Wagile áp dụng Agile ở các điểm như chia dự án thành những vòng lặp ngắn hạn, meeting đứng, hoặc kết hợp liên tục ở các công đoạn đầu của waterfall, mà không thật sự thay đổi cách làm của Waterfall truyền thống.
※Source
https://www.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban
All rights reserved
Bình luận
mình thì nghĩ agile mà làm dự án phức tạp, ít requirement thì fail sml
bạn thử nghĩ, ngày nào cũng daily nói về 1 feature mình làm trong vài tháng xem có chán kinh ko, PO thì ko quan tâm/ ko hiểu về kỹ thuật
Hi bạn @vinhthang
Theo mình thì dự án với quy mô như thế nào thì việc requirement rõ ràng là một trong những yếu tố then chốt để làm nên thành công của dự án. Nếu dự án phức tạp thì không thể ít requirement. Nếu dự án ít requirement mà phức tạp thì theo mình thấy điều phức tạp ở đây là PM và đội phát triển dự án đang phải vất vả để làm rõ nó -> phức tạp.
"agile mà làm dự án phức tạp, ít requirement thì fail sml" -> mình không đồng ý quan điểm này, agile được sinh ra là để dễ dàng đáp ứng cho những thay đổi và phát triển/ tiến hóa của dự án. Còn việc requirement không rõ, nắm không chắc vấn đề thì dự án chắc chắn fail, càng không thể nào áp dụng waterfall vào loại dự án này.
PO có thể không cần hiểu biết về kỹ thuật, PM nên là người đứng giữa làm cầu nối giữa PO và đội phát triển. Cho nên mình thấy đây là trường hợp rất phổ biến trong các dự án.
mình làm cho ngân hàng, thì requirement liên quan đến core banking thì gần như không thay đổi, và do phòng nghiệp vụ làm, nếu có thay đổi thì thường là do nghiệp vụ, và sẽ là 1 issue khác. sản phẩm chỉ có đúng hoặc sai, chứ ko có vừa làm vừa sửa. trung bình 3 tháng cho 1 issue, 1 tháng phân tích, code 1 tháng, nghiệm thu 1 tháng.
nhưng bên internet banking thì lại khác, các issue rất nhiều nhưng mình chỉ làm trong ngày, có khi báo 1 cái 15 phút sau đã làm xong rồi, làm agile rất chuẩn
nên theo mình agile hay water fall thì cũng tùy ngữ cảnh mới có hiệu quả
Về ý kiến là agile hay water fall thì tùy hoàn cảnh mới hiệu quả, mình hoàn toàn đồng ý với bạn. Dựa vào hoàn cảnh, sự kết hợp/tương tác của các bên tham gia đôi khi mình phải tạo ra một development model riêng biệt, kết hợp giữa các mô hình với nhau. Mình không nên cứng nhắc khi lựa chọn model nếu như hoàn cảnh không cho phép, điều đó chỉ làm tăng rủi ro (về nhân sự, thời gian phát hành) và chi phí hơn. Mục đích là đưa dự án đến thành công nên cuối cùng chọn model nào phù hợp mới là điều quan trọng nhất. Bên trên mình chỉ muốn nói là "mình thì nghĩ agile mà làm dự án phức tạp, ít requirement thì fail sml" thì nó nghe có vẻ không logic. Vì nếu dự án phức tạp mà ít requirement thì khó xảy ra lắm (thậm chí mình chưa bao giờ thấy).