Tôi mất hơn 5 giờ trong kế hoạch chạy nước rút trong một tuần nước rút dài. Điều đó dường như quá nhiều.

Chúng tôi thảo luận về những điều chi tiết trong kế hoạch chạy nước rút, vì hầu hết các thành viên trong nhóm không phải là cấp cao. Nếu chúng ta không làm điều đó sẽ dẫn đến những sai lầm trong quá trình thực hiện và thiết kế lại trong giai đoạn nước rút.

Chúng ta xử lý việc này thế nào đây?

Bao nhiêu chi tiết tôi nên thảo luận trong quá trình lập kế hoạch để phù hợp với nó chỉ dài 2 giờ mỗi tuần nước rút?

Bạn đã đúng - 5 giờ trong Lập kế hoạch Sprint cho 1 tuần Sprint dường như là một khoảng thời gian dài. Hộp thời gian Hướng dẫn Scrum lập kế hoạch Sprint tới 8 giờ cho Sprint 1 tháng và nói rằng "đối với Sprint ngắn hơn, sự kiện thường ngắn hơn". Nếu bạn xem xét tỷ lệ, mục tiêu tốt có thể là 2 giờ Lập kế hoạch Sprint cho Sprint 1 tuần, nhưng không có bảng thời gian cố định.

Vì vậy, làm thế nào bạn có thể giải quyết một Kế hoạch Sprint dài?

Là một Scrum Master, tôi sẽ thực hiện các bước sau:

Trước tiên, tôi sẽ làm việc với Chủ sở hữu sản phẩm để đảm bảo rằng Product Backlog được đặt đúng. Điều cốt yếu là Tinh chỉnh Backlog và Lập kế hoạch Sprint hiệu quả để đảm bảo rằng công việc quan trọng nhất và sự phụ thuộc của họ nằm ở đầu Product Backlog để Nhóm Scrum có thể tập trung năng lượng của họ vào việc xác định, tinh chỉnh và chuẩn bị công việc phù hợp.

Thứ hai, tôi chắc chắn rằng nhóm đang dành đủ thời gian cho Backlog Refinement. Hướng dẫn Scrum chỉ ra rằng các hoạt động sàng lọc thường chiếm không quá 10% khả năng của Nhóm phát triển. Ví dụ, Nhóm phát triển gồm 4 người làm việc trong một tuần tiêu chuẩn 40 giờ nên lên kế hoạch cho khoảng 16 giờ tinh chỉnh Backlog. Điều này có thể được thực hiện riêng lẻ, trong các nhóm nhỏ hoặc theo nhóm. Tôi đã thấy rằng có một phiên Tinh chỉnh Backlog được lên kế hoạch cho nhóm và sau đó thoát ra để thực hiện bất kỳ nghiên cứu hoặc điều tra hoặc lập kế hoạch nào có xu hướng hoạt động tốt nhất.

Thứ ba, đảm bảo rằng nhóm nhận ra rằng họ không cần phải có được mọi chi tiết ngay trong Kế hoạch Sprint. Mục tiêu của Lập kế hoạch Sprint là tạo ra một kế hoạch để hoàn thành các Mục tiêu của Sprint. Đừng cố gắng thiết kế lớn trước phiên họp Lập kế hoạch Sprint. Hiểu cách các công việc khác nhau phù hợp, phụ thuộc và mục tiêu và sử dụng thời gian bên ngoài các phiên Lập kế hoạch Sprint với đúng người để thực hiện thiết kế, triển khai và thử nghiệm cần thiết để phân phối công việc.

Nhiều bước có thể rơi ra khỏi đây, nhưng đây sẽ là điểm khởi đầu tốt.

Tôi nghe bạn. Quá lâu để chi tiêu! Hy vọng rằng, nhóm của bạn đang thảo luận về điều này trong quá trình hồi tưởng của bạn. Chúng tôi đã thử một vài thí nghiệm với kết quả hỗn hợp:

1. Mọi người đều thực hiện một thiết kế cấp cao trên một vé duy nhất và chuyển nó sang trái hoặc phải xung quanh bàn để sửa đổi, sau đó là đánh giá nhóm về kế hoạch cho mỗi vé. Không phải ai cũng thích điều này, nhưng nó đã buộc các đàn em của chúng tôi thử nó. Một số cá nhân trong nhóm khá vui khi chỉ để người khác thực hiện suy nghĩ và họ chỉ làm theo hướng dẫn. Vì vậy, về mặt tích cực, thí nghiệm của chúng tôi buộc mọi người phải đối mặt với lỗ hổng kiến ​​thức của họ, nó mang lại thách thức tăng trưởng cho đàn em. Về mặt tiêu cực, không phải ai cũng thích được đưa vào vị trí và điều đó không nhất thiết làm giảm thời gian trong cuộc họp. Kế tiếp!

