26

この一連の質問は、スクラム 2 を使用して TFS 2012 の領域と反復をセットアップする方法に関するベスト プラクティスの回答を引き出すことを試みます。

コンテキスト: 私たちは 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)上記のチーム構成に問題がないと仮定すると、上記の各エリアを各チームに「マッピング」するのは正しいでしょうか。つまり、チーム「クライアント 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 週間 (2 週間のスプリントを想定) で新しい製品 B の作業を開始できるようになる可能性があります。次に、リリース 1 から「スプリント 1」と「スプリント 2」のみを選択 (チェック ボックス) しますか? 正しく理解/使用していますか?

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

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

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

質問 5) TFS Web アクセス Web サイト - 「作業 | 作業項目 | 共有クエリ」の下にある特定のチームについて、「現在のスプリント」(ブロックされたタスク、スプリント バックログなど) というフォルダーの下に定義済みのクエリがありますが、これらのクエリは"Root Project\Release 1\Sprint 1" に対してハードコードされています - これらは、反復に対して定義された日付が与えられた現在のスプリントを自動的に検出するべきではありませんか? そうでない場合、これらのクエリを維持するためのベスト プラクティスは何ですか?

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

4

2 に答える 2

26

また、 One Team Project to rule them allとTFS vNext: Configuring your project to have a master backlog and sub-teams をご覧になることをお勧めします。

ここにあなたの質問に答えるために私の最善の努力があります：

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

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

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

それは確かに正しく、そのチームがそれらのデフォルトで選択されると、すべての作業項目が作成されるはずです。また、多くの組織は親バックログまたはマスター バックログを作成し、さまざまなアイテムが作成、注文されてから、適切なチーム バックログに分割されます。TFS アジャイル プランニング ツールのプロダクト オーナーである Greg Boer は、彼の投稿TFS vNext: Configuring your project to haveでブログを書いています。マスター バックログとサブチーム。

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

-> 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 週間 (2 週間のスプリントを想定) で新しい製品 B の作業を開始できるようになる可能性があります。次に、リリース 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」を選択した場合の影響については、まだ理解できません。私はここで自分自身を混乱させていると思います-賢明な選択は何でしょうか?

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

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

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

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

質問 5) TFS Web アクセス Web サイト - 「作業 | 作業項目 | 共有クエリ」の下にある特定のチームについて、「現在のスプリント」(ブロックされたタスク、スプリント バックログなど) というフォルダーの下に定義済みのクエリがありますが、これらのクエリは"Root Project\Release 1\Sprint 1" に対してハードコードされています - これらは、反復に対して定義された日付が与えられた現在のスプリントを自動的に検出するべきではありませんか? そうでない場合、これらのクエリを維持するためのベスト プラクティスは何ですか?

オプション 1: 各スプリントは、クエリを変更するのにかかる 2 分間を費やします

オプション 2: それを行うためのツールを作成する

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

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

Scrum.org の Professional Scrum Developer トレーニングを受講するか、ALM コンサルタントと連携することをお勧めします。

于 2012-12-05T19:45:14.053 に答える
1

この質問と、TFS の構造化、プロジェクト、およびチームに関するすべての事柄に関連して、@MrHinsh は、エリアに割り当てずに TFS チームを使用することに関する次のブログ投稿を行っています。ただし、注意がないわけではありません。

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

于 2013-11-01T13:32:22.187 に答える