Liệu muộn có bất kỳ ý nghĩa trong phương pháp Agile?

Điều này xuất phát từ một số câu trả lời và nhận xét về một câu hỏi khác (câu hỏi này ).

Tôi đã làm việc chủ yếu với các dự án thác nước và trong khi tôi làm việc với các dự án đặc biệt có hành vi nhanh nhẹn và đã đọc một chút công bằng về sự nhanh nhẹn, tôi nói rằng tôi chưa bao giờ làm việc trong một dự án nhanh "đúng đắn" .

Câu hỏi của tôi là khái niệm "muộn" có ý nghĩa gì trong nhanh nhẹn không, nếu có thì sao?

Lý do của tôi là với sự nhanh nhẹn, bạn không có kế hoạch trả trước và bạn không có yêu cầu chi tiết ngay từ đầu. Bạn có thể có một mục tiêu cấp cao trong tâm trí và một ngày đáng chú ý gắn liền với nó nhưng cả hai có thể thay đổi (có khả năng ồ ạt) và không chắc chắn.

Vì vậy, nếu bạn không biết chính xác những gì bạn sẽ cung cấp về cơ bản cho đến khi bạn cung cấp nó và người dùng chấp nhận nó, và nếu bạn không có lịch trình vượt quá lần chạy nước rút tiếp theo, làm thế nào bạn có thể bị trễ theo bất kỳ cách nào thực sự có ý nghĩa gì?

(Rõ ràng tôi hiểu rằng một cuộc chạy nước rút có thể vượt qua nhưng tôi đang nói về điều đó.)

Nói rõ hơn là tôi (cá nhân) hài lòng với giả định rằng các dự án thác nước đúng giờ (thậm chí tương đối lớn) có thể dựa trên thực tế tôi đã thấy chúng và đã tham gia vào chúng - thậm chí chúng không dễ dàng hoặc phổ biến nhưng họ có thể

Đây không phải là về gõ nhanh, đó là về tôi hiểu nó. Tôi luôn thấy lợi ích của việc nhanh nhẹn là không liên quan gì đến thời hạn hoặc ngân sách (hay chỉ là gián tiếp), điều đó có liên quan đến phạm vi - nhanh nhẹn mang đến gần hơn những gì thực sự quan trọng thay vì những gì nhóm dự án nghĩ là quan trọng trước khi họ ' đã thấy bất cứ điều gì.

Tôi không đồng ý rằng một dự án Agile không có kế hoạch trả trước.

Kinh nghiệm của tôi là các nhà phân tích kinh doanh đã dành một lượng thời gian hợp lý để làm việc trong các cuộc họp thiết kế với khách hàng và nhà phát triển để đưa ra một danh sách chi tiết các yêu cầu có thể đạt được được trình bày dưới dạng câu chuyện của người dùng. Chúng sau đó được chia thành các nhiệm vụ với các ước tính phù hợp được đính kèm bởi các nhà phát triển có kinh nghiệm.

Khi các nhiệm vụ quan trọng nhất đã được xác định khi bắt đầu chạy nước rút / lặp thì mã hóa có thể bắt đầu. Quá trình lựa chọn này xác định ý nghĩa của việc lặp trong dự án tổng thể ("Chúng tôi đang xây dựng quy trình đăng nhập"). Nhiều người ghi nhớ của nhóm bắt đầu với các nhiệm vụ khác nhau cần thiết để thực hiện câu chuyện người dùng đó.

Vào cuối vòng lặp, tất cả các câu chuyện của người dùng cho lần lặp đó sẽ hoàn tất hoặc bạn đã trễ . Tương tự, sự phát triển sẽ có thể dừng lại ở cuối mỗi lần lặp và sản phẩm được phát hành. Nó có thể không hoàn chỉnh về tất cả các câu chuyện của người dùng, nhưng những câu chuyện người dùng được yêu cầu trong lần lặp lại đã hoàn tất và sản phẩm có thể hoạt động đến những giới hạn đó.

"muộn" trong một phương pháp nhanh có nghĩa tương tự như trong phương pháp thác nước: các ước tính sai, phạm vi quá lớn so với thời gian quy định, xuất hiện những khó khăn bất ngờ, khách hàng không đáp ứng đủ, các lập trình viên lười biếng, các máy bị hỏng, con chó của bạn đã ăn mã byte của tôi, v.v.

bạn học hỏi từ nó và điều chỉnh cho lần lặp tiếp theo

sự khác biệt là điều này có thể xảy ra cứ sau 2-4 tuần, vì vậy các bài học được học và quá trình được điều chỉnh nhanh chóng

Có, nhưng sẽ chỉ mất 1 tháng để biết bạn sẽ không đạt được 9 tháng huyền thoại-cuối cùng-dự án-dự án thay vì 9 tháng.

