Agile, Waterfall và yêu cầu thay đổi

10

Có ai có vấn đề này của một dự án được định nghĩa là 'Agile' bị tràn ngập bởi những thay đổi yêu cầu không? Tôi làm việc trong một dự án phát triển được chạy trong 4 tuần Sprint nhưng luôn có những thay đổi ở giữa những Sprint này. Nó vẫn được định nghĩa là Agile chứ? Tôi cảm thấy đó là một quy trình Agile phụ - Các yêu cầu của quy trình Agile nên được xác định khi bắt đầu chạy nước rút và được xem xét đến cuối. Tôi có đúng trong này không? Xin vui lòng cho tôi biết kinh nghiệm của bạn trong việc này.

agile requirements

— Aravind A
nguồn

"Yêu cầu thay đổi" là một thuật ngữ lỏng lẻo. Là sự thay đổi bởi vì khách hàng thực sự thay đổi suy nghĩ của họ về một yêu cầu được phê duyệt? Điều gì đã kích hoạt sự thay đổi đó? Nếu điều này tiếp tục xảy ra thì bạn cần kiểm tra lại cách bạn thu thập các yêu cầu. Không có phương pháp SE nào có thể phục vụ cho việc thiếu thu thập yêu cầu thích hợp.

— NoChance

@Emmad Các thay đổi yêu cầu xảy ra trong UAT khi người dùng cảm thấy rằng khả năng sử dụng có thể được cải thiện bằng các phương tiện nhất định. Điều này gây ra sự tích tụ của các vấn đề tiền sản xuất. Điều này chắc chắn không phải là Agile.

— Aravind A

@Aravind A: UAT xảy ra vào cuối giai đoạn nước rút, phải không? Sau đó, bất kỳ ý tưởng / thay đổi mới nào xuất hiện trong UAT thường sẽ trở thành câu chuyện cho lần chạy nước rút tiếp theo (nếu bạn sử dụng nước rút).

— sleske

Có thể những gì @sleske đang đề xuất có hiệu quả với bạn, nhưng đồng thời, tính dễ sử dụng có thể được tạo nguyên mẫu trước nếu người dùng có yêu cầu đặc biệt. Đôi khi, trong các dự án bị ràng buộc bởi tài nguyên, bạn cần kiểm soát tham vọng người dùng của mình.

— NoChance

9

Các yêu cầu của quy trình Agile nên được xác định khi bắt đầu chạy nước rút và được xem xét theo hướng của nó. Tôi có đúng trong này không?

Không, điều này phụ thuộc vào bản chất của dự án (và quy trình).

Có một số mô hình phát triển nhanh trong đó các yêu cầu được cố định trong quá trình chạy nước rút và chỉ nên thay đổi cho lần chạy nước rút tiếp theo (một ví dụ nổi bật là Scrum).

Tuy nhiên, cũng có những quy trình mà sự thay đổi có thể xảy ra gần như bất cứ lúc nào (miễn là khách hàng chấp nhận sự chậm trễ và công việc làm thêm mà thay đổi gây ra). Kanban thường được sử dụng để quản lý các quy trình công việc này (mặc dù Kanban cũng có thể được kết hợp với Scrum).

Mô hình nào bạn theo dõi phụ thuộc vào chi tiết của từng dự án.

Vì vậy, có, nếu khách hàng cảm thấy họ cần khả năng liên tục thay đổi các yêu cầu, thì một quy trình nhanh có thể đáp ứng điều này. Tuy nhiên, khách hàng nên nhận thức được hậu quả của những thay đổi liên tục, và nên hiểu rằng họ sẽ làm chậm dự án.

Điều này tập trung vào các nguyên tắc từ bản tuyên ngôn nhanh - "Cá nhân và tương tác qua các quy trình và công cụ" và "Phản ứng để thay đổi theo kế hoạch".

— sleske
nguồn

Không làm cho quá trình Agile công khai? Ý tôi là, Agility có thể đi bao xa? Nếu một nhà phát triển đáp ứng yêu cầu lần đầu tiên, chắc chắn sẽ có nhu cầu vào lần tiếp theo. Tôi cảm thấy đây là một trong nhiều vấn đề khiến chất lượng mã bị đảo lộn.

— Aravind A

@AravindA Chất lượng mã phải là mối quan tâm riêng biệt và bất kể số lần thay đổi mã bao nhiêu lần, nhóm nên luôn tập trung vào cùng một tiêu chuẩn chất lượng mã. Trong thực tế, chất lượng mã quan trọng hơn vì các yêu cầu và mã thay đổi liên tục.

— maple_shaft

2

@maple_shaft là đúng - chất lượng là (ít nhất là) trực giao với sự thay đổi yêu cầu. Cho tôi một req: Tôi bắt đầu viết mã tốt. Nếu tôi đã hoàn thành và nhận được một req mới, hoặc đã hoàn thành một nửa và nhận được một sự thay đổi, tôi bắt đầu (viết lại) viết mã tốt. Sau khi đã nhấn mạnh tác động đến lịch trình / cam kết / v.v.

— sdg

Các thay đổi yêu cầu có ảnh hưởng lớn đến cách hệ thống được kiến trúc sẽ dẫn đến sự chậm trễ lớn hoặc thỏa hiệp chất lượng. Đó là lý do tại sao bạn nên thực hiện một số phân tích thác nước cũ tốt (cũng có thể lặp đi lặp lại) khi bạn cố gắng giảm nguy cơ xuất hiện "đột ngột" của chúng.

