スクラムとベストプラクティス

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020

スプリント計画会議

スプリント計画の多くは、製品所有者とチームの間で交渉を行い、フォーカスを決定し、今後のスプリントで取り組む作業を行います。計画会議を 4 時間以下に制限してタイムボックス化すると便利です。

会議の最初の部分では、製品所有者がチームとミーティングを行い、スプリントに含まれる可能性のあるユーザーストーリーについて話し合います。製品所有者は情報を共有し、チームがそれらのストーリーに関して持っている質問に回答します。この会話では、データソースやユーザーインターフェイスのレイアウトなどの詳細が表示される場合があります。また、応答時間の期待や、セキュリティと使いやすさに関する考慮事項が明らかになることがあります。チームは、バックログ項目フォーム内でこれらの詳細をキャプチャする必要があります。会議のこの部分では、チームは何を構築する必要があるかを学習します。

スプリントを計画する際に、バックログをキャプチャして追加するためのその他の要件が見つかることがあります。適切に定義され、優先順位が付いていることを確認します。

また、計画作業の一環としてスプリントの目標を設定することで、チームは各スプリントにとって最も重要な点に集中し続けることができます。

スプリントを計画したら、計画を主要な利害関係者と共有することができます。

詳細については、次のリソースを参照してください。

スプリントの目標を設定する

スクラムチームはスプリントの目標を使用して、スプリントアクティビティに集中します。多くの場合、スプリント計画会議中にこの目標を設定します。目標は、チームがスプリントの終わりまでに達成したいと考えるものを要約したものです。目標を明示的に示すことで、コア目的のチーム内で共有の理解を作成します。スプリントの目標は、優先順位に関する競合が発生したときにチームを導く際にも役立ちます。

塹壕からのヒント: スプリントの目標を定義する

スプリントの目標は、製品所有者とチームがそのスプリントを達成するための最終的な目標と考えるものを定義します。実際にリレーションシップを持たないバックログ項目のランダムな選択ではなく、チームが何を達成しようとしているかをキャプチャする短いテキストです。通常、製品所有者は、次のスプリントのために多くの項目を選択する前に、スプリントの目標を思い付く。そのスプリントの項目はすべて、その共通の目標に適合している必要があります。

スプリントの目標は機能指向である場合がありますが、デプロイの自動化やテスト自動化などの大規模なプロセスコンポーネントがある場合もあります。

例えば次が挙げられます。

このスプリントでは、単純なユーザーストーリーに焦点を当てます。これを使用して、提案されたソリューションが機能することを証明します。
このスプリントでは、Web サイトの管理セクションを適切にセキュリティで保護するセキュリティ機能の実装を中心に説明します。
このスプリントは、お金の収集を開始できるように、最も重要な支払いゲートウェイを統合することです。

スプリントの目標を設定すると、チームは集中し続けることができます。スプリント内のタスクの優先順位を簡単に定義でき、関係する利害関係者とエンドユーザーの数を制限するのに役立つ可能性があります。

スプリントレビュー中に最も重要な質問は、スプリントの目標を達成できたかどうかです。完了したストーリーの数が 2 番目に表示されます。目標が達成された場合、すべてのストーリーが完了していない場合でも、スプリントは成功します。

Jesse Houwing、Visual Studio devops Ranger、およびアバナード・オランダで働くシニアコンサルタントによって提供されました。

成功するトリアージ会議のためのヒント

バグの修正は、他の作業とのトレードオフを表します。トリアージ会議を利用して、プロジェクトのスコープ、予算、スケジュールに関連する他の優先事項と比較して、各バグ修正の重要性を判断します。

