プロジェクトの階層の設定

CA Agile Central のプロジェクト階層を設定する方法は、組織のニーズによって異なります。表現しようとしている階層は、組織構造です。 CA Agile Central 内のプロジェクトは、単純の組織構造のノードを意味します。 

プロジェクト階層の設定には、以下が含まれます。

基本階層

チームのノード

CA Agile Central は、作業がチームを通過する速度を追跡し、予測可能かつ持続可能なペースを決定します。Agile では、チームが職能横断型で永続的である場合、最適なパフォーマンスが得られます。 

複数レベルの階層

職務横断型のチーム 

後でプロジェクトと作業アイテムを再構築する必要がある場合は、以下を考慮してください。

CA Agile Central で開始するには、全体構造ではなく、組織の論理的な部門(R&D、販売、マーケティング)の階層を定義します。 単純な構造で開始し、発展させることを許可します。

ベスト プラクティス

チームは、階層構造の各レベルに配置できます。 複数のチームまたは領域間でロールアップする場合は、親ノードを使用します。 ワークスペースによって最上位のノードが自動的に作成されることはありません。

階層内でチームを複製しない

複製

推奨事項: 同じチームが複数のバックログからの作業を所有している場合、この処理には 4 つの推奨される方法があります。 どの方法を選択しても、必要なレベルのグラフ(ストーリー、ポートフォリオ アイテム)を指定できるため、追跡と可視性が保持されます。

タイムボックスをノードとして使用しない

タイムボックスは、プロジェクト階層に属しません。タイムボックスの構成を保持する場合は、[計画]-[タイムボックス]ページでリリースを使用することをお勧めします。

テスト構造を階層内に配置しない

プロジェクト階層にテスト構造を追加しないでください。CA Agile Central のテスト構造の概要については、「CA Agile Central Quality Manager の概要」を参照してください。 CA Agile Central Quality Manager をお持ちでない場合は、テスト ケースをユーザ ストーリーに関連付けて、タグまたはテスト ケース フィールドを使用して、機能領域を追跡することができます。

忘れずに階層に最上位ノードを配置する

忘れずに構造の最上位にノードを配置してください。 ワークスペースによって最上位のノードが自動的に作成されることはありません。 データをロールアップできるように、ここで配置する必要があります。

CA Agile Central のコーチからのアドバイス

成功した組織の主な要因は以下のとおりです。

永続的な機能横断的チーム

CA Agile Central は、作業がチームを通過する速度を追跡します。この測定により、持続可能なペースでのチームの作業量を予測することができます。予見可能性の要点の 1 つは、チームが永続的であり、週ごとで同じ人が作業する必要があることです。 作業が完了する速度を測定するために、開発者やテスターなど、すべての必要な協力者がチームのメンバとしてカウントされる必要があります。

一致するタイムボックス

複数のチームがスクラムのような反復プロセスを使用している場合は、タイムボックスを一致させることが多くのメリットにつながります。イテレーションとリリースで開始日/終了日が同じである場合、CA Agile Central で自動的にロールアップが実行されて、タイムボックスのステータスの複合ビューが提供されます。[チームのステータス]ページにはチーム間のキャパシティが表示されます。これは、アジャイルへの移行中に、引き続きいくつかの人が複数のチームに関与する場合に便利です。最後に、イテレーションを一致させると、容易に複数のチームを導くことができます。一致するイテレーションのハートビートに移ることから発生する不安や不快感は数日間のみですが、メリットは長い間続きます。

複数のバックログまたはプロジェクトからの作業を 1 人のユーザが所有することを避ける

Agile の有効性は、チームベースのコミットメントとは別に提供されます。ユーザが複数のチームまたはプロジェクトで作業する場合、これらの有効性が減少します。1 人のユーザが複数のチームで作業する必要がある場合、キャパシティを減らすことを計画する必要があります。ユーザが 1 つのプロジェクトに対して 50%、2 番目のプロジェクトに対して 50% の共同作成者になるように考慮することをお勧めします。あるユーザが同時に 3 つのプロジェクトに対応する場合、そのユーザがどのプロジェクトに時間を費やすかを予測するのは困難であるため、キャパシティ計画を行うときはそのユーザの貢献を考慮しないことをお勧めします。 さらに、調査によると、ユーザが複数のタスクを切り替えるときに作業の有効速度が大幅に低下します。

