アジャイル開発
TFS 2010 でアジャイルを味方につける
Chris Adams
これは、あるチームが Team Foundation Server (TFS) 2010 を使用してアジャイル開発を目指した道のりを描く物語です。
アジャイル開発宣言には、アジャイル チームは連携すべきであることを強調するキーワードがいくつか含まれています。たとえば、プロセスやツールよりも個人 (と対話) に価値がある、と謳われています。今回のチームは、こうしたキーワードの中でも、この価値をアジャイル開発に移行する理由の 1 つとして使用します。この宣言からここ 10 年ほどで、さまざまな特色を備えたアジャイルが考案されてきました。この記事では、アジャイルのプロセス テンプレートの 2 つの特色のうちの 1 つを適応させる機会を提供する、TFS 2010 のいくつかのオプションについて詳しく説明し、マイクロソフトのチームがそれらのオプションをどのように使用しているかを紹介します。
マイクロソフトのソフトウェア開発チームは数年前に再編成されました。そのときの最重課題は、必ず、マイクロソフトのユーザーが使用しているツールを使用することでした。マイクロソフトに長年存在していた社内ツールを使用することは許されません。管理とセキュリティの部門 (MSD) の開発チームは、マイクロソフトが幅広いユーザー (IT ユーザー、IT 管理者とエンジニア、およびオンライン サービスのオペレーター) にサービスを提供できるようなソフトウェアの構築に力を注いでいます。つまり、マイクロソフトのチームは潜在的に読者の皆さんのチームとまったく同じです。顧客が拠りどころにしているビジネスを強化、改善するソフトウェアを構築しています。
アジャイルを採用する前は、顧客からのフィードバックをあまり重視しておらず、チームのメンバーの間には肩書きによる人為的な境界があり、管理チームには正確な状況が伝わっていませんでした。この状況を変えていなければ、チーム全体の有効性は徐々に低下し、いずれは完全に失敗してしまっていたでしょう。
アジャイルに移行するにあたり、他のメンバーとの対話、顧客、そして最後にプロセスを重視することを考えました。それまでは、逆の順序、つまり、プロセス、顧客、対話の順に力を注ぐことに時間を費やしていました。ここ 2 年間の成果として、チームを活力を与え、顧客重視に回帰し、適切なタイミングで適切なソリューションを実行することに注目するようになりました。今回はその方法について説明します。
自身の役に立でば他人にも役立つ
今回独特のソフトウェア チームを編成したわけではありません。ビジネス価値に直接つながる最高品質のソフトウェアを開発することを目指す若いチームに過ぎません。このチームには 3 年以上の在籍者はいません。既に述べたように、マイクロソフトは悪戦苦闘の最中でした。
2010 年 3 月に、事態を変えなければならないと決断しました。自身に不利に働くのではなく、連携して、顧客に価値を提供することに重点を置けるシステムが必要です。そのうえ、チーム全体だけでなく、より大きな組織全体の進捗状況をさまざまなレベルで監視および追跡する機能を実現するシステムが必要でした。
さらに、アジャイル手法での開発を希望していましたが、その方法を知りませんでした。
MSF Agile バージョン 5.0 の導入
チームでは、ベータ段階の初期に TFS 2010 を導入し、Microsoft Solutions Framework Agile バージョン 5.0 (以下、簡潔に "MSF Agile" と表記します) を使用してプロジェクトの 1 つを作成することにしました。まず、チームの中心目標の実現に役立つプロセス テンプレートを探しました。その中心目標とは、製品とスプリントの効果的な計画を可能にすること、開発チームのリズムを合わせることに傾注できること、そして最も重要な点は、開発者、テスター、およびプログラム マネージャー (PM) の対話を増やすことです。MSF Agile に付属するライフサイクル (図 1) が、探し求めていたテンプレートにぴったり一致するように思われました。
.jpg)
図 1 MSF Agile プロセス
MSF Agile は、アジャイルの導入に役立つ作業項目の種類 (WIT) をいくつか提供します。そこで、各 WIT (図 2 に定義) を調べて、WIT を効果的に使用する方法を理解することから始めました。
図 2 MSF Agile の WIT の定義
| 作業項目の種類 (WIT) | 目的 |
| ユーザー ストーリー | この製品でユーザーが実行できるアクティビティをトラックします。 |
| タスク | 実行する必要がある作業をトラックします。 |
| バグ | 必要な動作と実際の動作との相違点を記述し、障害を修正するために行った作業をトラックし、修正を検証します。 |
| 懸案事項 | 進行を妨げる障害をトラックします。 |
| テスト ケース | テストするステップ セットと期待する結果を記述します。 |
| 共有ステップ | 再利用可能なテスト ステップ セットと結果を定義します。 |
重要な点は、各 WIT を詳しく調べたにもかかわらず、最初からそれらすべてを使用したわけではないことです。ユーザー ストーリー、タスク、およびバグに大半の注意を向けました。テスト ケースなどの WIT の導入を始めたのは数か月 (または 1 年も) たってからでした。懸案事項の WIT にいたってはいまだに使用していません。ただし、この WIT が役に立たないと言っているわけではありません。アジャイルを学んでいる多くのチームと同様、好ましいものを採用し、それ以外は採用しませんでした。誰もがアジャイル ソフトウェア開発を完全に導入するわけではないため、重要なことは、TFS 2010 では MSF Agile テンプレートを使用してこうした柔軟性が確保される点です。
ユーザー ストーリー WIT を使用したビジネス価値の促進
アジャイル チームはユーザー ストーリーにかなりの労力を費やさなければならないことを学びましたが、このことを一晩で学んだのではありません。最初のユーザー ストーリーはかなり長く、複数のイテレーションにまたがっていました。段階的に価値を高めるユーザー ストーリーよりも、タスクを促進するテーマの方を多く含めていました。
しばらくして、優れたユーザー ストーリーには 3 つの重要な要素があることを学びました。最初の要素はタイトルです。タイトルは、ストーリーの内容を想起させる短いヒントです。短いタイトルは目を通しやすいため、ユーザー ストーリーのスタック順位付けが簡単になります。次の要素は説明です。説明は「<ユーザーの種類> として、<理由> のために <目的> が必要です」という形式で記述し、ストーリーの内容を表現します。つまり、価値を高める理由や、だれの価値が高まるのかを表します。これが顧客の価値です。3 つ目の要素は、受け入れ基準です。これは、後になって Microsoft Visual Studio Scrum 1.0 (以降、簡潔に Scrum 1.0 と表記します) のプロセス テンプレートに切り替えたときに学んだ価値です。受け入れ基準があれば、チームが提供を予定しているサービスが明確になります。
アジャイルの導入に慣れていく過程で、ユーザー ストーリーについて多くのことを学び、関係者や顧客と重要な会話を交わす方法を学びました。強力なユーザー ストーリーを記述することでだけに集中していてはいけません。チームがユーザー ストーリーのスタック順位付けを正確に行っているかどうかについても議論する必要があります。作業順序についての顧客との対話が適切で生産的になるにつれて、チームとしてのさらなる成長につながります。
ソフトウェア チームは、多くの場合、何が重要かを自分たちで決定します。これは、顧客がすべてであることを強調するアジャイル ソフトウェア開発宣言に反します。そのギャップを埋めるために、ユーザー ストーリ WIT のスタック順位のフィールドを使用して、価値を生み出す作業の順序を定義します。このフィールドは、顧客やパートナーとの対話を促進し、開発者と顧客やパートナーとのスタック順位が一致するようになります。関係者や顧客は、シンプルな TFS クエリを使用して、顧客のニーズを満たすために提供する必要がある、順序付けした作業一覧を確認できます (これはダッシュボードにも公開されますが、これについては後で説明します)。
MSF Agile でのイテレーションの計画
チームとしては、ほとんどまたはまったく警告されることなく機能の範囲や規模が拡大するという過去の歴史を克服したいと考えていました。さらに、機能ではなく価値に注目したいとも考えていました。作業を正確に計画し、適切な量のリソースを割り当て、中断を効果的に考慮する必要があります。
アジャイル チームでの作業は、決まった長さのイテレーションに分けます。しかし、1 回のイテレーションの長さはどの程度にすべきなのでしょう。何回か議論を重ねた結果、4 週間以内に "出荷準備の整った" ソフトウェアを提供できると思えなかったため、イテレーションの長さに 4 週間を選択しました。数回のイテレーションを行った後、すべての作業を 1 回のイテレーション内で終わらせるのは難しいことがわかったので、長さを 6 週間に切り替えようとしました。しかし、その結果、顧客とのフィードバックのループが長くなりすぎるため、4 週間のイテレーションに戻すことにしました。10 か月ほど前に、スプリントの長さを 2 週間に切り替えたことで、フィードバックをより早く受け取れるようになりした。
顧客に最も高い価値を提供するユーザー ストーリーを選択後、そのユーザー ストーリーにイテレーションを割り当てます。チームは、大きくてモノリシックになることが多い機能ではなく、小さく段階的なコンポーネントの構築に重点を置くことを学ばなければなりませんでした。コンポーネントを小さくすることで、より細かいレベル (5 ～ 10 時間の増分内など) で作業を見積もることができます。また、コンポーネントが小さくなることで、テスターが長いテスト サイクルを行わなくても済むようになり、テスターの効率も向上しました。
リソースを割り当てるという目的から、機能の "設計" に重点を置くことにかなりの時間を費やし、続いてその構築にコストを費やしていました。そこで、MSF Agile のストーリーごとのストーリー ポイントを使用してこの点を置き換え、[最初の見積もり] フィールドを使用して、作業に価値を置きました。チームでは、スプリントの計画でプランニング ポーカーを使用して、この見積もりを行いました (プランニング ポーカーの詳細については、planningpoker.com (英語) を参照してください)。毎日、チーム メンバーに [実績作業] フィールドと [残存作業] フィールドの更新を求め、イテレーションの目標に対する進捗状況をトラックしました (図 3 参照)。
図 3 MSF Agile での計画の見積もり管理
| MSF Agile のフィールド | 用途 |
| 最初の見積もり | 残存作業の初期値 - 作業開始時に 1 回設定 |
| 残存作業 | タスクを完了するための残存時間の見積もり |
| 実績作業 | このタスクに対して費やされた時間 |
これは、毎日の作業を正確にトラックするための基礎となり、アジャイル チームとして作業を進めるにつれて、効率が上がったことがわかりました。
チームが成熟するにつれて、作業の見積もりを日々更新することが習慣となり、標準プロセスの一部になりました。
MSF Agile の製品計画とイテレーション バックログの追跡ツール
MSF Agile の製品計画とイテレーション バックログのブック (図 4 参照) を使用することで、実行して正常に完了できる作業を見積もる能力が向上しました。
.jpg)
図 4 MSF Agile で計画を行うためのブックのテンプレート
初期のイテレーションでは、失敗に落胆することなく、改善に力を注ぎました。チームとしてイテレーションを計画中に、製品計画のブックを使用して、ユーザー ストーリーをイテレーションに割り当てました。時間節約のためにスプリントの計画に着手する前にイテレーションのセットアップを試みました (イテレーション作成の詳細については、https://msdn.microsoft.com/ja-jp/library/ms181692.aspx を参照してください)。チームの平均作業速度について詳しく把握するにつれて、特定の日時までに作業を完了できるというある程度の自信を持って、イテレーション間のストーリーのバランスをとるのがうまくなりました。
アジャイルへの移行で最も重要な部分の 1 つは、イテレーション バックログのブックを使用することに直接関連します。このブックには、イテレーションの計画中に役立つ Microsoft Excel のタブをいくつか用意します。ここで各タブの用途について説明しておきます。
ブックには、まず [イテレーション バックログ] タブを用意し、ユーザー ストーリと、そのユーザー ストーリーに関連する後続タスクを示します。このタブを TFS のツリー クエリにバインドします。その結果、使い慣れたツリー ビュー形式でユーザー ストーリーとそのすべての子タスクを簡単に表示できます (ツリー クエリの種類の詳細については、https://msdn.microsoft.com/ja-jp/library/ms244365.aspx を参照してください)。スプリントごとにクエリを更新し、現在イテレーションに割り当てられているすべての項目が最初のタブに表示されるようにする必要があります。このタブでデータを操作して、Excel を終了することなく TFS サーバーに再発行できます。チームではこの方法を使用して、スプリントの計画中にユーザー ストーリーに基づいてタスクを作成しました (詳細については、bit.ly/lmPN4k を参照してください)。
[領域とイテレーション] という 2 つ目のタブは、イテレーションの開始日、終了日、およびイテレーション パスを設定できるようにします (図 5 参照)。
.jpg)
図 5 MSF Agile でのイテレーション バックログのブックの開始日と終了日
複雑なプロジェクトでは、"領域" のパスを使用して、ブックのスコープを指定できます。小さなチームでは、このレベルまでスコープを設定することはめったにありません。複数の領域を使用する大規模チームでは、領域のパスごとにブックのコピーを個別に保持することもあります。
3 つ目のタブは [中断] です。このタブでは、チーム メンバーがプロジェクトの作業に参加できない、休暇や祝日といった休日を考慮できます。ただし、このタブでは、イテレーションの作業項目に現在割り当てられているチーム メンバーのみに中断を設定できるようにします。したがって、このタブに移動する前に、(1 つ目の [イテレーション バックログ] タブで) 作業を正確にタスクにし、チーム メンバーに割り当てるようにします。そうしないと、チーム メンバーのドロップダウン リストが空白になります。
チームでは、4 つ目のタブが非常に重要であることがわかりました。[キャパシティ] と名付けたこのタブは、イテレーションの残存作業と残存日数に基づいて、各チーム メンバーのキャパシティの過不足に関する情報を提供します。前述の [中断] タブの情報は、このタブで考慮します。
[キャパシティ] タブを使ってチーム メンバー間でタスクを移動すれば、ごく簡単に負荷を分散できるようになります。これは、アジャイル導入前のチームに欠けていた能力です。つまり、多くの場合手遅れになってから土壇場で割り当て直すのではなく、初期段階でこのような再割り当てを行う能力です。
キャパシティを計算するため、ブックでは、各チーム メンバーの 1 日の全体キャパシティ (1 日あたりの作業時間) にイテレーションの残存日数を掛けています。この最終結果 (図 6 参照) により、イテレーションの 1 日目 (たとえば、イテレーション計画) から開始して、現在の進捗を把握できます。
.jpg)
図 6 MSF Agile のチームのキャパシティ計画
これは、毎日の作業開始時に調べる動的なビューです。図 6 の場合、各チーム メンバーのキャパシティを超えており、そのイテレーションで計画されているすべての作業を完了できないことを把握できます。
私のブログ (bit.ly/fZpzWx、英語) では、このブックの使用方法のチュートリアルをまとめて、より詳細な情報を共有しています。
チーム固有のカスタマイズを行う
ソフトウェアの構築は、必ずしも 1 つのチームだけで行われるわけではありません。実際には、複数のチームが連携するのが一般的です。複数のチームにまたがるソフトウェア開発の課題は、"チーム" ごとに異なるプロセスが存在することです。あるチームはウォーターフォール型のソフトウェア開発手法に従い、別のチームはスクラムを使用するといった具合です。各チームの独自性は、多くの場合、課題を招きます。今回のチームでは、もちろん、手法が分かれることはなく、この問題は回避できました。それでも、MSF Agile を使用した最初のプロジェクトの 1 つでは、2 つのチームがアジャイルを基盤としていたにもかかわらず、異なるイテレーションの長さと異なるスタイルを使用するため、両チーム間で対話が必要になりました。これは TFS 2010 の柔軟性によって助けられました。TFS 2010 では、あらゆる WIT をカスタマイズする (またはまったく新しい WIT を作成する) ための豊富かつ強力な機能が提供されます。今回、新しい WIT は必要ありませんでしたが、WIT の微調整は必要でした。
今回は、Microsoft Deployment Toolkit (MDT) チームと連携して、ユーザー駆動型のインストール (UDI) (bit.ly/kjySZk、英語) という新しい機能を開発していました。この機能では、エンド ユーザーが自身の Windows 7 デスクトップやラップトップを変更できるようにします。MDT チームはスクラム (マイクロソフト社内のみで使用できる独自のツール) を使用していましたが、こちらは TFS 2010 を使用していました。そのうえ、チーム間でのかなりの対話を繰り返しましたが、こちらが新しい機能を提供したときのバグとバグ修正に重点を置いていたのに対し、MDT チームはすべてのテストをチームで行っていました。
両チームは複数のイテレーションにわたって連携しましたが、最初のいくつかのイテレーションでは、目的とする結果 (たとえば、出荷可能なソフトウェア) を達成するのに苦労することがわかっただけでした。作業速度は低速でした。こちらはチームとして、パートナーと連携する前にアジャイルを数か月使用して、すべての作業が完了した状態でイテレーションを終了するリズムをつかんでいました。では、なぜ突然、スプリントで計画していたすべての作業が停止したのでしょう。
皮肉なことに、これはスプリントの計画中にバグの推定数を含めるという失敗を犯したためです。つまり、多くの場合、新しい機能と共に、パートナー チームが修正を求めてきたすべてのバグの解決を行おうとしたことです。バグの WIT には、残存作業や実績作業のような時間ベースのフィールドがないため、バーンダウンは未完了の作業があることを警告しません。
TFS 2010 のカスタマイズ機能を使ってこの WIT を微調整すれば、かなり簡単にこのニーズを満たすことができます。バグ WIT に時間のフィールドを含めるように更新して、このフィールドをバグ フォームに追加することで、イテレーションのバーンダウンからバグとタスクの両方を把握できるようになります。カスタム フィールドの追加方法 (WIT に計画のフィールドを追加するなど) の詳細については、私のブログ (bit.ly/gb1BOb、英語) を参照してください。
TFS と Windows SharePoint Services の統合
最初に示したように、チームの機能を改善して、進捗をトラックし、適宜、チーム、パートナー、および経営陣に報告する必要がありました。
TFS 2010 には統合が組み込まれ、新しい Windows SharePoint Service (WSS) または既存の WSS を利用できます。MSF Agile プロジェクトを作成するときに、希望すれば、優れたカスタマイズ可能なダッシュボードを含む SharePoint サイトの作成も同時に行えます。 チーム内の対話や顧客との対話を改善するための取り組みの一環として、TFS に付属する組み込みのダッシュボードを使用しました。ダッシュボードと SharePoint との統合の魅力的な側面は柔軟性です。たとえば、標準の TFS プロジェクトに付属するダッシュボードでは、そのダッシュボードのビュー内に必要な情報がすべてが提供されませんでした。もっと多くの情報が必要でした。
ダッシュボードでは、バーンダウン、速度、バグ数といった進捗レポートの日常の電子メール共有を進化させ、経営陣やパートナーに、ほぼリアルタイムで進捗状況を表示できる SharePoint サイトへのアクセスを提供できます。
どのような組織でも同じですが、確認を希望する情報は人によってさまざまです。今回は、ダッシュボードでは既定で有効になっていなかった追加のレポートを含めるように、ダッシュボードをカスタマイズしました。たとえば、管理チームとは毎月ミーティングを行い、チームの作業を確認し、アジャイル プロジェクトのライフサイクルの進捗に応じてフィードバックを提供していました。こうしたミーティングの中で、リーダーの 1 人が、作業中のユーザー ストーリー、進捗状況、および現在のスプリント内に含まれないバックログとなっているユーザー ストーリーを確認できるかをたずねました。ダッシュボードを活用してこのリーダーのニーズを満たした方法の詳細については、私のブログ記事 (bit.ly/jJ6XUp、英語) を参照してください。
SharePoint と TFS 2010 プロジェクトの力を引き出す
既に Microsoft Office SharePoint Server (MOSS) の Enterprise バージョンをお持ちであれば、MOSS にリンクされる MSF Agile プロジェクトを使用して、機能を新しいレベルに引き上げることができます。既に述べたように、TFS 2010 には WSS が付属していますが、WSS にはエンタープライズ対応の機能がいくぶん不足しています。
今回、MSF Agile に付属する優れた Excel レポートをいくつか活用することを考えていました。このレポート (図 7 参照) は、Excel Web Services (EWS) を使用してプロジェクトのダッシュボードの Web パーツでレポートとそのデータをホストするなど、多くの機能を提供します。
.jpg)
図 7 MSF Agile の Excel レポート
チーム プロジェクトに使用できる SharePoint 2007 または SharePoint 2010 Enterprise をインストールしたサーバーを使用していない限り、この機能は使用できません。
MSF Agile プロジェクトの作成中に TFS 2010 が SharePoint Enterprise サーバーを検出すると、EWS レポートと SQL Server Reporting Services (SSRS) レポートの両方を含むダッシュボードが作成されます。コード チャーンやバグ (割り当て順) などのレポートに加えて、バーンダウンやバーン レートといった MSF Agile で提供されるレポートを使用できるため、この柔軟性により、多くの機能を利用できるようになります。
SharePoint ダッシュボードの管理中の大きな懸案事項は、管理 (具体的には、ダッシュボードのレポートを最新の状態に保つ作業をだれが行うか) でした。たとえば、チームが 2 週間の間隔でイテレーションを行っていると、バーンダウンの開始日と終了日を 2 週間ごとに更新する必要があります。このように更新しなければ、ダッシュボードのデータは最新状態になりません。ダッシュボードを数か月管理しましたが、時間がたつにつれて、これらのレポートを自動化する方法や、イテレーションをトラックするもっと簡単な方法を模索するようになりました。Scrum 1.0 がリリースされてから、移行するまで長く (1 年近く) はかかりませんでした (Scrum 1.0 は bit.ly/fdojaD (英語) からダウンロードできます)。
アジャイル: 振り返りが非常に重要
アジャイル チームとして時間の経過とともに進化するに従い、チーム、プロセス、および実行の改善に連携して力を注ぐことに、数え切れない時間を費やしてきました。こうした改善は、イテレーションの完了時に始まり、(スプリントの目標に照らしてチェックする) スプリントのレビューおよび振り返りで終了するのが一般的です。アジャイル チームとしては、振り返りを見落としがちです。今回もときどき見落としがあり、振り返りにエネルギーを再び注ぐことになりました。
MSF Agile では、TFS により、プロジェクトの SharePoint サイトで提供されるイテレーション バックログのテンプレートを通じて、振り返りをトラックする機能が提供されます。このブックでは、作業速度、適切に作業した点、および今後改善できる点をトラックできます (図 8 参照)。
.jpg)
図 8 MSF Agile のイテレーション振り返りテンプレート
チームとしては振り返りの改善に力を注いだことだけでなく、絶えずすべての作業を再評価したことにかなり誇りを持っています。振り返りの見直しで多くのことを学びましたが、テクノロジが進化するにつれてアジャイル プロセスも微調整しています。今回の場合は、マイクロソフトが Scrum 1.0 と呼ばれる新しいプロセス テンプレートをリリースしたときに TFS も進化したため、これを無視することはできませんでした。実際に、喜んでこれを受け入れました。
Scrum 1.0 への移行
チームは厳密にスクラムベースの方式で作業することは考えていませんでしたが、多くの点でスクラムのチームと似ていました。MSF Agile の導入前は、製品バックログ項目 (PBI) といった用語を使用しており、その後、ユーザー ストーリーに移行しました。
以前に行ったように、短いプロジェクトの 1 つを選択して、新しい Scrum 1.0 のプロセス テンプレートを評価することにしました。MSF Agile を導入したときとほぼ同じように、Scrum 1.0 テンプレートで使用できる WIT を理解することに時間を費やしました。図 9 に示すように、用語はやや異なりますが、概念の多くは似ています。
図 9 Scrum 1.0 の作業項目の種類の定義
| 作業項目の種類 (WIT) | 目的 |
| 製品バックログ項目 | この製品でユーザーが実行できるアクティビティをトラックします。 |
| タスク | 実行する必要がある作業をトラックします。 |
| バグ | 必要な動作と実際の動作との相違点を記述し、障害を修正するために行った作業をトラックし、修正を検証します。 |
| 障害 | 進行を妨げる障害をトラックします。 |
| テスト ケース | テストするステップ セットのサーバー側データ。 |
| 共有ステップ | 再利用可能なテスト ステップ セットのサーバー側データ。 |
| スプリント | 開始日と終了日が明確な製品バックログから取得した作業を実行するスプリント。 |
Scrum 1.0 ですぐに気付いた大きな変化は、スプリントという WIT です。これにより、Scrum 1.0 チームは、スプリントの具体的な開始日と終了日を定義して、そのスプリントの目標をトラックし、TFS 2010 内の振り返りからメモを保存できます。既に述べたように、MSF Agile では、イテレーション バックログのブックと、振り返りの Microsoft Word テンプレートで同様の機能が提供されます。スプリント、目標、および振り返りが作業項目として用意され、その作業項目に作業を割り当てられるようになったことは魅力的な変化でした。MSF Agile から Scrum 1.0 に移行したのはこれが大きな理由です。
機能のダッシュボード、レポートといったイテレーションの成果物を管理するチームの PM たちは、多くの場合、レポートを更新してチームおよびパートナーの現時点のビューを反映するのにかなりの時間を費やしていました。しかし、Scrum 1.0 には、スプリントに日付を割り当てるスプリント WIT があります。バーンダウンのレポートでは、スプリント WIT の情報を使用して、適切な日付範囲を表示します (図 10 参照)。
.jpg)
図 10 Scrum 1.0 のサンプル スプリント バーンダウン
これはシンプルかつシームレスで、スプリントの計画中に実行できる作業とうまく適合します。もうレポートをカスタマイズして開始日と終了日を設定しなくてもよくなりました。スプリントの計画の前に、スプリント WIT を作成するときに自動作成されるようになったためです。
要点をまとめると、MSF Agile と Scrum 1.0 は、アジャイル チームにさまざまなオプションを提供します。もちろん、どのオプションを使用するかは、今回のチームと同様、皆さんしだいです。図 11 の表に、各プロセス テンプレートの WIT の概要と、これらの WIT が互いに対応するようすを示します。繰り返しになりますが、TFS 2010 を使用してアジャイル ソフトウェア開発を導入する新しいチームは、まず、各 WIT の使用方法について詳しく理解することをお勧めします。
図 11 MSF Agile と Scrum 1.0 の WIT の比較
| MSF Agile | Scrum 1.0 |
| ユーザー ストーリー | 製品バックログ項目 |
| タスク | タスク |
| バグ | バグ |
| 懸案事項 | 障害 |
| テスト ケース | テスト ケース |
| 共有ステップ | 共有ステップ |
| スプリント |
プロセス テンプレートの違いの詳細については、私のブログ (bit.ly/i5tF2G、英語) を参照してください。
Scrum 1.0 プロジェクトでイテレーションのブックを使用する
チームが進化し、TFS 2010 でより多くのプロジェクトを作成するにつれて、イテレーションのブックが必要であることに気が付きました。イテレーションのブックは、中断や、さらに重要なことに、スプリント レベルでのチームのキャパシティを把握するのに大いに役立ちます。このため、Scrum 1.0 と互換性を持つようにブックをカスタマイズしました。
この変更を敢えて取り上げたのは、Scrum 1.0 が役に立たないと指摘するためではなく、イテレーションのブック内で提供する多くの機能が必要であることを指摘するためです。チームメイトの John Socha-Leialoha が、ブログ (blogs.msdn.com/b/jsocha、英語) で、イテレーション バックログのブックを Scrum 1.0 テンプレートで機能するように変更する方法について説明しています。ブックがネイティブに機能しない 1 つの理由は、Scrum で使用できないフィールドに格納されているデータを使用するためです。John のブログ記事は、ブックを Scrum 1.0 プロジェクトで機能するようにした方法を、他のチームが理解できるようにすることに重点を置いています。最終結果として、計画中や作業開始時にブックを使用して、キャパシティを把握できるようになりました。そこで気付いた 1 つの問題点は、Scrum 1.0 の既定では、計画中に作業が個人に割り当てられません。代わりに、作業にスタック順位を設定し、順序付けられた方法でバックログから直接取り出します。したがって、ブックとの互換性を保つために、すべての作業を個人に割り当てて、キャパシティを確認できるようにする必要がありました。
作業分野ベースのトラッキングと Scrum 1.0 の割り当て
既に述べたように、チーム メンバーへの作業の割り当てには問題があります。1 人の開発者、1 人のテスター、および 1 人の PM が携わるプロジェクトでは、個人への作業の割り当てはうまくいきました。しかし、今回苦労したのは、プロジェクトのキャパシティがチームの動向によって変化する点です。たとえば、1 つの機能に 3 人の開発者、2 人のテスター、および 1 人の PM が携わるとします。その時点で作業できるメンバーに応じて作業を個人に振り分けるにはどのようにすればよいでしょう。
Scrum 1.0 テンプレートへの移行時に、個人への作業の割り当てから作業分野ベースの割り当てに移行するという大きな変更を行いました。Scrum 1.0 で実行した最初のプロジェクトでは、作業を作業分野ではなく個人に割り当てたことが失敗につながったことがわかりました。チームでこのことを話し合い、"Activity (アクティビティ)" という作業分野のフィールドを使用することにしましたが、作業項目では "Discipline (作業分野)" という名前に変更しました (図 12 参照)。
.jpg)
図 12 Scrum 1.0 での作業分野ベースの割り当て
これにより、開発者、テスター、および PM のキャパシティをひとめで確認できるようになったため、機能チームのリソースの増減を調整することができます。
まとめ
アジャイルへの道のりは終わったわけではありません。プロセスの効率を上げるチャンスはまだまだたくさんあります。アジャイル チームには統制がないというのは、アジャイルに関する誤った表現です。チームとしてこの表現をまったく不正確だと感じます。どちらかと言えば、アジャイル チームの統制レベルは高いことを学びました。アジャイルへの移行前のチームには効果的なプロセスが不足しており、残念ながら、統制もとれていませんでした。TFS 2010 と MSF Agile のプロセス テンプレートへの移行で、チームが成熟し始め、学習と適応に重点を置く精神が生まれました。
今回の適応は、MSF Agile のプロセス テンプレートを使用する状態から、現在の状態にまで進化するのに役立ちました。現在は、Scrum 1.0 のプロセス テンプレートを使用しており、チームとして、目標まであと 1 歩のところまで来ていると感じています。ここまでの道のりが読者の皆さんの参考になり、皆さんのチームが TFS 2010 と上記のプロセス テンプレートに移行するきっかけになればと思います。
ただし、TFS 2010 なしでは、今の状態には至らなかったでしょう。最後になりましたが、これはあるチームが TFS 2010 を使用してアジャイルに見事に移行した物語です。
Chris Adams は、マイクロソフトのグループ プログラム マネージャーを務めており、マイクロソフトのエンタープライズ管理ツールを基盤とするソフトウェアを構築するソフトウェア開発チームを率いています。現在の担当に就く前は、開発、サポート、UI、コア アーキテクチャなどの機能について、プログラム マネージャーとして数年間 IIS (blogs.iis.net/chrisad、英語) に集中的に取り組んでいました。彼は熱心なブログ執筆者でもあり (blogs.technet.com/chrad、英語)、Windows、System Center、および Visual Studio に力を注いでいます。連絡先は chrad@microsoft.com (英語のみ) です。
この記事のレビューに協力してくれた技術スタッフの Aaron Bjork と John Socha-Leialoha に心より感謝いたします。