2. Thiết kế ghép đã được cố gắng. Nhóm hai hoặc ba người sẽ chia một vé thành các nhiệm vụ. Toàn bộ đội sẽ xem xét các kế hoạch kết quả. Nó đã đi nhanh hơn rất nhiều, nhưng một số chiếc kén nhỏ có cùng một vấn đề của một người đi cùng trong khi người kia làm công việc thiết kế.

3. Bỏ qua các sự cố nhiệm vụ. Chúng tôi quyết định rằng câu chuyện của chúng tôi được tính trung bình, vì vậy chúng tôi chỉ lãng phí thời gian để cố gắng lôi kéo cả nhóm vào mọi thứ. Kết quả là chúng tôi đã có các cuộc họp lập kế hoạch ngắn hơn nhiều, nhưng công việc thiết kế là điều mà các cặp của chúng tôi phải tự làm khi họ bắt đầu một vé. Nếu đàn em đang làm một vé, mong rằng họ sẽ cần giúp đỡ để vượt qua bước này. Nếu bạn thử điều này, chấp nhận ít câu chuyện hơn trong lần chạy nước rút cho đến khi bạn cảm thấy thoải mái với nó. Ngoài ra, hãy đảm bảo rằng "an toàn" cho các đồng đội của bạn để yêu cầu giúp đỡ khi họ không biết điều gì đó.

Cuối cùng, nó đến với sự trưởng thành của đội. Mọi người cần hiểu khả năng và sở thích của nhau và tin tưởng rằng đồng đội sẽ yêu cầu đầu vào khi họ cần. Sửa chúng trước, nếu bạn không có chúng. Sau đó, giải quyết vấn đề của các cuộc họp không hiệu quả trở nên dễ dàng hơn.

Tôi thích câu trả lời bạn nhận được từ @ Thomas-Owens nhưng tôi cũng sẽ thêm một mục nữa. Bạn đã xem việc thực hiện lập trình cặp như là một phần của việc triển khai Agile của bạn chưa?

Lập trình cặp sẽ giúp (1) dạy một số lập trình viên cơ sở của bạn cách viết mã tốt hơn và (2) trong lập trình cặp, bạn không phải luôn có mọi tính năng thiết kế được đưa ra cho bạn trong kế hoạch chạy nước rút. Với cặp làm việc cùng nhau, một số quyết định thiết kế có thể được đưa ra "một cách tự nhiên" với các lợi ích lập trình cặp được thêm vào.

Nếu bạn có thể giúp các lập trình viên cơ sở của mình học nhanh hơn và bạn biết rằng các mục thiết kế mà bạn không giải quyết trong Sprint Planning sẽ do hai người quyết định, không có lý do gì bạn không thể cắt giảm thời gian bạn dành cho kế hoạch Sprint trong tương lai

Tôi không phải là người hâm mộ cuồng nhiệt và chỉ có khoảng một năm kinh nghiệm thực tế. Vì vậy, sau đây là được đọc với một hạt muối.

Tôi thấy một vài lá cờ đỏ trong những gì bạn viết:

Kế hoạch chạy nước rút 5 giờ

Đây là cách quá dài cho một lần chạy nước rút một tuần.

Mục tiêu của kế hoạch chạy nước rút là AFAIR để

• cho phép nhóm biết những ưu tiên hiện tại là gì và
• để phát triển một kế hoạch chiến đấu cho nước rút sắp tới.

Để làm điều này một cách hiệu quả, mỗi bên phải hiểu Product Backlog items.

Để hiểu được các Product Backlog itemstồn đọng phải được trong tình trạng tốt.

Trong giai đoạn lập kế hoạch cụ thể, Product Backlog itemsđược chuyển thành Sprint Backlog items.

Một nguyên nhân có thể là, những mặt hàng này không được làm rõ / tinh chế đủ.

Một nguyên nhân khác có thể là, các mặt hàng quá phức tạp và chừa chỗ cho quá nhiều sự giải thích.

Thảo luận rất chi tiết trong kế hoạch nước rút

Như đã nói ở trên, giai đoạn thảo luận sẽ ngắn hơn, khi các mục cụ thể hơn.

Mặt khác: lập kế hoạch Sprint mong đợi hành vi chuyên nghiệp từ mọi người tham gia. Điều này bao gồm tránh các cuộc thảo luận về đạp xe .

Có lẽ mọi thứ đã rõ ràng, nhưng ai đó bắt đầu một cuộc thảo luận về đạp xe .

Thêm: Tránh thảo luận về chi tiết thực hiện . Mặc dù mọi ý tưởng kết thúc bằng mã tại một số thời điểm, nhưng đó không phải là điểm của kế hoạch chạy nước rút thảo luận, liệu một mảng đơn giản sẽ thực hiện thủ thuật hay không, sẽ tốt hơn nếu sử dụng danh sách được liên kết.

