Là quyết định ngày phát hành trước khi thu thập tất cả các yêu cầu không nhanh nhẹn?

Tôi mới bắt đầu đọc cuốn sách Áp dụng UML và các mẫu của Craig Larman. Tôi thấy nó rất thú vị vì nó thách thức nhiều điều tôi đã nói trong công việc. Tôi đọc rằng các yêu cầu không được thu thập đầy đủ trong một lần nhanh nhẹn và phải mất nhiều lần lặp để hoàn thành thu thập yêu cầu. Nếu đó là trường hợp, đưa ra một thời hạn thiết lập cứng, đó là điều tôi buộc phải làm trong công việc, rất không nhanh nhẹn, xem xét có thể có một số yêu cầu đột phá mới (hoặc thay đổi yêu cầu giả mạo theo yêu cầu) vào ngày mai?

Hoàn toàn không có vấn đề "Nhanh nhẹn" nào khi có ngày phát hành cố định nếu bạn chuẩn bị di chuyển một trong hai cạnh khác của "tam giác sắt": các yêu cầu đối với những gì cần có trong bản phát hành đó hoặc tài nguyên bạn có sẵn . Bạn không thể sửa cả ba - và trong thực tế, phần "tài nguyên" của tam giác rất thường không linh hoạt hoặc không hiệu quả để sửa đổi.

Nếu có một yêu cầu mới lớn vào ngày mai, điều đó tốt miễn là doanh nghiệp sẵn sàng chấp nhận yêu cầu đó có thể không đưa ra ngày phát hành - tức là nó trượt sang phiên bản tiếp theo.

Tôi nghĩ vấn đề ở nhiều trại Agile là thời hạn cuối cùng. Rủi ro với thời hạn là bạn cho rằng bạn biết cần phải làm gì. Như bạn chỉ ra, bạn không thể có thời hạn cho một điều chưa biết.

Những gì được mô tả trong câu trả lời của Philip là thời hạn ít hơn nhiều so với một ràng buộc. Chúng tôi có thể nói rằng chúng tôi có tài trợ cho đến tháng 3 và vì vậy chúng tôi phải tạo ra sản phẩm tốt nhất có thể trong thời gian đó.

Để đưa ra một sự tương tự, giả sử tôi yêu cầu bạn đi đến câu chuyện tạp hóa và mua tất cả các cửa hàng tạp hóa trong tuần và, trước khi bạn đi hoặc xem bất kỳ giá nào, tôi muốn bạn cho tôi biết chính xác những gì bạn sẽ chi tiêu. Hơn nữa, bạn sẽ bị phạt nếu bạn sai. Bạn sẽ làm chính xác những gì mọi người làm với thời hạn dự án - bạn sẽ chọn một số ở cấp cao của những gì bạn nghĩ rằng phạm vi có thể là vì nó có khả năng bị phạt thấp nhất. Bây giờ, hãy để chúng tôi nói tôi nói với bạn điều này là không thể chấp nhận được và bạn phải mua những thứ giống như bạn đã lên kế hoạch, nhưng bạn phải làm điều đó với giá rẻ hơn 50 đô la, nếu không. Bây giờ bạn có thể làm gì? Bạn có thể từ chối, bạn chỉ có thể hoãn lại cuộc tranh luận cho đến sau khi bạn mua sắm, hoặc bạn có thể tìm cách gian lận tình hình. Đây là những gì xảy ra trong nhiều tổ chức với thời hạn được đặt ra cho những ẩn số.

Bây giờ, khi thấy toàn bộ tình huống này không lành mạnh như thế nào, Agile chỉ nói "Nếu bạn có ngân sách, tôi có thể hứa sẽ tham gia theo đó và sẽ cung cấp cho bạn những bữa ăn tốt nhất có thể trong tuần này trong sự hạn chế đó". Đó là một cuộc trò chuyện lành mạnh hơn để có.

Agile là một kỹ thuật, không phải là kết quả. So với việc cắt cỏ, một lần lặp giống như một dòng cỏ mà bạn đã cắt. Nếu ai đó nói "cắt toàn bộ bãi cỏ của bạn trong 15 phút" và bạn đang sử dụng nhanh nhẹn, có lẽ bạn sẽ hoàn thành 30% vào cuối. Sau đó, bạn sẽ lặp lại một số chi tiết sau và hoàn thành nó.

Bạn có thể có một ngày phát hành theo kế hoạch mà không có vấn đề. Chỉ cần chắc chắn rằng vào ngày đặc biệt này, bạn không có kết thúc thua. Bạn nên có một sản phẩm có thể được vận chuyển vào cuối mỗi lần chạy nước rút, nhưng thường thì sẽ không có hại gì nếu bạn không làm vậy; đó là một mục tiêu tập trung vào công việc thay vì một yêu cầu. Nếu bạn có một ngày phát hành theo kế hoạch, thì bạn phải có một sản phẩm đáng tin cậy vào ngày đó.

Bạn thường sẽ nhắm đến việc có một sản phẩm chưa được kiểm tra, nhưng hy vọng một thời gian trước khi phát hành theo kế hoạch, sau đó sản phẩm được kiểm tra và sửa lỗi cho đến khi đạt tiêu chuẩn chất lượng, và sau đó nó được phát hành mà không cần phải hoảng sợ. Bản phát hành sẽ chứa bất cứ thứ gì đã sẵn sàng tại thời điểm đó.

Bây giờ có thể không rõ ràng với sếp của bạn rằng bạn cũng nên lên kế hoạch cho ngày phát hành thứ hai, với nhiều tính năng thực sự được triển khai.