修正するバグと優先度と重大度を割り当てる方法を評価するためのチームの基準を確立します。重要な価値 (または遅延の大きな機会コスト) またはその他のプロジェクトリスクの機能に関連するバグには、優先度と重大度を高く割り当てる必要があります。トリアージ条件を他のチームドキュメントに保存し、必要に応じて更新します。
トリアージ条件を使用して、修正するバグとその状態、優先度、重大度、およびその他のフィールドを設定する方法を決定します。
開発サイクルの場所に基づいてトリアージ条件を調整します。早い段階で、トリアージするほとんどのバグを修正することに決めるかもしれません。ただし、サイクルの後半でトリアージ条件を上げて、修正する必要があるバグの数を減らすことができます。
バグをトリアージしたら、開発者に割り当てます。開発者は、修正プログラムを実装する方法を調査して決定できます。

技術的負債を管理する

チーム全体の継続的な改善活動の一環として、バグバーと技術的負債を管理することを検討してください。次の目的のリソースが見つかる場合があります。

「Good and Bad Technical Debt (and how TDD helps) (良い技術的負債と悪い技術的負債 (そして TDD がどのように役立つか))」、投稿者: Henrik Kniberg
技術的負債の管理 (投稿者: Sven Johann & Eberhard Wolff)

塹壕からのヒント:バグ管理

アジャイルバグ管理: Oxymoron ではない
による Gregg Boer、プリンシパルプログラムマネージャー、Visual Studio Cloud Services (Microsoft)

すべてのスプリントで既知のバグ負債に対処する

すべてのスプリントでは、チームはバグバックログに残っているバグを確認し、既知のバグのセットをゼロ (ゼロに近い) に抑える能力を割り当てています。これが 1 日、1 週間、またはスプリント全体のいずれであっても、最初にバグを修正します。スプリント内で後で見つかったバグは、その初期コミットメントの一部とは見なされません。優先度が高い場合を除き、次のスプリントのバグバックログに置かれます。

多くのチームは、コミットメントベースの組織で働いています。多くの場合、経営陣は、コミットメントを満たすチームの能力に大きな価値を置きます。既知の一連のバグに対して容量計画を行うと、スプリント計画がより決定的になり、コミットメントを満たす機会が増えます。スプリント中に検出された新しいバグは、最初のコミットメントの一部ではなく、次のスプリントに対処できます。

企業全体のバグ負債を管理する

負債が継続的に排除される文化に移行している組織は、次の質問に対処している可能性があります。チームに何をすべきかを正確に伝えずに、チームのバグ数を減らすにはどうすればよいでしょうか。リーダーシップは、チームが変化することを望んでいますが、チームがどのように変化するかを決定するための自律性を与えます。 1 つのオプションは、バグキャップを使用することです。

たとえば、エンジニアごとに 3 つのバグのバグ上限を考えてみましょう。そのため、10 人のチームは、バグバックログに 30 個を超えるバグを含めることはできません。チームが上限を超えている場合は、新機能の作業を停止し、バグ数を上限以下に抑えることが期待されます。チームは常に上限以下に維持することが期待されていますが、チームはどのようにそれを達成するかを決定します。バグキャップにより、チームがバグ負債を長く抱えすぎないようにします。チームは、最初にバグが挿入される原因となるミスから学ぶことができます。

バグキャップは、バグバックログに含まれるバグを表していることをお忘れなく。機能が開発されたスプリント内で検出され、修正されたバグは含まれません。これらのバグは借金ではなく、未完了の作業と見なされます。

バグは技術的負債に寄与しますが、すべての負債を表しているわけではありません。

ソフトウェアの設計が不十分な場合、コードが記述されていない、または短期的な修正がすべて技術的負債に寄与する可能性があります。技術的負債は、これらすべての問題から生じる追加の開発作業を反映しています。

PBI、ユーザーストーリー、バグなどの技術的負債に対処するための作業を追跡します。技術的負債の発生と対処におけるチームの進捗状況を追跡するには、作業項目と追跡する詳細を分類する方法を検討する必要があります。任意の作業項目にタグを追加して、任意のカテゴリにグループ化できます。

スクラムマスターの役割

