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

  • [アーティクル]

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

スプリント計画会議

スプリント計画の多くは、製品所有者とチームの間で交渉を行い、今後のスプリントで取り組む焦点と作業を決定することと関係します。 計画会議の時間を定めて、4 時間以内に制限すると役に立ちます。

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

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

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

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

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

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

スクラム チームは、スプリント目標を使ってスプリント活動に集中します。 多くの場合、スプリント計画会議中にこの目標を設定します。 目標は、スプリントの終了までにチームが達成したいことを要約したものです。 目標を明示的に指定することで、主要な目的の理解をチーム内で共有することができます。 スプリント目標は、優先度に関する競合が発生したときにチームを導くうえでも役立ちます。

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

スプリント目標では、製品所有者とチームが、そのスプリントを達成するための最終目標と見なすことを定義します。 これは、あまり関係のないバックログ項目の任意の選択ではなく、チームが何を達成しようとしているかを記録する短いテキストです。 通常、製品所有者は、次のスプリントの多くの項目を選択する前にスプリント目標を設定します。 そのスプリントの項目はすべて、その共通の目標に適合する必要があります。

スプリント目標ではフィーチャーを重視することもできますが、デプロイの自動化やテストの自動化などの大規模なプロセス コンポーネントを含めることもできます。

次に例を示します。

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

スプリント目標を設定すると、チームの集中力を保つのに役立ちます。 スプリント内のタスクの優先度を定義しやすくなり、関係する利害関係者とエンド ユーザーの数を制限するのにも役立つ場合があります。

スプリントのレビュー中に自問自答すべき最も重要なことは、スプリント目標を達成できたかどうかです。 完了したストーリーの数は 2 番目です。 目標が達成できたなら、すべてのストーリーが完了していなくても、そのスプリントは成功です。

"協力: Jesse Houwing、Visual Studio DevOps Ranger および Avanade Netherlands で働くシニア コンサルタント。"

トリアージ会議を成功させるためのヒント

バグの修正は、他の作業とのトレードオフを表します。 トリアージ会議を使い、プロジェクトのスコープ、予算、スケジュールを満たすことに関連する他の優先度に対して、各バグを修正することがどれほど重要かを判断します。

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

技術的負債を管理する

チームの継続的な改善活動の全体的なセットの一環として、バグ バーと技術的負債を管理することを検討してください。 次のリソースが役立つかもしれません。

前線からのヒント: バグ管理

アジャイル バグ管理: 矛盾ではない
"作成者: Gregg Boer、Microsoft の Visual Studio Cloud Services、プリンシパル プログラム マネージャー"

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

すべてのスプリントで、チームはバグ バックログに残っているバグを調べて、その既知の一連のバグをゼロ (またはほぼゼロ) に抑えるためのキャパシティを割り当てます。 それが 1 日、1 週間、またはスプリント全体であっても、最初にバグを修正します。 スプリント内で、後で見つかったバグは、その初期コミットメントの一部とは見なされません。 優先度が高くない限り、次のスプリントのバグ バックログに配置されます。

多くのチームは、コミットメントベースの組織で働いています。 多くの場合、経営陣は、コミットメントを満たすチームの能力に高い価値を置きます。 既知の一連のバグに対してキャパシティ プランニングを行うと、スプリント計画がより確定的になり、コミットメントを満たす可能性が高まります。 スプリント中に検出された新しいバグは、初期コミットメントの一部でなく、次のスプリントで対処できます。

エンタープライズ全体のバグ負債を管理する

負債が継続的に除去されるような文化に移行する組織は、おそらく次の問題に対処することになります。すなわち、チームに何をすべきかを正確に伝えることなく、チームのバグ数を減らすにはどうすればよいかという問題です。 リーダーは、チームが変化することを望むと同時に、変化の方法を決定する自律性をチームに与えます。 1 つのオプションは、バグ キャップを使用することです。

たとえば、エンジニアごとに 3 個のバグというバグ キャップを考えてみましょう。 そのため、10 人のチームでは、30 個を超えるバグをバグ バックログに含めることはできません。 チームがキャップを超えている場合は、新機能の作業を停止し、バグ キャップ以下になるようにする必要があります。 チームは常にキャップ以下になるようにする必要がありますが、その実現方法はチームで決定します。 バグ上限を使うと、チームがバグ負債を長く抱えすぎないようにすることができます。 チームでは第一に、バグが挿入される原因となった間違いから学ぶことができます。

バグ上限は、バグ バックログ内のバグを表すことを忘れないでください。 ある機能を開発するスプリント内で見つかり、修正されたバグは含まれません。 それらのバグは、負債ではなく、未完了の作業と見なされます。

バグは技術的負債の一因となりますが、すべての負債を表すとは限りません。

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

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

スクラム マスターの役割

