Không chỉ các cuộc họp lập kế hoạch nước rút của chúng tôi không vui vẻ, họ còn hết sức đáng sợ.

Các cuộc họp là tẻ nhạt, và nhàm chán, và kéo dài mãi mãi (một ngày, nhưng nó cảm thấy như dài hơn rất nhiều).
Các nhà phát triển phàn nàn về nó, và sợ quy hoạch sắp tới.

Thói quen của chúng tôi khá chuẩn (câu chuyện người dùng được đưa vào tồn đọng chạy nước rút theo mức độ ưu tiên >> câu chuyện được tách ra thành các nhiệm vụ >> các nhiệm vụ được ước tính theo giờ >> lặp lại) và tôi không thể hiểu được mình đang làm gì sai.

Làm thế nào chúng ta có thể làm cho các cuộc họp thú vị hơn?

...

Một số chi tiết khác, đáp lại yêu cầu cung cấp thêm thông tin:

Tại sao các mục tồn đọng không được chèn và ưu tiên trước khi khởi động nước rút?

Câu chuyện của người dùng thực sự được ưu tiên; chúng tôi không biết họ sẽ mất bao lâu cho đến khi chúng tôi chia nhỏ chúng thành các nhiệm vụ! Từ các câu trả lời (xuất sắc) ở đây, tôi thấy rằng có lẽ chúng ta không nên ước tính các nhiệm vụ, chỉ có các câu chuyện của người dùng. Lý do chúng tôi ước tính các nhiệm vụ (chứ không phải câu chuyện) là vì chúng tôi đã nhận được ước tính câu chuyện sai lầm khủng khiếp - nhưng tôi đoán đó là chủ đề cho một câu hỏi hoàn toàn khác.

Tại sao các nhà phát triển phàn nàn?

1. Cuộc họp còn dài.

2. Cuộc họp thật đơn điệu. Câu chuyện sau câu chuyện, nhiệm vụ sau nhiệm vụ, đấu tranh (vâng, đấu tranh) để ước tính thời gian sẽ mất bao lâu và những gì nó liên quan.

3. Ước tính nhiệm vụ làm cho ước tính câu chuyện người dùng dường như vô nghĩa.

4. Cuộc họp càng kéo dài, càng ít tập trung trong phòng. Các đồng nghiệp càng ít tập trung, cuộc họp càng kéo dài. Một xoắn ốc ghét đệ quy phát triển. Chúng tôi đã cân nhắc việc chia cuộc họp thành hai ngày để giữ mọi người tập trung, nhưng các nhà phát triển sẽ không nghe về nó. Một ngày lập kế hoạch là đủ xấu; Bây giờ chúng ta sẽ có hai ?!

Một phần của vấn đề của chúng tôi là chúng tôi đi vào chi tiết rất nhỏ (để có được ước tính chính xác hơn). Nhưng khi chúng tôi ước tính khoảng, chúng tôi đi ra khỏi nhãn hiệu!

Để tổng hợp câu hỏi:

• Chúng ta đang làm gì sai?

• Có những cách bổ sung nào để làm cho cuộc họp thường thú vị hơn?

Làm cho việc ước tính dễ dàng hơn

Phá vỡ kế hoạch chạy nước rút của bạn xuống.

Bạn có cần ước tính các nhiệm vụ cá nhân? Tôi đã thực hiện kế hoạch chạy nước rút theo hai cách:

1. Câu chuyện được ước tính theo điểm câu chuyện và sau đó nhiệm vụ được ước tính theo giờ
2. Câu chuyện được ước tính theo điểm câu chuyện và nhiệm vụ chỉ đơn giản là không có ước tính

Trong hai, tôi thích lựa chọn thứ hai. Tôi thấy rằng việc không ước tính các nhiệm vụ mang lại nhiều tự do hơn cho các nhà phát triển để đối phó với các thay đổi. Nếu một nhiệm vụ không còn ý nghĩa (bạn đã phát hiện ra rằng một nhiệm vụ không thể áp dụng được bao nhiêu lần hoặc đã được thực hiện trong lần chạy nước rút trước đó), bạn chỉ cần ném nó ra mà không bị phạt, hoặc bạn có thể phải thay đổi một nhiệm vụ hiện tại một cái gì đó mới, có thể phá vỡ nó Bạn thực sự dư thừa nếu bạn ước tính cả hai, vì tổng số các nhiệm vụ sẽ đại diện cho các điểm câu chuyện và ngược lại. Giá trị nào bạn thực sự đạt được bằng cách này ngoài việc biết các nhiệm vụ cá nhân sẽ mất bao nhiêu thời gian? Nếu bạn thấy mình có kích thước nhiệm vụ thực sự đủ khác nhau để tạo ra sự khác biệt, tôi sẽ khuyên bạn nên chia những nhiệm vụ đó thành các phần nhỏ hơn, đồng nhất hơn.

