Azure DevOps Services |Azure DevOps Server 2022 および Azure DevOps Server 2019
累積フロー図 (CFD) を使用して、システムを介した作業のフローを監視できます。 サイクル時間とリード タイムは、追跡に使用される 2 つの主要なメトリックです。 これらのメトリックは、CFD から抽出できます。
この記事では、CFD、サイクル時間、リード タイムを使用して作業プロセスの問題を特定し、システムを介して作業を移動する方法について説明します。
- CFD を構成または表示するには、「 累積フローダイアグラムの表示と構成」を参照してください。
- リード タイムまたはサイクルタイムコントロールチャートをダッシュボードに追加するには、「 リード タイム」ウィジェットと「サイクルタイム」ウィジェットを参照してください。
サンプル グラフと主要メトリック
継続的フローCFDは、リーンプロセスに従うチームが最も好むチャートを提供します。
ただし、多くのチームは、リーン プラクティスとスクラムやその他の手法を組み合わせています。 その結果、イテレーションまたはスプリントのスパン内でリーン プラクティスが使用されます。 この状況では、図は少し異なる外観になります。 次のグラフに示すように、2 つの余分で非常に貴重な情報である固定期間 CFD が提供されます。
連続フロー CFD
この固定期間 CFD は、完了したスプリント用です。
一番上の行は、スプリントのスコープ セットを表します。 作業はスプリントの最終日までに完了する必要があるため、Closed 状態の傾きは、チームがスプリントを完了するために軌道に乗っているかどうかを示します。 このビューを考える最も簡単な方法は、バーンアップ チャートです。
グラフでは、プロセスの最初のステップが左上の領域として示されます。 プロセスの最後のステップは右下の領域として示されています。
完了したスプリントの固定期間 CFD
グラフ メトリック
CFD には、時間の経過に伴って状態または列ごとにグループ化された作業項目の数が表示されます。 追跡に使用される 2 つの主要メトリックは、サイクル時間とリード タイムです。 これらのメトリックはグラフから抽出できます。
メトリック
定義
サイクル時間1
1 つのプロセスまたはワークフロー状態で作業を移動するのにかかる時間。 長さは、1 つのプロセスの開始から次のプロセスの開始まで測定されます。
リード タイム1
連続フロー プロセスの場合: 要求が行われた時刻 (提案されたユーザー ストーリーの追加など) から、その要求が完了 (終了) するまでの時間。
スプリントまたは固定期間プロセスの場合: 要求の作業が開始されてから作業が完了するまでの時間 (たとえば、アクティブからクローズ状態までの時間)。
進行中の作業 (WIP)
作業中の作業量または作業中の作業項目の数。
スコープ
特定の期間にコミットされた作業の量。 このメトリックは、固定期間プロセスにのみ適用されます。
1 分析データを使用するCFDウィジェットと、チームバックログまたはボードから表示できる組み込みのCFDは、個別のリードタイムとサイクルタイムの値を提供しません。 ただし、[ リード タイム] ウィジェットと [サイクルタイム] ウィジェットでは 、これらの値が提供されます。
リード タイムまたはサイクル時間と WIP の間には明確に定義された相関関係があります。 WIP が多いほどサイクル時間が長くなり、リード タイムが長くなります。 逆に言えば、WIP が少なくなると、サイクルとリード タイムが短くなります。 開発チームが重点を置く項目が少なくなると、サイクルとリード タイムが短縮されます。 この相関関係は、作業の追跡と管理に使用するボードで WIP 制限 を設定する必要がある主な理由です。
作業項目の数は、特定の日の作業時間の合計を示します。 固定期間 CFD では、この数の変化は、特定の期間のスコープの変更を示します。 連続フロー CFD では、キュー内にあり、特定の日に完了した作業の合計量を示します。
作業を特定のボード列に分類すると、プロセスの各領域の作業量が表示されます。 このビューでは、作業がスムーズに移動している場所、ブロックがある場所、作業がまったく実行されていない場所に関する分析情報が提供されます。 データの表形式ビューを解読するのは困難です。 ただし、視覚的なCFDは、作業プロセスで何が起こっているのか、なぜ起こっているのかを理解するのに役立ちます。
問題を特定し、適切なアクションを実行する
CFD は、次の質問に対する回答を提供します。 回答に基づいて、システム内で作業を移動するプロセスを調整できます。
チームは時間に合った作業を完了しますか?
この質問は、固定期間 CFD にのみ適用されます。 ボードの最後の列の作業の曲線 (または進行) を見ることで理解を得ることができます。
このシナリオでは、イテレーションの作業範囲を減らすことを検討できます。 このアクションは、作業が安定したペースで続行されると仮定して、作業が十分に迅速に完了していないことを明らかにする場合に適しています。 このシナリオは、作業が過小評価され、次のスプリントの計画に組み込まれる必要があることを示すことができます。
ただし、作業が十分に迅速に完了しない他の理由がある可能性があります。 これらの理由は、グラフ上の他のデータを調べることで判断できます。
作業の流れはどのように進行していますか?
チームは安定したペースで作業を完了していますか? 指示する 1 つの方法は、グラフ上のさまざまな列間の間隔を確認することです。 それらは、最初から最後まで、互いに類似または均一な距離ですか? 列は複数日にわたってフラットラインに表示されますか? それとも、膨らんでいるように見えますか?
むら、または不均一性は、平らな線や膨らみを示すためのリーン用語です。 「ムラ」は、システム内におけるムダ（無駄）の一種を示します。 システムの不均衡が原因で、CFD に膨らみが生じます。
フラットラインとバルジのCFDの監視は、制約理論プロジェクト管理プロセスの重要な部分をサポートしています。 システムの最も遅い領域の保護は 、ドラムバッファーロープ プロセスと呼ばれ、作業の計画方法の一部です。
2 つの問題は、フラットラインとバルジとして視覚的に表示されます。
チームが作業項目の状態を定期的に更新しない場合は、フラットな線が表示されます。
作業の追跡と管理に使用するボードは、作業を 1 つの列から別の列に移行する最も迅速な方法を提供します。
また、1 つ以上のプロセス間の作業に計画よりも長い時間がかかる場合にも、フラットな線が表示されます。 1 つまたは 2 つのパーツのみに問題がある場合は、バルジが発生するため、システムの多くの部分にフラットな線が表示されます。
フラットライン
バルジは、作業がシステムの一部に構築され、プロセスを移動しない場合に発生します。
たとえば、テストに時間がかかるが、開発にかかる時間が短い場合にバルジが発生する可能性があります。 その結果、開発状態で作業が蓄積されます。 バルジは、後続のステップに問題があることを示し、必ずしもバルジが発生しているステップであるとは限りません。
バルジ
フローの問題を修正する方法
次のアクションを実行することで、タイムリーな更新が不足している問題を解決できます。
- 毎日のスタンドアップを保持する
- その他の定期的な会議の開催
- 毎日のチームリマインダーメールのスケジュール設定
全身的なフラットラインの問題は、そのような問題はまれですが、より困難な問題を示しています。 フラットラインは、システム全体の作業が停止していることを示します。 基になる原因には、次の問題が考えられます。
- プロセス全体のブロック
- 時間がかかるプロセス
- ボードに取り込まれていない他の機会に移行する作業
体系的な機能停止の一例は、流体力学シミュレーションの特定の機能で起こり得る。 機能は複数のストーリーで構成されているため、機能作業はユーザー ストーリーの作業よりも大幅に時間がかかる場合があります。 このような状況では、(前の例のように) 傾きが予想されるか、問題がよくわかっており、チームによって既に問題が発生しています。 既知の問題である場合、問題解決はこの記事の範囲外です。
Teams は、CFD の膨らみとして表示される問題を事前に修正できます。 適切な修正は、バルジが発生する場所によって異なる場合があります。 たとえば、開発プロセスでバルジが発生したとします。 テストにコードを記述するよりもかなり時間がかかっているため、バルジが発生している可能性があります。 テスト担当者は、多数のバグを見つけている可能性もあります。 作業を開発者に継続的に移行すると、開発者は増え続けるアクティブな作業の一覧を継承します。
この問題を解決するには、次の 2 つの方法が考えられます。
- 開発者を開発プロセスからテスト プロセスに移行し、バルジが解消されるまで進めます。
- 作業の順序を変更します。 具体的には、作業に時間がかかる作業と迅速に実行できる作業を組み合わせています。
バルジを除去するための基本的な解決策を探してください。
注
作業が不均等に進むさまざまなシナリオが発生する可能性があるため、問題の実際の分析を実行することが重要です。 CFD は、問題が存在することを示します。 また、問題のおおよその場所を示すこともできますが、根本原因を調べる必要があります。 このガイダンスでは、特定の問題を解決するための推奨されるアクションを提供しますが、解決策は状況に適用されない可能性があります。
スコープは変更されたのですか?
スコープの変更は、固定期間 CFD にのみ適用されます。 グラフの一番上の線は作業の範囲を示します。 スプリントには、最初の日に実行する作業が事前に読み込まれる。 一番上の行に対する変更は、作業の追加または削除を示します。
特定のシナリオでは、CFD を使用してスコープの変更を追跡することはできません。 このシナリオは、同じ数の作業項目が同じ日に追加および削除されるときに発生します。 この場合、線はフラットなままです。
この場合、スコープの変更を追跡するには、次のアクションを実行します。
- 複数のグラフを比較します。
- 特定の問題を監視します。
- スプリント バーンダウンを使用して、スコープの変更を監視します。
WIP が多すぎますか?
ボードを簡単に監視して、WIP の制限を超えているかどうかを判断できます。 また、CFD を使用して WIP レベルを監視することもできます。
通常、大量の WIP は垂直バルジとして表示されます。 WIP が大量に存在する時間が長いほど、バルジが楕円状に拡大します。 この動作は、WIP がサイクルとリード タイムに悪影響を及ぼしていることを示しています。
WIPのガイドラインとして、各チームメンバーが同時に進行できる項目は2つまでとしてください。 より厳密な制限ではなく、2 つの項目の制限を使用する主な理由は、現実がソフトウェア開発プロセスに頻繁に侵入することです。
利害関係者から情報を取得したり、必要なソフトウェアを取得したりするのに時間がかかる場合があります。 作業を停止できる理由はいくつもあります。 ピボットする 2 番目の作業項目を用意すると、余裕を持つことができます。 両方の項目がブロックされている場合は、別の項目に切り替えるだけでなく、赤いフラグを上げてブロックを解除します。 進行中の項目が多数あるとすぐに、それらの項目に取り組んでいるユーザーはコンテキストの切り替えが困難になることがあります。 自分がやっていたことを忘れてしまう可能性が高く、間違いにつながる可能性があります。
リード タイムとサイクル時間
次の図は、リード タイムとサイクル時間の違いを示しています。 リード タイムは、作業項目が作成されたときに開始され、作業項目が完了状態カテゴリに入ると終了します。 サイクル時間は、作業項目が最初に進行中または解決済みの状態カテゴリに入ったときに開始されます。 作業項目が完了状態カテゴリに入ると、サイクル時間が終了します。
作業項目が完了状態カテゴリに入り、再アクティブ化されると、そのリードとサイクル時間が影響を受けます。 提案済み、進行中、または解決済みの状態カテゴリに費やす余分な時間は、リードとサイクル時間に影響します。
チームがボードを使用して作業を追跡および管理する場合は、列がワークフローの状態にどのようにマップされるかを理解するのに役立ちます。 ボードの構成の詳細については、「ボード の列を管理する」を参照してください。
システムが状態カテゴリ (提案、進行中、解決済み、完了) を使用する方法の詳細については、「 バックログとボードのワークフロー状態について」を参照してください。
リードとサイクル時間に基づいて配送時間を見積もる
平均リードとサイクル時間と標準偏差を使用して、配送時間を見積もることができます。
作業項目を作成するときに、チームの平均リード タイムを使用して、その作業項目の完了日を見積もることができます。 チームの標準偏差によって、見積もりの変動性が示されます。 同様に、サイクル時間とその標準偏差を使用して、作業の開始後に作業項目の完了を見積もることができます。
サイクル タイム ウィジェットの例
次のグラフでは、平均サイクル時間は 8 日間です。 標準偏差は 6 日間です。 このデータを使用して、チームが作業を開始してから約 2 ~ 14 日後に将来のユーザー ストーリーを完了すると見積もることができます。 標準偏差が狭いほど、予測しやすくなります。
プロセスの問題を特定する
外れ値は、多くの場合、基になるプロセスの問題を表します。 たとえば、待機時間が長すぎて pull request を確認できない、外部の依存関係をすばやく解決しないなどがあります。 チームの管理図で外れ値を確認します。
いくつかの外れ値を示すサイクル時間ウィジェットの例
次のグラフは、いくつかのバグが完了するまでに平均より長くかかったため、いくつかの外れ値を示しています。 これらのバグに時間がかかった理由を調査すると、プロセスの問題を明らかにするのに役立つ可能性があります。 プロセスの問題に対処することで、チームの標準偏差を減らし、チームの予測可能性を向上させることができます。
また、プロセスの変更がリードとサイクル時間にどのように影響するかを確認することもできます。 たとえば、5 月 15 日に、チームは WIP を制限し、古いバグに対処するために協調的な取り組みを行いました。 標準偏差がその日付より後に縮小され、予測可能性が向上していることがわかります。