スクラムマスターは、スクラムプロセスを採用することで、健全なチームを構築し、維持するのに役立ちます。彼らはスクラムの方法の適切な活用においてスクラムチームを導き、コーチし、教え、支援します。スクラムマスターは、チームが障害を克服し、大幅な生産性の向上に向けてチームを推進するために、変更エージェントとしても機能します。

スクラムマスターズの主な責任は次のとおりです。

チームがスクラムプロセスを採用し、従うことをサポートします。たとえば、毎日のスクラム会議を 45 分間続くオープンなディスカッションにしないでください。
スプリントの開始後、製品所有者またはチームメンバーが作業を追加しないように保護します。
チームが前進を妨げるブロックの問題を解消します。この作業では、新しいビルドコンピューターの発注書の承認やチーム内の競合の解決など、小さなタスクを完了することが必要になる場合があります。
チームが発生した競合や問題を解決し、プロセスから学ぶのに役立ちます。
非表示の問題を明らかにする質問をし、ユーザーが通信しているものがチーム全体で十分に理解されていることを確認します。
主要な問題になる可能性のある問題からチームを特定し、保護します。バグが検出された直後に修正する方が安価であるのと同様に、チームの問題が小さく管理しやすいときに修正する方が簡単で中断が少なくなります。
スプリントレビュー会議中に、チームが不完全なユーザーストーリーを提示できないようにします。
データを収集し、分析し、ビジネス利害関係者に提示して、チームがどのように改善し、成長しているかを示します。たとえば、チームが提供する価値の量を増やしながらバグを減らした場合は、ビジネス関係者への定期的なコミュニケーションを通じてその価値を見えるようにします。

良いスクラムマスターは、優れたコミュニケーション、交渉、紛争解決のスキルを持っているか、または開発します。彼らは積極的に人々が言って書く言葉に耳を傾ける。また、ボディランゲージ、表情、話す速度、その他の非言語コミュニケーションにおけるメッセージの伝え方にも注意を向けています。

バグが検出された後すぐに修正する方が安価であるのと同様に、チームの問題が大きな問題に発展する前に、小さくて管理しやすいときにチームの問題を修正する方が簡単で中断が少なくなります。

毎日のスクラム会議

毎日のスクラム会議は、チームが翌日に何を行う必要があるかに集中するのに役立ちます。集中することで、チームはスプリントコミットメントを満たす能力を最大限に高めるのに役立ちます。スクラムマスターは、会議の構造を強制し、時間に基づいて開始され、15 分以内に終了することを確認する必要があります。

スクラム会議の成功の 3 つの側面は次のとおりです。

全員が立ち上がる。立ち上がりは、会議に集中して短く保つのに役立ちます。
それらは時間に基づいて開始および終了し、毎日同じ場所で同時に発生します
全員が参加し、各チームメンバーが次の 3 つのスクラムの質問に回答します。
- 私は最近スクラム以来何を成し遂げましたか?
- 次のスクラムの前に何を達成できますか?
- どのようなブロックの問題や障害が作業に影響を与える可能性がありますか?

注

スクラム会議の焦点は、あるチームメンバーから別のチームメンバーに渡す必要がある作業の状態です。

チームメンバーは、質問に迅速かつ簡潔に答えるように努める必要があります。例えば次が挙げられます。

"昨日、データベースからプルする新しいデータ要素を反映するようにクラスを更新し、インターフェイスに表示されるようにしました。このタスクは完了です。現在、新しいデータ要素がストアドプロシージャとテーブル内の他のデータ要素を使用して正しく計算されていることを確認します。私は今日このタスクを達成することができると信じています。計算を確認する人が必要です。障害やブロックの問題はありません。

この応答は、チームメンバーが何を成し遂げたか、チームメンバーが何を行う予定なのか、チームメンバーがコードを見るのを助けたいと思っていることを伝えます。

次の例とは対照的です。

「昨日、クラスに取り組み、それは動作しました。」今日、私はインターフェイスに取り組みます。ブロッキングの問題はありません。