Bằng cách này, bạn có thể cắt giảm thời gian bạn dành cho kế hoạch chạy nước rút . Câu chuyện được ước tính trong quá trình lập kế hoạch nước rút, và khi bạn bắt đầu chạy nước rút, bạn có thể đặt tất cả các nhiệm vụ bạn có thể nghĩ ra để tạo nên câu chuyện đó. Rõ ràng nếu có những điểm bạn gặp phải khi ước tính câu chuyện mà bạn biết sẽ phải xử lý trong một nhiệm vụ, bạn có thể thêm nó vào thông tin câu chuyện và đặt nó làm nhiệm vụ.

Ước tính theo đơn vị lý tưởng

Điểm câu chuyện có nghĩa là trong các đơn vị lý tưởng như giờ người đàn ông lý tưởng hoặc ngày làm việc lý tưởng. Điều này có nghĩa là cho một ngày hoàn hảo mỗi ngày, nơi bạn không bị gián đoạn, không có cuộc họp và mọi thứ diễn ra theo đúng kế hoạch, bạn có thể hoàn thành nhiệm vụ trong X ngày. Bây giờ mọi người đều biết rằng điều này đơn giản là không đúng, nhưng điều tuyệt vời về thống kê là nó không phải như vậy.

Điều tôi muốn nói là điều này là sau một thời gian ước tính những điều này trong những ngày lý tưởng, bạn nhận ra rằng có thể phải mất thêm 25% thời gian bạn ước tính trung bình để hoàn thành một câu chuyện. Hãy nói rằng bạn đã ước tính 4 ngày làm việc lý tưởng và thay vào đó bạn phải mất 5. Theo thời gian, bạn theo dõi điều này và sau đó bạn có một ý tưởng sơ bộ về việc chuyển đổi từ ngày lý tưởng sang ngày thực. Bản năng đầu tiên của bạn sẽ là cố gắng và bù đắp cho điều này bằng cách ước tính quá mức, và bạn có thể sẽ sai. Điều chính ở đây là để phù hợp. Bằng cách đó, trung bình dài hạn của bạn vẫn giữ nguyên. Chắc chắn đôi khi, nó sẽ ở dưới và đôi khi nó sẽ kết thúc, nhưng bạn càng ước tính, bạn càng có lợi. Nếu bạn thấy rằng bạn vẫn còn không thể có được ước tính chính xác, có thể điều đó có nghĩa là bạn không biết đủ về câu chuyện để ước tính đúng.

Nói về những câu chuyện

Khi bạn ước tính, mọi người nên có một ý tưởng sơ bộ về những gì sẽ cần phải làm, từ đầu đến cuối, về những gì sẽ cần để câu chuyện này được hoàn thành. Bạn không cần phải biết mọi chi tiết, nhưng đủ để bạn nghĩ rằng chính bạn, có thể thực hiện câu chuyện. Nếu bạn không có mức độ tự tin đó, có lẽ bạn không nên ước tính nó. Nếu bạn nói "Chà câu chuyện này quá lớn để chúng ta biết hầu hết các chi tiết" thì đó là một dấu hiệu cho thấy câu chuyện quá lớn, và nên được chia nhỏ. Những câu chuyện, ít nhất là theo kinh nghiệm của tôi, đã đủ nhỏ để một người, nếu cần, có thể làm việc một mình và hoàn thành nó trong vòng một hoặc hai tuần.

Điều này cũng sẽ giúp giải quyết điểm thứ hai của bạn trong chỉnh sửa, đó là quá nhiều ước tính . Thay vì ước tính từng nhiệm vụ cho mỗi câu chuyện, bạn chỉ cần ước tính toàn bộ câu chuyện, điều này sẽ giúp loại bỏ rất nhiều ước tính. Để làm cho các cuộc họp bớt đơn điệu, tôi sẽ đề nghị lập kế hoạch chơi bài xì phé mà bạn có thể xem thêm thông tin ở trên.

Làm cho kế hoạch hấp dẫn hơn

Ước tính bằng Kế hoạch Poker

Theo như ước tính thú vị hơn, bạn đã thử lập kế hoạch chơi bài chưa? Đó là cách mà tôi luôn thực hiện kế hoạch cho tất cả các lần chạy nước rút của mình trên nhiều đội và đó là cách tốt để giữ mọi người tham gia, vì mỗi người ít nhất phải chọn SOMETHING. Ngoài ra còn có rất nhiều niềm vui liên quan khi mọi người trong nhóm chọn 3, và ai đó hạ xuống 20 và phải tự giải thích, hoặc khi mọi người trong nhóm hạ xuống 5 nhưng người quản lý đặt xuống 8 (ai sẽ tranh luận với ông chủ khi muốn cho bạn thêm thời gian!).

