スクラムを用いた、実際のアジャイル開発において、TFSの豊富な機能は最初から最後まで、さまざまな形で活用されます。この記事では、TFSの実際のプロジェクトにおいて、行われるタスクを順に取り上げ、その中でTFSの各機能がどのように使われるかを説明します。
プロジェクトの開始
顧客側担当者の要望を聞くところからプロジェクトは開始されます。担当者との打ち合わせの結果、完成した要件一覧表が出発点となります。要件一覧表には通常、必要となる機能の概要しか書かれていないのですが、それにストーリー ポイント（各機能を完成させるのに必要な工数を相対的なポイントで表したもの）で表した規模感、高中低で表した優先度を要件ごとに追加すると、製品バックログとなります。製品バッグログを明確にすることが、スクラムによるアジャイル開発の第一歩です。
製品バックログをもとに、開発チームは見積もりを行い、顧客との間で合意が取れたら、いよいよアジャイル開発プロジェクトが立ち上がります。このタイミングで、TFS上にチーム プロジェクトを作成します。チーム プロジェクトとは、ソース コードやドキュメント、ビルド結果や作業項目といった、プロジェクトに関するありとあらゆるデータが格納される器です。チーム プロジェクトがアジャイル テンプレート（MSF for Agile Software Development v5.0）を使用するように設定します。そのことによって、アジャイル開発用のデータをチーム プロジェクト内に格納することができるようになります。このテンプレートには、ビルドに失敗した時は自動的に作業項目を追加するなどの設定が事前に行われています。チーム プロジェクトごとに、専用のバージョン管理のリポジトリが存在します。
チーム プロジェクトを作成したら、TSFのユーザーを登録します。プロダクト オーナー、ステークホルダー、開発チームのメンバー、スクラム マスターというプロジェクトに関わる全員がTSFのユーザーとなります。TFSのユーザーは権限に従って、閲覧者、共同作成者、プロジェクト管理者に分かれています。
図 1 新しいチーム プロジェクトの作成
スプリント計画会議
プロジェクトの最初にはスプリント計画会議を開催し、各イテレーションで行うことを決定します。製品バックログ内の項目がイテレーションに割り振られます。また、リリースをどのように行うかの計画が立てられます。そして、ストーリー（製品バックログ項目）毎にどのようなタスク（スプリント バックログ タスク）が必要かを導き出します。スプリント計画会議によって決まったストーリーやタスクを作業項目としてTFSに登録します。作業項目を登録する際には、「区分」にリリース、「イテレーション」にスプリントを設定します。スプリントを設定する際には休日を指定することもできるので、より正確に計画を立てることができます。アジャイル テンプレートには、「タスク」「ユーザー ストーリー」という種別の作業項目が用意されているので、そのまま使用することができます。タスクを登録する際は、関連するストーリーの作業項目とのリンクを作成し、ストーリーとタスクの親子関係を形成します。
これらの作業はVisual Studioから行うことができますが、TFSによる製品計画、スプリント計画では、計画ツールとしてのExcelが強力です。MSF for Agile Software Development v5.0には、あらかじめExcelブックが用意され、製品計画やスプリント計画をExcelから作業できるようになっています。したがって、スプリント計画会議の前に用意していたExcelシートを生かして、ストーリーやタスクを容易に登録することができます。プロジェクト管理者はExcelからプロジェクトの作業項目を把握し、開発者はVisual StudioやEclipseから同じ作業項目を参照することが可能です。
図２ スプリント バックログ の登録
日次スクラム
スプリントでのタスクが明確になったら、実際の開発を開始します。ここまでの手順が少し大変だと感じられたかもしれませんが、これまでに行った準備がプロジェクトの全体を通して効果を発揮します。開発中は毎日、日次スクラムを行います。「前回の日次スクラムから行ったタスク」「次回の日次スクラムまでに行うタスク」「タスクを行う上での問題点」に対する意識合わせを行い、その結果をTFS上の作業項目にすぐに反映します。必要な情報は、TFSから参照しながら、発表を行うことができるので、とても効率的です。日次スクラムの後、その日に行うタスクと担当者は明確になっているので、作業に迷いなく入ることができます。
日次スクラムの際に、TFSのレポートを用いて、タスクの進捗状況を確認するのも効果的です。TFSのレポートを用いると、「各ストーリーの残存作業量は予定どおりか」「優先度の高いストーリーが先に着手されているか」「各ストーリーにいくつテストが定義されているか」「テストはいくつ合格しているか」「テスト ケースが定義されていないストーリーはどれか」などを確認することができます。そして、問題があれば、対処することができます。ストーリー概要のレポートでは、ストーリー単位で、作業見積もりと進捗、残作業時間、テスト件数とテスト結果、バグが一望することができます。TFSではリポジトリが一つのため一貫した情報を容易にレポートすることができます。また、バーンダウン チャートをみて、スプリント バックログ内の未完了タスクの残作業時間を折れ線グラフで確認し、作業が順調に消化されているか、スプリント終了日までに予定の作業が完了するかの見通しを立てることができます。
図３ レポートの参照
バージョン管理
アプリケーションのソースコードを作成するタスクの場合、作成したソースコードをTFSのバージョン管理リポジトリにチェックインし、ビルドに成功しないと、そのタスクは完了しません。また、HTMLファイルのデザインを作成したり、マニュアルなどのドキュメントを作成したりするタスクの場合も、レビューを通った成果物がバージョン管理にチェックインされないことには、タスクは完了とはなりません。このように、実際の開発においてバージョン管理のリポジトリは欠かせないものです。
誰がいつ、どの作業項目に対して、どのファイルを、どのように修正したかというのは、システム開発において重要なことです。TFSでは、そのような記録を簡単に取ることができます。
アジャイル プロジェクトにおいては、通常テスト駆動開発（TDD）が行われます。TDDにおいては、コードの前に単体テストを書き、その単体テストが常にパスする状態を保ちます。そして、コードの意図が明確となり、無駄な重複がなくなるように、常にリファクタリングを行います。タスクの一部の機能が完成するたびに、コードはバージョン管理にチェックインされます。そうすることで、チーム メンバー全員が最新のコードに基づいて、常に開発が行えるようにします。
図４ 作業項目と関連付けたチェックイン
ビルド管理
開発の早い段階から絶えずビルドを実施し、結合テストを実施することで、リリース段階での想定外の障害を防ぐことができます。アジャイル開発では、これを継続的インテグレーションと呼んでいます。TFSでは、バージョン管理のリポジトリにソースコードがチェックインされるたびに自動でビルドを実行させることができます。また、ビルドされた結果に対して、結合テストを実行させることも容易に行うことができます。さらに、コーディング規約に準拠しているかのチェック、静的なコード分析、コードのカバレッジ、テストの影響範囲の記録など、動作以外のコード品質に関するレポートを生成することもできます。
TFSではビルドを手動で実行することもできます。どのようにビルドを行うかの定義をTFS上で行ったら、手動でビルドを実行し、想定通りの動作を行うか確認するとよいでしょう。
ビルド結果はつねに記録され、レポートとして参照することができます。ビルドに失敗した場合、バグという作業項目が自動的に登録されるので、最優先でそのバグに対処するようにすることもできます。
図5 ビルド結果
スプリント レビュー会議
スプリント レビュー会議では、「動くソフトウェア」を顧客にみせて、スプリントの目的を達成しているかのフィードバックを得ます。ドキュメントではなく、実物をみて確認するというアジャイルを象徴するイベントです。顧客の想像とは少し違うところがあったとしても、以降のスプリントで修正することができます。また、スプリント計画会議の時点では気付いていなかった要件に気づくこともあります。
スプリント レビュー会議や、その後に行われる反省会ミーティング（開発メンバーによる、続けるべきこと、現状の問題、新たに試すことを明確にする会議）の内容は、TFSのチームポータル上にあるWikiに登録します。そして、以降のスプリントで取り組むべきユーザーストーリーやタスクがあれば、作業項目として登録します。スプリント レビュー会議中に明らかになったバグがあれば、そのバグも作業項目として登録します。なお次のスプリントの中で対処されるので、バグに対処するというユーザー ストーリーも登録することになります。
図6 Wikiへの登録
テストの管理
アジャイル開発では、ユーザー ストーリーが正しく実現されているかを、顧客（プロダクト オーナー）の立場でテストします。これは受け入れテストと呼ばれ、リリースやスプリント（イテレーション）毎に実施します。Test Managerを使用すると、テストの計画から実施、バグの管理まで、本格的にテスト工程を管理することができます。Test Managerではテスト スイートによってテスト ケースをグループ化、階層化することができ、テスト ケースに紐付けてテストを実施することができます。また、要件 (ユーザー ストーリー) をそのままテスト スイートとして取り込むことができます。要件に対するテストが明確になり、受け入れテストをスムーズに進めることができます。
Test Managerで作成したテスト ケースはTFSの作業項目として、そのまま登録することができます。関連する作業項目はお互いにリンクすることができるので、テスト ケースはテスト対象のユーザー ストーリーやバグなどへリンクさせることで、障害のトレースが容易になります（要件をテスト スイートとして取り込めば、自動的にリンクが設定されます）。また、テスト ケースを一覧するクエリを作成すれば、テスト項目一覧となります。Test Managerからテストを実行した結果、不具合が発見された場合は、バグとして作業項目に登録します。
図７ 要件をテスト スイートとして追加
以上、TFSがアジャイル開発でどのように使われるかに関して、簡単に説明してきました。御覧のように、TFSは計画からリリース前のテストまで、アジャイル開発のあらゆる局面をサポートしており、チーム メンバー間の連携にとても役立ちます。
関連情報