【WITブログ(訳)】マイクロソフトの開発部門でのTFSの活用 - 第2章（フィーチャ クルー）
※この投稿は、米Microsoftのデベロッパーツール開発部門のブログ（Teams WIT Tools）を長沢流に意訳・変訳したものです。
※英語原文を正とし、この投稿はあくまで理解の一助としてご活用ください。
※翻訳にあたって Teams WIT Tools ブログの執筆者から許可を得ています。
第2章 フィーチャ クルー
マイクロソフトでは、単一のコードベース上で、1,200もの個別のフィーチャというとても大きなスケールのものを管理しなければならない。
個々のチームに彼らに与えられたフィーチャに集中させつつ、コードベースの品質を維持するにはどういうアクティビティを行っていかなければならないのかを考えないといけない。
我々の答えは、フィーチャ クルーだった。このモデルは、Microsoft Office チームから応用した。下図のようなものだ:
フィーチャ クルー（チームメンバー）がフィーチャの作業をアサインされたら、ライフサイクルは以下のようになる:
- フィーチャ クルーは、まずフィーチャに取り組むための分離した環境を得るために、メインのソース ブランチ（※俗にいうメイン ブランチ）からフィーチャ用のブランチを作成する。これにより、メインのソース ブランチ上での変更から分離されつつ、また、他の誰にも邪魔されないで済むようになる。
- フィーチャの作業に取り組むにあたっては、２つのチェックポイントがある。チェックポイントは、管理者に何を実施しているのかを明示し、フィードバックを行い、意思決定してもらうために用いる。チェックポイント＃１は、デザイン（※実施計画）である。ここでは、問題を解決するためにどう計画したのかを説明する。
- チェックポイント＃２は、機能をデモすることである。ここでは、問題解決のために実際に実施したことを提示する。
- フィーチャの作業を完了したら、メインのソース ブランチでの変更を、フィーチャ用のブランチに統合する（※俗に言う、リベース）。
- メインのソース ブランチへ、フィーチャ実装時の変更を反映する前に、フィーチャ クルーは品質ゲートを通過する必要がある。品質ゲートには、「パフォーマンスのリグレッションがないこと」、「テスト自動化によるカバレッジが70%を満たしていること」などが含まれる。
- フィーチャ クルーは、品質ゲートをクリアしていることを検証し、メインのソース ブランチにフィーチャ実装時の変更をチェックインする。メインのソース ブランチは、いつでもリリース可能に近い状態を保持するため、品質ゲートによって保護されているのである。
注: だいたい、4から6週で完了していた。
16 の異なる品質ゲートを持ち、フィーチャ クルーが「作業の完了」を宣言するには、これらを通過する必要があった。より詳細は、下図となる:
品質ゲートは、膨大なコード行を持つコードベースにおいて、3,000人以上の人員で、700以上のフィーチャの作業を確実に行うために選択した方法であった（分散した作業においても全体的に一貫した品質レベルを維持することができた）。
各フィーチャ クルーがそれぞれのフィーチャに取り組む間、部門では、イテレーションのセットの管理をしていた。それは、全体で 14 のイテレーションであった。
下図は、フィーチャ クルーがメインのソース ブラインチからフィーチャ用のブランチを作成し、作業完了後に、メインのソース ブランチへ統合するまでと、イテレーションの関係を示している。フィーチャ クルーは、他のフィーチャ クルーやイテレーションをオーバーラップすることもある。
イテレーションのレビューにおいて、「実際に、前のイテレーションで何が完了したのか」、「次のイテレーションで何を完了するのか」を上位の管理者に報告した。
次の投稿： TFS を用いたプロセスの実装
※訳者追記:
フィーチャ クルーの背景については、@IT .NET エンタープライズ新時代 インタビュー編 （https://www.atmarkit.co.jp/ad/ms/vs2007/interview/interview.html）も参考になります（ここではフィーチャ チームと呼ばれていますが）。
※訳者余談:
この投稿は、新大阪の駅で新幹線の発車待ちの時間にポストしています。今日は大阪で Microsoft On でした(^^) あっ、出発したぁ。。。．．．. . .
※この意訳・変訳した投稿に関するお問い合わせは、長沢まで