Có sai khi sử dụng Agile khi yêu cầu của khách hàng không thay đổi gì không?

Tôi đã thấy rất nhiều bài đăng gần đây nói rằng một trong những lý do chính tại sao Agile được sử dụng là vì khách hàng thường thay đổi các yêu cầu.

Tuy nhiên, giả sử khách hàng không thay đổi yêu cầu thường xuyên . Trên thực tế, các khách hàng có các yêu cầu vững chắc mặc dù có thể hơi mơ hồ (nhưng không có gì mơ hồ một cách vô lý), nhưng dù sao tôi cũng sử dụng Agile.

Lý do tại sao tôi sử dụng Agile là vì phần mềm đủ phức tạp để có những chi tiết, vấn đề mà tôi sẽ không nhận ra cho đến khi tôi thực sự phải đối mặt với chúng. Tôi có thể thực hiện một phương pháp lập kế hoạch nặng quy mô đầy đủ như thác nước, nhưng sau đó sẽ mất vài tháng để hoàn thiện tất cả các thiết kế cấp cao và chữ ký mã hóa cấp thấp. Có một thiết kế kiến ​​trúc cố định rất cụ thể cho hệ thống mặc dù.

Câu hỏi của tôi là: Điều này sẽ được coi là xấu, mã hóa cao bồi, chống mẫu, vv ..? Chúng ta phải sử dụng thác nước và lập kế hoạch càng nhiều càng tốt chi tiết trước khi chúng ta bắt đầu viết mã khi các yêu cầu ổn định thay vì điều này 'hãy làm điều đó' trong Agile?

EDIT: Điểm chính ở đây là: chúng tôi KHÔNG THỂ đổ lỗi cho khách hàng thay đổi yêu cầu. Giả sử khách hàng chỉ cho chúng tôi một vấn đề rất cụ thể, cung cấp cho chúng tôi danh sách mong muốn với các chi tiết rất hợp lý và để chúng tôi yên (ví dụ: khách hàng có những việc hữu ích của riêng họ để làm, đừng làm phiền họ nữa. kết thúc khi bạn có một nguyên mẫu làm việc tối thiểu). Sẽ là sai khi sử dụng Agile trong kịch bản này?

Điều này sẽ được coi là xấu, mã hóa cao bồi, chống mẫu.

Câu trả lời ngắn gọn: không. Làm "nhanh nhẹn" một cách chính xác không có nghĩa là "không có kế hoạch", nó có nghĩa là không bao quát mọi thứ.

một trong những lý do chính tại sao Agile được sử dụng là vì khách hàng thường thay đổi các yêu cầu.

Đó là một tuyên bố đơn giản. "Thay đổi yêu cầu" cũng là về cách hiểu của nhóm về các yêu cầu thay đổi. Và đó là về cách các ưu tiên của khách hàng về yêu cầu thay đổi khi anh ta thực sự thấy một vài bản phát hành phần mềm.

Trên thực tế, "nhanh nhẹn" hoạt động IMHO chính xác nhất trong tình huống bạn mô tả - khách hàng có kiến ​​thức tốt về các yêu cầu chung của anh ấy, bạn có thể viết một kế hoạch chung từ đó, điền vào hồ sơ tồn đọng của bạn với nhiều "câu chuyện người dùng", và đã đủ thông tin để chọn kiến ​​trúc hệ thống phù hợp. Việc lặp lại một chiến lược phát triển nhanh sau đó sẽ giúp làm cho "các yêu cầu mơ hồ" chính xác hơn, với rất nhiều phản hồi nếu bạn vẫn đang đi đúng hướng. Nó cũng sẽ cung cấp cho bạn thông tin phản hồi sớm về nỗ lực và chi phí thực sự (đó là điều bạn vẫn có thể thất bại trong cách tiếp cận thác nước, ngay cả khi bạn biết chi tiết từng yêu cầu).

Sử dụng nhanh nhẹn trong tình huống này vẫn là một ý tưởng rất tốt. Có nhiều lợi ích cho nhanh nhẹn, chỉ một trong số đó là phản hồi thường xuyên từ khách hàng và khả năng đáp ứng các yêu cầu thay đổi như bạn đề cập.

Một trong những lý do chính khiến các dự án thác nước nổi tiếng là thất bại là vấn đề 'gần như đã hoàn thành' - thử nghiệm đã tạo ra hàng đống lỗi, để lại một sản phẩm không đáng tin cậy và không biết liệu có cần thêm hai hay hai năm nữa để khắc phục các lỗi còn tồn tại hay không. Agile loại bỏ hoàn toàn rủi ro này. Nếu một dự án nhanh đang chạy quá mức, bạn vẫn có thể cung cấp một phiên bản hoạt động:

A) Cung cấp cho khách hàng mà bạn thực sự ở gần đó thông qua bản demo ("Tất cả những câu chuyện này đã được thực hiện, chúng tôi có thể thực hiện vài lần cuối nếu bạn muốn") và một thời gian nữa sẽ có được chính xác những gì họ muốn.

B) Dù sao cũng đủ tốt để họ hạnh phúc và giải thoát.

Đối với tôi, loại bỏ nguy cơ thất bại hoàn toàn này là lý do đủ để một doanh nghiệp chuyển sang quy trình phát triển nhanh, khả năng xây dựng phần mềm tốt hơn so với kế hoạch ban đầu là đóng băng. Như đã đề cập trong các câu trả lời khác, những yêu cầu 'cụ thể' đó thường vẫn dễ uốn nắn một cách đáng ngạc nhiên.

Agile là lý tưởng nếu bạn cần một vòng phản hồi thường xuyên với khách hàng. Điều này có thể là do các yêu cầu thay đổi thường xuyên, nhưng cũng có thể vì những lý do khác.

Mặt khác, Agile có thể hoạt động tốt như nhau nếu các yêu cầu hoàn toàn ổn định và khách hàng chỉ mong đợi một lần giao hàng lớn, nhưng bạn có thể phải điều chỉnh mọi thứ một chút cho lượng khách hàng tham gia trong thời gian dự án. Điều này có nghĩa là vai trò Chủ sở hữu sản phẩm phải được điền từ bên trong tổ chức của bạn và người đó phải có đủ sự ủy nhiệm từ khách hàng để đưa ra quyết định.

Bạn luôn có thể chia bản phát hành lớn thành các bản phát hành nhỏ hơn (chạy nước rút) và yêu cầu khách hàng phản hồi. Bằng cách này, bạn chắc chắn rằng mình đang làm đúng và khách hàng có thể theo dõi tiến trình của bạn.

Nếu có điều gì đó sai, bạn có thể cung cấp cho khách hàng của bạn cơ hội để sửa chữa bạn sớm hơn, điều này là rất tốt. Tốt hơn hết là sửa lỗi của bạn càng sớm càng tốt, thay vì chỉ cho anh ta một điều nhảm nhí ở cuối và cố gắng sửa nó khi bạn thậm chí không biết bắt đầu từ đâu.