Helpex - Trao đổi & giúp đỡ Đăng nhập

Agile vs. Waterfall - Chọn cái nào?

Với sự cạnh tranh ngày càng tăng để cung cấp sớm và hiệu quả, các tổ chức thường xuyên phải đối mặt với các quyết định về phương pháp luận tốt nhất để sử dụng cho việc phát triển phần mềm. Quyết định không phải lúc nào cũng là một nhiệm vụ dễ dàng. Dự án là một công việc mang lại giá trị gia tăng cho khách hàng hay nó là một công việc mang lại giá trị gia tăng cho doanh nghiệp? Hoặc là không và không thêm gì ngoài chi phí.

Lưu ý đến những yếu tố này, chúng tôi đã quyết định so sánh trực tiếp hai trong số các phương pháp luận phát triển phần mềm được sử dụng rộng rãi nhất (Agile vs Waterfall) và đánh giá nơi mỗi phương pháp có thể được sử dụng tốt nhất.

Agile là gì?

Agile là một phương pháp tiếp cận hiện đại, tinh gọn để phát triển phần mềm, được tạo ra về cơ bản như một giải pháp đáp ứng những hạn chế của các phương pháp luận trước đây. Với tên gọi, Agile nhấn mạnh vào việc phân phối sớm sản phẩm và hỗ trợ các thay đổi thích ứng và linh hoạt có thể được thực hiện tại bất kỳ thời điểm nào trong vòng đời của dự án.

Các phương pháp Agile chứa nhiều dạng khác nhau: Scrum, Extreme Programming (XP), Feature-Driven Development (FDD) và Crystal.

Khảo sát Quản lý Dự án Toàn cầu lần thứ 9 năm 2017 , cho thấy khoảng 71% các tổ chức sử dụng phương pháp Agile.

Cơ chế chính của Agile

Quy trình làm việc Agile hoạt động dựa trên các nguyên tắc sau:

Cách tiếp cận lặp lại - Sự phát triển được phân mảnh thành các khung thời gian ngắn được gọi là lặp lại, kéo dài 2-4 tuần. Mỗi lần lặp lại liên quan đến hiệu suất của nhóm chức năng chéo, tập trung vào việc phân phối thành phẩm vào cuối hộp thời gian nhất định.

Quản lý thay đổi - Mỗi giai đoạn phát triển đều trải qua quá trình xem xét và phân tích tiến độ để đảm bảo sự hài lòng của khách hàng phù hợp với phạm vi của dự án. Các thay đổi được khuyến khích thực hiện và áp dụng bất cứ khi nào được yêu cầu vì mục đích tối ưu hóa và cải tiến.

Ưu tiên - Nhóm làm việc hài hòa hoàn toàn trong tất cả các lĩnh vực của giai đoạn phát triển: lập kế hoạch, thiết kế, mã hóa, thử nghiệm và đánh giá. Mỗi đơn vị trong nhóm liên lạc với đơn vị khác để chia sẻ báo cáo tiến độ của họ và cộng tác làm việc để giảm thiểu các sơ hở hiện có hoặc các rào cản sắp xảy ra.

Vòng đời phát triển nhanh

Vòng đời phát triển Agile là sự phân chia công việc được thực hiện thành sáu bước sau:

Kế hoạch: Khi bức tranh lớn hơn cho phạm vi dự án được hoàn thiện, phác thảo được chia thành các mục tiêu nhỏ hơn, dễ đạt được. Mỗi mục tiêu này sau đó được chỉ định cho các lần lặp lại có các mục tiêu và tính năng dành riêng cho chúng.

Phân tích: Trong giai đoạn phân tích, nhóm cùng nhau phác thảo các yêu cầu chính của dự án. Các cuộc họp giữa các bên liên quan và các nhà quản lý được tiến hành để thực hiện mục đích và nhân khẩu học của việc sử dụng sản phẩm.

Thiết kế: Nhóm bắt đầu công việc thiết kế phần mềm và thiết kế hệ thống bằng cách sử dụng các yêu cầu được thiết lập trong giai đoạn phân tích.