Vì hầu hết các thành viên trong nhóm không phải là cấp cao

Trong scrum không có sự phân biệt giữa cấp cao và cấp cơ sở . Cả hai chỉ là nhà phát triển. Và đây là một điểm khởi đầu tốt, giúp bạn giữ cho cuộc thảo luận của bạn tập trung vào một giải pháp khả thi được hỗ trợ bởi các lý lẽ tốt hơn và không phải là tiền lương.

Những sai lầm khi thực hiện và thiết kế lại trong giai đoạn nước rút

Dường như có một vấn đề cơ bản trong việc thu thập các yêu cầu, tiếp theo là tồn đọng sản phẩm rất mơ hồ.

Như tôi đã nói ở trên: Miễn Product Backloglà trong một hình dạng tốt, thật khó để bỏ lỡ điểm.

Tôi không thể tưởng tượng một tình huống như:

»Là người dùng, tôi muốn thấy một số ít khách hàng!«

»Ồ, bạn không có nghĩa là mỗi 2 triệu khách hàng của chúng tôi?«

OTOH: Thiết kế lại bối cảnh này có ý nghĩa gì? Nếu một nhà phát triển chọn một thuật toán hoạt động chậm , thì sẽ có mục tiêu rõ ràng tiếp theo: chọn một thuật toán hoạt động tốt hơn. Nhưng đó không phải là "thiết kế lại", đây là một sự tối ưu hóa.

Cho câu hỏi chính của bạn:

Làm thế nào để đối phó với điều này?

Thật là tầm thường khi đề cập đến, nhưng dù sao tôi cũng làm điều đó: Đừng quên rằng bạn đang đối phó với con người .

Rất khó để có một nhóm các tâm trí khác nhau, có thể chia sẻ các khái niệm phổ biến (như trong Rashomon ). Để giải quyết vấn đề này một cách hiệu quả, hãy sử dụng càng nhiều dự phòng trong giao tiếp của bạn càng tốt: ví dụ: giải thích bối cảnh của mục rộng rãi, ngay cả khi mọi người "nên biết" phải làm gì. Đặt câu hỏi, liệu mọi người có nhận được chủ đề của một mục cụ thể là gì không.

Nếu bạn đang chơi poker lập kế hoạch một chỉ số tốt, cho dù sự hiểu biết là đủ tốt, thì, các nhiệm vụ đó được đánh giá thấp. Thấp có nghĩa là phức tạp thấp có nghĩa là dễ hiểu và khó bỏ lỡ.

Một tác dụng phụ của việc lặp lại là, các con số cho một số nhiệm vụ nhất định sẽ tăng lên (vì nhóm có sự hiểu biết về khả năng của nó và sự phức tạp ẩn giấu). Sau đó, có cơ hội để chia mục thành nhiều mục ít phức tạp hơn với độ phức tạp thấp hơn.

Bao nhiêu chi tiết tôi nên thảo luận trong quá trình lập kế hoạch để phù hợp với 2 giờ mỗi tuần nước rút?

Câu trả lời của Salomonic: Càng ít càng tốt và càng nhiều càng cần thiết, nhưng không nhiều hơn.

tl; dr

• Chọn một ngôn ngữ dễ dàng (nếu nó giúp, sử dụng tiếng Anh đơn giản hoặc ELI5) để tránh hiểu lầm

• Cải thiện thu thập yêu cầu

• Cải thiện tồn đọng

• Tăng sự tự tin của các thành viên trong nhóm về khả năng cá nhân cũng như khả năng của họ với tư cách là một nhóm

• Tránh đi xe đạp

• Nâng cao kỷ luật cá nhân

• Có lẽ sử dụng bảng thời gian cố định cho mọi mục để thảo luận

• Tăng cường vị trí của scrum mastervừa phải hiệu quả.

Chúng tôi đã thành công trong việc giảm thời gian họp lên kế hoạch bằng cách thực hiện tổng cộng ba giờ trong 2 tuần nước rút. Chúng tôi chia sự chải chuốt thành bốn phiên. chúng tôi chải chuốt 30 phút vào thứ Hai và 1 giờ chải chuốt vào thứ Tư mỗi tuần. Chạy nước rút của chúng tôi bắt đầu vào thứ Hai và kết thúc vào thứ Sáu. Kết quả là chúng tôi có thông tin tốt từ các cuộc họp chải chuốt góp phần làm đầu vào cho kế hoạch làm cho nó ngắn hơn. Kỷ lục tốt nhất của chúng tôi là một cuộc họp lập kế hoạch dài 30 phút trong một trong những lần chạy nước rút của chúng tôi. Hầu hết thời gian không mất hơn một giờ đến một giờ và 30 phút. Dù sao vẫn còn thời gian, nhưng kế hoạch đã được thực hiện từ rất sớm.