スクラム
スクラムとは、アジャイルの基本原則と価値に基づいた、プロジェクトを実行するためのフレームワークです。 スクラムには、チームがより速くより大きな価値を顧客に提供するのに役立つ、アクティビティのセットが定義されます。 これらのアクティビティによって、顧客は、作業の進行に合わせてチームの作業を見直したり、チームの作業に指針や影響を与えたりすることができます。 このアプローチでは、プロジェクトの開始時にすべてを定義しようとはしません。 チームは、短いイテレーション (スプリント) で作業し、チームの進行に合わせて計画を定義します。 スクラムの基となっているアジャイルの基本原則と価値については、「アジャイルの基本原則と価値 (Jeff Sutherland 著)」を参照してください。
MSF for Agile Software Development v5.0 はスクラムに基づいています。 したがって、チームは、中心となる開発アクティビティと統合されたツールを使用して、スクラムを導入できます。
このトピックの内容
|
.png "スクラム") |
プロジェクトの準備
プロジェクトを開始する前に、次の各タスクを実行する必要があります。
ビジネス ケースの確立
チームの組み立て
チームのインフラストラクチャの設定
ビジネス ケースを確立するには、ビジネスのニーズと根拠を識別し、ビジョンを定義し、資金を調達します。 Geoffrey Moore の著書『Crossing the Chasm』では、ビジョンを明確化するための適切な指針を示しています。 詳細については、"Crossing the Chasm" についての Web リソースを参照してください。
ビジネス ケースを確立したら、チームを構成し、スクラム マスターと製品所有者を特定する必要があります。 詳細については、「ロール」を参照してください。
最後に、チームはインフラストラクチャを設定する必要があります。 たとえば、Visual Studio Team Foundation Server と Visual Studio アプリケーション ライフサイクル管理 (ALM) をインストールし、チーム プロジェクトの作成や必要に応じたカスタマイズを行い、エンジニアリング手法を設定します。 詳細については、「Visual Studio のアプリケーション ライフサイクル管理の概要」、「チーム プロジェクトのカスタマイズ」、および「エンジニアリング手法」を参照してください。
プロジェクトの計画
スクラム プロジェクトでは、チームの作業は主に一連のスプリントにて製品を開発することです。 ただし、チームはまずプロジェクトの上位の計画を作成する必要があります。 この計画は、プロジェクトの進行時に細部にわたってチームが行う決定の指針となるロードマップです。 チームは計画を実行しながら、計画に変更を加えていきます。 チームがプロジェクトの計画を終了すると、製品バックログと、必要に応じてリリース計画が作成されます。
製品バックログの作成
製品バックログとは、ユーザーのニーズや価値について記述したユーザー ストーリーの一覧です。 ユーザー ストーリーは、ビジネス価値とリスクによって優先度が付けられ、チームは、ストーリー ポイントと呼ばれる抽象的な単位でユーザー ストーリーを見積もります。
.png "ユーザー ストーリーの作成、順位付け、および見積もり")
.gif "手順 1.") |
ユーザー ストーリーの作成: Mike Cohn は、著書『User Stories Applied』で、ユーザー ストーリーを "ユーザー ストーリーは、システムやソフトウェアのユーザーまたは購入者にとって価値のある機能について記述する。" と定義しています。 ユーザー ストーリーは、エンド ユーザーの視点で記述します。 次に例を示します。 "リピータとして、前に注文したことがある料理を見つけたい。" 詳細については、「効果的な製品バックログの作成」を参照してください。 |
.gif "手順 2.") |
ユーザー ストーリーの優先度付け: 製品所有者は、顧客と共に作業して顧客の価値を理解したり、チームと共に作業してリスクと依存関係を理解したりすることで、製品バックログのユーザー ストーリーに優先度を付けます。 製品所有者は、各ユーザー ストーリーに順位を割り当てて、チームによるユーザー ストーリーの実装順序を示すことで、優先度を示します。 製品所有者は、多くの手法を使用して、ユーザー ストーリーの価値を分析および比較できます。 既にチームに実績のある優先順位付けの手法があれば、その手法を使用します。 一部の優先度付け技法は、Karl Wiegers が提唱する顧客満足と相対的な重み付けの Kano モデルなどのアジャイル コミュニティと密接に関連しています (相対的な重み付けの詳細については、「First Things First: Prioritizing Requirements (重要なことから優先する: 要件の優先度付け)」のページを参照してください)。 コストの優先度付け、正味現在価値、資本回収期間、内部利益率など他の優先度付けは、アジャイル コミュニティの外部で既に確立されています。 これらの手法は、スクラム プロジェクトの製品バックログの優先度付けにも適用できます。 詳細については、『Agile Estimation and Planning』の「Part II: Estimating Size」を参照してください。 |
.gif "手順 3.") |
ユーザー ストーリーの見積もり: チームは協力して、ユーザー ストーリーをストーリー ポイントで見積もります。 Mike Cohn の著書『Agile Estimation and Planning』では、ストーリー ポイントを "ストーリー ポイントは、ユーザー ストーリー、機能、またはその他の作業のサイズ全体を表す測定単位である。" と定義しています。 ストーリー ポイントは、特定の時間数に直接変換しない相対的な値です。 ストーリー ポイントは、チームがユーザー ストーリーの全般的なサイズを数値化するのに役立ちます。 これらの相対的な見積もりは正確さに欠けるため、最初は工数を少なく見積もる必要があり、見積もりは時間の経過と共に精度を増していきます。 ストーリー ポイントで見積もることによって、チームはユーザー ストーリーの現時点での全般的なサイズを示し、チーム メンバーがユーザー ストーリーを実装する段階になると、作業時間のより詳細な見積もりができ上がります。 |
チームの速度の決定
チームはリリース計画を作成し、各スプリントを計画する前に、チームの速度を決定する必要があります。 チームの速度は、チームが 1 つのスプリントで完了できるストーリー ポイントの数です。
チームが指定期間内に完了するユーザー ストーリーの数をデータ収集して速度を測定している場合は、そのデータを使用する必要があります。 このデータからチームの最適な速度を把握できます。 データがない状態で、Visual Studio ALM と MSF for Agile Software Development v5.0 を使用してプロジェクトを開始している場合、そのデータはプロジェクトの進行と共に収集されます。 詳細については、「"すべてのイテレーションの状態" レポート」を参照してください。
履歴データを使用できない場合、最初のスプリントでチームが完了できるストーリー ポイントの数から、チームは大まかな見積もりを行うことができます。 優先度スタックの先頭にあるユーザー ストーリーの見積もりを確認して、1 つのスプリントで完了できるストーリー ポイントの数を早急に評価します。 ユーザー ストーリーごとにストーリー ポイントを追加し、最初の見積もりを取得します。 最初のスプリントが過ぎたら、履歴データを使用して、チームの速度を決定できます。 最初のいくつかのスプリントで、チームは一貫した見積もりの出し方がわかるので、それに合わせて実質的な変動を予想します。 いくつかのスプリントを過ぎると、チームの測定速度はより安定してきます。 チームの測定速度が安定したら、リリース計画を再評価します。
チームの速度の見積もりは、スプリントで実装するユーザー ストーリーの数を決定するための開始点となりますが、見積もりはチームのコミットメントの根拠ではありません。 チームのコミットメントは、ユーザー ストーリーの完了に必要なタスクのより詳細な見積もりに基づいて行われます。 詳細については、「製品計画ブック」を参照してください。
リリース計画の確立
各スプリントで、チームは、出荷できる製品インクリメントを完成します。 チームが実装するユーザー ストーリーは、スプリントの終わりで出荷の準備ができていますが、製品を実際にリリースするには、まだビジネス価値が不足している可能性があります。 イテレーションに割り当てることによるリリースの計画では、次のことを行います。
顧客にリリースするのに十分なビジネス価値を同時に提供するユーザー ストーリーのグループを識別します。
それらのユーザー ストーリーのグループの完了が予定されるスプリントを決定します。
チームが進行するに従い、ユーザー ストーリーは、製品バックログに追加されたり削除されたりします。 また、ユーザー ストーリーの優先度は最初の予定よりも早く実装されることも、遅く実装されることもあります。 製品所有者は、プロジェクトの進行に合わせて、リリース計画を製品バックログと共に維持します。
詳細については、「製品計画ブック」を参照してください。
最初のスプリントの準備
スプリントとは、通常、1 週間から 4 週間の時間枠が設定された開発のイテレーションです。この時間枠のイテレーションで、チームは、出荷できる製品インクリメントを生成します。 チームが最初のスプリントを開始する前に、製品所有者は製品バックログを準備します。 最初のスプリントで優先度が高いと見なされているユーザー ストーリーは、チームが実装する準備を完了しておく必要があります。 製品所有者は、以下のことを実行して、製品バックログを準備する必要があります。
ユーザー ストーリーを小さいストーリーに分割します。
チームがストーリーをタスクに分割するために必要な、ユーザー ストーリーに関する詳細を提供します。
チームの総合速度においてユーザー ストーリーがかなりの量を占めている場合、製品所有者はユーザー ストーリーが大きすぎることに気付きます。 たとえば、チームの速度が 30 ストーリー ポイントの場合、ユーザー ストーリーが 15 ストーリー ポイントでは大きすぎるため、スプリント計画会議には進めません。 ユーザー ストーリーを完了するだけで、チームはそのスプリントの半分を使用することになります。
チームは、それらのタスクを分割して見積もることができるよう、ユーザー ストーリーに関する詳細を要求します。 たとえば、チームが "顧客として、料理の種類を検索できるようにしたい" というユーザー ストーリーを調べる場合、次のような質問をします。
それはフリーテキストの検索である必要があるか、それとも使用可能な種類の一覧から選択できる形式でよいか
複数のお店で検索に一致する料理を提供している場合、結果をどのように並べ替える必要があるか
詳細については、「次のスプリントの準備」を参照してください。
スプリントの計画
チームが製品バックログを開発し、リリース計画を確立したら、チームはスプリントの作業を開始できます。 チームは、スプリントをスプリント計画会議から開始します。スプリント計画会議では、チームは、製品バックログから一連のユーザー ストーリーを完了することをコミットします。 その一連のユーザー ストーリーと、それをサポートするタスクが、スプリント バックログになります。 詳細については、「製品バックログとスプリント バックログの比較」を参照してください。
スプリントが開始されると、スプリント バックログのユーザー ストーリーは変更されません。 したがって、チームがその計画を確信を持ってコミットできるように、計画は詳細に作成されている必要があります。
詳細については、「スプリント計画会議」を参照してください。
ユーザー ストーリーの選択
チームは、スプリントで実装される候補となるユーザー ストーリーを選択します。 優先度が最も高く、見積もられた速度を超えていないストーリー ポイントを持つユーザー ストーリーを識別します。 たとえば、優先度が最も高い 4 つのユーザー ストーリーには、それぞれ 8、3、7、6、および 2 のストーリー ポイントがあります。 チームがスプリントごとに 25 ストーリー ポイントの容量を持つ場合、チームは最初の 4 つのユーザー ストーリーをスプリント バックログに含めます。
詳細については、「イテレーション バックログ ブック」を参照してください。
タスクの識別
チームは各ユーザー ストーリーを評価して、そのユーザー ストーリーを実装するために何を実行する必要があるかを決定します。 ユーザー ストーリーをタスクに分割すると、ユーザー ストーリーの理解が進み、スプリントのユーザー ストーリーの完了を確信を持ってコミットできます。
.png "イテレーション バックログ ワークシート")
スクラムに習熟しているチームは、ユーザー ストーリーをタスクに分割せずにコミットできる場合があります。
タスクの見積もり
タスクを識別したら、チームは、各タスクの作業時間 (時間単位) を見積もります。 チームは多くの場合、プランニング ポーカー手法を使用してタスクを見積もります。 この手法を使用すると、必要以上に正確に見積もることがありません。
ユーザー ストーリーのコミット
イテレーション バックログ ブックを使用すると、タスクのすべてを完了するために十分な作業時間を確保できます。 チームがスプリントで行うことができる作業よりも多くの作業がスプリントにある場合、作業がそのスプリントのチームの容量内に収まるまで、最も低い優先度のユーザー ストーリーから順に削除する必要があります。 優先度が低くて小さいユーザー ストーリーを、スプリントに収まらない大きいユーザー ストーリーと交換できます。
![[キャパシティ] ワークシート](images/dd997796.procguid_iterationbacklog_capacity_wrkbk(ja-jp,vs.100).png "[キャパシティ] ワークシート")
チームは、完了できると判断したユーザー ストーリーの完了をコミットします。 チームは、製品所有者が追加作業を持ち込まないこと、またはスプリントで実装中のユーザー ストーリーの優先度を変更しないことを了解したうえでこれをコミットします。
スプリントの実行
スプリントの期間中に、チームはスプリント バックログのユーザー ストーリーの実装に必要なタスクを完了します。 チームは進行状況を追跡して、終了したソフトウェアに対する顧客の承認基準とチームの基準を満たしていることを確認してから、各スプリントを終了します。
ユーザー ストーリーの完了
チームがスプリントを計画すると、そのスプリント期間中に完了することがコミットされたユーザー ストーリーが一覧表示されます。 これらのユーザー ストーリーは、タスクに分割されます。 チームの各メンバーは、スプリントの開始時にタスクへの参加を表明します。 そのタスクが完了すると、チーム メンバーはそのステータスを変更し、別のタスクへの参加を表明します。 この方法で、チームはタスクの一覧にある作業を順次行い、スプリント バックログのユーザー ストーリーを完了します。 コードをチェックインして、チーム メンバーは完了したタスクを示すことができます。 詳細については、「作業項目の変更セットへの関連付け」を参照してください。
タスクの割り当てとステータスの更新の詳細については、「タスク (アジャイル)」を参照してください。
スクラムは、正式なプロセスに比べ、メンバーが互いに話し合うことに重点を置いています。これにより、依存関係が理解され、専門知識が共有され、計画の変更が効率的に行われます。 毎日短いスクラム会議を行います。この会議では、各チーム メンバーが、前日に達成した作業と当日に達成する予定の作業の詳細を共有したり、他のチーム メンバーから影響を受ける可能性のある問題や障害または他のチーム メンバーからの支援が必要な問題や障害の詳細を共有したりします。 詳細については、「毎日のスクラム ミーティング」を参照してください。
Kent Beck の著書『Extreme Programming Explained』では、バグの修正を先延ばしにするよりもすぐに解決した方がコストが削減されると述べています。 その事実をふまえて、チームは顧客にとって何が重要かを理解する必要があります。 おそらく、顧客は多くの機能があることよりも品質に価値を置いていると考えます。 顧客はチームの作業フローを制御するため、製品所有者はこのような情報について理解しておく必要があります。
スクラム チームが生成するソフトウェアは、エラーのない状態でなければなりません。 しかし、チームがプロジェクトのバグを検出する可能性があります。 バグを検出してからすぐに修正する方が、先延ばしにするよりもコストが削減されることを認識したうえで、チームはバグを処理することになります。 チームがバグを検出したら、すぐに修正してください。 バグが検出された当日にチームがそのバグを修正できなかった場合、Visual Studio ALM にバグ作業項目を作成して、スプリントが終了するまでにそのバグを修正します。
詳細については、「バグ (アジャイル)」を参照してください。
スプリントの進行状況の追跡
チームは、スプリントの進行状況を追跡して、作業が予定どおり完了しているか、また、作業が承認基準を満たしているかどうかを確認できます。 スクラム チームは、バーンダウン レポートを積極的に使用して、スプリント全体におけるチームの進行状況を追跡します。 MSF for Agile Software Development v5.0 には、チームがスプリントの進行状況の追跡に使用できる、一連のレポートが用意されています。
.png "正常なバーンダウン レポート")
スプリント計画会議で出した見積もりよりも、タスクの完了に時間がかかることがあります。 このような見積もりのズレはよくあることです。 この情報は、チームがタスクに費やした実際の時間を指定することで記録できます。
場合によっては、スプリントが進行するにつれて、ユーザー ストーリーの完了に予定外の作業が必要だと気付くこともあります。 このような場合、タスクを作成してそのタスクを見積もり、スプリントに残された時間でチームがそのタスクを完了できるかどうかを判断します。 タスクを完了できる場合、チームはスプリントを続行します。 チームがスプリントでタスクを完了できない場合は、スプリントの続行方法について製品所有者と話し合う必要があります。 製品所有者とチームは、次のような変更を行うことで、この問題を解決できます。
タスクが不要になるようにユーザー ストーリーの承認基準を下げます。
ユーザー ストーリーをスプリント バックログから削除します。
スプリントを中止します。
スプリントの終了
スプリントの終了が近づいたら、チームがすべてのユーザー ストーリーまたは要件を完了していることを確認します。 たとえば、受け入れテストに合格しているか、また、各ユーザー ストーリーがチームで定義した基準を満たしているかどうかを確認します。 完了の定義の詳細については、Web ページ「Mitch Lacey & Associates, Inc. (Mitch Lacey & Associates, Inc.)」を参照してください。
スプリントの最終日に、製品所有者、および必要に応じて顧客に、チームが完了したユーザー ストーリーを示します。 製品所有者と顧客は、各ユーザー ストーリーを承認するかどうかを決定します。 詳細については、「スプリント レビュー会議」を参照してください。
顧客レビュー会議後に、チームは振り返り会議を行います。 詳細については、「振り返り会議」を参照してください。
プロジェクトの追跡
プロジェクトのインクリメントを提供しようとチームがスプリントで作業するにつれ、顧客は残りのニーズについて理解を深めていきます。また、ビジネス環境も変化しているので、それを考慮に入れる必要があります。 製品所有者は、顧客と連携してこれらの変化を把握します。 製品所有者は、製品バックログとリリース計画にこれらの変化を反映して保守し、各スプリントの開始時の必要項目をチームが維持しているかどうかを確認します。 チームは製品の進行状況の全体を追跡することで、チームがプロジェクトの完了に向けて正常に進行していることを確認します。
次のスプリントの準備
製品バックログ更新を確認する間隔は、プロジェクトの全体的な品質と完全さに直接関係します。 バックログの更新、変更、見直しを定期的に行うことで、チームがスプリントを開始する準備ができていることを確認します。
製品所有者は、次のスプリントの製品バックログを準備するために、以下のタスクを実行します。
顧客のニーズの変化に合わせて、ユーザー ストーリーとその優先度を更新します。
次のスプリントで実装される可能性が高いユーザー ストーリーを分割します。
.png "製品バックログ")
チームがスプリントを終了すると、他のユーザー ストーリーが製品バックログのリストの上位に繰り上がっていきます。 製品所有者は、トップにあるユーザー ストーリーの分析と分割を行う必要があります。これにより、チームは、次のスプリントでユーザー ストーリーを実装できます (詳細については、前の「最初のスプリントの準備」を参照してください)。 Mike Cohn はよく、このプロセスのことを製品バックログの氷山と述べています。 チームが一連の機能に取り組むにつれて、氷山は融けていき、新しい作業が表面に浮上し、そして氷山はだんだんと小さくなっていきます。 このプロセスでは、他に必要な詳細が適時に明確になります。
チームはスプリントを実行中であるため、製品所有者は、製品バックログの維持について、チームが最初のスプリントの準備で提供したのと同様のレベルでのチームの関与を期待することはできません。 製品所有者がスプリントの混乱を最小限に抑えて製品バックログを準備できるように、チームと製品所有者はスプリントの途中で、製品バックログについて未処理の懸案事項を話し合います。
リリースの進行状況の追跡
プロジェクトがスプリントからスプリントに進むにつれて、チームは次のリリースに向けて進行状況全体を追跡します。 チームは進行状況を追跡して、チームの速度の評価と改善も行います。 チームが進行状況を追跡するのに合わせて、次のような質問に回答する必要があります。
最も適切なユーザー ストーリーの作業を行っているか。 プロジェクトが進行するにつれて、製品バックログは新しいユーザ ストーリーで更新されているか。 ただし、バックログ内のユーザー ストーリーの総数が減少していない場合は、各スプリントでユーザー ストーリーを完了している場合でも、チームはその原因を調査する必要があります。 完了しているユーザー ストーリーが最適な選択でない可能性があります。 チームはリリースごとにビジョンと目標を持ち、ユーザー ストーリーが顧客の要求事項と直接関連付けられている必要があります。
技術的な負債を抱えていないか。 バグ修正などの作業が完了せずに残っている場合でも、ユーザー ストーリーを終了したと見なして処理するチームもあります。 このようなチームは、後で支払う必要がある技術的な負債を抱えています。この負債は通常コストが高く付きます。
Visual Studio ALM には、チームが多くのスプリントにわたる進行状況を追跡できるように、複数のレポートを用意しています。
.png "正常なすべてのイテレーションの状態レポート")
カスタム レポートと作業項目クエリを作成して、進行状況を追跡できます。 詳細については、「Visual Studio ALM のレポートの作成、カスタマイズ、および管理」および「バグ、タスク、およびその他の作業項目の検索」を参照してください。
リリースの終了
チームに蓄積された技術的な負債がない場合、そのリリースのスプリントが完了して追加の作業がなければ、チームは製品をリリースできます。 チームと製品所有者は、顧客レビュー会議と振り返り会議を行い、リリースを全体的に確認します。
ただし、技術的な負債は、チームが簡単に取り除けない困難な問題です。 他の多くのチームと同様に、チームが技術的な負債を累積している場合、チームは、未解決の作業に時間をかけてユーザー ストーリーを終了し、その後に製品をリリースする必要があります。 リリースの振り返りでは、負債をこれ以上抱え込まないために、次のスプリントで実行する必要がある事項について検討する必要があります。