Mã hóa: Đây là giai đoạn thực hiện mà sự phát triển bắt đầu với lần lặp đầu tiên. Các tính năng và khía cạnh của sự phát triển được tạo ra và sau đó được kiểm tra để có chức năng hoàn hảo.

Kiểm tra: Sau khi hoàn thành việc viết mã và phát triển, nó sẽ được kiểm tra các yêu cầu nghiệp vụ và các lỗi có thể xảy ra. Giai đoạn này được đặc trưng bởi tất cả các loại thử nghiệm có thể cải thiện hiệu quả sản xuất như thử nghiệm đơn vị, thử nghiệm hệ thống, thử nghiệm tích hợp và thử nghiệm chấp nhận.

Triển khai: Đây là giai đoạn cuối cùng của một chu trình lặp đi lặp lại, trong đó sản phẩm hoàn chỉnh được triển khai cho khách hàng. Phản hồi của khách hàng được thu thập và mọi thay đổi hoặc cải tiến có thể cần được thực hiện sau đó sẽ được đưa vào chu kỳ lặp lại tiếp theo.

Mô hình thác nước là gì?

Có niên đại từ năm 1970, Waterfall , là một phương pháp phát triển phần mềm truyền thống hoạt động theo một định dạng phát triển tuần tự. Nó bao gồm tiến trình từng bước của quá trình, trong đó mỗi giai đoạn diễn ra theo cách tuyến tính, giúp dễ quản lý và dễ hiểu.

Theo một báo cáo do Gartner công bố vào năm 2015 , 56% các phương pháp quản lý dự án bao gồm phương pháp thác nước.

Cơ chế chính mà Mô hình thác nước vận hành

Mô hình Thác nước hoạt động dựa trên các nguyên tắc sau:

Mục tiêu riêng biệt: Phạm vi dài hạn của dự án được xác định trước khi bắt đầu phát triển. Các nhà quản lý dự án, các bên liên quan và khách hàng đều cần có tầm nhìn rõ ràng về sản phẩm cuối cùng sẽ hình thành như thế nào.

Thời gian Quyền Anh: Mỗi giai đoạn được chỉ định một khoảng thời gian cố định. Sau khi giai đoạn hoàn thành, nó được thực hiện để đóng băng nên không có đường dẫn trở lại bước trước đó.

Phương thức làm việc độc lập: Mỗi nhóm cho một lĩnh vực cụ thể, làm việc theo các mục tiêu riêng lẻ mà ít hoặc không có sự cộng tác với các nhóm làm việc trong các đơn vị khác.

Các khía cạnh chính của phương pháp luận thác nước

Dòng công việc Waterfall có thể được hình dung theo các bước sau:

Yêu cầu: Giống như Agile, đây là giai đoạn đầu tiên sử dụng tất cả các yêu cầu kỹ thuật và phi kỹ thuật của dự án trong một tài liệu yêu cầu cụ thể. Những yêu cầu này hoàn toàn vĩnh viễn xác định vai trò và triển vọng của sản phẩm cuối cùng.

Phân tích: Nhóm tiến hành phân tích các hệ thống và kỹ thuật được sử dụng để tiến hành phát triển sản phẩm.

Thiết kế: Các đặc tả thiết kế như dịch vụ, ngôn ngữ lập trình và lớp dữ liệu được xác định và hoàn thiện.

Viết mã: Để tham khảo các yêu cầu, phân tích và mục tiêu được tạo trong các giai đoạn trước, nhóm phát triển viết mã nguồn trong giai đoạn thứ tư.

Kiểm tra: Trong giai đoạn này, tất cả các loại người kiểm tra, hãy bắt đầu kiểm tra phiên bản hoàn thiện của sản phẩm để tìm bất kỳ lỗi và lỗi nào.

Hoạt động: Giai đoạn hoạt động chịu trách nhiệm triển khai phiên bản hoàn chỉnh và thử nghiệm của sản phẩm ra thị trường.

Ưu và nhược điểm của Agile so với Waterfall

