毎日スクラム-開発者ごとに3つの質問をしますか、それともチケットで行きますか？
私たちは約5人の開発者からなる小さなチームです。
仮想スクラムボードを備えたチケット管理システムを使用しています。
スクラムボードにはいくつかの列があります。列の項目は優先度でソートされています。
New | Consultation | Working | Waiting | Test & Review | Done
相談=外部の誰かからのフィードバックが必要です
待っている=誰かまたは何かを待っている
2週間のスプリントを行っている間、約40〜50のアクティブなチケットがあります。
標準のスクラムでは、通常、すべての開発者が3つの質問に答えます。
昨日何をしましたか？
今日は何をしますか？
私の障害は何ですか？
どういうわけか私たちのプロセスは異なります：
列ごとに移動し、次に列内の各チケットごとに移動します。
これを行う理由はいくつかあります。
- このプロセスは独自に開発されました。私たちはそれを計画していませんでした。
- 一部の開発者は、他の開発者が話したり聞いたりしないときに「スペースを空ける」でしょう。はい、通常は1日15分ですので、この時間のリスニングは可能であると期待できます。しかし、私たちは皆自宅で仕事をしているので、誰かが聞いているかどうかはわかりません。
- 開発者が3つの質問を終えると、焦点がなくなったため、他の質問に耳を傾けない可能性があります。
- 開発者はチケットに表示されますが、作業中のチケットを見つけるために自分の名前を検索するには少し時間がかかります。ビューを切り替える方法はいくつかありますが、ビューを絶えず切り替えると、誰にとっても非常に速く煩わしくなります。
- 開発者が行くと、彼はプレゼンテーションをしているときに重要なチケットを見落とすことがありました
列をたどってからチケットを見ると、より「自然」に感じられます。また、次のチケットは自分のものである可能性があるため、誰もがより積極的に聞くように見えます。また、重要な詳細やチケットを見落とすことはありません。ほとんどの場合、開発者はこの方法でも3つの質問に間接的に回答しますが、常にそうとは限りません。このプロセスは、少なくとも私たちの環境では、まだいくらか優れていると感じています。
それで、あなたは常に3つの質問に行くべきですか、それともチケットで行くべきですか？
または、どちらのアプローチが「より良い」かを判断する方法はありますか？
（たぶん、この写真は私の質問を理解するのに役立つかもしれません）
回答
それで、あなたは常に3つの質問に行くべきですか、それともチケットで行くべきですか？または、どちらのアプローチが「より良い」かを判断する方法はありますか？
2020年版のスクラムガイドでは3つの質問が削除されましたが、2017年版のガイドでは次のように述べられています。
会議の構造は開発チームによって設定され、スプリント目標に向けた進捗に焦点を当てる場合はさまざまな方法で実施できます。一部の開発チームは質問を使用し、一部はよりディスカッションベースになります。
ですから、あなたが最善だと思うことは何でもするか、チームに何を好み、もっと役立つかを尋ねてください。
3つの質問は、目標に向けた取り組みを調整するためにカバーする必要のある基本的な事柄に焦点を当てているため、毎日の実施方法の例です。チケットについて話し合うことが優れたアプローチであることがわかった場合は、それに従ってください。
あまりにも多くの詳細に没頭しないように注意してください（毎日の後でいつでも詳細に話し合うことができます）。タイムボックスを超えると、会議に変わり、人々に精神的なチェックアウトの機会が増えます。
TL; DR
開発者またはコラムでボードを歩く必要がありますか？どちらでもない。どちらもアンチパターンです。
チームからのステータスのプルとして立ち上がりを処理しないでください、そして間違いなく全体のスプリントのために計画されたすべてのタスクのステータスのミニレビューとしてそれを使用しないでください。スタンドアップの範囲を今日の仕事に留めておけば、「ボードを歩く」ための最善の方法（ヒント：そうするべきではないので、ボードはありません）の問題はなくなります。
チームの調整に再び焦点を合わせる
あなたの質問は根本的に欠陥のある仮定から始まります：すべてのチケットでステータスレポートを実行することはスクラムで有益であるか、あるいは望ましいということです。チームが今日の活動のジャストインタイムの計画と調整を実行するという毎日のスタンドアップのすべてのポイントを見逃している限り、それは本当にX / Yの問題です。
「3つの質問」は目的を達成するための手段にすぎません。成熟度の低いチームでは、ガイドラインや話し合いのポイントがあると、チームメンバーがタスク間の依存関係を特定するのに役立ちます。ただし、その目的はステータスレポートを提供することではありません。目標は常に、チームが今日の作業を共同で計画できるようにすることです。例えば：
Sandy：昨日、中央のウィジェットの拡大に取り組みました。今日はプライマリコグを小さくする必要がありますが、それを行うにはスーザンのwhatchamacallitが必要です。
スーザン：昨日、whatchamacallitを終了したので、Sandyの準備ができました。今日はフロブノスティケーターに取り組みたかったのですが、マクガフィンの話が終わるまで立ち往生しています。誰かがまだそれに取り組んでいますか？
言い換えれば、「ボードを歩く」ために毎日のスタンドアップを使用しないでください。これを使用して、チームがその日の作業を自己組織化できるようにします。質問がチームがそれを行うのに役立つなら、素晴らしい。そうでない場合は、それらを投げます。
同様に、すでに進行中またはその日に計画されている作業のみをスタンドアップで話し合う必要があります。スプリントバックログまたは保留状態での作業は、それが現在のタスクの依存関係である場合、他の何かのブロッカーである場合、または誰かが今日進行中の作業としてそれを取り込むことを計画している場合にのみ関係します。
本当にスプリントステータスが必要な場合は、[完了]列とバーンダウンチャートを利用して、スプリント目標を達成するために順調に進んでいるかどうかを判断します。スプリントゴールのステータスが疑わしい場合、それはおそらく毎日のスタンドアップの外で別の会議に値するでしょう、そしてあなたの次のスプリント回顧展の間にスクラムチーム全体からの注意が最も確実です。せいぜい、ボードを歩くことは、効果のない通信や情報ラジエーターの欠落/無効を隠すための一時的なものです。最悪の場合、チームメンバー間のやり取りよりもステータスレポートを優先することで、チームがジャストインタイム計画で共同作業することを積極的に防ぎます。
3つの質問のアプローチは個人に焦点を当てていますが、取締役会のアプローチはチームとスプリントの目標に焦点を当てています。（または、少なくとも、ボードの右側の目標です。）私の経験では、3つの質問の落とし穴は、個人が自分が働いていることを証明しなければならないと感じたときです。しかし、チケットで行くと、すべての人と話すことすらできないかもしれません。
上で示唆したように、どちらが良いかはあなたの目標に依存します。
チームがまとまり、ボードがゴールへの道を反映している場合は、必ずボードを使用してください。（さらに進んで、ボードを明示的に右から左に使用することをお勧めします。作業を完了することに重点を置きます。）
しかし、チームが新しいか、まだうまく連携していない場合、または取締役会が実際に目標を表していない場合は、3つの質問の方が適している可能性があります。スプリントの目標は、実際には「この新しいチームをゲル化させる」、または「フランキーに乗って彼女が効果を発揮できるようにする」ことかもしれません。その場合は、誰もが何をしているのか、何が機能し、何が機能しないのかについて話す機会があることを確認する必要があります。
または、どちらのアプローチが「より良い」かを判断する方法はありますか？
アジャイル開発の1つの点は、プロジェクトの目標と組織に柔軟性を提供することです。毎日の作業方法について柔軟に対応できることの1つは、それを繰り返し改善することです。チームからフィードバックを収集し、スプリントの回顧展で日々の構造について話し合い、チームの提案を試すことを恐れないでください。
私は現在、両方のアプローチを実際に持っているチームで働いています。どちらも、毎日タスク指向で、毎日「3つの質問」があります。1つ目は、開発者間で毎日10分間、現在のボードについて話し合い、技術的な観察のためのスペースを確保することです。2つ目は、1日15分で、より幅広いチームとより人道的になるように、「3つの質問」に重点を置いています。
私たちは開発者とそのタスクを毎日行っていましたが、焦点、時間の懸念、および関連するタスクのステータスについてのまとまりのない理解の欠如の両方の理由から、プロセスを廃棄することにしました。そして、はい、開発者によるタスクの絶え間ないフィルタリングは私たちにとっても面倒でした。
コメントできないので、2セントを答えとして追加しました。
私が提案するかもしれない場合：「3つの質問」は「おへそを見つめる」かもしれませんが、あなたは本当にそれらすべてを「見回す」ことを望んでいます。
私が最初にすることは、「ビジネスに役立つ」方法で関連するタスクを一緒に検討できる便利な方法でタスクリストをグループ化する方法を見つけることです。（また、複数のグループに関連している可能性のあるタスクに「タグ付け」する機能的な方法を見つけます。ソフトウェアでは、通常、すべてが他のすべてに何らかの形で関連しています。）
次に、チームに各グループを一緒に検討し、すべての人がチームの「その日の3つの質問」となるものを（相互の情報に基づいたコンセンサスによって）選択できるように支援します。
一方では、ソフトウェア開発者は、その日の問題に集中するための優れた能力を習得することを学びました。いわば、「彼らは深く潜り、身をかがめる方法を正確に知っている」のです。しかし、今の個人的な経験から言えば、遅すぎて、自分が間違った場所に間違った理由で深く潜り、ハリケーンに襲われたことを知らなかったことに気付くのはひどいことです。「知っていたけど…」
したがって、根本的な問題は明らかです。開発者は「ディープダイバー」であり、常にボートに座って、常に乾いていて、常に全体像を見ているのでしょうか。サメを探していますか？彼らが水面を漕いでいるときに、次にどこで、なぜダイビングするのかを知るのを助けますか？それはあなたです。
さて、考えを完成させるために、時々、それらのダイバーは、あなたが知ることができなかったいくつかの重要な新しい発見で表面に戻ってくるでしょう。常に開発者自身があなたのミックスに「チケット」を提供するようにしてください。
他の人が述べたように、スクラムガイドはもはや3つの質問を規定していません。そして、正直なところ、3つの質問に基づくほとんどの毎日のスクラムはイベントの目的と矛盾しています。スクラムマスターによって調整され、チームメンバーが過去24時間について報告する必要がある場合、それは0％の自己組織化です。スプリントのステータスを真に検査し、スプリントの目標を達成するという精神でその日を計画することにはなりません。チームメンバーが自分の成功に関心を持っている開発チームの内部ディスカッションである必要があります。