スクラムデイリースタンドアップミーティングでチェックインに関連しないディスカッションを行うことは許容されますか？
人々が私に潜在的に明白な質問を甘やかしてくれることを願っています。私は、毎日スクラムミーティングを行う多くの組織で働いてきました。一部の組織はチェックインにスクラムのみを使用することに非常に厳格です（「3つの質問」-昨日何をしましたか、今日何をしていますか、ブロッカーはいますか）。発表または詳細な技術的議論。
この記事 のように、このようなチェックインに関連しないディスカッションを許可するのは誤りであるという議論を聞いたことがあります。スクラムミーティングは、スクラムマスターからの一般的な発表には使用しないでください。技術的な議論など.
私がこれから見た主な害は、会議が必要以上に長く続く可能性があることです（そして、私に関係のない詳細の議論に座ることを余儀なくされるのは面倒です）。
グループ全体に関連しておらず、「3つの質問」の一部でもないディスカッションは、スタンドアップの一部であってはならないことは明らかです。しかし、グループ全体に関連する他のアナウンスがあり、とにかく議論する必要がある場合、その時点で（個別の会議や電子メールではなく）アナウンスを行うことは有害ですか？
Daily Scrumの目的は、開発チームが過去24時間を確認し、次の24時間の計画を更新することです。
この目標を達成し、15分でカバーできるものはすべて、スクラムガイドのとおり、デイリースクラムの目的にぴったりです。発生する必要があるより長い会話がある場合は、それらが何であるかについての実行中のメモを保持し、デイリースクラムの最後に、そのトピックを気にする小さなグループに分けてください。
デイリースクラムの目的は、問題の解決策を見つけることです。その後に...
確かにそれは許容できますが、最初に重要なことに集中してください。 15分以内に残り時間がある場合、これは swarming である5人の開発チームによくあることです（開発中により頻繁に同期するため）、余分な通信や問題は発生しません。発表。デイリーの終わりまでそれらを延期する限り。
スクラムマスターとして、私はチームが3つの重要な質問に何らかの形で答えることを確認します。
Daily Scrumは、開発チームがアクティビティを同期し、次の24時間の計画を作成するための15分のタイムボックスイベントです。
場合によっては、チームを同期するために短い技術的な議論が必要になります。スクラムマスターとして、私は15分のタイムボックスに適合し、スタンドアップ後に開催される長いディスカッションをカットオフすることを確認します。
開発チームまたはチームメンバーは、デイリースクラムの直後に会合して、詳細なディスカッションを行ったり、残りのスプリントの作業を調整または再計画したりすることがよくあります。
非スクラムとよりアジャイルの観点から見てください。チームにとって何が機能し、何が機能しないかに焦点を当てます。チームが決定を下し、変更がより効果的で高品質のソフトウェアを作成できると感じた場合は、変更を実験してください。
チームメンバーは、スタンドアップのポイントを覚えておく必要があります。つまり、非公開にしたり、限られたサークル内にいると時間がかかる問題にお互いが貢献できるようになります。一方、重要でチーム全体に関係する問題を回避することは非常に俊敏ではありませんが、スクラムポケットブックに記載されているガイドラインの基準には適合しません。明らかに時間を節約することを意図しているルールのために、別の会議をスケジュールするのは愚かでしょう。
彼の問題が何であるかは必ずしも話者にとって明確ではないかもしれません。彼がしばらくしゃべることを許可すると、彼が苦労している、または行き止まりの道を進んでいることを他の誰かに明らかにする場合、結局どこかに行く可能性があります。フォームにあまりにも関心を持つことは、生産性を損ない、人々を苛立たせることにもなります。
文化に応じて、スタンドアップは厳格になる場合もあれば、社会問題も含まれる場合もあります。 「ゾンビスクラム」と見なされる、無知な動きのあるイベントであってはなりません。
多くの場合、さまざまな人々がスクラムであると強く主張していることと、プロセスに関する人々の概念との間には二分法があります。
伝える情報がある場合、最終的には判断の呼びかけです。かなりの量の議論を引き起こす可能性がある場合は、別の時間に移動するのが最善です。それがサーバーのダウンタイムなどのように迅速なものである場合、それはそこで行うことができます。もちろん、中間にシェードがあります。その場合、スクラムマスターは、15分（または何でも）が経過するとオフラインになることを提案するだけです。
いずれにせよ、通常のスタンドアッププロセスが完了した後、私はそれを最後に持つ傾向があります。
「有害ですか」と尋ねました。しかし、他の回答は主に「それは「会議の目的」ですか？」と答えましたが、私はそれらは異なる質問だと思います。あなたが他の議題をこっそり会議にこっそり持ち込むとき、特にそれが常習的になるならば、それは本当に有害でありえます。スタンドアップは、毎日かなりの時間を費やします。通常、人々が多くのエネルギーを持っている朝の最も生産的な時間です。スタンドアップが必要以上に長くなくなり、完全に関係があると見なせない場合は、そのエネルギーを人々から直接吸収することができます。
彼らは「より生産的な」何かに従事しているので、人々は遅く現れ始めます。彼らはすべての日でまったく表示されません。 「全員」が遅れて現れるか、まったく現れないため、他の人々は遅れて現れるか、すべてではないでしょう。問題は互いに複雑になり、スタンドアップは本来の目的に役立つものではなくなります。それは極端に聞こえますが、私はそれが起こるのを見てきました。これを行う場合は、veryどこにつながるかに注意してください。
私が参加しているほとんどのチームは、スタンドアップの直後に設計会議を開くことがありますが、控えめに使用すれば大丈夫ですが、正直に言うと、スタンドアップでチームメイトに設計入力が必要になるとすぐにブロックされ、 mその日の午後に会議をスケジュールするつもりです。それは彼らに同様に問題を熟考する時間を与え、昼食後に人々は少し不調に陥り、ペースの変更を望みます。また、そうすることで、スタンドアップ後に最初に「ミニミーティング」を行う人々が競争しないように、彼らが去ることができます。
もちろん、インターネット上のランダムな男（私も含む）があなたに言ったからといって、私が盲目的に何かをしたり、何もしないことを主張することは決してありません。 個人とプロセスとツールの相互作用 スタンドアップミーティングにいくつかの追加の議題項目を導入することにした場合は、後続の回顧で具体的に取り上げることをお勧めします。かどうか、そして必要に応じて調整を行います。最終的に、各チームは異なる快適さのレベルを持ち、何が適切かどうかについて異なる考えを持つことになります。
更新：私は明確にする必要があります：15分は、すべてのスタンドアップで考慮する必要がある最大時間です。以下のルールに従う効率的なスタンドアップは、通常最大で5分を超えることはなく、その時間をさらに短縮できる場合は、さらに優れています。繰り返しますが、あなたが関連すると考えるほとんどの議論は、スタンドアップが最も純粋な形であることになっている単純な毎日のチェックインプロセス以外のチームメンバー間で簡単に議論できます。
経験則として、友人とのプロジェクトの最中、ドリルダウンし、プロの環境で磨きました。
- 昨日
プロジェクトを進めるために昨日個別に行ったこと、および必要に応じて他の人に影響を与えたもの。
- 今日
上記と同じですが、今日
- ブロッカー
些細なことでも、アラームを発生させる可能性のあるすべてのこと（誰かが来てあなたのコードをチェックしたり、健全性チェックをしたりできることを意味します）
それ以外は注意散漫です。これは、プロジェクトの進行状況に「関連がある」ように見えるかもしれないという主題を意味する場合があります。それはかなり厳しいですが、XPの目的には非常に効果的です。
スタンドアップミーティングの目的は効果的なコミュニケーションです。盲目的なルールに従うのではなく、それをあなたの目標にします。この質問を投稿してから、順調に進んでいます。
あなたの懸念はすべて有効です。これにより問題が発生するかどうかを予測することはできますが、試してみることをお勧めします。
以下は避けてください。
- 長すぎる会議がある。
- アナウンスを他の場所で入手することを好む人が多すぎます。予定された会議中にそれを行うのは魅力的ですが、乱用しないでください。ほとんどの人は、出会いを嫌います。
- 情報はすべての人に当てはまるわけではありません。いくつかの例外は場合によっては問題ありません。
- すべての会議には、必要ではなく習慣からの発表があります。職業であること。
知識に基づいた情報に基づいた決定を行い、ルールを過度に適用したり、ルールを文字どおりに取り入れたりすることの背後に隠れないでください。
アジャイルモデルのほとんどは、アジャイルプロセスを初めて使用するチームに最適な開始構造を提供します。これは、ニーズに合わせて変更できないという意味ではありません。これらの発表によってコミュニケーションが改善されない場合は、改善しないでください。シンプルなようですが...