Làm thế nào thư giãn (hoặc không) nên chạy nước rút?

Điều gì nên là thái độ đối với việc hoàn thành những câu chuyện được gán cho một lần chạy nước rút? Rõ ràng là bạn muốn ưu tiên hoàn thành chúng trong giai đoạn nước rút, nhưng với tôi, toàn bộ vấn đề của sự nhanh nhẹn là phải năng động: Bạn không muốn cố tình trì hoãn hoặc làm cho nó "ok" để bỏ lỡ việc hoàn thành câu chuyện của người dùng trong lần chạy nước rút, nhưng tại cùng lúc khi những điều bất ngờ xuất hiện và những câu chuyện đó không được hoàn thành và được đẩy sang giai đoạn nước rút tiếp theo, bạn không muốn cảm giác rằng mình đã làm gì đó sai. Đó không phải là một kinh nghiệm đáng sợ hoặc tiêu cực, phải không?

Là kinh nghiệm tiêu cực / đáng sợ có thể chấp nhận cho các cam kết nước rút bị bỏ lỡ? Các nhà phát triển có nên chịu trách nhiệm cho các cam kết nước rút bị bỏ lỡ khi các nhiệm vụ bất ngờ xuất hiện phải được xử lý (Ví dụ: hỗ trợ sản xuất)?

Bạn nên hoàn toàn nhắm đến việc hoàn thành các mục trong một lần chạy nước rút.

Một trong những lợi ích chính của SCRUM là nó mang lại cho dự án một 'nhịp đập'.

Bạn ưu tiên, chọn các mục trong danh sách, bạn phân phối chúng, bạn demo chúng, bạn phản ánh cách chúng đi, sau đó bạn làm lại theo chu kỳ có thể điều chỉnh được.

Tất cả các kế hoạch, ước tính và ưu tiên được dựa trên khái niệm này. Rằng chúng ta có thể và sẽ cam kết thực hiện các điểm X trong giai đoạn nước rút, và theo thời gian, có thể thiết lập một vận tốc mà chúng ta có thể sử dụng để lập kế hoạch tốt hơn.

Nếu bạn quá bình thường về nội dung và các cam kết trong lần chạy nước rút của mình thì SCRUM chỉ bị phá vỡ theo ý kiến ​​của tôi và bạn sẽ mất rất nhiều lợi ích.

Tất nhiên thế giới thực đôi khi sẽ có điều gì đó để nói về điều này, nhưng đó nên là ngoại lệ chứ không phải là quy tắc ....

Điều quan trọng là cần có trách nhiệm giải trình xung quanh việc không hoàn thành các câu chuyện.

Điều đó có nghĩa là cần phải có một lý do vững chắc tại sao một câu chuyện chưa hoàn thành và lý do này được tính đến trong kế hoạch dự án trong tương lai để nó không lặp lại.

Lý do này cần nhiều hơn một "công cụ mơ hồ".

Ví dụ: nếu một câu chuyện chưa hoàn thành do một thành viên trong nhóm phải giải quyết vấn đề sản xuất, thì khả năng này cần được giải quyết trong các lần lặp lại trong tương lai - bằng cách lập kế hoạch cho ít giờ hơn từ thành viên nhóm này hoặc sắp xếp cho bảo hiểm khác.

Nếu lý do có thể tránh được với sự siêng năng hơn hoặc làm việc chăm chỉ hơn, thì, vâng, trách nhiệm này có thể hơi đau đớn. Hy vọng rằng, nỗi đau thuộc về "Đây là điều chúng ta cần làm tốt hơn vào lần tới" chứ không phải là sự đa dạng "Bạn không làm việc của mình".

Đó không phải là một kinh nghiệm đáng sợ hoặc tiêu cực, phải không?

Nếu nó xảy ra một hoặc hai lần, thì không, đó không phải là một trải nghiệm tiêu cực. Nếu nó xảy ra thường xuyên, bạn có một vấn đề. Đội sau đó luôn luôn quá tải. Hãy ước lượng tốt hơn và suy nghĩ kỹ về những gì bạn cam kết cho một lần chạy nước rút, nhưng đừng trở nên lo lắng.

Chạy nước rút thư giãn có nghĩa là bạn đã có một sự thiếu sót.

Chạy nước rút không liên quan có nghĩa là bạn đã có một sự cố gắng quá mức.

Tôi chỉ cung cấp những gì tôi cam kết và cố gắng cải thiện tốt hơn. Chỉ trong những trường hợp đặc biệt, tôi mới chuyển một câu chuyện sang lần chạy nước rút tiếp theo. Tôi thích có áp lực nhẹ mỗi ngày hơn là có một áp lực khủng khiếp trong thời gian ngắn trước một số thời hạn.

Dựa trên kinh nghiệm của tôi - Giống như mọi thứ khác nhanh nhẹn, chúng tôi thích nghi với hệ thống phản hồi liên tục bao gồm cả ước tính.

Bạn có thể bỏ lỡ thời hạn cho lần chạy nước rút đầu tiên (bắt đầu dự án) nhưng bạn TÌM HIỂU điều đó đã sai (ước tính dưới mức, không biết điểm mạnh của đội, v.v.). Sau đó, bạn lấy thông tin phản hồi và đưa nó đến lần chạy nước rút tiếp theo và bạn sẽ có được ước tính tốt hơn.

Từ kinh nghiệm của tôi, đã 11 tháng trong dự án nhanh nhẹn mới của chúng tôi, chúng tôi hiếm khi bỏ lỡ thời hạn nếu chúng tôi bỏ lỡ nó. Nhưng chúng tôi đã bỏ lỡ thời hạn cho lần chạy nước rút đầu tiên vì chúng tôi không biết tốc độ và sức mạnh của các thành viên trong nhóm.

