Có bao giờ được chấp nhận để có các cuộc thảo luận không liên quan đến checkin trong các cuộc họp Standup hàng ngày của Scrum không?

Tôi hy vọng mọi người sẽ thưởng cho tôi một câu hỏi có khả năng rõ ràng. Tôi đã làm việc trong một số tổ chức có các cuộc họp hàng ngày. Một số tổ chức thực sự nghiêm ngặt về việc chỉ sử dụng scrum để đăng ký ("ba câu hỏi" - hôm qua bạn đã làm gì, bạn đang làm gì, bạn có bất kỳ trình chặn nào không?) Nhưng một số tổ chức khác có xu hướng chung khác thông báo hoặc thảo luận kỹ thuật chi tiết.

Tôi đã nghe lập luận, như trong bài viết này , cho phép thảo luận không liên quan đến kiểm tra như thế này là một sai lầm - cuộc họp scrum không nên được sử dụng cho các thông báo chung từ Scrum Master, thảo luận kỹ thuật, v.v.

Tác hại chính mà tôi đã thấy từ điều này là các cuộc họp có thể kéo dài hơn mức cần thiết (và thật khó chịu khi bị buộc phải ngồi vào một cuộc thảo luận về các chi tiết không liên quan đến tôi).

Rõ ràng là các cuộc thảo luận không liên quan đến toàn bộ nhóm và không phải là một phần của "ba câu hỏi" không nên là một phần của cuộc trò chuyện. Tuy nhiên, nếu có những thông báo khác có liên quan đến toàn bộ nhóm và dù sao cũng cần phải thảo luận, liệu có hại khi thảo luận về những điều đó vào thời điểm đó (thay vì tại một cuộc họp hoặc email riêng biệt)?

Mục đích của Scrum hàng ngày là để Nhóm phát triển xem xét 24 giờ qua và cập nhật kế hoạch của họ trong 24 giờ tới.

Bất cứ điều gì đạt được mục tiêu này và có thể được bảo hiểm trong 15 phút là chính xác những gì Scrum hàng ngày dành cho, theo Hướng dẫn Scrum. Nếu bạn có các cuộc hội thoại dài hơn cần phải xảy ra, thì bạn chỉ cần ghi chú lại những gì họ đang có và vào cuối Scrum hàng ngày, chia thành các nhóm nhỏ hơn quan tâm đến chủ đề đó.

Điều mà Scrum hàng ngày không dành cho việc tìm ra giải pháp cho các vấn đề. Làm điều đó sau ...

Chắc chắn nó được chấp nhận, nhưng tập trung vào những điều quan trọng đầu tiên. Nếu chúng tôi có thời gian còn lại trong 15 phút, điều khá phổ biến đối với nhóm phát triển 5 người đang tràn ngập (vì họ đồng bộ hóa thường xuyên hơn trong quá trình phát triển), tôi không gặp vấn đề gì với việc liên lạc và thông báo thêm. Miễn là chúng tôi hoãn chúng cho đến khi kết thúc Daily.

Là một Scrum Master, tôi chắc chắn rằng nhóm trả lời ba câu hỏi chính bằng cách nào đó.

Daily Scrum là một sự kiện kéo dài 15 phút để Nhóm Phát triển đồng bộ hóa các hoạt động và tạo kế hoạch cho 24 giờ tiếp theo.

Đôi khi một cuộc thảo luận kỹ thuật ngắn là cần thiết để đồng bộ hóa nhóm. Là một Scrum Master, tôi đảm bảo rằng chúng tôi phù hợp với bảng thời gian 15 phút và thảo luận dài hơn để được tổ chức sau khi đứng lên.

Nhóm phát triển hoặc các thành viên trong nhóm thường họp ngay sau Scrum hàng ngày để thảo luận chi tiết hoặc để điều chỉnh hoặc thay thế phần còn lại của công việc của Sprint.

Nhìn từ góc độ không Scrum và Agile hơn. Tập trung vào những gì hoạt động và những gì không cho nhóm. Chỉ cần đảm bảo nhóm quyết định và thử nghiệm các thay đổi nếu họ cảm thấy điều này sẽ giúp họ hiệu quả hơn và sản xuất phần mềm chất lượng cao hơn.

