Là phương pháp phát triển phần mềm Waterfall vẫn còn khả thi?

Theo kinh nghiệm của tôi, dường như mô hình Waterfall đã được chứng minh là quá không linh hoạt và không đáp ứng với các yêu cầu thay đổi để được coi là một phương pháp khả thi trong thế giới phát triển phần mềm hiện đại. Sự tăng trưởng và hồ sơ theo dõi đã được chứng minh của các phương pháp lặp đi lặp lại nhanh nhẹn hơn dường như chỉ ra rằng không có lý do tại sao bất cứ ai cũng phải tuân theo một quy trình của các khối cứng nhắc mà ít thay đổi từ khi bắt đầu dự án đến khi giao sản phẩm.

Là phương pháp phát triển thác nước vẫn còn khả thi để cung cấp các hệ thống phần mềm, liên quan đến thời gian, chi phí và chất lượng?

Mô hình thác nước mà bạn đang đề cập không bao giờ có ý định trở thành mô hình quy trình được sử dụng trên một dự án thực tế. Thay vào đó là một người rơm. Nó xác định các giai đoạn và hoạt động chính tồn tại trong các dự án phần mềm và luồng cơ bản nhất giữa chúng. Sự đơn giản hóa cách phát triển phần mềm này là một thiếu sót, và nó thậm chí còn được trình bày theo cách đó.

Từ bài viết Wikipedia:

Mô tả chính thức đầu tiên về mô hình thác nước thường được trích dẫn là một bài viết năm 1970 của Winston W. Royce, mặc dù Royce đã không sử dụng thuật ngữ "thác nước" trong bài viết này. Royce đã trình bày mô hình này như một ví dụ về một mô hình không hoàn hảo, không hoạt động.

Bài viết thảo luận có tiêu đề Quản lý sự phát triển của các hệ thống phần mềm lớn . Trong đó, Royce trình bày mô hình đó trên trang thứ hai. Tuy nhiên, văn bản ngay bên dưới đại diện bằng hình ảnh tiếp tục đọc:

Tôi tin vào khái niệm này, nhưng việc thực hiện được mô tả ở trên là rủi ro và mời thất bại.

Ông đã làm theo điều này với một cuộc thảo luận về các vấn đề với việc thử nghiệm sau khi "hoàn thành" giai đoạn phát triển, và sự thất bại ở đây có thể dẫn đến việc thiết kế lại và thay đổi mã lớn như thế nào, và làm thế nào những điều này có thể dẫn đến sự vượt quá lớn về chi phí và tiến độ. Xuyên suốt bài báo, anh tinh chỉnh mô hình ban đầu thành một mô hình thực sự khả thi trong một dự án. Cuối cùng, anh kết thúc với một mô hình giới thiệu nguyên mẫu, tương tác khách hàng và hoàn thiện các đồ tạo tác - những ý tưởng cuối cùng sẽ trở nên quan trọng đối với phong trào nhanh nhẹn bắt đầu vào cuối những năm 1990 và đầu những năm 2000.

Để trả lời câu hỏi của bạn: Thác nước mà bạn đang hỏi không phải là một phương pháp khả thi để cung cấp các dự án phần mềm với chất lượng hợp lý về thời gian và ngân sách. Tuy nhiên, có những phương pháp dựa trên kế hoạch khác nằm đối diện với nhanh nhẹn có thể và thực hiện các dự án.

Mọi người không sử dụng mô hình thác nước trong sách giáo khoa và có lẽ không bao giờ có.

Đây là một cấu trúc lý thuyết, lý tưởng hóa với mục đích là để bạn suy nghĩ về các bước phát triển hệ thống. Điểm chính của nó là bạn muốn những thay đổi lớn hơn xảy ra càng sớm càng tốt, bởi vì bạn sẽ không bao giờ có thời gian hay tiền bạc để thực hiện một thay đổi lớn một khi có rất nhiều mã được xây dựng.

Mặc dù thực tế đó là một cách suy nghĩ nhiều hơn một quá trình, nó vẫn là cách mà nhiều người - có lẽ là hầu hết các tổ chức đi về xây dựng phần mềm (hoặc nhà, hoặc tàu ngầm, hoặc bất cứ điều gì khác ...).

