目標を設定する
TFSの主な「信条」は、ソフトウェアの開発と部分的な操作に関連するすべての組織プロセスの予測可能性を高めることです。 このコンテキストでの予測可能性とは、文字通り1つのことを意味します。いつでも、TFSツールを使用して、状況を確認し、結論を導き出すことができます 。 エラーの数、まだ完了していない要件などがあります。 この情報の信頼性は、ソースデータに直接依存します。このようなデータがTFSによって収集されるほど、その後の意思決定がより適切になります。 TFSをさまざまなソースからの情報が絶えず群がっているデータベースとして表すのは非常に正しいことです。 自動モードのどこか、人々がこの情報を自分で提供することを要求するところ。 収集する情報が多いほど、その中に相乗効果と関係が増えることを理解する必要があります。
このことから、TFSの実装を成功させる主な要因は、主にReporting ServicesとOLAPに基づく機能的なレポート、それらの情報コンテンツ、およびこれらのレポートに基づいて結論を導き出す機能です。 つまり、Excelを使用してReporting Services、OLAPキューブを使用せず、TFSが分析に提供するインジケーターのリストを理解していない場合、顕微鏡で釘を打ちます。
レポートの品質を改善する
上記の目標に基づいて、TFSコンポーネントをより集中的に操作する方法、およびこの操作のレベルをさらに上げるために実行する必要がある手順をより詳しく理解できます。
レポートに表示できるデータは、TFS操作レベルの段階的な改善の段階を表すリストにグループ化できます。
- プロジェクトに表示されるすべてのワークアイテムに関する情報。 このデータには、タスク、要件、エラーに関する情報が含まれ、TFSはこれらの作業項目のフィールド変更の完全な履歴を保存します。 この情報に基づいて、現在の課題を理解できます。 この時点で、時間を追跡し、ダウンロードするチームをスケジュールできます。 このデータの品質は人々に直接依存することを忘れないでください。 この段階では、TFSでクエリを操作する方法を学習し、作業項目の状態を移行するメカニズムを説明し、Excelなどの統合ツールを使用する必要があります。
- プロジェクトソースファイルの変更に関する情報。 ソースコードの行のすべての追加、変更、削除。 この操作またはその操作を誰が、いつ、どの基準で行ったか。 TFSでは、ソースコードの変更をエラー、タスク、およびその他の作業項目にリンク（関連付け）できるため、「ベース」に注意することが重要です。 すでにこの段階で、特定の要件の実装または必要なエラーの修正をコード行数で確認できます。 また、コードの変更と実行するタスクとの関連付けの重要性をプログラマに説明するために、この情報の形成への人の参加に注意することも重要です。
- アセンブリ情報。 TFSには、非常に柔軟なプロジェクトビルド環境が含まれています。 自動アセンブリを設定するとすぐに、作業項目とコードの変更に関連する情報がリンクされ、特定のビルドの変更のレベルと規模を理解する機会が得られます。 この段階では、継続的インテグレーション（「継続的インテグレーション」）のメカニズムが含まれます。これにより、プロジェクトの進捗状況をよりよく理解し、長期的な予測を行うことができます。
- テストおよびテストごとのコードカバレッジに関する情報。 テストは、製品の品質を確保するための非常に重要なメカニズムです。 テストは、要件、コードの変更、およびビルドにリンクできます。 これらのメカニズムがオンになるとすぐに、必要な自動テストに合格しなかったため、現在のビルドの容量を評価し、手動テストに提供する機会がすぐに得られ、それによりテスターからの負荷が軽減されます。 さらに、テスト品質のレベルに関する情報を受け取ります（コードカバレッジのおかげです）。
これらすべてのコンポーネントを実装し、すぐにレポートで完全な情報を取得するよう努力する必要はまったくありません。 プロジェクトの構成を段階的に周期的に変更し、組織をスムーズに変更できます。 間違いを恐れないでください。原則として、それらはTFSの実際の経験の不足とのみ関連しており、すぐに追いつきます。
サンプルTFS改善計画
ALMプロセスにTFS機能を段階的に繰り返し含めることは、小さなサイクル（「カイゼン」など）に分割できます。各サイクルでは、レポートを使用して関数を徐々に接続し、パフォーマンスを確認します。
週1：
- 作業項目のステータスに関する30分間のワークショップを実施し、リクエストを処理する
- プロジェクトエリアのリストを作成する（エリア）
- タスクの作業スケジュールの[エリア]フィールドに必須入力を行います
- 最初の自動ビルドシステムを作成する
- 完了したタスクのコンテキストで、レポートにビルドの変更に関する情報が含まれているかどうかを確認します
週2：
- ワークアイテムのリンクに関する30分間のワークショップを実施する（マスター/チャイルド）
- プロジェクトの反復のリストを作成する（反復）
- 要件に従属するタスクを処理するための規則に、計画時間と使用時間のフィールドでの必須入力を含める
- 規則に、変更可能なコードを使用したタスクと要件の必須の関連付けを導入する
- レポートに要件ごとのコード変更量に関する情報が含まれているかどうかを確認します。 KPI-関連付けのないコードの変更数を導入し、チームからこのインジケーターを減らす必要があります。
週3：
- 30分間のコードカバレッジワークショップを開催する
- テストの初期リストを作成し、2〜3個のテストを準備します
- 要件を含む作業スケジュールに、この要件の手動テストの必須作成を含めるには
- テストサブシステムを有効にして新しいビルド定義を作成する
- レポートにテストの完了レベルとコードのカバレッジ率に関する情報が含まれているかどうかを確認します
したがって、各短い段階で特定の結果が達成されますが、これはチームにとって明らかです。
プロセスの変更とTFS構成
TFSは柔軟で汎用性の高いツールです。 パッケージには、2つのプロセステンプレート（アジャイルとCMMI）が含まれています;さらに、他のプロセステンプレートをインストールできます。 彼らの意見では、TFSの実装はこの組織で採用されている慣行に準拠していないため、多くのチームはこれらのテンプレートを改良したいと考えています。 これは完全に容認できる状況ですが、極端なことにはなりません。たとえば、作業要素の移行の条件と基盤を完全にやり直します。 原則として、ALMオートメーションシステムを使用した本格的な作業の経験がない場合、これは非常に悲しい結果につながります。
一般に、使用するプラクティスがプロセスの実装の現在のバージョンに完全に適合し、用語の不一致があるだけである可能性が非常に高い場合があります。 いずれにせよ、コストの形で計画された変更を評価してみてください。会議の新しい組織に同意するか、TFSを変更する方が簡単です。
おわりに
段階的な改善アプローチを使用する場合、ALMの自動化はそれほど難しくないかもしれません。 TFSは、さまざまなコンポーネントから情報を収集する統合された複合体であるためです。 収集するデータが多いほど、プロジェクトの現在の状況をより効果的に理解できるため、ソフトウェア開発プロセスをより効率的に管理できます。 MSDNのドキュメントからApplication Lifecycle Managementの詳細を学び、 フォーラムで議論できます。