Có nghiên cứu nào về Hiệu quả / Hiệu quả của Agile vs Waterfall [đã đóng]

Trong một cuộc họp vào một ngày khác, một tuyên bố đã được đưa ra rằng nhanh nhẹn chỉ hiệu quả hơn 60% trong thời gian phát triển so với thác nước. Tôi không tìm cách xác nhận hoặc bác bỏ yêu cầu này. Tôi rất thú vị trong việc tìm hiểu xem đã có nghiên cứu nào so sánh 2 phương pháp này chưa.

Có nghiên cứu nào ngoài đó so sánh hai?

Cuốn sách "Làm phần mềm: Điều gì thực sự hoạt động và tại sao chúng ta tin vào điều đó" có một số chương về các phương pháp Agile bao gồm XP, Scrum, Phát triển phần mềm động và Lean, với sự hỗ trợ khoa học tốt. Đó là chất lượng cao, như bạn mong đợi từ O'Reilly. Một trong những biên tập viên là Greg Wilson , một tác giả, biên tập viên và người dẫn chương trình khoa học máy tính đáng tin cậy.

Cuốn sách tự tóm tắt nhiều nghiên cứu, bao gồm nhiều nghiên cứu về nhanh nhẹn. Một phần tóm tắt nghiên cứu bao gồm "Hai đầu có tốt hơn một không? Về hiệu quả của lập trình cặp" của Dybå, T.; Arisholm, E.; Sjøberg, DIK; Hannay, JE; Shull, F.; và " Nghiên cứu thực nghiệm về phát triển phần mềm nhanh: Đánh giá có hệ thống " của Tore Dybå và Torgeir Dingsøyr.

Ý nghĩa chung là hầu hết các thực hành nhanh nhẹn đều có lợi, nhưng tác động của lập trình cặp và TDD và những người thuê nhanh nhẹn khác không mạnh như người ta có thể hy vọng. Thậm chí còn có một chú thích đáng lo ngại rằng trên thực tế TDD có thể gây nghiện *.

Cuốn sách là một cách tuyệt vời để tiếp cận với rất nhiều nghiên cứu đã được thực hiện, tất cả trong một tổng thể gắn kết. Có một vài blog và các trang web khác trên web xem xét cuốn sách.

* Đây không hẳn là ý kiến ​​của tôi!

Nhiều như tôi không thích tiêu đề, tôi tin rằng Cân bằng nhanh nhẹn và kỷ luật: Hướng dẫn cho sự bối rối có thể chứa một số thông tin có liên quan đến bạn. Cuốn sách này của hai chuyên gia về quy trình kỹ thuật phần mềm và quản lý dự án phần mềm - Barry Boehm và Richard Turner. Cuốn sách này xem xét các khía cạnh khác nhau của các phương pháp nhanh và theo kế hoạch, so sánh và đối chiếu chúng, và cũng thảo luận về việc tích hợp chúng để đạt được tình huống "tốt nhất của cả hai thế giới".

Phụ lục E của Cân bằng nhanh nhẹn và Kỷ luật chứa nhiều thông tin thực nghiệm liên quan đến chi phí và lợi ích của các phương pháp nhanh và theo kế hoạch khác nhau. Tuy nhiên, dường như không có bất kỳ dữ liệu nào liên quan đến hiệu quả thời gian. Nhưng liếc qua dữ liệu, có vẻ như (tôi nghi ngờ) rằng đây không phải là một hoặc một sự lựa chọn - một số dự án đã giảm nỗ lực, tiến độ nhanh hơn và các khiếm khuyết thấp hơn khi áp dụng các phương pháp nhanh. Tuy nhiên, các dự án khác đã sử dụng. Phần này thảo luận về một số dự án khác nhau trong các ngành công nghiệp khác nhau, loại quy trình họ đã sử dụng và những gì họ đã trải qua trong quá trình thực hiện dự án.

Có rất nhiều nghiên cứu trường hợp được trích dẫn trong Phụ lục E mang lại dữ liệu này. Có quá nhiều thứ để tôi bắt đầu đặt tên ngẫu nhiên, vì nhiều người tập trung vào một ngành cụ thể hoặc thậm chí trong một tổ chức cụ thể. Nếu bạn sẽ xem xét các trường hợp, tôi khuyên bạn nên tìm những trường hợp có bản chất tương tự với nhóm, dự án, tổ chức và ngành của bạn để đưa ra kết luận hợp lý.

