Team Foundation Server をよりイケてる環境にする!? TFS Workbench と TFS の意義
Team Foundation Server (TFS) は Open ALM Platform であるとご紹介をし続けています。それは、Visual Studio Team System のときの構想から生き続けています。
マイクロソフトからは、Visual Studio からアクセスするための Team Explorer （チーム エクスプローラー）が同梱されているため、
”TFS は、Visual Studio 専用の ALM プラットフォーム”
と言われがちですが、決してそんなことはありません。
マイクロソフトから提供しているものだけを挙げても、
- Excel から接続する
- Project から接続する
- Project Server と連携する
- Eclipse から接続する（Team Explorer Everywhere）
- クロスプラットフォーム環境 (Mac OS X, Linux, UNIX,…) から接続する (Team Explorer Everywhere)
- Web ブラウザから接続する (プロジェクト ポータル、Team Web Access)
- Java で操作する （TFS Java SDK）
- OData で RESTful に操作する (OData Service for TFS v1.0)
- MSSCCI でソース管理する (TFS MSSCCI)
- Windows エクスプローラーでソース管理する (TFS Power Tools)
などがあります。
TFS が Open ALM Platform である所以は、マイクロソフトから提供されているもの以外にも多くのサードパーティさんのツール、オープンソース コミュニティが作成、公開しているツールがたくさんあるからです。
TFS が開発プロジェクト、ソフトウェア開発ビジネスに与えてくれるのは、これら、一番使い勝手のよいツールから接続し、開発リソース（要求、タスク、ソースコード、ビルド、テストケース、テスト結果、バグ、テスト環境、などなど）に最適かつ、近道かつ、もっともシンプルなアプローチでつないでくれて、ストレスなく、本来やりたいことに注力させてくれることです。
★ ★ ★
想像してみてください。バグを改修する作業を開発者が行う風景を。
開発者は、バグを識別するために、Excel や BTS で管理されたバグ票を見に行きます。そしてそのバグ票に記載された内容を確認し、テスト結果が管理された他のツールや共有フォルダを覗きに行きます。さらに、テストで使用したテスト環境とテストしたビルドを識別します。そして、そのビルド時に使用していたソースコード一式を SCM や VCS から取り出します（もう書くの疲れましたw）。
さらに、バグを改修します（やっと本業ですね）。
ソースコードをチェックイン（コミット）します。この際に、コメント欄にバグのIDを入力したりします。気が利いていればここで、継続的インテグレーションを走らせるといいでしょう。
さてさて、これは開発者ビューですが、この間、いくつもの開発リソースにいくつものツールからアクセスしてます。本業にたどりつくのも結構大変ですね。本来は、これで終わりではなく、テスト担当者に作業を引き継がねばなりませんし、テスト環境にデプロイもしないといけないわけです。
それでいて、どこからで状況が把握できるトレーサビリティ（BSEの際や、最近ではお米のトレーサビリティで話題にもなっていますので、ここでは解説しません）が求められます。そのトレーサビリティを見るには、またまたいくつものツールから情報を取り出して・・・（もういい加減書くのやめますw）。
★ ★ ★
話が逸れましたが、TFS では、さまざまなシーンでチームが一番ほしい情報に横断的にアクセスすることができるような仕組みを持っています。.NET/Java の API 、そして、新たに OData Service とつながる仕組みがオープンにされています。
これを使った非常に好例として、今日は一つご紹介します。それが、TFS Workbench です。
こちらが TFS Workbench で TFS に接続した例です。ここではタスクボードが実現できていますね（TFS Workbench ではこれ以外にも様々なビューで TFS で管理されている開発リソースを扱いやすく見せてくれます）。
ここで表現されている開発リソースは、２つです。要求（ユーザーストーリー）と、タスクです。
要求単位で、実施するタスクが、ステータス（To Do、In Progress、Done、Removed）で仕切られて非常にわかりやすく表現されています。
これに必要なのは、要求とタスクの有機的な “つながり” です。そして、作業が Done になるとこのタスクとソースコードも有機的な ”つながり” で把握できるようになります。ソースコード、タスクは、自動ビルドされたビルド成果物とも有機的な ”つながり” があります。
要するに、見栄えがよく即把握できるタスクボードとその裏付けである情報が完全にトレーサビリティが取れた状態を保つことができるのです。
このビューを要求（ユーザーストーリー）とテストケースのタスクボードにしたらどうでしょうか。要求単位で、実施しているテストケースを把握できます。テストケースには当然、過去実施した幾度となく存在するテスト結果と有機的な ”つながり” があります。もちろん、テスト対象となるビルド成果物とも 有機的な ”つながり” があります（この時点で、開発成果とテスト成果が有機的な ”つながり” があることがわかりますね）。そして、テスト結果と、バグも有機的な ”つながり” があります。バグは、ビルド成果物、ソースコードとも有機的な ”つながり” がありますので、これでコンプリートな有機的な ”つながり” が完成しているのがわかります。
TFS Workbench のようなツールが、いろいろなシステムや情報源からこれらの情報を収集しようとしたらどうでしょうか？ツール固有のAPIなどを駆使してなおかつ、機能的につながっていない情報を収集しなければなりません。
ここで ツールを開発者に置き換えてみてください。そうです。開発者も実は同じ苦労を毎日絶えず行っています。ツールをまたがり、つながっているようでつながっていない情報に右往左往しながら、開発しています。本業はなんだったのかだんだんわからなくなってきますね。
★ ★ ★
TFS Workbench は、CodePlex でホストされたオープンソース コミュニティで開発、公開がされています。