Một số người cho rằng "phân bổ" nhiều thời gian hơn cho lần chạy nước rút đầu tiên để khắc phục vấn đề nước rút đầu tiên.

Thật thú vị khi xem câu trả lời / bình luận ở đây. Trên mọi dự án (loại) nhanh nhẹn mà tôi đã thực hiện, ưu điểm chính là phân tán áp lực thời hạn trên nhiều thời hạn nhỏ hơn là một cuộc tử chiến hạn chót vào cuối dự án. IMO, chạy nước rút nên được thực hiện nghiêm túc. Bất kỳ sự trượt dốc nào trong thời hạn hoặc chức năng được cung cấp phải được xem là những vấn đề tiềm ẩn trong quản lý hoặc phát triển dự án.

Các quy trình nhanh nhẹn thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển và người dùng sẽ có thể duy trì tốc độ không đổi vô thời hạn. - Nguyên tắc đằng sau Tuyên ngôn Agile

Nếu đó là một trải nghiệm đáng sợ hoặc tiêu cực, và nó xảy ra mọi lúc, bạn có vấn đề. Phát triển phần mềm nên được vui vẻ. Không tiêu cực hay đáng sợ.

Tuy nhiên, nếu nhóm đang cam kết hoàn thành một số câu chuyện trong một lần chạy nước rút và liên tục không phân phối, bạn cũng gặp vấn đề. Vấn đề này gần như chắc chắn sẽ không được giải quyết bằng cách tạo thêm áp lực cho đội để hoàn thành các câu chuyện. Nếu vấn đề là do các yếu tố bên ngoài, những người cần phải được quản lý. Nếu nhóm quá cam kết, ScrumMaster có thể hướng dẫn nhóm hướng tới cam kết ít điểm câu chuyện hơn. Có thể có nhiều lý do và mỗi lý do có thể cần được giải quyết khác nhau. Một đội ngũ năng động và có động lực nên có nhiều động lực để tiến về phía trước.

Lý tưởng nhất là bất kể vấn đề là gì, nó được nêu ra trong quá trình hồi cứu và cố định.

Không nên quá phức tạp khi nhóm tìm ra những gì họ có thể đạt được trong khoảng thời gian chạy nước rút tương đối ngắn và sau đó hoàn thành nó (một câu chuyện thỉnh thoảng được đẩy sang lần chạy nước rút tiếp theo là OK, vận tốc có thể dao động, mọi thứ thay đổi, v.v. .). Nếu bạn không thể có được điều đó một cách hợp lý suôn sẻ sau một vài lần chạy nước rút, bạn đang làm gì đó sai.

Nó thực sự phụ thuộc vào dòng thời gian của bạn.

Đôi khi bạn sẽ CẦN phải hoàn thành tất cả các câu chuyện, hoặc hầu hết trong số chúng. Mặc dù Agile cung cấp một số tính linh hoạt, bạn cũng sẽ cần hoàn thành dự án, có thể theo thời gian chặt chẽ .. Vì vậy, hầu hết các câu chuyện được thực hiện sẽ cho phép bạn hoàn thành dự án của mình kịp thời.

Mặc dù vậy, những thứ sẽ xuất hiện sẽ ngăn bạn hoàn thành mọi câu chuyện, mọi lần chạy nước rút.

Nếu sản phẩm nằm trên dòng thời gian và những câu chuyện quan trọng bị bỏ lỡ, điều đó sẽ khiến sản phẩm bị trễ. Sản phẩm bị trễ trong một số trường hợp có thể ảnh hưởng đến vị thế cạnh tranh của công ty. Vì vậy, trong trường hợp đó, bạn có thể MUỐN đó là một trải nghiệm tiêu cực khi thiếu những câu chuyện - nó có thể khiến bạn hoàn thành nó vào lần sau.

Khi dùng đúng liều, căng thẳng là tốt. Bạn muốn không muốn lấy đi mọi căng thẳng, bạn chỉ muốn lan tỏa nó kịp thời hơn. Ngay cả khi bạn chơi trò chơi yêu thích của bạn, bạn sẽ có một số lượng giảm căng thẳng và cảm giác tiêu cực. Bạn thực sự nhận được nhiều năng lượng hơn từ nó.

Một đội nên thực sự cảm thấy tồi tệ về những câu chuyện bị bỏ lỡ. Nó sẽ cung cấp cho họ năng lượng để thay đổi một cái gì đó vào lần tới (làm việc khác đi hoặc lên kế hoạch ít câu chuyện hơn, cả hai đều tốt). Họ cũng nên cảm thấy tự hào khi họ thực hiện câu chuyện của họ, tất nhiên.

Bạn cũng đề cập đến các nhiệm vụ bất ngờ (hỗ trợ sản xuất). Điều đó làm tăng cờ đỏ với tôi. Đáng lẽ phải có một hộp thời gian đồng ý cho tất cả các vấn đề không liên quan đến câu chuyện. Nếu không, trò chơi không công bằng, nhóm cảm thấy bất lực và cảm giác tiêu cực không được sử dụng để cải thiện.

Bạn nên xem xét các yếu tố khiến các cam kết của bạn thất bại và cố gắng khắc phục chúng. Một lượng lớn các sự kiện ngẫu nhiên sẽ tiếp tục gây rối cho nước rút của bạn làm cho tốc độ của bạn không thể đoán trước. Hoặc khắc phục các nguyên nhân của điều này hoặc giới thiệu sự chậm chạp trong nước rút của bạn. Tôi thích sửa chữa.

Dù bằng cách nào, nhóm không thể chịu trách nhiệm nếu công việc của họ bị xáo trộn bởi các yếu tố bên ngoài. Sử dụng hồi tưởng để xem xét điều này.