Để làm điều này, tất cả những gì bạn cần là một số thẻ bài lập kế hoạch , chúng tôi thường làm ở mặt sau của thẻ chỉ mục hoặc sử dụng thẻ chơi bình thường với các giá trị được gắn vào thẻ mặt. Không có gì lạ mắt, và nó giữ cho mọi người tập trung. Chỉ cần nhớ rằng cố gắng thực hiện bất kỳ nhiệm vụ nào trong cả ngày (bao gồm cả lập kế hoạch chơi bài) sẽ ảnh hưởng đến năng suất. Nhiều bộ thẻ đi kèm với một thẻ cà phê vì một lý do; nếu ai đó cảm thấy kiệt sức, hãy cho cả đội nghỉ ngơi để nạp năng lượng và nhặt nó lên khi mọi người còn tươi!

Thay thế cho thẻ vật lý , bạn cũng có thể nhìn vào thẻ điện tử . Lợi ích thực sự ở đây là tự động theo dõi kết quả, theo dõi các câu chuyện của người dùng và cho phép mọi người hiển thị thẻ của họ cùng một lúc để tránh "gian lận" (trong đó ước tính của một người bị ảnh hưởng bởi người khác do có thể nhìn thấy thẻ của họ). Rõ ràng điều này đòi hỏi tất cả mọi người đều có máy tính và khả năng tập trung vào nhiệm vụ trong tay, vì vậy hãy sử dụng nó theo ý của bạn.

1. Tại sao các mục tồn đọng không được chèn và ưu tiên trước khi khởi động nước rút? Lãng phí thời gian của các nhà phát triển là không vui. Hãy để nhóm lãnh đạo của bạn làm việc với chủ sở hữu sản phẩm và người quản lý dự án trước vài ngày để ưu tiên công cụ. Điều này cũng dành cho kế hoạch ai là người trong mỗi đội chạy nước rút.

2. Tại sao phải mất một ngày để chia mọi thứ thành nhiệm vụ? Nếu bạn có một nhóm có quy mô hợp lý (2-4 nhà phát triển, 0,5-1,5 người QA cho mỗi nhà phát triển, 1-2 misc) thì bạn nên có 2-4 câu chuyện người dùng trong lần chạy nước rút này. Dành 30 phút hoặc lâu hơn với chủ sở hữu sản phẩm để làm rõ các yêu cầu, sau đó 30 phút hoặc lâu hơn để phá vỡ nó thành các nhiệm vụ ~ 8 giờ. Đừng tham gia các nhiệm vụ trong cuộc họp. Chỉ cần đồng ý với tư cách là một nhóm những nhiệm vụ đủ để mọi người lành mạnh hiểu họ, người chịu trách nhiệm cho họ và về thời gian họ nên làm. Đồng ý rằng "họ nên mất bao lâu (bao gồm cả thử nghiệm)" phù hợp thoải mái trong giai đoạn nước rút.

3. Nếu nó không chỉ phá vỡ mọi thứ thành nhiệm vụ, bạn còn làm gì nữa? Chắc chắn, quá trình hồi tưởng có thể mất 30-60 phút, nhưng sẽ ngắn hơn khi các đội đi vào một rãnh.

Vì vậy, tóm lại - bỏ lãng phí thời gian của mọi người và họ sẽ sợ các cuộc họp ít hơn một chút. Ngoài ra, niềm vui và comradarie trong đội không phải là thứ bạn có thể giải quyết trong các cuộc họp. Đi ăn trưa cùng nhau, đùa giỡn, kết hợp mọi người để có những tính cách phù hợp hơn, có những cuộc thi mọc ria mép ... một khi tinh thần lên cao thì mọi người sẽ tự nhiên làm cho các cuộc họp lập kế hoạch nước rút trở nên nhẹ nhàng hơn.

Lập kế hoạch là một lĩnh vực của scrum nơi các đội có rất nhiều sự linh hoạt. Hãy thử một cái gì đó mới mỗi lần chạy nước rút cho đến khi bạn nhấn vào thứ gì đó phù hợp với nhóm của bạn.

Một số ý tưởng thành công tôi đã từng thử hoặc nghe từ các đội khác:

