毎日のスクラム ミーティング
ラグビーのスクラムは、アメリカン フットボールのダウンによく似たプレーです。 スクラム メソドロジでは、スクラム会議により 1 日の作業がラグビーのプレーのように進められます。 このやり方は荒削りで乱雑かもしれませんが、前進に向けて達成する必要のあるゴールが明確であるため、チームはその共通のゴールに向かって一丸となって作業できます。 チームは、毎日スクラム会議を行い、翌日の作業内容を確認して責務を果たすことができるようにする必要があります。 各チーム メンバーは、前回の会議以降に達成した作業と当日に達成する予定の作業について説明し、他のチーム メンバーから影響を受ける可能性のある問題や障害または他のチーム メンバーからの支援が必要な問題や障害について説明します。
スクラム マスターは、会議の構成を厳格に順守し、定刻に会議を始め、15 分以内に終了するようにします。 この会議では、各チーム メンバーは次の 3 つの質問に答えます。
前回のスクラム会議以降に何を達成したか。
次回のスクラム会議までに何を達成するか。
どのような問題や障害が作業を妨げる可能性があるか。
チーム メンバーが、上記の質問に迅速かつ簡潔に回答することが重要です。 模範的な回答の一例は次のようになります。「昨日は、データベースから取り出した新しいデータ要素をクラスに反映するため、クラスを更新しました。また、新しいデータ要素がインターフェイスに表示されるようにしました。 このタスクは完了しました。 今日は、新しいデータ要素がストアド プロシージャおよびテーブル内のその他のデータ要素で計算を正しく行っているかどうかを確認します。 このタスクは今日中に完了する予定です。 他のメンバーに計算箇所を確認してもらう必要があります。 現在のところ、障害や作業を妨げる問題はありません。」 この回答例を、次の回答例と比べてください。「昨日は、クラスを操作し、それはうまくいきました。 今日は、インターフェイスを操作します。 作業を妨げる問題はありません。」これは、あまり役に立たない回答です。
これらの例が示すように、1 つ目の回答では、チーム メンバーが達成した作業、これから達成する作業、およびコードの確認で他のメンバーに支援を求めていることが伝わります。 2 つ目の例では、メンバーが操作したクラスとこれから操作するインターフェイスのコンポーネントに関する詳細が十分に伝わりません。 実際に、「達成」という言葉は一度も使用されていません。
上の例では、回答中にだれも邪魔をしていないことに注目してください。 計算箇所をレビューするのに最適なメンバーはだれであるか、またはクラスをどのように実装したかについて、何人かのメンバーが話し合うようなフォローアップ ディスカッションはありませんでした。 各メンバーに、3 つの質問に答えるのに十分な時間が割り当てられる必要があります。 詳細についての話し合いは、会議の後にチーム メンバーがそれぞれの席に戻ってから行います。また、多くの話し合いが必要な場合、それはフォローアップ会議で行います。 多くのチームは、"仮想駐車場" 方式を使ってディスカッションを後回しにします。 チーム メンバーが後で話し合いが必要であると感じるようなトピックが持ち上がった場合、どのメンバーでもホワイトボードまたはフリップチャートの "駐車場" (後で話し合うために書き留めておく場所) にそのトピックを書き込むことができます。 会議の終了時に、チームは "駐車場" に一覧表示されたトピックを話し合う予定日を設定します。
スクラムが成功するためのもう 1 つの要点は、メンバー全員が立って会議を行うことです。 メンバー全員が座っていると、特にメンバーが話をするときは、居心地がよくありません。 全員が立っていると、会議が円滑に進められ、長々と続く会話を防ぐことができます。
最後に、会議は、毎日同じ時刻に開始および終了し、毎日同じ場所で行う必要があります。 一貫性を持たせることによりパターンが確立されるため、より簡単に毎日の会議を継続できます。 また、チームは、バーンダウン、問題、リリース計画、タスクなどに関するデータまたはメモを会議の開催場所に掲示できます。 Alistair Cockburn 氏は、アジャイル ソフトウェア開発のおいて、これらの情報をラジエータと呼びます。 これらの重要な資産をチームが集まる 1 つの場所に保存および表示することは、作業を円滑に進めるのに役立つ簡単な方法の 1 つです。