11

私たちのチームはTFS2010を初めて使用します。これまで、独自のビジネス要件マトリックス（トレーサビリティマトリックス）のExcelスプレッドシートを使用してきました。次のような典型的な列があります。

要件ID| プロジェクト| ルールグループ| ビジネスルール| タイプ...etc

ビジネスルールの列には、次のようなものがあります。

  • 「システムは、アクターが研究を検索できるようにする手段を提供するものとします。」
  • 「システムは、アクターがプロジェクトを検索できるようにする手段を提供するものとします。」
  • 「システムは、インバウンドパッケージの移動アクティビティを生成する必要があります。」
  • 「バーコードマニフェストをインポートするには、システムは、各サンプルプレースホルダーとともに、サンプルがバーコードマニフェストによって作成されたことを示すコードを含める必要があります。」

ドキュメントや監査などに関する業界の厳格さから、プロセステンプレートの選択肢としてアジャイルのMSFではなくCMMIのMSFを選択しました。

私たちは、TFS2010の世界に「私たちの働き方」を実装するための最善の方法について多くの議論を重ねてきました。私たちの問題の核心は次のように思われます：

  • [実装]タブの[要件]->[タスク]の間の「親/子」の関係に従う必要があるようです。ただし、これは、すべての要件に対応するタスクがあることを意味します（冗長で過度に細かく見える）。
  • タスクは、よりきめ細かいものと考えるのが好きです（つまり、「アウトバウンドコンソール画面の開発」）。
  • 開発者は、自分に割り当てられたタスクを確認し、それらのタスクに関連付けられている要件（機能および非機能）を簡単に確認できるようにしたいと考えています。
  • トレーサビリティは最優先事項ですが、必ずしも非常に細かく（実際のコード行まで）する必要はありません。私たちが見ているように、そうすることは開発を非常に退屈で逆効果にするでしょう。この点で、私たちは賢明なバランスを望んでいます。

私たちのアプローチは本当にそれがそうであるように見える正方形の穴への丸いペグですか？それとも、私たちは何かを誤解/見逃しているだけですか？さまざまな作業項目の種類をしっかりと理解しているように感じます。

もう少しコンテキストを追加すると、タイプ「機能」の要件は、機能、非機能、QoSなどのより詳細な要件の「親」であると理解しています。シナリオの要件タイプはユースケースに類似していることを理解しています。

したがって、TFS2010は次の階層に従うと考えています。

  • 要件（機能）
    • 要件（機能）
      • タスク

明らかに、私たちにとっての問題は、いくつかの点で要件/タスク間の親子関係が必要である一方で、同時に要件の親としてのタスクの必要性をほぼ認識していることです。

[実装]タブ（およびそれが適用する親子関係）をスキップして、[すべてのリンク]タブを使用するだけでよいと考えています。これにより、「関連」や「影響/影響を受ける」などの他のリンクタイプを介して要件とタスクをより柔軟に関連付けることができます...しかし、そこでの大きな問題は、組み込みのTFS 2010レポート（特に要件の進捗状況/時間の追跡）。

任意の洞察をいただければ幸いです。

4

3 に答える 3

6

TFSに付属しているすぐに使用できるプロセステンプレートをカスタマイズする必要があるようです。

正直なところ、ツールに合わせてプロセスを変更するのではなく、プロセスに合わせてツールを入手できるように、テンプレートをカスタマイズする必要があると思います。

利用可能なカスタマイズオプションのいくつかを知っているかどうかはわかりません。そのため、会社のTFSをカスタマイズするときに使用したオプションのいくつかについて説明します。

プロセステンプレートのボックスから出てくる任意のワークアイテムタイプを編集できます。実行できるカスタマイズはたくさんあります。たとえば、私の会社では、テストグループのメンバーだけがバグを閉じることができるようにしたかったので、閉じた状態へのすべての遷移にその制約を課しました。

必要に応じて、遷移、状態、フィールド、タブなどを追加できます。

新しいワークアイテムが必要な場合は、空白から新しいワークアイテムを作成するか、既存のワークアイテムタイプに基づいて新しいワークアイテムを作成できます。既存のタイプから新しいワークアイテムを作成するには、ワークアイテムタイプをエクスポートし、xmlを編集して名前を新しいタイプを入力してからインポートします。

さまざまな作業項目タイプ間の関係についての懸念は、カスタムリンクタイプを作成し、それらを新しいテンプレートに含めることで対処する必要があります。

実行したいプロセスを十分に理解しているようです。そのプロセスに合わせてTFSをカスタマイズする必要があると思います。

これだけ多くのカスタマイズを実行することの1つの欠点は、標準レポートでは多くの有用な情報が提供されないことです。これには、チームがいくつかの新しいレポートを作成する必要があります。それがあなたのニーズを満たすならば、あなたはExcelでいくつかの素晴らしい報告をすることもできます。

HTH

于 2011-04-21T08:31:12.600 に答える
2

ここでは、カスタマイズされたアプローチを採用する必要があると思います。TFSの要件として、自分にとって重要なレポートと指標を選択してください。そこから、レポートとメトリックを取得する方法で作業項目間のリンクを設計します。また、あなたはおそらくこれをすでに知っているでしょうが、タスクWIには、開発だけでなくそれを使用できるようにする規律フィールドがあります。幸運を！

于 2011-04-14T14:38:25.137 に答える
2

まず、TFSの世界へようこそ。:)

あなたの働き方に問題はありません。概説した階層は問題なく、TFSは、必要な作業項目タイプ（WIT）と関係（リンク）のセットをサポートします。[実装]タブ、および他のWITとの関係を示す他のすべてのタブは、タイプが関連するWITのリスト全体に対するフィルターにすぎません（つまり、[要件の実装]タブには、タイプが要件またはタスクであり、親を持つすべての作業項目が表示されます。 /子関係）。

次に、プロセスに必要なアーティファクト（WIT）と、それらがどのように連携するかを考え、プロセステンプレートをカスタマイズして希望どおりに機能させる必要があります。

これは、特にTeam FoundationPowerToolsの一部であるプロセスエディターを使用する場合は比較的簡単に実行できます。リンクページを変更する場合は、すべてワークアイテムタイプのレイアウト部分で行われます。

要件とタスクの関係の問題について：私は常に要件をユーザー/顧客が必要とするものの定義と見なしています。要件は、必要性、目標、および望ましい効果（および副作用）を説明する、より外向きである必要があります。タスクはより内向きであり、開発者に上記の目標を達成するためにどのように取り組むべきかを伝える必要があります。

そのことを念頭に置いて、私は常に開発者にタスクのみを担当させることを好みます。さらに、タスクは常に要件（またはバグ、変更要求など）から派生する必要があります。要件の結果として表示されないタスクは、作業が不要であるか、計画が不十分であることを示している可能性があります。

これがお役に立てば幸いです、アサフ。

于 2011-04-21T11:47:05.067 に答える