Các thành viên trong nhóm nên ghi nhớ quan điểm của standup - nghĩa là cho phép nhau đóng góp cho các vấn đề có thể mất nhiều thời gian hơn khi được giữ kín hoặc trong một vòng tròn giới hạn. Mặt khác, sẽ không nhanh nhẹn để tránh các vấn đề quan trọng và liên quan đến toàn đội nhưng không phù hợp với tiêu chí hướng dẫn được nêu trong sách bỏ túi Scrum. Sẽ thật ngu ngốc khi lên lịch một cuộc họp riêng chỉ vì một quy tắc rõ ràng là để tiết kiệm thời gian.

Nó có thể không phải luôn luôn rõ ràng cho người nói vấn đề của mình là gì. Nếu cho phép anh ta bập bẹ một lúc sẽ nói rõ với người khác rằng anh ta đang vật lộn hoặc đi theo con đường cụt mà bạn có thể đi đâu đó sau tất cả. Quá quan tâm đến hình thức cũng có thể gây hại cho năng suất và làm mọi người thất vọng.

Tùy thuộc vào văn hóa, standup có thể nghiêm ngặt hoặc bao gồm các vấn đề xã hội. Nó không bao giờ nên là một sự kiện chuyển động không suy nghĩ sẽ được coi là "zombie scrum".

Thường có một sự phân đôi giữa những gì nhiều người khăng khăng khẳng định là Scrum và khái niệm về con người qua các quá trình.

Nếu có thông tin để truyền đạt, cuối cùng đó là một cuộc gọi phán xét. Nếu nó có khả năng gây ra một lượng thảo luận đáng kể, tốt nhất có thể được chuyển sang thời điểm khác. Nếu nó chỉ là một cái gì đó nhanh chóng như thời gian chết máy chủ, vv, nó có thể được thực hiện ở đó và sau đó. Tất nhiên sẽ có các sắc thái ở giữa trong trường hợp đó, chủ scrum chỉ nên đề nghị nó được thực hiện ngoại tuyến sau 15 phút (hoặc bất cứ điều gì) đã trôi qua.

Dù bằng cách nào, tôi sẽ có xu hướng có nó vào cuối sau khi quá trình standup thông thường đã hoàn thành.

Bạn hỏi, "nó có hại không?" nhưng các câu trả lời khác chủ yếu đề cập đến "đó có phải là" mục đích của cuộc họp không? "" Tôi nghĩ đó là những câu hỏi khác nhau. Nó thực sự có thể có hại khi bạn lén các mục chương trình nghị sự khác vào cuộc họp, đặc biệt nếu nó trở thành thói quen. Standups mất một phần thời gian mỗi ngày, thường là vào thời gian năng suất nhất trong ngày, vào buổi sáng khi mọi người có rất nhiều năng lượng. Bạn có thể loại bỏ năng lượng đó ngay lập tức khỏi mọi người nếu họ không thể tin tưởng vào việc đứng lên miễn là cần thiết và không còn nữa, và hoàn toàn phù hợp với họ.

Mọi người sẽ bắt đầu xuất hiện muộn, bởi vì họ đang tham gia vào một cái gì đó "năng suất hơn". Họ thậm chí sẽ không xuất hiện ở tất cả các ngày. Những người khác sẽ xuất hiện muộn hoặc không phải tất cả vì "tất cả mọi người" có xuất hiện muộn hay không. Các vấn đề phức tạp lẫn nhau, và các bản dựng đứng không còn hữu ích cho mục đích ban đầu của chúng. Nghe có vẻ cực đoan, nhưng tôi đã thấy nó xảy ra. Nếu bạn làm điều này, hãy rất cẩn thận về nơi nó dẫn đến.

Hầu hết các đội tôi đã tham gia đôi khi sẽ tổ chức các cuộc họp thiết kế ngay sau khi đứng lên và sẽ ổn nếu được sử dụng một cách tiết kiệm, nhưng thành thật mà nói, tôi sẽ nhận được kết quả tốt hơn nếu tôi nói với các đồng đội của mình rằng tôi sẽ sớm bị chặn cần thiết kế đầu vào và tôi m sẽ sắp xếp một cuộc họp cho buổi chiều hôm đó. Điều đó cũng cho họ thời gian để giải quyết vấn đề, và sau bữa ăn trưa, mọi người rơi vào tình trạng suy sụp và muốn thay đổi tốc độ. Ngoài ra, theo cách đó, bạn sẽ không khiến mọi người cạnh tranh trở thành người đầu tiên có "cuộc họp nhỏ" sau cuộc họp để họ có thể rời đi.