Trong thế giới thực, bạn không bị cắt đứt hoàn toàn giữa các giai đoạn và đôi khi bạn lặp lại các giai đoạn trước cho các dự án nhỏ. Điều mà phương pháp học nói với bạn không phải là "những điều này không được phép". Những gì nó nói với bạn là "những điều này làm bạn tốn tiền và / hoặc thời gian" - vì vậy hãy cố gắng tránh điều đó trong tương lai.

Agile Snobs (TM) rất tốt và tốt khi nhìn xuống mũi của họ tại các nhà phát triển "lỗi thời" và phương pháp thác nước kỳ quặc, không thể thực hiện được của họ, nhưng thực tế vấn đề là Agile cũng không phải là thuốc chữa bách bệnh. Một số dự án không thể được xây dựng bằng Agile và rất nhiều nhóm cho rằng Agile thực sự chỉ là cẩu thả và không có tổ chức.

Phương pháp không phải là điểm chính. Vấn đề là suy nghĩ về những gì bạn đang làm và tại sao bạn lại làm theo cách đó - và để có được giá trị cao nhất cho khách hàng trong thời gian hợp lý ngắn nhất.

Quá trình thác nước huyền thoại thường được so sánh với nhanh nhẹn chưa từng tồn tại và do đó không thể được coi là đã chết. Các quy trình thác nước thực sự vẫn còn sống và tốt, và xuất sắc trong việc cung cấp đúng thời gian trên phần mềm ngân sách đáp ứng mong đợi của người dùng.

Có lẽ một cách tốt hơn để hỏi những gì bạn đang nhận được là, "khi nào ít lặp đi lặp lại và chính thức hơn tốt hơn?"

Có những tình huống trong trường hợp này:

• Khi các yêu cầu sẽ không thay đổi.

• Khi đáp ứng các yêu cầu mới ít quan trọng hơn so với việc đạt 100% so với yêu cầu ban đầu.

• Khi tất cả các thành phần công nghệ là trưởng thành và hiểu rõ.

Theo một nghĩa nào đó, bạn có thể đi ngược lại với những gì có thể khiến bạn trở nên nhanh nhẹn.

Rất ít kỹ thuật được áp dụng ở mọi nơi. Rất ít không có sử dụng.

Vâng, nó còn sống rất nhiều, mặc dù ngày nay nó là " mô hình V " phổ biến hơn được sử dụng.

Trong cả hai trường hợp, vấn đề mà Agile gặp phải là giải pháp gần như không bao giờ kết thúc, khách hàng có thể tiếp tục yêu cầu thay đổi và sự phát triển sẽ tiếp tục lặp lại giải quyết chúng. Đối với một dự án dựa trên thời gian và chi phí vật liệu, điều này hoạt động rất tốt. Đối với một dự án có chi phí cố định, thì không.

Đối với các dự án có chi phí cố định này, khách hàng hầu như luôn mong đợi các cột mốc được xác định trước sẽ chứng minh tiến độ, tuy nhiên, đây là nhiều loại văn bản chính thức hơn là mã làm việc. Đối với những khách hàng như thế này, các thông số kỹ thuật bằng văn bản trở thành dự án, một trong đó việc phát triển phần mềm là điều cần xem xét thứ yếu (vì họ cho rằng, nếu bạn có một dự án được xác định rõ, phần mềm sẽ dễ dàng phát triển). Các công ty này cũng là những công ty sử dụng nhiều tài nguyên phát triển thuê ngoài, giá rẻ.

Vì vậy, nếu bạn có một số tiền hoặc thời gian cố định, đừng mong đợi các yêu cầu thay đổi hoặc không được phép thay đổi bất kỳ yêu cầu nào và dự kiến ​​sẽ cung cấp một bộ tài liệu bằng văn bản mạnh mẽ, thì các mô hình thác nước là những mô hình duy nhất có lý.

Agile có thể được giới thiệu ở giữa các dự án này để thực hiện phát triển, nhưng bạn vẫn có một giai đoạn tăng cường trong đó các thông số kỹ thuật được tạo ra từ các yêu cầu và giai đoạn đi xuống nơi phần mềm được cài đặt và thử nghiệm tại chỗ. Agile không đáp ứng tốt với những trường hợp này.

Tới ai? Hầu hết các nhà quản lý mà tôi đã xử lý vẫn sử dụng Quy trình phát triển phần mềm Waterfall để lập lịch trình và các cấp độ dường như thích nó để dễ dàng lên lịch.

Thực tế, rất ít nhà phát triển mà tôi biết tin rằng nó hoạt động hoặc thậm chí là hợp lệ.