階層および CA Agile Central Portfolio Manager (RPM)

ポートフォリオ アイテムを作成するか、プロジェクトを作成するか

以下の記述に該当する場合は、ポートフォリオ アイテムを作成します。

  • ライフサイクル(開始日と終了日)がある
  • 開始したか、終了したかと、残存作業の割合を追跡する必要がある

ポートフォリオ アイテムを作成するか、親ユーザ ストーリー(エピック)を作成するか

上記の 2 つの記述に該当し、作業が戦略的な観点から重要な場合は、ポートフォリオ アイテムを作成します。 大企業では、特定のジョブ ロールは戦略に関係し、それ以外のジョブ ロールは実行に関係します。作業に関心を持つ人を把握しておくと、ポートフォリオ アイテムにするか、ユーザ ストーリーにするかを決定するのに役立ちます。

ポートフォリオ アイテムは、ビジネス ケースと明確なバリュー ステートメントが必要な戦略的イニシアチブです。エピックは、通常、問題のエンジニアリングの解決方法です。

RPM のサンプルの階層

CA Agile Central プロジェクト階層には、戦略および実行のためのレイヤを含めることができます。これらのレイヤは、組織構造内のノードです。これらの 2 種類のレイヤの違いは概念的なもので、CA Agile Central のユーザ インターフェースの部分ではありません。

戦略レイヤ
  • ポートフォリオ アイテムが含まれる
  • 戦略的ジョブ ロールの適切なレベルのスコープを許可する
  • まだ開発段階にない作業を整理および計画する場合に特に役立つ
  • ポートフォリオ アイテムの完了率の可視性を提供する
実行レイヤ
  • ユーザ ストーリーとディフェクトが含まれる
  • チームの速度と進行状況を追跡できる
 

ポートフォリオ アイテムは、プロジェクトの階層内に存在する場所に関係なく、関連するストーリーの完了率をロールアップします。ポートフォリオ アイテムの子は、同一のプロジェクトやポートフォリオ アイテム自体の子プロジェクトに格納する必要はありません。

CA Agile Central Portfolio Manager でのプロジェクト階層の設定方法に関する厳密な会社のルールはありません。 CA Agile Central Portfolio Manager の導入前に長期間 CA Agile Central を使用していた組織は、新しく CA Agile Central を導入した組織とは異なる構造である場合があります。以下の例では、CA Agile Central Portfolio Manager でプロジェクト階層を設定するためのさまざまな方法を示しています。

   

組織タイプ 特定の製品またはプログラム専用のチーム 同時にすべてまたはいくつかの製品またはプログラムに対して作業するチーム
ISV/製品会社
企業の IT グループ
製品/IT ハイブリッド  

概念的には、最下位レベルのポートフォリオ アイテムは戦略レイヤで開始しますが、その作業がチームに割り当てられると、実行レイヤに移動します。どのチームが作業を処理するかを反映するようにプロジェクト フィールドを更新することをお勧めします。戦略レイヤと実行レイヤの両方に表示できるようにするため、ポートフォリオ アイテムを複製しないでください。

エピックが 1 つのブランチ(戦略)に入力されて、別のブランチ(実行)の子になると、チーム レベルでの追跡がわかりづらくなる場合があります。エピック ストーリーの詳細ページから、子を追跡します。

フィードバック

ヘルプをお求めですか?CA Agile Central コミュニティは、セルフサービスとサポートのワンストップ ショップです。CA Agile Central サポートにフィードバックを送信したり、答を見つけたり、他のユーザとのコラボレーションには CA Agile Central コミュニティ にご参加ください。