[アーカイブ] TFS 2012からの新機能「チーム」とはなにか

Article
11/30/2013

<オリジナル投稿 2013年3月12日本ポストの情報はオリジナル投稿時点のものです。マイクロソフトの正式な見解や製品の仕様を保証するものではないことをご了承ください。>

Team Foundation Server、Team Foundation Service には、「チーム」という概念があります。
これは、TFS 2012 から新たに登場した機能です。
TFS では、以下の概念を使って複雑になりがちな開発リソースを構造化することができます。
※以下、でてくる画面ショットは、Team Foundation Service で取得しています。TFS 2012 では日本語で表示されます。また、若干設定が TFS と TF Service で異なる箇所がありますが、ここではあまり影響がありません。あらかじめご了承ください。

縦の概念

チームコレクション
最上位の概念です。リポジトリ（≒DB）の単位と思ってください。基本的にこの単位の中の開発リソースはこの中に閉じて利用、関連付けなどが行えます。作業項目や変更セットの ID もこの単位で連番が割り振られます。この概念は、TFS 2010 から登場しました。Team Foundation Service では、アカウント（≒ https://<account name>.visualstudio.com) なので、事実上この概念はあまり意識されません。
チームプロジェクト
これはおなじみの単位ですね。このチームプロジェクト単位で、開発プロセス（プロセステンプレート）、ソースコードの起点、プロジェクトポータル、レポーティングサイト、ビルド定義、イテレーション、区分などが構築されます。気を付けていただきたいのは、チームプロジェクト : Visual Studio のソリューション＝ 1 : 1 ではないということです。
チーム
チームプロジェクト内のリソースをより小さな単位にカテゴライズする仕組みと思ってください。その名の通り、「チーム」単位で割り振れると覚えるとわかりやすいでしょう。たとえば、少し大き目なプロダクト（やプロジェクト）があり、その中で各機能を担当するチームがあったとしましょうか。その「チーム」の単位で開発リソースを扱いやすくする新たな概念です。新たな概念ですが、これは「区分」の拡張で行われています。なので、「区分」をチーム単位にした場合に相当すると思ってください。これが今回の投稿のメインテーマです。TFS 2012 から登場しました。Team Foundation Service でももちろん利用可能です。

横の概念

上記が縦の構造化だとすると、以下は、チームプロジェクト以下における横の構造化に相当します。

イテレーション
その名の通りですが、「反復」を表します。ウォーターフォールなど反復を想定していない場合は、何か固定にしてもいいですし、この単位で「プロジェクト」があると思うといいかもです。Visual Studio Scrum 2.2 プロセステンプレートだと以下の階層のイテレーションが設定されています。
リリース1 の中で、スプリント 1 ～ 6 があるという設定です。もちろん、階層を増やしたり、減らしたり設定は変更可能です。また、このスプリントの単位で開始日と終了日を設定します。これは各イテレーションごとに行う設定です。ここで行った設定は、スプリントバックログに反映されます。バーンダウンチャートの基準線に影響します。
区分
区分は、機能やコンポーネント、レイヤー、顧客などどのような単位で設定してもかまいません。開発リソースをより把握しやすくしたいためにはどのような概念があるといいのかを考えてください。開発リソースが複雑でないということでしたら、「区分」は事実上無視をしていても問題はありません。上述のように、「チーム」はこの区分の拡張ですので、ここでは「チーム」としての機能を見ていきます。

チーム

チームは、チームプロジェクトを新規に作成した際に実は、一つ作成されています。それは、チームプロジェクトと同じ名前のチームです。チーム分けを必要としない場合は、事実上無視してしまって構いません。チームは、Webベースの管理画面から設定/編集が可能です。
チームの設定時には、画面上部のパンくずリストを見るとわかりやすいです。
チームプロジェクトでの設定
チームでの設定
チームで設定できる主なものは以下です。

チームの識別子
- チーム名
- チームの説明
- チームのアイコン
チームのメンバー
- チームメンバー（チームのメンバーを登録する概念があります）
  それぞれのアカウントを設定することもできますが、グループ指定がおすすめです。
チーム運営上の設定
- イテレーション
  チームの単位でイテレーションのどの部分を使うのかを設定ができます。具体的にいうと、どのイテレーションを「プロダクトバックログ」として採用し、どのイテレーションを「スプリントバックログ」として採用するのかを決めることができるのです。
  この例では、”通常” tfsug と書いてある最上位の部分がプロダクトバックログで、Sprint 1 ～ 4 がスプリントバックログの対象ですが、このチームではこれを限定し、プロダクトバックログの対象を Sprint 1 にし、その下の Feature Crew A をスプリントバックログの対象に設定しています。
  設定方法はとても簡単です。プロダクトバックログの対象としたいイテレーションを右クリックし、「Set as team’s backlog iteration」をクリックするだけです。採用されているかどうかは、イテレーションの横に、「Backlog iteration for this team」と記載されているのでわかりやすいです。また、スプリントバックログの対象は、プロダクトバックログで選択したイテレーションの配下にあるものが選択可能となります。こちらはチェックボックスがでてますので、より直感的に設定できますね。ここで、チェックを入れたイテレーションだけが、Web インターフェイスのチームの「バックログ」に表示されます。
  (↑) こういうことです。
  最上位のいつものバックログ画面と比較するとわかりやすいです (下図)。
  扱っている粒度が異なることがわかりますね。粒度が異なりますので、ベロシティ (※上記画面ショットでは表示データがありません)や、CFD（累積フロー図) も異なっているのがわかります。これはスプリントバックログでも同様です。それぞれのスプリントバックログを見てみましょう。チーム、チームプロジェクトの順になっています。
  チームのスプリントバックログ (↑)
  チームプロジェクトでのスプリントバックログ(↑)
  このチームの概念を用いることで、Scrum of Scrum のようなことがよりやりやすくなるのではないかと期待してます。
- 区分
  「区分」にセットした項目のみが、 Web インターフェイスのバックログ管理に表示されます。他のチームの情報が入ってきませんので、より運営がやりやすくなります。
- セキュリティ
  アクセス権などももちろん、チームの単位で設定できます。基本的に上位からの継承となります。
- 通知 (アラート)
  各種の通知もチーム単位で設定できます。

開発リソースの割り当て

さて、チームが今までかゆいところに届きにくかったところをカバーしてくれることを見てきましたが、では、チームに開発リソースを割り振るにはどうすればいいのかを簡潔に書いておきます。Web インターフェイスで、「チーム」として、アクセスしている場合は、特別に意識する必要はありません。どういうことかというと、上部のパンくずリストが、

となっている場合は、そのチームとしての情報しか見えませんし、この状況下で設定した場合は、そのチームの所有物として既定で設定されます。たとえば、タスクを新規に作成したとすると、「区分 (Area)」が自動で設定されます。

上位のチームプロジェクトのスプリントバックログで見てみると「区分」で振り分けられているのがわかります。
「Area Path」のところを見てください。