Tất nhiên, tôi sẽ không bao giờ ủng hộ việc mù quáng làm điều gì đó hoặc không làm điều gì đó chỉ vì một người ngẫu nhiên nào đó trên Internet (thậm chí cả tôi) nói với bạn. Cá nhân và tương tác qua các quy trình và công cụ. Nếu bạn quyết định giới thiệu một số mục chương trình nghị sự bổ sung cho các cuộc họp chờ của mình, tôi khuyên bạn nên đưa nó cụ thể vào phần hồi cứu tiếp theo, xem nhóm có thấy nó gây rối hay không và điều chỉnh khi cần thiết. Cuối cùng, mỗi đội có một mức độ thoải mái khác nhau, và sẽ có những ý tưởng khác nhau về những gì phù hợp hay không.

CẬP NHẬT: Tôi nên làm rõ: 15 phút là thời gian TỐI ĐA mà bạn nên tính đến với BẤT K stand standup nào - một standup hiệu quả theo quy tắc dưới đây thường không bao giờ nhiều hơn 5 phút và nếu bạn có thể chưng cất thời gian đó xuống nhiều hơn, thậm chí còn tốt hơn. Một lần nữa, hầu hết các cuộc thảo luận mà bạn nghĩ là có liên quan có thể dễ dàng được thảo luận giữa các thành viên trong nhóm ngoài quy trình kiểm tra hàng ngày đơn giản, một standup được cho là ở dạng thuần túy nhất.

Quy tắc ngón tay cái tôi đã kiên trì và thực hiện trong các dự án với bạn bè và mài giũa trong môi trường chuyên nghiệp:

• Hôm qua

Những gì bạn đã làm ngày hôm qua cá nhân để thúc đẩy dự án và, nếu có liên quan, điều đó đã ảnh hưởng đến người khác.

• Hôm nay

Như trên nhưng hôm nay

• Chặn

Bất cứ điều gì có thể gây ra một, tăng báo động, bất kể tầm thường như thế nào (có nghĩa là ai đó có thể đến và kiểm tra mã của bạn hoặc kiểm tra sự tỉnh táo của bạn)

Bất cứ điều gì khác là một sự xao lãng. Điều này có thể có nghĩa là "có thể" có vẻ như chúng có liên quan đến tiến độ dự án thực sự không. Nó khá khắc nghiệt nhưng nó RẤT hiệu quả cho các mục đích XP.

Mục đích của cuộc họp độc lập là giao tiếp hiệu quả. Thực hiện mục tiêu của bạn thay vì theo quy tắc mù. Vì bạn đã đăng câu hỏi này, bạn đang đi đúng hướng.

Tất cả các mối quan tâm của bạn là hợp lệ. Mặc dù chúng tôi có thể cố gắng dự đoán nếu điều này tạo ra bất kỳ vấn đề nào, tôi sẽ chỉ trả lời câu hỏi của bạn bằng cách đề nghị bạn hãy thử.

Tránh những điều sau đây:

1. Có những cuộc họp quá dài.
2. Quá nhiều người thích nhận được thông báo ở nơi khác. Làm điều đó trong một cuộc họp theo lịch trình là hấp dẫn, nhưng đừng lạm dụng nó. Hầu hết mọi người ghét các cuộc họp bade.
3. Thông tin không áp dụng cho tất cả mọi người. Một vài trường hợp ngoại lệ là tốt trong dịp.
4. Mỗi cuộc họp đều có thông báo theo thói quen thay vì cần thiết. Hãy là người chuyên nghiệp.

Đưa ra quyết định có giáo dục và được thông báo và không che giấu đằng sau việc áp dụng quá mức hoặc thực hiện các quy tắc quá theo nghĩa đen.

Hầu hết các mô hình Agile cung cấp một cấu trúc khởi đầu tuyệt vời cho các nhóm chưa quen với quy trình nhanh. Điều đó không có nghĩa là chúng không thể được thay đổi để phù hợp với nhu cầu của bạn. Nếu những thông báo này không cải thiện giao tiếp, đừng làm điều đó. Có vẻ đơn giản, nhưng ...