web-dev-qa-db-ja.com

TFSおよびスクラム-エリア、反復、バックログの反復、スプリントの反復のベストプラクティス構成

この一連の質問は、TFS 2012 Areas and Iterations with Scrum 2のセットアップ方法に関するベストプラクティスの回答を導き出そうとします。

コンテキスト：TFS 2005以来Team Systemを使用しており、最初に各製品のチームプロジェクトを作成してからMSF 4.2プロセステンプレート。最終的に少し調整しました（一部の作業項目タイプにいくつかのフィールドを追加しただけです）。

現在に進んで、TFS 2012とVS 2012を実行します。過去の経験とコミュニティのフィードバックを考慮して、単一のチームプロジェクトとスクラム2.1に移行し、エリアを使用して製品とチームを分離します。以下のリンクは、このアプローチの良い読み物です。

エリアに適用する予定の典型的なレイアウトは、次のラインに沿ったものになります。

-> Team Project (Area root)
 |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
    |---> Product A
    |   |---> Feature Area 1
    |   |---> Feature Area 2
    |   |---> Feature Area 3
    |
    |---> Product B
    |   |---> Feature Area 1
    |   |---> Feature Area 2
    |
    | (ETC)

 |--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B)
    |---> Product C
    |   |---> Feature Area 1
    |   |---> Feature Area 2
    |
    | (ETC)

概念的には、環境に論理的であるため、上記にはかなり満足しています。上記によれば、次のようなチームがあります。*「クライアントAチーム」*「クライアントBチーム」

質問1）私たちのチームはそれほど大きくなく、管理をより管理しやすくするために、製品ごとにチームを定義したくないと考えましたクライアントごとに物理的なチームがあり、彼らがそのクライアントのすべての製品を監督しているためです。これは間違いですか、それとも大丈夫ですか？

質問2）上記のチーム構成がOKであると仮定した場合、上記の各エリアを各チームに「マッピング」するのは正しいですか。 「クライアントAチーム」は、そのチームが所有するエリアとしてエリア「クライアントA」（およびすべてのサブエリア）を指定します。デフォルトエリアについてはどうですか。「クライアントA」エリアのルートをチームのデフォルトとして設定してもかまいませんか？

反復レイアウトについては、次のような類似したものを計画します。

-> Team Project (iteration root)
 |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
    |---> Product A
    |   |---> Release 1
    |   |   |---> Sprint 1
    |   |   |---> Sprint 2
    |   |   |---> Sprint 3
    |   |
    |   |---> Release 2
    |   |   |---> Sprint 1
    |   |   |---> Sprint 2
    |   |   |---> Sprint 3
    |   |
    |   |---> Release 3
    |
    |---> Product B
    |   |---> Release 1
    |   |   |---> Sprint 1
    |   |   |---> Sprint 2
    |   | 
    |   |---> Release 2
    |   |   |---> Sprint 1
    |   |   |---> Sprint 2
    |
    | (ETC)

 |--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B)
    |---> Product C
    |   |---> Release 1
    |   |   |---> Sprint 1
    |   |   |---> Sprint 2
    |   |
    |   |---> Release 2
    |   |   |---> Sprint 1
    |   |   |---> Sprint 2
    |
    | (ETC)

質問3）これは、特にTFSがバックログを表示する場合、反復を正しく行うのが難しいようです。具体的には、TFSスクラム2反復のセットアップでは、計画とその後の開発のためにリーフレベルの反復のみを選択（チェックボックス）する必要があるようです。したがって、上記の例を拡張すると、「クライアントAチーム」が今後4週間にわたって新しい製品Bの作業を開始できるようになる場合があります（2週間のスプリントを想定）。次に、リリース1からのみ「スプリント1」と「スプリント2」を選択（チェックボックス）しますか？私はそれを正しく理解/使用していますか？

質問4）チームバックログの反復選択-これは、製品ごとのチームではなく、クライアントごとにチームを持つという概念のために問題になる可能性がありますが、たぶん理解しているだけかもしれませんそれは間違っています。 TFSエリアのセットアップでは、どの反復が「チームのバックログ反復」であるかを指定します。私の問題は、PBI（製品バックログアイテム）が製品固有であり、別の製品のPBIと混同したくないことです。したがって、まだ理解できないのは、おそらく「製品B」ではなく「チームのバックログの反復」として「クライアントA」を選択した場合の影響です。私はここで自分自身を混乱させていると思います-賢明な選択は何でしょうか？

