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