— MaR

@sles Cảm ơn bạn đã giải thích. Tôi nghĩ rằng tôi nhận được nó ngay bây giờ. Tôi nghĩ rằng tôi sẽ phải làm quen với Agile nhiều hơn.

— Aravind A

12

Tôi nghĩ rằng câu hỏi bạn nên đặt ra là: Tại sao bạn lại bị thay đổi bởi các yêu cầu thay đổi? Nguyên nhân phổ biến bao gồm:

Các nhà phát triển không có (đủ) liên hệ với người dùng cuối để họ không thể hiểu nhu cầu của người dùng. Thay vào đó, họ đối xử với các yêu cầu như một khối Rubik trừu tượng - họ tuân theo các chữ cái của các yêu cầu mà không cần cố gắng hiểu tinh thần của họ
Ai đó (ví dụ từ tiếp thị) đang thêm các yêu cầu không có ý nghĩa gì đối với người dùng cuối (nhưng ví dụ: âm thanh tốt trên một tập tài liệu). Vì vậy, có một cuộc chiến giữa các yêu cầu "thực tế" và các yêu cầu "khác" đã chiến đấu trên lưng các nhà phát triển
Phạm vi của dự án không được xác định ("Chà, nếu bạn đang triển khai một trình xử lý văn bản, bạn có thể chỉ cần thêm một mô-đun nhỏ làm kế toán tiền lương của chúng tôi không? Ồ, và Bill từ nhóm phát triển khác đã hỏi nó khó đến mức nào cũng để làm cho trình xử lý văn bản biên dịch mã C ++? ")

Dù vấn đề gốc là gì, bạn cần khắc phục điều đó. Việc nhấn chìm nó dưới các lớp "Agile" (hoặc bất kỳ phương pháp nào khác) sẽ không hoạt động.

— nikie
nguồn

@nike Cảm ơn. Đây chỉ là những gì tôi nghĩ. Điểm thứ ba của bạn phù hợp với kịch bản của tôi. Một số khách hàng chỉ tận dụng công việc 'Agile' nghĩ rằng đó là viên đạn bạc để hoàn thành công việc nhanh hơn.

— Aravind A

9

Ít nhất trong Scrum, dường như là quy trình Agile phổ biến nhất với các loại quản lý hiện nay, phạm vi của một Sprint được cố định. Nếu Sprint Backlog của bạn thay đổi trong giai đoạn nước rút, đó không phải là Scrum, thì đó là sự hỗn loạn. Sprint Backlog nên được tạo khi bắt đầu chạy nước rút và duy trì cố định cho đến khi kết thúc lần chạy nước rút (tại thời điểm đó bạn tạo Sprint Backlog mới cho lần chạy nước rút tiếp theo).

Nếu Product Backlog của bạn thay đổi trong giai đoạn nước rút, thì đó không phải là vấn đề lớn. Các thay đổi trở thành công việc mới được ưu tiên, ước tính và được chọn như bất kỳ yêu cầu nào khác cho lần chạy nước rút tiếp theo. Tuy nhiên, nếu các yêu cầu thay đổi nhiều đến mức Chủ sở hữu sản phẩm phải hủy bỏ chạy nước rút một cách thường xuyên, thì bạn đã gặp rắc rối với số vốn 'T'.

Có lẽ bạn cần nước rút ngắn hơn?

— Adam Jaskiewicz
nguồn

+1 khi cần chạy nước rút ngắn hơn. Quy mô trở lại 2 tuần và xem nếu nó giúp.

— Giăng

1

4 tuần thực sự nghe có vẻ khá dài cho một lần chạy nước rút, đặc biệt là trong một dự án đang bị mất ổn định yêu cầu.

— Carson63000

7

Đối với sự tỉnh táo của các lập trình viên, tốt nhất là nếu các yêu cầu không thay đổi trong quá trình sửa đổi / chạy nước rút.

Trong tình huống của bạn, có hai lựa chọn rõ ràng:

nước rút ngắn
khiến khách hàng đồng ý không thay đổi các yêu cầu trong quá trình sửa đổi / chạy nước rút trừ khi toàn bộ sửa đổi / chạy nước rút bị hủy bỏ và lên kế hoạch lại

Tôi đánh giá cao cả hai .

— Steven A. Lowe
nguồn

3

Vấn đề chính là bạn tin rằng bạn đang sử dụng Scrum nhưng bạn thì không. Đặc biệt là chủ sở hữu sản phẩm của bạn không làm theo nó. Trong Scrum, chạy nước rút là vùng an toàn và không có thay đổi nào đối với các câu chuyện của người dùng đã cam kết trừ khi chạy nước rút hiện tại bị hủy bỏ. Scrum master có trách nhiệm thực thi điều này. Nếu điều này không hoạt động trong môi trường của bạn thì đó là một vấn đề về quy trình = bạn không sử dụng Scrum.

Thay đổi đơn giản nhất bạn có thể làm (nếu bạn muốn theo Scrum) là làm cho cuộc chạy nước rút của bạn ngắn hơn - ví dụ một tuần. Chạy nước rút 4 tuần được coi là tùy chọn trong những ngày đầu của Scrum nhưng ngày nay phổ biến là 1 - 2 tuần và 3 tuần được coi là ranh giới trên. 4 tuần là thời gian rất dài trong môi trường thay đổi.

— Ladislav Mrnka
nguồn