Vì Agile là một phương pháp luận phát triển phần mềm hiện đại, nó cung cấp vô số lợi ích và lợi thế cho các nhóm CNTT chọn làm việc bằng cách sử dụng nó làm phương pháp luận chính của họ.

Trong một cuộc khảo sát trực tuyến của HP với 601 chuyên gia CNTT và phát triển , 54% người được hỏi cho biết rằng sau khi áp dụng các phương pháp Agile, họ đã trải qua sự hợp tác nâng cao giữa các nhóm vốn không tồn tại. Ngoài ra, 43% cho biết thời gian bán hàng trên thị trường đã giảm đáng kể.

Tuy nhiên, không phải tất cả các loại dự án và kịch bản đều phù hợp với các tính năng tự do của Agile.

Hãy cùng xem xét cả ưu điểm và nhược điểm của Agile.

Ưu điểm và nhược điểm của Agile

ƯU ĐIỂM CỦA AGILENHƯỢC ĐIỂM CỦA AGILE
Hỗ trợ thay đổi:

Đây là ưu điểm quan trọng nhất của Agile. Khi quá trình phát triển được thực hiện theo nhiều lần lặp lại, nhóm có quyền truy cập linh hoạt để quay lại giai đoạn trước đó để thực hiện bất kỳ loại và quy mô thay đổi nào.

Thiếu ngày kết thúc:

Bởi vì một dự án nhanh hoạt động trong các chu kỳ lặp lại ngắn, có thể khó ấn định ngày đến hạn xác định cho tiến trình dự án.

Giao sản phẩm nhanh chóng:

Công việc được thực hiện trong các phần nhỏ hơn cho phép các thành viên trong nhóm hoàn thành đúng thời gian. Ngoài ra, vì mã hóa và thử nghiệm được tiến hành đồng bộ với kế hoạch và giai đoạn thiết kế của quá trình phát triển, nên tất cả các thay đổi và cải tiến đều được thực hiện một cách thuần thục với quy trình làm việc đang di chuyển.

Điều này cũng làm tăng khả năng ra mắt sản phẩm sớm.

Tốn thời gian cho các nhà phát triển:

Các chỉnh sửa và cải tiến được thực hiện ở mỗi chu kỳ làm tăng thêm khối lượng công việc cho một phần của nhóm phát triển. Điều này có thể dẫn đến mất thêm thời gian nếu sự cống hiến và năng lực không được các thành viên trong nhóm phát triển thể hiện.

Người dùng - tập trung:

Phản hồi của khách hàng vào cuối mỗi chu kỳ lặp lại cho phép khách hàng tham gia bình đẳng vào kết quả và thiết kế của sản phẩm.

Không thuận lợi cho các đội ở xa:

Vì Nhóm Agile được xây dựng để liên lạc chặt chẽ với nhau, tất cả các thành viên trong nhóm cần ở gần nhau mọi lúc trong quá trình làm việc để thực hiện cấp độ giao tiếp đó một cách hiệu quả.

Tăng cường hợp tác nhóm:

Agile khuyến khích các nhóm làm việc cùng nhau bằng cách thiết lập sự phù hợp với mục tiêu và mục tiêu của họ. Giao tiếp minh bạch và thường xuyên giữa các đơn vị nhóm khác nhau cho phép mức độ năng suất cao hơn và xóa bỏ nguy cơ xung đột.

Sự không chắc chắn của mục tiêu cuối cùng:

Vì Agile không bắt buộc dự án phải có một phác thảo chặt chẽ khi bắt đầu, nên kết quả cuối cùng của sản phẩm có thể hoàn toàn bất ngờ và hoàn toàn khác so với yêu cầu kinh doanh ban đầu.

Tăng năng suất sản phẩm:

Agile tạo điều kiện thuận lợi cho việc cải tiến liên tục. Vào cuối mỗi lần lặp, thành phẩm được kiểm tra các sơ hở và được thực hiện để cải thiện sau mỗi chu kỳ thử nghiệm được hoàn thành.

Các cải tiến cũng là một phần liên tục của quá trình phát triển khi phản hồi của khách hàng được thu thập trong suốt vòng đời của dự án.

 
Linh hoạt và tiến hóa:

