デフォルトのTFSセットアップには、シナリオ、タスク、バグの3つの作業項目タイプがあります。最後の1つは非常に簡単で、タスクもあります。チームメンバーが完了するのは特定の仕事です。しかし、シナリオは少し曖昧だと思います。
私は通常、より大規模でより一般的な作業単位のシナリオを作成します。たとえば、「従業員のラインを雇用主に追加する機能を作成する」などです。その場合、より小さく、より具体的な作業項目はタスクになります。たとえば、「詳細フォームを作成する」、「サーバーに保存メソッドを作成する」などです。
変更をチェックインするとき、変更セットをシナリオと特定のタスクにリンクします。これは良い習慣ですか？タスクとシナリオをどのように処理しますか？ベストプラクティスのリソースはありますか？
シナリオは実際にはユースケースを対象としていると聞きましたが、そうですか？
シナリオは、任意のユーザー ストーリーにすることができます。
タスクにチェックインするだけです。タスクを作成したら、開発者に割り当てる前に、まずシナリオにリンクする必要があります。
そうすれば、チェックインとシナリオの間の関連付けは自動的に (そしてレポート可能になります)。
ノーポイントダブル取り扱い
MSF アジャイル テンプレートでは、シナリオは "ユーザー ストーリー"と考えることもできます。これは軽量アジャイル ユース ケースのようなものです。
シナリオは、実装が必要な機能の全体像を詳述し、システムの一部とのユーザー インタラクションの単一パスを記録します。たとえば、スタック オーバーフローでは、いくつかのシナリオが「質問する」または「質問に答える」である場合があります。シナリオとサービス品質要件は、MSF Agile の最上位の作業項目 (システムを定義する作業項目) と考えることができます。シナリオは機能要件であり、サービス品質は非機能要件です。
私は各シナリオから複数のタスクを作成する傾向があり、通常はタスクに対するチェックインのみを記録します。TFS 2010 では、適切に階層化された作業項目が導入され、この作業方法でのレポート作成が容易になります。現在、作業項目の関連付けは双方向です (つまり、タスクがシナリオに関連付けられているとは言えますが、シナリオの子であるとは言えません)。
タスクとシナリオに対してチェックインをマークすることに問題はありませんが、チェックイン時に作業が増えるだけです。また、タスクがダウンする傾向があるため、多くの開発者によってシナリオが配信される可能性があります。個人の活動の粒度で。
作業項目をシナリオに関連付ける作業が多い場合は、次のヒントが役立ちます ( http://www.woodwardweb.com/vsts/top_tfs_tip_3_r.html )。標準の MSF Agile プロセス テンプレートを変更して、チェックインがシナリオを解決する機能を削除し、チェックインをその作業項目に関連付ける方法を示します。シナリオのような長時間実行される作業項目のチェックイン時に解決することは、ほとんどの場合、望んでいることではありませんが、すぐに使用できるデフォルトの動作です。
それが役立つことを願っています。
「デフォルトの TFS セットアップ」が「MSF for Agile Software Development」プロジェクト テンプレートを意味する場合、シナリオは次のように定義されます。
シナリオは、システムを介したユーザー インタラクションの 1 つのパスを記録する作業項目の一種です。ペルソナが目標に到達しようとするとき、シナリオには、その目標に到達するために実行する特定の手順が記録されます。一部のシナリオでは、成功したパスが記録されます。他の人は失敗したものを記録します。シナリオを作成するときは、可能なパスが多数あるため、具体的に記述してください。
これについてもう少し情報を得るには、チーム エクスプローラーのプロジェクトの下にある "Documents/Process Guidance" フォルダーをよく見てください。推奨されるプロセスがかなりよく説明されています。
シナリオはユーザーの視点を表していると考えることができますが、タスクは開発者の視点を表しています。MSF アジャイルのドキュメントによると、シナリオは「構築中のシステムを介したユーザー インタラクションの 1 つのパスを表す」ものであり、タスクは「チーム メンバーが実行する特定の作業項目を識別する」ものです。
タスクはシナリオにリンクできます。開発者としてチェックインするときは、シナリオではなくタスクを解決したので、変更セットをこのタスクに関連付ける必要があります。