Trong Phát triển nhanh: Lịch trình phần mềm thuần hóa , Steve McConnell xác định một số yếu tố cần xem xét khi chọn phương pháp vòng đời: mức độ hiểu biết về các yêu cầu, mức độ hiểu biết về kiến ​​trúc, độ tin cậy mong muốn, quản lý rủi ro, ràng buộc lịch trình, số lượng quy trình trên cao, "sửa chữa khóa học" giữa dự án, khả năng cung cấp cho khách hàng khả năng hiển thị, khả năng cung cấp quản lý với khả năng hiển thị và sự tinh tế của đội ngũ phát triển và quản lý. Cũng có những thứ khác, chẳng hạn như văn hóa tổ chức, nên có lẽ không có một danh sách đầy đủ ở bất cứ đâu.

Ngay cả khi đưa ra cùng một dự án, cũng có yếu tố nhóm. Nếu bạn đưa một nhóm đã phân phối phần mềm một cách nhất quán bằng phương pháp xoắn ốc theo kế hoạch và ném chúng vào Scrum, họ sẽ bị giảm năng suất, tăng cường đập và phải vượt qua mô hình quy trình mới trước khi họ có thể đến xung quanh để thành công. Mặc dù phương pháp khác có thể phù hợp hơn, luôn có doanh nghiệp thực sự cần phải cung cấp phần mềm. Đó là lý do tại sao các nỗ lực cải tiến quy trình thường là những nỗ lực dài hạn và không qua đêm - những thay đổi lớn gây sốc cho một nhóm và (ngay cả khi phương pháp này có thể phù hợp hơn trên giấy) có thể làm giảm năng suất.

Có nhiều thứ hơn là chỉ đơn giản là hiệu quả hoặc hiệu quả của quy trình, và bạn không thể chỉ nhìn vào một ảnh chụp nhanh của cùng một nhóm làm việc trong môi trường theo kế hoạch và môi trường nhanh nhẹn. Bạn cần xem xét bối cảnh công nghiệp và tổ chức, các thuộc tính của dự án, nhóm, khách hàng, v.v. khi đưa ra quyết định.

Dựa trên những gì tôi đọc, tôi sẽ không đồng ý với đánh giá của đồng nghiệp. Tôi chắc chắn rằng bạn có thể tìm thấy một số nghiên cứu điển hình ở đâu đó trong đó một dự án nhanh có hiệu quả thấp hơn 60% liên quan đến một số chỉ số hiệu suất so với một dự án theo kế hoạch tương tự. Tuy nhiên, cũng có những nghiên cứu cho thấy rằng agile mang lại nỗ lực ít hơn 80%, thời gian ít hơn 50% và sự hài lòng của khách hàng cao với sản phẩm.

Tôi không có nghiên cứu nhưng tôi muốn truyền đạt kinh nghiệm của mình.

Hiệu quả của bất kỳ phương pháp được đề cập nào phụ thuộc nhiều vào các nhà phân tích.

Khi bạn đã có một chủ sở hữu sản phẩm tuyệt vời, thì ví dụ SCRUM chắc chắn nhanh hơn cách tiếp cận thác nước với thông số xấu.

Agile với chủ sở hữu sản phẩm xấu chắc chắn chậm hơn thác nước với thông số kỹ thuật tuyệt vời.

Tuy nhiên, thường xuyên hơn không, chúng tôi không biết sớm các yêu cầu chính xác và các phương pháp nhanh có chu kỳ phản hồi nhanh hơn. Điều này có nghĩa là, trong địa hình không chắc chắn, nhanh nhẹn là một phương pháp tốt hơn để cung cấp một sản phẩm chất lượng cao với chi phí hợp lý. Có rất nhiều lợi thế khác, ví dụ, các dự án nhanh sẽ dễ bị hủy hơn khi chúng không hoạt động và do đó có thể giảm tổn thất đến mức tối thiểu.

Người ta có thể nói rằng các phương pháp nhanh nhẹn làm giảm rủi ro, trong khi thác nước, ngay cả khi đôi khi có thể nhanh hơn, có thể là một canh bạc tiền tệ.

nhanh nhẹn chỉ hiệu quả 60% trong thời gian phát triển

Thật.

Nhưng, đó là một phép đo khập khiễng.

Phương pháp nhanh nhẹn thường cung cấp giá trị thực sớm hơn.

Thác nước chỉ đơn giản là dính vào một lịch trình bất kể những gì được giao và thường không mang lại giá trị gì cho đến khi một khoảng thời gian khổng lồ được thông qua.

Thêm nữa.

Bạn có thể đo "thời gian phát triển" tách biệt với "thời gian phát triển và thử nghiệm".

Agile thường bao gồm thử nghiệm. Vì vậy, nó có vẻ chậm hơn.

Phát triển thác nước có thể được tách ra khỏi thử nghiệm. Vì vậy, mã là "sẵn sàng để kiểm tra" sớm hơn. Nhưng không "thực hiện" cho đến sau này.

Vì thế. Họ hoàn toàn đúng. Đối với những gì họ đo lường.