• Do người dùng tạo và ưu tiên câu chuyện mà không có toàn bộ nhóm. Chủ sở hữu sản phẩm và / hoặc chủ scrum có thể xử lý rất nhiều công việc bận rộn và chỉ cần để nhóm điều chỉnh nó.
• Làm cho hồ sơ tồn đọng của bạn dài hơn đáng kể so với một lần chạy nước rút. Có thể mất một chút thời gian để xây dựng nó, nhưng nếu tồn đọng của bạn đủ dài, các cuộc họp lập kế hoạch sẽ giảm xuống để thực hiện các điều chỉnh nhỏ hoặc giải quyết các phát triển kinh doanh gần đây.
• Có các cuộc họp dự toán tách biệt với kế hoạch nước rút. Nếu mọi người nghĩ rằng các cuộc họp quá dài, không có lý do gì để không chia chúng ra.
• Cụ thể kế hoạch đột nhập vào chương trình nghị sự. Điều này rất hữu ích nếu bạn thường lãng phí thời gian chờ đợi một hoặc hai thành viên trong nhóm quay trở lại.
• Nghỉ giữa cuộc họp và phân công mọi người thực hiện một hoặc hai câu chuyện của người dùng, sau đó gặp lại nhau để báo cáo và đạt được sự đồng thuận.
• Hãy chắc chắn rằng cuộc họp lập kế hoạch của bạn là về những gì cần làm, không phải làm thế nào để làm điều đó. Các kỹ sư rơi rất dễ dàng vào sau này. Nếu bạn cần, hãy thiết lập các cuộc họp thiết kế riêng biệt nơi bạn thảo luận về cách thức.
• Tách câu chuyện của bạn thành điều tra và thực hiện. Các cuộc họp lập kế hoạch thường diễn ra quá lâu khi các thành viên trong nhóm biết quá ít về những gì họ sẽ làm việc và cố gắng tìm ra nó trong cuộc họp.
  Ví dụ: giả sử bạn cần tích hợp với API mà nhóm của bạn không có kinh nghiệm. Thay vì cố gắng tạo ra các ước tính và nhiệm vụ trong cuộc họp lập kế hoạch về điều gì đó mà bạn không biết, hãy tạo một câu chuyện điều tra để tìm hiểu API, làm một ứng dụng "xin chào thế giới" đơn giản và dạy cho nhóm. Sau đó, bạn sẽ được trang bị để lập kế hoạch công việc thực tế.
• Theo dõi trong các cuộc họp của bạn về các vấn đề cụ thể. Không chỉ "lập kế hoạch là nhàm chán", mà là một mức độ chi tiết như "chúng tôi dành nhiều thời gian để nói về các yêu cầu không rõ ràng, và dường như không ai biết câu trả lời đúng". Sau đó thảo luận về những vấn đề cụ thể trong quá trình hồi tưởng và động não của bạn để có giải pháp cụ thể. Phá vỡ vấn đề của bạn cho đến khi các mảnh dễ dàng để giải quyết.

Chúng tôi giữ kế hoạch chạy nước rút và hồi cứu cùng một lúc, và hầu như luôn luôn được thực hiện trong 90 phút, nhưng chúng tôi là một trong những đội nhanh hơn. Chúng tôi thực hiện một kế hoạch dài hạn trên toàn công ty lớn cứ sau 5 lần chạy nước rút mất từ ​​4 đến 6 giờ. Tất cả mọi đội đều khác nhau, tất nhiên, nhưng nếu bạn dành cả ngày cho mỗi lần chạy nước rút, sẽ có rất nhiều cơ hội để cải thiện.

Phiên kế hoạch của bạn là quá dài!

Dựa trên kinh nghiệm của tôi, một cuộc họp lập kế hoạch nước rút sẽ mất không quá 2 giờ mỗi tuần để lên kế hoạch (ví dụ, một cuộc chạy nước rút 2 tuần nên mất tối đa 1/2 ngày), nhưng cuộc họp thành công nên ngắn hơn (một nửa số đó).

Trong trường hợp cụ thể của bạn: tại sao bạn ước tính nhiệm vụ? Bạn chỉ nên ước tính những câu chuyện trong quá trình lập kế hoạch. Nhiệm vụ có thể được ước tính sau bởi các chủ sở hữu nhiệm vụ cụ thể .

Một cách làm việc cho tôi:

• Giới thiệu nhanh về nước rút bởi PO
• Ước tính khả năng chạy nước rút
• Các câu chuyện chạy xuống và lên kế hoạch chơi bài xì phé (được ghi thời gian ở mức 5/10 phút cho mỗi câu chuyện) cho đến khi có đủ thứ ước tính để chạy nước rút
• Cam kết / dự báo chính thức của nhóm

Sau đó, song song / cặp / tự tổ chức tại bàn của chúng tôi, nhiệm vụ và ước tính nhiệm vụ.

Ở công việc trước đây của tôi, toàn bộ ngày đầu tiên của mỗi lần chạy nước rút (chúng tôi gọi chúng là các lần lặp ở đó) đã được đưa lên:

• Hồi tưởng. Chúng tôi bắt đầu thực hiện việc này vào chiều ngày cuối cùng, nhưng chúng tôi thường thấy mình hồi tưởng về cuộc chạy nước rút và sau đó quay lại làm việc để buộc các đầu lỏng lẻo cuối cùng của công việc chạy nước rút đó, vì vậy chúng tôi nghĩ rằng sẽ tốt hơn để đảm bảo công việc là tất cả phía sau chúng tôi trước khi nhìn lại nó. Nó cũng có vẻ hợp lý để hợp nhất tất cả chi phí cuộc họp của quy trình Scrum để những ngày khác có thể được lên kế hoạch và chi tiêu theo các điều khoản lý tưởng hơn. Điều này thường mất 2 giờ.
• Kế hoạch nước rút. Việc tồn đọng được ước tính trong Cuộc họp Lập kế hoạch Mốc (có thể là cả ngày cho cả Dev và PO), và đã được các PO ưu tiên trước khi bắt đầu mỗi lần chạy nước rút. Chúng tôi đã tìm ra có bao nhiêu ngày nhà phát triển chúng tôi có sẵn (kế toán cho các ngày lễ, vaca, v.v.), đã nắm bắt công việc mà chúng tôi nghĩ rằng chúng tôi có thể thực hiện từ đầu đống và nhanh chóng xem xét các yêu cầu của người dùng (trước đây đã được các BA của chúng tôi xem xét) hiểu rõ hơn về những gì công việc đòi hỏi hơn những gì chúng ta có với tổng quan đơn giản trong MPM. Điều này thường mất thêm 2 giờ.
• Lập kế hoạch nhiệm vụ. Biết được các câu chuyện và tiêu chí chấp nhận, chúng tôi chia từng câu chuyện thành các nhiệm vụ có kích thước lớn được ước tính trong giờ lý tưởng (một giờ chỉ tập trung vào việc thực hiện nhiệm vụ đó "không" mà không bị phân tâm hoặc cản trở). Cách thang điểm của chúng tôi cuối cùng được hiệu chỉnh, số 5 là một lần chạy nước rút của nhà phát triển, do đó, 1 có thể là bất cứ điều gì lên đến và bao gồm hai ngày của nhà phát triển. Vì lý do đó, hầu như mọi thứ phải được chia nhỏ để các thành viên trong nhóm có thể hiển thị tiến trình trên bảng scrum. Đây là một khối 2 giờ nữa, với một số cho và nhận giữa mục này và mục tiếp theo.
• AAT phác thảo. PO và BA của chúng tôi không phải là lập trình viên và không viết mã. Các PO ẩn đằng sau một hợp đồng quy định rằng họ sẽ đưa ra các yêu cầu dưới dạng mẫu Word và sẽ làm việc với các BA để tinh chỉnh chúng theo hình thức đó. Các BA hiểu mã, nhưng thời gian của họ hoàn toàn là phân tích và thử nghiệm cuối cùng (yêu cầu hệ thống tồn tại, vì vậy họ có thể ghi lại các macro của họ vào Selenium). Vì vậy, để xác minh rằng mã của chúng tôi sẽ đáp ứng các tiêu chí chấp nhận khi nói đến điều đó, chúng tôi đã phải viết AAT của riêng mình mô hình hóa các hành động của thử nghiệm chấp nhận "giấy". Chúng tôi thường làm điều này trong cùng một khung NUnit mà chúng tôi đã sử dụng cho các bài kiểm tra đơn vị và tích hợp (chúng tôi đã thử FitNesse và không thể từ bỏ nó đủ nhanh). Đây là phần còn lại của ngày đầu tiên của chúng tôi trong mỗi lần chạy nước rút và tiếp tục vào lần thứ hai.

Trong công việc hiện tại của mình, chúng tôi vẫn đang áp dụng quy trình Scrum, chúng tôi không có kế hoạch cột mốc toàn đội và rất nhiều điều chúng tôi đang làm không có tiêu chí chấp nhận nghiêm ngặt. Vì vậy, kế hoạch chạy nước rút của chúng tôi là một lời giải thích về những gì mỗi câu chuyện đòi hỏi và những gì chúng ta sẽ gọi là thực hiện vì đó là một cam kết để lấy X giờ làm việc lý tưởng hàng đầu ra khỏi đầu. Chúng tôi tránh xa nó - ít nhất là bây giờ - bởi vì chúng tôi là một nhóm nội bộ và mỗi người chúng tôi làm việc cá nhân với người dùng cuối phần mềm của chúng tôi để thu thập các yêu cầu và giải pháp thiết kế. Ngay cả khi đó, kế hoạch chạy nước rút là một việc cả buổi sáng vào mỗi thứ Hai khác, và buổi chiều được dành để xóa mọi rào cản cá nhân để có thể bắt đầu phát triển một cách nghiêm túc vào thứ ba.

Để thực sự trả lời câu hỏi của OP thay vì đối chiếu với các bình luận / câu trả lời khác nói rằng không nên mất nhiều thời gian như vậy, có nhiều cách để tiếp cận ước tính Agile, lập kế hoạch chạy nước rút và hồi tưởng thú vị hơn bạn có thể sử dụng.

Cụ thể giải quyết mối quan tâm của bạn:

• Các cuộc họp dài - Hộp thời gian chúng. Mỗi cuộc họp, có thể là hồi cứu, lập kế hoạch chạy nước rút, phân chia nhiệm vụ, v.v., nên có mục đích và chủ đề thảo luận nhất định, và nên giới hạn càng nhiều càng tốt trong một khoảng thời gian nhất định. Đó là công việc của Scrum Master để giữ các cuộc họp này theo chủ đề và tiếp tục đáp ứng các mục tiêu thời gian.