スクラム マスターは、スクラム プロセスを採用することで、健全なチームの構築と維持を支援します。 彼らはスクラム チームに対してスクラム メソッドの適切な採用を指導し、コーチングし、教え、支援します。 また、スクラム マスターは変更エージェントとしても活動し、チームが懸案事項を克服して、生産性を大幅に向上できるよう支援します。

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

  • チームによるスクラム プロセスの採用と遵守をサポートします。 たとえば、毎日のスクラム会議が 45 分続くオープンなディスカッションにならないようにする必要があります。

  • 製品所有者またはチーム メンバーが、スプリントの開始後に作業を追加しないようにします。

  • チームの前進を妨げる障害となっている問題をクリアします。 この作業では小さなタスクを完了することが必要になる場合があります。たとえば、新しいビルド コンピューターの発注書の承認や、チーム内の対立の解決などです。

  • チームが生じた対立や問題を解決し、そのプロセスから学習できるように支援します。

  • 隠れた問題が明らかになるような質問を行い、メンバーが伝えている情報がチーム全体で十分に理解されていることを確認します。

  • 重大な問題になる可能性のある問題を特定し、チームを保護します。 バグは検出された直後に修正する方が安価であるのと同様に、チームの問題も小さく管理しやすいときに修正する方が簡単で、混乱が少なくなります。

  • スプリント レビュー会議中に、チームが不完全なユーザー ストーリーを提示できないようにします。

  • データを収集、分析してビジネス上の利害関係者に提示し、チームがどのように改善され、成長しているかを示します。 たとえば、チームが提供した価値の量を増やしつつ、バグは減っている場合は、ビジネス上の利害関係者への定期的なコミュニケーションを通じてその価値を可視化します。

優れたスクラム マスターは、コミュニケーション、交渉、紛争解決の優れたスキルを持っているか、上達させます。 メンバーが発言した言葉や書いた言葉に、積極的に耳を傾けます。 また、メンバーがどのようにメッセージを伝えるかにも注意します。たとえば、ボディ ランゲージ、表情、声のペース、その他の言葉によらないコミュニケーションなどです。

バグは検出された直後に修正する方が安価であるのと同様に、チームの問題も小さく管理しやすいうちに、重大な問題になる前に修正する方が簡単で、混乱が少なくなります。

毎日のスクラム会議

毎日のスクラム会議は、チームが翌日に行う必要がある作業に集中するのに役立ちます。 集中力を維持することで、チームがスプリントのコミットメントを満たす能力を最大限に高めることができます。 スクラム マスターは、会議の構成を確実に実施し、会議を時間通りに開始して、15 分以内に終了させるよう努める必要があります。

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

  • 全員が立っています。 立っていることは、会議を集中的な短いものにするのに役立ちます。
  • 時間どおりに開始および終了し、毎日同じ場所で同じ時間に開催します
  • 全員が参加し、各チーム メンバーが 3 つのスクラムの質問に回答します。
    • "最新のスクラム以降、何を達成しましたか?"
    • "次のスクラムの前に何を達成できますか?"
    • "作業に影響を与えるおそれがある障害となっている問題や懸案事項は何ですか?"

注意

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

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

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

この応答は、チーム メンバーが達成したこと、チーム メンバーが達成する予定であること、チーム メンバーがコードを確認してもらうサポートを必要としていることを伝えています。

次の例とは対照的です。

"昨日は、クラスに取り組んで、うまくいきました。 今日は、インターフェイスに取り組みます。 障害となっている問題はありません。"

このチーム メンバーは、取り組んだクラスや、完了する予定のインターフェイス コンポーネントに関する十分な詳細を提供していません。 実際に、達成という言葉も使われていません。

報告中は、誰も口を挟まないようにすることが重要です。 各メンバーに、3 つの質問に答えるのに十分な時間を与える必要があります。

より詳細なフォローアップ ディスカッションは、会議の後、メンバーが各自のデスクに戻ってから行う必要があります。または、かなりの量の会話が必要な場合は、フォローアップ会議で行います。

多くのチームでは、"仮想駐車場" メソッドを使ってディスカッションを遅延させます。 あるチーム メンバーがさらなる議論が必要だと思うテーマを思い付くと、ホワイトボードやフリップグラフまで静かに歩いて行き、そのテーマを駐車場に記入することができます。 会議の最後に、チームは記入された項目の処理方法を決定します。

スプリント レビュー会議

スプリントの最終日にスプリント レビュー会議を実施します。 チームは、スプリントで完了した各プロダクト バックログ項目を示します。 製品所有者、顧客、利害関係者は、期待に沿ったユーザー ストーリーを確認し、新しい要件を特定します。 多くの場合、顧客はデモを見た後に自分たちのニーズをより明確に理解し、場合によっては、今後に向けて希望する変更点を確認します。

この会議に基づいて、一部のユーザー ストーリーが完了として確認されます。 不完全なユーザー ストーリーは、プロダクト バックログに残ります。 新しいユーザー ストーリーはバックログに追加されます。 両方のストーリーのセットがランク付けされ、次のスプリント計画会議で見積もりまたは再見積もりが行われます。

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

スプリント振り返り会議

振り返りは、適切かつ定期的に実施される場合、継続的な改善をサポートします。

通常、スプリント振り返り会議は、スプリントの最終日に、スプリント レビュー会議の後に行われます。 この会議では、チームがスクラムの実行と、微調整が必要かもしれないことについて調べます。

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

注意

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

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

  • チームの全般的な有効性、生産性、品質に影響を与えた問題。

  • チームの全体的な満足度とプロジェクト フローに影響を与えた要素。

  • 不完全なバックログ項目が生じた原因は何だったか。 今後このような問題を防ぐために、チームではどのようなアクションを実行できるか。

    たとえば、チームのある 1 人にしか実行できないタスクがいくつかあったチームを考えてみましょう。 孤立した専門知識によって、スプリントの成功を脅かすクリティカル パスが作成されました。 その 1 人のチーム メンバーは余分な時間を費やしましたが、他のチーム メンバーはそれ以上支援できないことに不満を感じていました。 今後、チームではエクストリーム プログラミングを実践し、時間をかけてこの問題の是正に役立てることにしました。

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

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