So sánh giữa Agile và waterfall

Hoài An, Phạm Thu Trang| 30/11/2018 17:28
Theo dõi ICTVietnam trên

Bài viết giải thích sự khác biệt giữa hai phương pháp phát triển, thực hiện các dự án công nghệ phần mềm phổ biến hiện nay là Agile và waterfall.

development

Agile và waterfall (phương pháp mô hình thác) là hai phương pháp phát triển được sử dụng phổ biến nhất để tạo các ứng dụng. Waterfall là cách truyền thống hơn để phát triển ứng dụng và phần mềm, trong khi Agile là một phương pháp hiện đại hóa thường tạo ra nhiều phản ứng nhanh hơn và tích cực hơn.

Phương pháp mô hình thác tập trung hơn vào việc lập kế hoạch, với các giai đoạn của một dự án được hoàn thành trong một cấu trúc tuyến tính, và kết quả cuối cùng là phần mềm hoạt động hoàn toàn. Agile nằm ở đầu kia của thang đo. Nó tập trung hơn vào phát triển hơn là lập kế hoạch và nhanh nhẹn hơn, theo đúng tên gọi của nó. Các ứng dụng được phát hành theo từng giai đoạn, với sự thích ứng và thay đổi liên tục để đáp ứng nhu cầu của khách hàng.

Bởi vì hai phương pháp quá khác biệt nên cần có sự phân chia rõ ràng giữa các nhà phát triển để xem xét xem phương thức nào là tốt nhất và tạo ra kết quả hiệu quả nhất. Tuy nhiên, các nhà phát triển khác, cởi mở hơn sẽ hi vọng vào một phương thức hợp nhất các phần của cả hai phương pháp để tạo ra những gì được coi là môi trường tốt nhất để phát triển.

Agile và waterfall: Phương pháp làm việc

Phương pháp Agile

Phương pháp phát triển Agile có liên quan đến việc phát triển phần mềm một cách nhanh chóng và đến một trạng thái dễ nhận biết đối với khách hàng muốn sản phẩm. Khách hàng kiểm tra phần mềm và sau đó nó được tinh chế theo phản hồi của khách hàng trong giai đoạn phát triển sau này.

Vào đầu chu kỳ phát triển, dự án được vạch ra theo nhu cầu của khách hàng (các tính năng của sản phẩm), được gọi là câu chuyện của người dùng. Sau đó, các nhà phát triển phát triển “các lần lặp” được xây dựng để giải quyết các nhu cầu này, theo thứ tự của tầm quan trọng.

Các đội làm việc trong các cuộc chạy nước rút để hoàn thành mỗi lần lặp trong một khoảng thời gian đã đặt ra, thường được tính bằng tuần. Mỗi mục tiêu chạy nước rút là tạo ra phần mềm làm việc mà người dùng có thể dùng thử, sau đó thực hiện những thay đổi để phù hợp hơn với nhu cầu của người dùng.

Nhưng cuối dự án không có nghĩa là tất cả các tính năng đều được xây dựng. Các dự án nhanh có thể hết thời gian, có nghĩa là các nhà phát triển hoặc phải được sự đồng ý với khách hàng để thực hiện dự án mà vẫn còn một số tính năng vẫn chưa hoàn thành hoặc mở rộng dự án (và được trả thêm tiền) để phân phối chúng.

Phương pháp mô hình thác

Một dự án phát triển theo phương pháp mô hình thác theo một cách tiếp cận truyền thống, tuyến tính. Giai đoạn đầu tiên là giải quyết các yêu cầu của người dùng, đây có thể là một quá trình mở rộng. Bởi vì các nhà phát triển sẽ không tạo ra phần mềm cho khách hàng để làm việc thử nghiệm giữa dự án, họ muốn hiểu trước chính xác những gì người dùng muốn phần mềm hoạt động và trông như thế nào.

Sau đó, các nhà phát triển sẽ thiết kế phần mềm, tạo cho mình một mẫu chi tiết để làm việc. Bằng cách làm việc từ một kế hoạch, ý tưởng là quá trình phát triển thực tế, tiếp theo, sẽ mượt mà hơn và gặp ít trở ngại hơn.

Khi họ đã xây dựng hệ thống, nhà phát triển bước vào giai đoạn thử nghiệm - đây là nơi họ đảm bảo phần mềm thực sự hoạt động. Quá trình này cho thấy các nhà phát triển gỡ lỗi hệ thống, đôi khi liên quan đến những người dùng dùng thử. Sau đó, các nhà phát triển đi vào chế độ bảo trì, cài đặt, hỗ trợ và duy trì phần mềm thay mặt cho khách hàng.