• Các cuộc họp rất đơn điệu - Sẽ có một số điều đó; bạn đang làm việc trong các khối kích cỡ cắn, từng cái một, vì vậy bạn sẽ làm điều tương tự lặp đi lặp lại. Giữ cho nhóm tập trung và hướng tới việc hoàn thành mục đích của cuộc họp sẽ giúp ích.

  Một điều khác tôi nghe thấy là có thể các cuộc họp lập kế hoạch nước rút của bạn đang cố gắng thực hiện quá nhiều. Tại công ty cuối cùng của tôi, việc ước tính câu chuyện đã được thực hiện tại "các cuộc họp lập kế hoạch cột mốc", diễn ra khoảng một phần tư và mất cả ngày. Trong các cuộc họp đó, mọi thứ được xây dựng trên hồ sơ tồn đọng mà chúng tôi không ước tính được ước tính bằng điểm. Nếu bạn đang thực hiện ước tính câu chuyện theo điểm, và sau đó ước tính nhiệm vụ theo giờ, bạn không muốn thực hiện cả hai cùng một lúc (có thể trong cùng một ngày).

• Ước tính câu chuyện theo điểm, sau đó các nhiệm vụ trong giờ dường như dư thừa - Chúng có hai mục đích khác nhau. Mục đích của ước tính câu chuyện là cung cấp một ước tính sơ bộ về độ phức tạp, mà bạn có thể sử dụng để lấp đầy tồn đọng nước rút của mình dựa trên vận tốc trong quá khứ và băng thông dự kiến. Mục đích của ước tính nhiệm vụ là chia nhỏ các câu chuyện thành những thứ mất một ngày dành cho nhà phát triển (và có thể được chỉ định cho một anh chàng duy nhất sẽ hoàn thành kịp thời gian) và đảm bảo bạn chưa ước tính sai bất kỳ sự phức tạp của câu chuyện cũng như không bị cắn nhiều hơn bạn có thể nhai trong nước rút.

  Nếu tất cả các câu chuyện của bạn mất một ngày hoặc ít hơn, thì nó là dư thừa, nhưng không phải tất cả các thang điểm đều được hiệu chỉnh như nhau; ở công việc cuối cùng của tôi, số 5 là hai tuần của nhà phát triển (vì lúc đầu chúng tôi có rất nhiều sử thi để ước tính), trên quy mô tuyến tính đã tạo ra một điểm bất cứ thứ gì lên đến 2 ngày cho nhà phát triển. Với quy mô như vậy, hầu như mọi thứ sẽ được chia thành các nhiệm vụ. Tại công ty mới của tôi, một điểm gần hơn một nửa ngày của nhà phát triển, do đó, 1 hoặc thậm chí 2 chắc chắn là nhiệm vụ của riêng mình và 3-8 là không rõ ràng khi buộc nhóm phải chia nó thành các nhiệm vụ.

• Có một vòng luẩn quẩn của nó mất nhiều thời gian hơn khiến mọi người ít tập trung hơn nên mất nhiều thời gian hơn - Hộp thời gian của bạn. Nghỉ giải lao, giống như bạn nên làm khi viết mã. Cứ sau 30 phút, hãy dành 5 phút để duỗi chân, tập hợp lại, v.v. Bạn có thể thực hiện mười phút mỗi giờ, nhưng đừng đẩy một khối thời gian họp vững chắc đi xa hơn thế. Những người của bạn có thể đang đói, hoặc cần thêm cà phê, hoặc nghỉ ngơi trong phòng tắm, v.v. Đừng từ chối họ; nếu bạn làm cho chúng mút nó, bạn sẽ thấy đầu óc mình lang thang. Ngoài ra, giữ cho các cuộc thảo luận ngắn gọn, ngọt ngào và cũng sẽ giúp ích, như đã đề cập trước đây.

Cuộc họp lập kế hoạch Sprint có 2 phần:

1. Quyết định đội sẽ làm gì
2. Quyết định cách nhóm sẽ làm điều đó.

Phần đầu tiên tương đối đơn giản - dựa trên số điểm câu chuyện mà nhóm cảm thấy họ có thể đảm nhận, cam kết hoàn thành nhiều câu chuyện của người dùng theo thứ tự ưu tiên của họ. Làm xong.

Phần thứ hai là những gì các nhà phát triển thực sự nên tận hưởng - xây dựng câu chuyện và thiết kế giải pháp. Các nhiệm vụ rơi ra khỏi đó. Vì vậy, có chủ sở hữu sản phẩm, hoặc bất kỳ doanh nghiệp vừa và nhỏ nào mà anh ấy đã cung cấp giải thích một câu chuyện đã chọn. Sau đó, bất cứ nhà phát triển nào muốn đưa nó vào, hãy dẫn dắt cuộc thảo luận thiết kế. Sử dụng bảng trắng. Bounce ý tưởng xung quanh. Chúc vui vẻ.