チームメンバーは、作業したクラスや完了するインターフェイスコンポーネントに関する十分な詳細を提供していません。実際、「accomplished」という言葉は一度も話に上がりませんでした。

報告中に誰も口を挟まないことが重要です。各人は、3つの質問に答えるのに十分な時間を持っている必要があります。

会議の後、人々が自分の机に戻ったり、大量の会話が必要な場合はフォローアップ会議で、より詳細なフォローアップディスカッションを行う必要があります。

多くのチームは、"仮想駐車場" メソッドを使用してディスカッションを遅らせていきます。さらに議論が必要だとチームメンバーが考える話題が出た場合は、ホワイトボードかフリップチャートに黙って近づき、その話題を検討事項としてリスト化するといいでしょう。会議の最後に、チームはリストされたアイテムの処理方法を決定します。

スプリントレビュー会議

スプリントの最終日にスプリントレビュー会議を実施します。チームは、スプリントで完了した各製品バックログ項目を示します。製品の所有者、顧客、利害関係者は、期待を満たすユーザーストーリーを受け入れ、新しい要件を特定します。多くの場合、お客様はデモを見た後にニーズをより完全に理解し、表示する変更を特定できます。

この会議に基づいて、一部のユーザーストーリーは完了として受け入れられます。不完全なユーザーストーリーは、製品バックログに残ります。新しいユーザーストーリーがバックログに追加されます。両方のストーリーセットがランク付けされ、次のスプリント計画会議で推定または再推定されます。

この会議と振り返り会議の後、チームは次のスプリントを計画します。ビジネスニーズはすぐに変化するため、製品所有者、顧客、利害関係者とのこの会議を利用して、製品バックログの優先順位をもう一度確認できます。

スプリント振り返り会議

振り返りは、適切かつ定期的に行われると、継続的な改善をサポートします。

スプリント振り返り会議は、通常、スプリントレビュー会議の後、スプリントの最終日に行われます。この会議では、チームがスクラムの実行と、調整が必要になる可能性のあるものを調査します。

ディスカッションに基づいて、チームは 1 つ以上のプロセスを変更して、独自の有効性、生産性、品質、満足度を向上させる可能性があります。この会議と結果の改善は、自己組織化のアジャイル原則にとって重要です。

注

チームの振り返りをサポートするには、Marketplace の振り返り拡張機能のインストールを検討してください。この拡張機能は、プロジェクトのマイルストーンに関するフィードバックの収集、フィードバックの整理と優先順位付け、および時間の経過に伴うチームの改善に役立つ実用的なタスクの作成と追跡をサポートします。

チームスプリントの振り返り中に、次の領域に対処します。

チームの一般的な有効性、生産性、品質に影響を与えた問題。
チームの全体的な満足度とプロジェクトフローに影響を与えた要素。
不完全なバックログ項目の原因として何が発生しましたか? 今後これらの問題を防ぐために、チームはどのようなアクションを実行できますか?

たとえば、チームの 1 人の個人しか実行できない複数のタスクを持つチームがあるとします。分離された専門知識によって、スプリントの成功を脅かす重要なパスが生み出されました。個々のチームメンバーは余分な時間を置いたが、他のチームメンバーは、彼らが助けるためにそれ以上を行うことができなかった不満を感じていた。今後、チームは eXtreme プログラミングを練習して、時間の経過とともにこの問題を解決することにしました。

チームとして、スプリント中の問題の発生を最小限に抑えるために 1 つ以上のプロセスを適応させるかどうかを判断します。

チームは、改善を実装するために何らかの作業を行う必要がある場合があります。たとえば、失敗したビルドの数が多すぎることによって悪影響を受けたチームは、継続的インテグレーションを実装することにしました。プロセスを中断する必要がなかったため、実稼働ビルドで試用ビルドを有効にする前に、試用ビルドを設定するのに数時間かかりました。この作業を表現するために、スパイクを作成し、製品の残りのバックログに対して機能するように整理しました。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-10-08