Agile và waterfall: Ưu điểm và nhược điểm

Ưu điểm của phương pháp Agile

Lợi thế lớn nhất của phương pháp Agile là nó liên quan đến khách hàng ở mọi giai đoạn phát triển. Với việc người dùng liên tục cung cấp phản hồi về phần mềm làm việc, dự án khi kết thúc có nhiều khả năng sẽ đáp ứng tốt hơn nhu cầu của họ, có thể phát triển khi dự án tiến triển. Không giống như phương pháp mô hình tháp, nếu một khách hàng có yêu cầu thay đổi, các nhà phát triển Agile có thể dễ dàng tạo ra nó.

Cách tiếp cận này cũng cung cấp phần mềm nhanh hơn cho khách hàng, làm cho nó lý tưởng cho các dự án trong đó chú trọng vào tốc độ.

Một ưu điểm khác trong phương pháp Agile là khái niệm về cải tiến liên tục, trong đó các bài học kinh nghiệm trong một lần lặp lại thông báo cho công việc về lần lặp tiếp theo.

Nhược điểm của phương pháp Agile

Tuy nhiên, các dự án Agile lại rất chuyên sâu cho khách hàng. Sự tham gia của khách hàng là điều cần thiết trong suốt dự án, vì vậy khách hàng phải có khả năng cho phép các bên liên quan, và họ phải nhiệt tình và tham gia vào dự án. Các dự án nhanh có thể sụp đổ nếu khách hàng không quan tâm đến việc làm việc chặt chẽ với các nhà phát triển.

Một nhược điểm khác của Agile là, do thời hạn chạy nước rút nghiêm ngặt, đôi khi dự án tổng thể có thể kết thúc không đầy đủ. Khách hàng phải hoặc chấp nhận phạm vi giảm của dự án hoặc trả nhiều tiền hơn để các nhà phát triển hoàn thành mọi thứ họ đã lên kế hoạch để hoàn thành.

Ưu điểm của phương pháp mô hình thác

Bằng cách tập trung vào chất lượng hơn tốc độ, phương pháp mô hình thác là rất phù hợp với các dự án ít khẩn cấp và khách hàng biết chính xác những gì họ muốn phần mềm của họ hoạt động như thế nào. Thời gian thử nghiệm rộng rãi có thể dẫn đến ít lỗi hơn khi dự án hoàn tất.

Quy trình tuyến tính nghiêm ngặt của mô hình thác có nghĩa là một dự án có khả năng được hoàn thành đúng thời hạn và trong phạm vi ngân sách và với các cột mốc thường xuyên, cả nhà phát triển và khách hàng đều dễ dàng theo dõi tiến độ của dự án.

Nhược điểm của phương pháp mô hình thác

Trong phát triển mô hình thác, một khi khóa học được thiết lập, không có sự lệch hướng nào từ nó. Không giống như Agile, phương pháp mô hình thác không liên quan đến khách hàng trên mọi bước đường, khách hàng chỉ rõ những phạm vi yêu cầu của mình khi bắt đầu một dự án.

Điều này có nghĩa là cách tiếp cận của mô hình thác hoạt động tốt nhất khi khách hàng có ý tưởng rõ ràng về những gì phần mềm của họ cần làm. Nếu người dùng chỉ có ý tưởng mơ hồ hoặc dự án mất nhiều thời gian để phân phối, phần mềm hoàn chỉnh thường sẽ không cần yêu cầu của người dùng, điều này có thể thay đổi trong suốt quá trình của dự án.

Tương tự, khi một dự án mô hình thác đi vào giai đoạn thử nghiệm, rất khó để thay đổi phần mềm. Khách hàng sẽ phải trả nhiều tiền hơn và chờ lâu hơn nếu họ muốn thực hiện thay đổi muộn này.

Để tránh điều này, các nhà phát triển mô hình thác đôi khi xây dựng trong các điểm phản hồi của khách hàng giữa các giai đoạn được nêu ở trên, để điều chỉnh dự án khi họ có nhu cầu.

Nổi bật Tạp chí Thông tin & Truyền thông
Đừng bỏ lỡ
So sánh giữa Agile và waterfall
POWERED BY ONECMS - A PRODUCT OF NEKO