Lý luận của bạn dựa trên giả định rằng các kế hoạch trả trước và các yêu cầu chi tiết cho các dự án lớn là có thể. Không chắc chắn có rất nhiều bằng chứng để hỗ trợ điều đó. Có lẽ tất cả những câu chuyện kinh dị chỉ là giai thoại? Bất kỳ nhà phát triển nào cũng thích làm việc với các thông số kỹ thuật đầy đủ và không bao giờ thay đổi mà khách hàng hoàn toàn đồng ý và hiểu rõ.

Bất cứ khi nào bạn thực hiện một cam kết của một số loại, bạn có nguy cơ bị trễ. Điều đó áp dụng cho nhanh nhẹn là tốt.

Nhưng chúng tôi biết bạn không thể dự đoán tương lai và chúng tôi biết khách hàng sẽ liên tục thay đổi suy nghĩ của mình và chúng tôi đồng ý rằng đó là một điều tốt. Nếu chúng ta chấp nhận điều đó, chúng ta cũng phải chấp nhận rằng tất cả các cam kết là khá nhiều luôn luôn sai, điều này, đến lượt nó, làm cho câu hỏi về độ trễ dễ trả lời: Chúng ta luôn sai (đến sớm hoặc trễ). Tất cả chỉ là vấn đề đoán, cho dù được đánh bóng tốt đến đâu. Tung đồng xu.

Đây là điều mà chúng tôi với tư cách là nhà phát triển đơn giản phải chấp nhận và từ quan điểm đó cố gắng tìm cách khác để làm việc, một cách mà vấn đề độ trễ được thực hiện ít quan trọng hơn nhiều. Một sự thay đổi về quan điểm. Tôi nghĩ rằng cách để làm điều đó là tập trung vào việc cung cấp phần mềm làm việc càng sớm càng tốt, với tùy chọn bỏ việc khi khách hàng hài lòng.

Và đó là những gì nhanh nhẹn là tất cả về. Một cách thông minh để quản lý khái niệm không thoải mái này rằng độ trễ là một thực tế và chúng ta chỉ đơn giản là phải đối phó với nó tốt nhất có thể.

Ví dụ, bạn đến trễ khi bạn không thực hiện được các cam kết bạn đã thực hiện khi bắt đầu lặp lại hiện tại. Điều này được mong đợi và bạn nên học hỏi từ điều này và điều chỉnh quy trình của bạn để bạn ít có khả năng thất bại trong lần lặp lại tiếp theo. Cách tốt nhất để xử lý việc này là giữ các lần lặp càng nhỏ càng tốt.

Để lập kế hoạch lặp lại, hay còn gọi là lập kế hoạch phát hành, bạn sử dụng vận tốc được tính từ các lần lặp hoàn thành và ngoại suy dữ liệu để dự đoán ngày phát hành trong tương lai. Tôi đề nghị bài viết của James Shores hoặc của riêng tôi (ngắn hơn) để biết thêm chi tiết về điều này. Lưu ý rằng đó không bao giờ là một cam kết chắc chắn và hơn thế nữa "chúng tôi chắc chắn 80% rằng chúng tôi sẽ hoàn thành các tính năng tiếp theo trước ngày đó". Điều này có thể (sắp xếp) dẫn đến việc bạn đến trễ, nhưng cam kết chỉ là xác suất, không phải là sự thật.

Bây giờ ngang với điều này với lời hứa cơ bản là nhanh nhẹn rằng bạn sẽ luôn sẵn sàng phát hành phần mềm hoạt động, tính năng hoàn chỉnh hay không. Điều này mang lại cho khách hàng sự tự do để ngừng phát triển khi anh ta nghĩ rằng hệ thống này đủ tốt, điều này có thể xảy ra sớm hơn rất nhiều so với dự đoán. Nó cũng khuyến khích đưa dự án theo hướng mới dựa trên phản hồi thực từ lần lặp mới nhất.

Các điểm trên phải đủ để mọi khách hàng có toàn quyền kiểm soát sự phát triển và tôi hy vọng rằng câu trả lời cho câu hỏi về độ trễ trong các phương pháp nhanh.

Có hai loại "trễ" trong Agile SCRUM>

1. Thực hiện - Các câu chuyện không được "Hoàn thành" khi kết thúc giai đoạn nước rút, các nhà phát triển "cam kết" hoàn thành PBI, vì vậy khi nó không được thực hiện, nó có thể được coi là thực hiện.

2. Lộ trình - Giả sử tổ chức của bạn có lộ trình và giả sử nó có ngày, nếu các giao hàng chính cho những ngày đó bị bỏ lỡ, điều đó có thể được coi là "trễ".