上記の質問は、定義された各TFS 2012チームに対して、これらの反復、エリア、チームバックログの反復、およびデフォルトエリアの選択がどのような影響を与えるのかを理解していないことに起因します。このセットアップで抱えている問題のいくつかは、TFSがチームの製品バックログとスプリントバックログを正しく識別することです。

1つのチームプロジェクトと製品の複数の領域（一般的に推奨）が問題を複雑にしているのかどうかはわかりません。

質問5）TFS Web Access Webサイト-「WORK | work items | Shared Queries」の下の任意のチームについて、「Current 「スプリント」（ブロックされたタスク、スプリントバックログなど）が、これらのクエリは「ルートプロジェクト\リリース1 \スプリント1」に対してハードコードされているようです。そうでない場合、これらのクエリを維持するためのベストプラクティスは何ですか？

これらの質問に対処するのに役立つかもしれない品質の高いTFS 2012およびスクラム2固有のトレーニング/チュートリアルを知っていますか、またはスクラム2 TFSセットアップを成功させるためのガイダンスを提供しますか？

tfstfs2012scrumbacklogsprint
26
Jaans

あなたが私の投稿の使用を見つけたことを願っています、そして、 すべてを支配する1つのチームプロジェクト と TFS vNext：マスターバックログを持つようにプロジェクトを設定するおよびサブチーム 。

質問に答えるための最善の努力は次のとおりです。

質問1）私たちのチームはそれほど大きくなく、管理をより管理しやすくするため、クライアントごとに物理的にチームを持ち、そのクライアントのすべての製品を監督するため、製品ごとにチームを定義したくないと考えました。これは間違いですか、それとも大丈夫ですか？

これは問題なく、チームの成長に合わせて成長できます。チームメンバーが複数のクライアントにまたがって作業している場合、優先順位付けとコンテキスト切り替えの問題が発生する可能性があります。これは、チームのレベルを上げるか、単一の統合バックログと個別のサブチームを持ち、製品作業ではなくクライアント作業に焦点を当てることで最小限に抑えることができます。私はあなたが持っているレイアウトのためにこのアプローチを本当にお勧めします。

質問2）上記のチーム構成に問題がないと仮定した場合、上記の各エリアを各チームに「マッピング」する、つまりチーム「クライアントAチーム」の場合、エリア「クライアントA」（およびすべてのサブエリア）をそのチームが所有するエリア。デフォルトエリアについてはどうですか。「クライアントA」エリアのルートをチームのデフォルトとして設定してもかまいませんか？

それは確かに正しいものであり、そのチームがそれらのデフォルトで選択されると、すべてのワークアイテムが作成されることになります。多くの組織は、その他のアイテムを作成、注文し、適切なチームバックログに分割する親またはマスターバックログも作成します。GregBoer、TFS Agile Planning Toolsのプロダクトオーナーは、彼の投稿でブログを書いています TFS vNext：構成プロジェクトにマスターバックログとサブチームを含める 。

チームがクライアント間の境界を越えない限り、またはエリアとイテレーションをチームに困難にマッピングし始める限り、反復のレイアウトは本当に見栄えが良いです。単一のチームまたはチームのグループを複数のクライアントにマップする必要があると思われる場合は、次のようなものが必要になる場合があります。

-> Team Project (Iteration root)
 |—> Team Boundary (This could be one or more teams)
    |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
        |---> Product A
        |   |---> Release 1
        |   |---> Release 2
        |   |---> Release 3
        |
        |---> Product B
        |   |---> Release 1
        |   |---> Release 2
        |
        | (ETC)

    |--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B)
        |---> Product C
        |   |---> Release 1
        |   |---> Release 2
        |
        | (ETC)

まだ動的ではありませんが、これはそのシナリオを可能にします。ただし、$\TeamProject\Client A\ProductAソース管理構造を保持し、これを除外しません。これは単に計画プロセスの区分化であり、ALMソリューションの他の部分に必要以上に溢れてはなりません。

質問3）これは、特にTFSがバックログを表示する場合、反復を正しく行うのが難しいようです。具体的には、TFSスクラム2反復のセットアップでは、計画とその後の開発のためにリーフレベルの反復のみを選択（チェックボックス）する必要があるようです。したがって、上記の例を拡張すると、「クライアントAチーム」が今後4週間にわたって新しい製品Bの作業を開始できるようになる場合があります（2週間のスプリントを想定）。次に、リリース1から「スプリント1」と「スプリント2」のみを選択しますか（チェックボックス）。私はそれを正しく理解/使用していますか？