Đó là nó, thực sự. Nếu các cuộc họp thiết kế không vui, thì có gì đó không ổn.

Vâng, tôi biết đây là một câu hỏi cũ, nhưng tôi có một câu trả lời mới. : P

Chia cuộc họp lên.

Chúng tôi chia cuộc họp lập kế hoạch Sprint của chúng tôi thành 3 cuộc họp nhỏ riêng biệt

• Backlog chải chuốt
• Lựa chọn truyện
• Phân chia nhiệm vụ

Chúng tôi thực hiện mỗi ngày vào một ngày khác nhau, ngay sau Scrum hàng ngày của chúng tôi - ngay sau khi hàng ngày hoàn thành, chúng tôi chuyển ngay vào hoạt động lập kế hoạch và sau đó chúng tôi không phải họp (lên kế hoạch thường xuyên) trong các ngày còn lại.

Vì vậy, chúng tôi đã bỏ kế hoạch của mình: -O

Tôi sẽ đi vào chi tiết hơn về những gì liên quan đến mỗi phiên trong một giây, nhưng hãy để tôi giải thích cách chúng tôi đến đây.

Chúng tôi, cũng như chính bạn, đã gặp vấn đề với các cuộc họp lập kế hoạch Sprint thực sự khủng khiếp. Chúng tôi có tất cả các yếu tố phù hợp, nhưng mọi thứ chỉ diễn ra mãi mãi và thực sự cạn kiệt tinh thần và cảm xúc để vượt qua.

Sau đó, tôi đã có ý tưởng này sau khi đọc bài viết này của Business Insider trên 5 phút hàng ngày của Pivotal về việc chia nhỏ các cuộc họp của chúng tôi thành các phiên ngắn hơn và thực hiện chúng vào đầu mỗi ngày.

Tôi đã đưa nó lên với đội ở một hồi tưởng. Một số thành viên trong nhóm thích nó ngay lập tức, những người khác hơi e ngại, nhưng sau đó thực tập sinh của chúng tôi đã đề cập đến một số nghiên cứu mà anh ấy đã đọc về kỹ thuật pomodoro và bắt đầu tiếp tục về nó, và điều đó thực sự giúp ý tưởng đạt được lực kéo.

Vì vậy, chúng tôi quyết định thử nó.
Chúng tôi đã chia cuộc họp kéo dài 2 giờ thành ba phiên 25 phút. (vâng, đó là toán học mờ, nhưng mọi người đều cảm thấy các cuộc họp của chúng tôi quá dài và chỉ muốn làm điều đó nếu chúng tôi tiết kiệm thời gian).

Va no đa hoạt động! Chúng tôi đã thực hiện được khoảng 6 tuần nay trên hai dự án riêng biệt (tổng cộng 6 lần chạy nước rút trong hai tuần) và nó đã tạo ra một thế giới khác biệt.
Chúng tôi làm việc hiệu quả hơn. Chúng tôi tiết kiệm một tấn thời gian.
Chúng tôi nhận được đầu ra tốt hơn. Và chúng tôi không còn sợ các cuộc họp lập kế hoạch của chúng tôi.

Và thành thật mà nói, hộp thời gian 25 phút của chúng tôi khá lỏng lẻo - một số phiên diễn ra rất nhanh, như 5-10 phút trong một số phiên chải chuốt của chúng tôi và một số kéo dài, như khi chúng tôi kết thúc việc xác định câu chuyện mới hoặc phải chia tay câu chuyện và ước tính lại trong quá trình đàm phán. Nhìn chung, nó thường trung bình không quá 1,5 giờ cho toàn bộ shebang, và tôi nghĩ đó là lý do tại sao nó hoạt động rất tốt.

Về chi tiết .....

Backlog chải chuốt

Khá đơn giản - chúng tôi xem xét các câu chuyện ưu tiên hàng đầu, nói về những gì chúng đòi hỏi và đảm bảo ước tính của chúng tôi là tốt.

Chúng tôi sẽ ước tính lại các câu chuyện nếu cần - như nói rằng chúng tôi đã ước tính vài tháng trước và sau khi nhận ra một câu chuyện tương tự thực sự đã diễn ra, chúng tôi có thể đồng ý ước tính lại. (chúng tôi sử dụng các điểm câu chuyện không có đơn vị bằng cách này và chúng tôi không ước tính các nhiệm vụ ).

Ngoài ra, nếu PO đã thêm bất kỳ câu chuyện mới nào mà anh ta cảm thấy là ưu tiên cao, thì đây là lúc để ước tính chúng.