Agile hỗ trợ các ý tưởng và quyết định đang phát triển để phù hợp với phạm vi và cửa sổ phát triển của dự án. Điều này đặc biệt có lợi cho các ứng dụng và công cụ phần mềm không có mục tiêu cuối cùng được xác định và có thể thay đổi dựa trên trải nghiệm của khách hàng.

Mặc dù kể từ khi Agile bước vào ánh đèn sân khấu, phương pháp luận của Waterfall giờ đây đã trở nên gần như bị hack nhưng cách tiếp cận tuyến tính để phát triển phần mềm vẫn có một loạt các lợi ích dành riêng cho chính nó.

Dưới đây là một loạt các ưu điểm và nhược điểm của phương pháp Waterfall:

Ưu điểm và nhược điểm của Waterfall


ƯU ĐIỂM CỦA WATERFALLNHƯỢC ĐIỂM CỦA TƯỜNG NƯỚC
Thích hợp cho các dự án định hướng mục tiêu :

Các dự án quy mô nhỏ có phạm vi xác định hoặc các dự án quy mô lớn có các cột mốc cụ thể để đạt được hiệu quả tốt nhất theo phương pháp tiếp cận thác nước.

Không linh hoạt: 

Không cho phép nhà phát triển quay lại giai đoạn trước để thực hiện thay đổi

Thi hành kỷ luật:

Tuy nhiên, không có khả năng quay lại các giai đoạn trước để thay đổi và cải tiến có thể có vẻ cứng nhắc nhưng từ một lăng kính thận trọng hơn, tuy nhiên, nó thấm nhuần kỷ luật, đạo đức làm việc mạnh mẽ hơn và tính tổ chức trong hiệu suất của nhóm.

Không có đầu vào của khách hàng:

Không cho phép phản hồi của người dùng cho đến khi sản phẩm được triển khai

Một lượng tài nguyên tối thiểu:

Yêu cầu số lượng thành viên trong nhóm ít hơn

Thiếu khởi động lại:

Kế hoạch và thiết kế phải được vạch ra khi bắt đầu dự án. Tuy nhiên, nếu bất kỳ loại lỗi thiết kế hoặc lỗi kỹ thuật nào xảy ra, toàn bộ dự án có thể bị đe dọa.

Dễ áp dụng:

Mô hình từng bước không có giai đoạn nào chồng chéo lên nhau rất dễ thực hiện và quản lý.

Không hiệu quả về thời gian:

Vì quá trình phát triển không diễn ra trong khoảng thời gian nhỏ và mỗi bước phải được hoàn thành trước khi bước tiếp theo bắt đầu, nên thời gian cần thiết để hoàn thành một dự án là rất lâu.

Ngoài ra, các bên liên quan, khách hàng và người quản lý dự án không thể có được ý tưởng sơ bộ về kết quả sản phẩm cho đến khi hoàn thành mỗi giai đoạn.

Vì quá trình phát triển không diễn ra trong khoảng thời gian nhỏ và mỗi bước phải được hoàn thành trước khi bước tiếp theo bắt đầu, nên thời gian cần thiết để hoàn thành một dự án là rất lâu.

Ngoài ra, các bên liên quan, khách hàng và người quản lý dự án không thể có được ý tưởng sơ bộ về kết quả sản phẩm cho đến khi hoàn thành mỗi giai đoạn.

Mô hình từng bước không có giai đoạn nào chồng chéo lên nhau rất dễ thực hiện và quản lý.

Agile vs. Waterfall: Sử dụng phương pháp nào và ở đâu?

Dự án có yêu cầu một phạm vi được xác định rõ ràng không?

Không có phương pháp luận đơn lẻ nào có thể hoàn toàn dựa vào để mang lại hiệu quả hoàn hảo về thời gian, hiệu quả, năng suất và quản lý dự án .

Sản phẩm cuối cùng có yêu cầu khách hàng phản hồi liên tục không?