あなたはそうですが、実際に3つのスプリントを見て、スクラムプロセスの一部として実行可能なバックログを持っています。スプリント1と呼ばれる場合、スプリント4にチェックマークを付けたときにUIでスプリント2で混乱しないように、スプリントを連続して番号を付けることをお勧めします。また、現在のチームの経験レベルの集計を保持するのも良いことです。 。

-> Team Project (Iteration root)
 |—> Team Boundary (This could be one or more teams)
    |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
        |---> Product A
        |   |---> Release 1
        |   |   |---> Sprint 1
        |   |   |---> Sprint 2
        |   |   |---> Sprint 3
        |   |---> Release 2
        |   |   |---> Sprint 4
        |   |   |---> Sprint 5
        |   |   |---> Sprint 6
        |   |---> Release 3
        |   |   |---> Sprint 7
        |   |   |---> Sprint 8
        |   |   |---> Sprint 9
        |
        | (ETC)

ただし、関連する技術プロセスとそれが達成する結果については、基本的に正しいです。

質問4）チームバックログの反復選択-これは、製品ごとのチームではなく、クライアントごとにチームを持つという概念のために問題になる可能性がありますが、おそらく間違っていると理解しています。 TFSエリアのセットアップでは、「チームのバックログの反復」の反復を指定します。私の問題は、PBI（製品バックログアイテム）が製品固有であり、別の製品のPBIと混同したくないことです。したがって、まだ理解できないのは、おそらく「製品B」ではなく「チームのバックログの反復」として「クライアントA」を選択した場合の影響です。私はここで自分自身を混乱させていると思います-賢明な選択は何でしょうか？

自分を混乱させず、チームのバックログに何かを入力する人は、デフォルトを変更したい製品の反復/領域に変更する必要があります。少なくともデフォルトでは、正しいチームとこれを取得していますアイテムを入力する人、プロダクトオーナー、またはチームメンバーにとって、これを正しく分類するのは簡単なことです。

チームのデフォルトとして指定したエリアの下にあるものはすべて、デフォルトで表示されるアイテムに含まれます。チームのデフォルトエリアを「右クリック」し、「サブエリアを含める」の選択を解除すると、トップレベルのみが表示され、これがグレッグのマスターバックログに使用されるテクニックになります。ただし、チーム内の可視性と透明性のために、「サブエリアを含める」設定を維持することをお勧めします。

1つのチームプロジェクトと製品の複数の領域（一般的に推奨）が問題を複雑にしているのかどうかはわかりません。

できる。一部の組織では、「チーム」のドロップダウンリストを作業項目（Conchango/EMCテンプレートなど）に追加し、それをアジャイルプランニングツールの構成でデフォルトとして構成できるチーム指定として使用することを好みます。そうすれば、エリアまたはイテレーションでチーム指定する必要はありません。あなたの組織がどのように構成されているかについての情報がなければ、どちらの方法も推奨できません。

質問5）TFS Web Access Webサイト-「WORK | work items | Shared Queries」の下の任意のチームには、「Current Sprint」（Blocked Tasks; Sprint Backlog;など）というフォルダーの下に事前定義されたクエリがありますが、これらのクエリは「Root Project\Release 1\Sprint 1」に対してハードコーディングされています-これらは、反復に対して定義された日付が与えられると、現在のスプリントが自動的に検出されませんか？そうでない場合、これらのクエリを維持するためのベストプラクティスは何ですか？

オプション1：各スプリントは、クエリの変更に2分かかります

オプション2：それを行うツールを作成する

オプション3：リリース内に「現在の」反復ノードを追加し、現在アクティブな反復をそのノードの下に移動します。次に、「クライアントA\Product A\Release 1\Current」という「Under」を指すようにクエリを設定します。その後、ネストされた繰り返しを一度変更すると、すべてのクエリが機能します。その後、Currentを変更する必要がありますが、リリースごとに1回です。

これらの質問に対処するのに役立つかもしれない品質の高いTFS 2012およびスクラム2固有のトレーニング/チュートリアルを知っていますか、またはスクラム2 TFSセットアップを成功させるためのガイダンスを提供しますか？

私は、Scrum.orgからのプロフェッショナルスクラム開発者トレーニングをお勧めします。または/およびALMコンサルタントと連携します。

26
MrHinsh - Martin Hinshelwood

この質問と、TFSの構造化、プロジェクト、およびチームに関するすべてに関連して、@ MrHinshには、TFSチームの使用に関する次のブログ投稿がありますwithout。 。ただし、注意が必要です。

彼のブログの詳細： http://nakedalm.com/team-foundation-server-2012-teams-without-areas/

1
Jaans