Vì chúng tôi không thực hiện lựa chọn Câu chuyện cho đến ngày hôm sau, quá trình này giúp PO có thêm một chút thời gian để đưa ra phán quyết cuối cùng về những gì quan trọng nhất cần thực hiện trong lần lặp lại tiếp theo - và điều này đã tỏ ra rất hữu ích.

Cuộc họp này có xu hướng diễn ra ngắn với một số PO và dài với những người khác. (cá nhân, tôi nghĩ đó là một chỉ số mùi tuyệt vời về cách PO của bạn đang làm)

Lựa chọn câu chuyện

Hãy để Chris Voss của bạn tiếp tục, đã đến lúc đàm phán.

Tại cuộc họp này, chúng tôi lấy những câu chuyện ưu tiên hàng đầu và xác định DoD cho mỗi câu chuyện . Chúng tôi đàm phán những gì mỗi người sẽ đòi hỏi - chia tách và kết hợp các câu chuyện khi cần - cho đến khi tất cả chúng ta có thể đồng ý về các mục tiêu Sprint của mình.

Chúng tôi hưởng lợi rất nhiều từ việc có đầu óc tươi mới và năng lượng buổi sáng tốt lành cho cuộc họp này - và biết rằng chúng tôi sẽ thực hiện các nhiệm vụ vào một ngày khác cho phép chúng tôi dành thời gian để thực sự đàm phán tốt và hiểu các cam kết của mình.

Nhiệm vụ

Được rồi, vì vậy tôi sẽ là người đầu tiên nói, các nhiệm vụ là phần yêu thích nhất của tôi trong kế hoạch trong các cuộc họp một ngày cũ của chúng tôi.

Chúng tôi chỉ không bao giờ đạt được bước tiến của chúng tôi với điều này. Chúng tôi đã cố gắng lưu các nhiệm vụ cho đến khi kết thúc cuộc họp - nhưng tất cả chúng tôi đều bị rút cạn và điều đó thực sự không hiệu quả. Chúng tôi đã cố gắng xác định các nhiệm vụ cùng lúc với DoD của chúng tôi trong quá trình đàm phán, nhưng chúng tôi thấy nó quá mất tập trung và quá cồng kềnh - chúng tôi sẽ tự thiêu trước khi chọn tất cả các câu chuyện. Ngoài ra, thật khó để tiếp tục chuyển trọng tâm / suy nghĩ qua lại giữa việc ước tính, đàm phán, lựa chọn câu chuyện và tạo nhiệm vụ. Chúng tôi vật lộn, và nó bị hút, và nó làm cho các cuộc họp của chúng tôi khủng khiếp.

Nhưng bây giờ, bằng cách xác định DoD vào một ngày và không thực hiện các nhiệm vụ cho đến ngày tiếp theo, chúng tôi sẽ không bị kiệt sức, chúng tôi luôn suy nghĩ đúng đắn và điều đó cho chúng tôi cả một ngày để ướp câu chuyện và thực sự suy nghĩ và hiểu tất cả các nhiệm vụ trước khi chúng ta bắt đầu.

IMHO này, là một thay đổi trò chơi tổng số.

Để tất cả chúng cùng nhau.

Vì vậy, đây là những gì lịch trình buổi lễ Sprint của chúng tôi trông giống như bây giờ:

• Thứ Hai - Scrum hàng ngày -> Đánh giá Sprint
• Thứ ba - Scrum hàng ngày -> Backlog chải chuốt
• Thứ tư - Scrum hàng ngày -> Lựa chọn câu chuyện
• Thứ năm - Scrum hàng ngày -> Nhiệm vụ
• Thứ Sáu - Scrum hàng ngày -> Hồi tưởng

Nó đã làm việc rất tốt cho chúng tôi. Nếu bạn cho nó một shot, tôi rất muốn nghe những gì bạn nghĩ.

Chúng tôi đang có một cuộc chạy nước rút hàng tuần với một cuộc họp kéo dài một giờ, trong đó chúng tôi thảo luận về lần chạy nước rút trước đó, những gì còn lại phải làm và sau đó chuyển sang kế hoạch của tuần tới. Tất cả trong vòng một giờ.

Điều này là tất nhiên bởi vì chúng tôi phát hiện ra rằng trong trường hợp của chúng tôi theo scrum quá nghiêm ngặt sẽ chỉ lãng phí quá nhiều thời gian. Đó là bởi vì hầu hết các câu chuyện đã được thảo luận với các thành viên trong nhóm của chúng tôi khi người yêu cầu tạo câu chuyện người dùng.

Tôi chỉ nói rằng nếu nhóm của bạn sợ lập kế hoạch cho các cuộc họp, có lẽ bạn nên bỏ qua một số "quy tắc" của scrum.

Câu hỏi này đã được trả lời toàn diện, nhưng chỉ có một điều cần thiết để làm cho nó hoạt động và vui vẻ.

Trao quyền lực cho đội. - tức là làm cho họ làm việc trên những thứ mà họ nghĩ là quan trọng nhất.