Đó là lý do tại sao tốt nhất là phân tích từng kịch bản dự án dựa trên một loạt các câu hỏi sau:

Việc cung cấp sản phẩm nhanh chóng có quan trọng hơn chất lượng của sản phẩm không?

Có: Sử dụng Waterfall. Không: Sử dụng Agile.

Nhóm phát triển có đủ năng lực để làm việc trong môi trường phát triển và sẵn sàng thích nghi không?

Có: Sử dụng Agile. Không: Sử dụng Waterfall.

Có: Sử dụng Agile. Không: Sử dụng Waterfall.

Có: Sử dụng Agile. Không: Sử dụng Waterfall.

Tuy nhiên, một nhóm các câu hỏi kỹ thuật không phải lúc nào cũng đảm bảo một sự lựa chọn ra quyết định dễ dàng. Đó là lý do tại sao chúng tôi đã chọn ba nghiên cứu điển hình cho chúng tôi biết giữa Agile và Waterfall, tổ chức nào đã áp dụng cái gì và tại sao:

Ví dụ Agile

Tại Cisco , Agile chủ yếu được sử dụng cho các dự án nhỏ với các nhóm nhỏ hơn cho đến 4 năm trước. Các dự án quy mô lớn phức tạp hơn và được vận hành bởi các nhóm lớn hơn vẫn được quản lý thông qua thác nước.

  1. Tỷ lệ hiệu quả loại bỏ khuyết tật giảm 16% so với khi sử dụng thác nước
  2. Giảm 40% các khuyết tật nghiêm trọng và lớn so với Waterfall
  3. Cải thiện khả năng cộng tác và tập trung của Nhóm, so với Thác nước mà các nhóm đã bỏ lỡ thời hạn
  4. Chu kỳ phát hành nhanh vượt quá 3 tháng trong Waterfall

Để thay thế các bản phát hành lẻ tẻ bằng việc phân phối nhanh chóng các tính năng mới, Công nghệ thông tin phần mềm và đám mây của Cisco, đã chuyển sang Khung Agile có quy mô. Nó chỉ định ba nhóm Agile (Agile Release Trains) cho các khả năng, khiếm khuyết & sửa chữa và dự án cho Nền tảng thanh toán đăng ký.

Kết quả của quá trình chuyển đổi này, Cisco đã trải qua các kết quả sau:

Ví dụ về mô hình thác nước

"Mô hình kinh doanh của chúng tôi là bán dự án triển khai và hỗ trợ và phát triển hệ thống ERP của chúng tôi. Mô hình thác nước, mặc dù đó là một cách hoạt động nghiêm ngặt mang lại cho cả chúng tôi và khách hàng kiến ​​thức sau khi mô tả kỹ thuật. Tôi sẽ nói rằng dự án nhỏ hơn, cách chúng tôi làm việc vẫn khá nhanh, mặc dù nó có rất nhiều bước vì bạn biết có thể khách hàng hôm nay phàn nàn rằng họ không thích cách hoạt động của một chức năng này và ngày mai họ đã có phiên bản mới của nó và chúng tôi đã thực hiện tất cả các bước mặc dù có rất nhiều bước bạn có thể khá nhanh với mô hình thác nước. " (Sundell Timo, 2.Oct. 2013).

Devlab , đã được tuyển dụng trong việc cung cấp hệ thống phần mềm ERP mã nguồn mở trong hơn 10 năm. Kể từ khi bắt đầu hành trình kinh doanh, Devlab đã sử dụng phương pháp luận thác nước để phát triển phần mềm và đã sửa đổi nó để phù hợp với nhu cầu của khách hàng.

Tại Devlab, phương pháp luận thác nước đã tự chứng minh là có lợi cho các yêu cầu kinh doanh của họ và không có khó khăn kỹ thuật nào xuất hiện có thể thúc đẩy công ty chuyển sang một phương pháp luận khác.

Ví dụ kết hợp Agile-Waterfall

Sở Y tế Công cộng Jember, Indonesia đã sử dụng mô hình lai giữa Agile-Waterfall , để phát triển hệ thống thông tin giám sát nhiễm vi rút Dengue. Hệ thống thông tin được thiết kế để hỗ trợ các cuộc điều tra dịch tễ học chia sẻ những phát hiện của họ với Sở Y tế Công cộng để có thể thực hiện các biện pháp phòng ngừa trong việc kiểm soát sự bùng phát vi rút sốt xuất huyết.

  1. Việc cung cấp sản phẩm nhanh chóng giúp báo cáo dữ liệu bệnh nhân nhanh hơn, một số vụ bùng phát và ca bệnh được phát hiện tại các bệnh viện và phòng khám khác nhau.
  2. Phản hồi của khách hàng song song đã hỗ trợ các ứng biến sớm trong hệ thống, từ đó hỗ trợ các nhà dịch tễ học xây dựng các chính sách, chiến lược và hướng dẫn kịp thời để ngăn chặn sự lây lan của vi rút sốt xuất huyết do muỗi

Sự kết hợp của các kỹ thuật Agile-Waterfall trong phát triển hệ thống thông tin về cơ bản tập trung vào việc loại bỏ những thiếu sót và làm nổi bật những điểm mạnh của chúng.

Việc sử dụng Hybrid Agile-Waterfall mang lại các kết quả sau:

Phần kết luận

Một cuộc khảo sát của KMPG về Agile Project Delivery 2017 , cho biết 76% người được hỏi ở Bỉ và Hà Lan cho rằng phương pháp Agile sẽ chiếm ưu thế hơn so với phương pháp Waterfall vào năm 2020. Trong khi 85% doanh nghiệp tin rằng thác nước sẽ không bị loại bỏ và sẽ tồn tại.

Truyền thống hay Mới, cả hai phương pháp đều có những điểm yếu không thể bỏ qua. Một lý do chính khiến chúng tôi tin rằng không có người chiến thắng thực sự trong vòng Agile vs Waterfall.

Xem lại Bảng so sánh Agile vs Waterfall dưới đây để tự quyết định.

 YẾU TỐ DỰ ÁN CÁCH TIẾP CẬN TƯỜNG NƯỚC CÁCH TIẾP CẬN AGILE VERDICT
PHẠM VI

Hoạt động tốt khi phạm vi được xác định. Không hỗ trợ các thay đổi.

Thích hợp cho các dự án có phạm vi không xác định. Ủng hộ và tạo điều kiện cho sự thay đổi.

Thay đổi là có lợi vì nó là không thể tránh khỏi. Nhưng thay đổi đi kèm với chi phí, nỗ lực và thời gian bổ sung.

KHÁCH HÀNG ĐẦU VÀO

Chỉ hỗ trợ đầu vào của khách hàng ở các giai đoạn quan trọng.

Khuyến khích phản hồi của khách hàng tại tất cả các điểm trong quá trình phát triển sản phẩm.

Sự tham gia của khách hàng có lợi cho cả hai mô hình.

ĐỘI

Không yêu cầu cộng tác nhóm liên tục. Hiệu suất độc lập được nhấn mạnh hơn.

Khuyến khích làm việc theo nhóm đồng bộ ở tất cả các giai đoạn phát triển sản phẩm. Yêu cầu các đội phải có kỹ năng.

Nỗ lực hợp tác mang lại năng suất cao hơn. Tuy nhiên, bản chất khác nhau của các hợp đồng được giao cho các nhà cung cấp khác nhau không hoạt động tốt trong điều kiện đồng bộ hóa nhóm cao

GIÁ CẢ

Ngân sách được cố định khi bắt đầu, bao gồm các kế hoạch dự phòng cho những rủi ro đã xác định.

Ngân sách không được xác định giống như phạm vi. Có khả năng trở nên đắt đỏ khi xảy ra những thay đổi và rủi ro không lường trước được.

Ngân sách cố định là tốt cho các doanh nghiệp nhỏ. Tuy nhiên, ngân sách cố định cũng có thể gây xáo trộn nếu phát sinh những thay đổi cần thiết.

14 hữu ích 0 bình luận 14k xem chia sẻ

Có thể bạn quan tâm

loading