Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
累積フロー図 (CFD) は、システムを介した作業のフローを視覚化することによって、作業プロセスを監視するのに役立ちます。 この記事では、CFD、サイクル時間、リード タイムを使用して問題を特定し、ワークフローの効率を向上させる方法について説明します。
- CFD を設定または表示するには、「 累積フローダイアグラムの表示と構成」を参照してください。
- リード タイムまたはサイクルタイムコントロールチャートをダッシュボードに追加するには、「 リード タイム」ウィジェットと「サイクルタイム」ウィジェットを参照してください。
- CFD を設定または表示するには、「 累積フローダイアグラムの表示と構成」を参照してください。
- リード タイムまたはサイクルタイムコントロールチャートをダッシュボードに追加するには、「 リード タイム」ウィジェットと「サイクルタイム」ウィジェットを参照してください。
継続的フローCFDは、リーンプロセスに従うほとんどのチームが好むチャートです。
しかし、多くのチームは、リーンプラクティスとスクラムやその他の方法を組み合わせています。 反復またはスプリント中にリーン プラクティスを使用します。 この場合、図は少し異なって見えます。 そのチャートは2つの追加項目を示しています。連続フローのCFDはリーンプロセスを行っているほとんどのチームが好むものです。
しかし、多くのチームは、リーンプラクティスとスクラムやその他の方法を組み合わせています。 反復またはスプリント中にリーン プラクティスを使用します。 この場合、図は少し異なって見えます。 次のグラフに示すように、2 つの追加の貴重な情報である固定期間 CFD が表示されます。
連続フロー CFD
この固定期間 CFD は、完了したスプリントを示します。
スプリントのスコープ設定が上部の行に表示されます。 作業は最終日までに完了する必要があるため、Closed 状態の傾きはチームが軌道に乗しているかどうかを示します。このビューはバーンアップ チャートと考えてください。
グラフでは、プロセスの最初のステップは左上の領域にあります。 最後の手順は右下の領域にあります。
完了したスプリントの固定期間 CFD
グラフ メトリック
CFD は、時間の経過に伴って状態または列ごとにグループ化された作業項目の数を示します。 追跡の 2 つの主要なメトリックは、サイクル時間とリード タイムです。 これらのメトリックはグラフから抽出します。
メトリック
定義
サイクル時間1
1 つのプロセスまたはワークフロー状態で作業を移動するのにかかる時間。 1 つのプロセスの開始から次のプロセスの開始までの長さを測定します。
リード タイム1
継続的フロー プロセスの場合: 要求が行われた時刻 (提案されたユーザー ストーリーの追加など) から、その要求が完了 (終了) するまでの時間。
*スプリントまたは fi 連続フロー プロセスの場合: 要求が行われた時刻 (提案されたユーザー ストーリーの追加など) から、その要求が完了 (終了) するまでの時間。
スプリントまたは固定期間プロセスの場合: 要求の作業が開始されてから作業が完了するまでの時間 (たとえば、アクティブからクローズ状態までの時間)。
進行中の作業 (WIP)
作業中の作業量または作業中の作業項目の数。
スコープ
特定の期間にコミットされた作業の量。 このメトリックは、固定期間プロセスにのみ適用されます。
1 分析データを使用するCFDウィジェットと、チームバックログまたはボードから表示できる組み込みのCFDは、個別のリードタイムとサイクルタイムの値を提供しません。 ただし、[ リード タイム] ウィジェットと [サイクルタイム] ウィジェットでは 、これらの値が提供されます。
リード タイムまたはサイクル時間と WIP の間には明確な相関関係があります。 WIP の数が多いほど、サイクル時間が長くなり、リード タイムが長くなります。 逆に言えば、WIP が少なくなると、サイクルとリード タイムが短くなります。 開発チームが重点を置く項目が少なくなると、サイクルとリード タイムが短縮されます。 この相関関係は、作業の追跡と管理に使用するボードで WIP の制限 を設定する主な理由です。
作業項目の数は、特定の日の作業の合計量を示します。 固定期間 CFD では、このカウントの変更は、その期間のスコープの変更を意味します。 連続フロー CFD では、キュー内にあり、特定の日に完了した作業の合計量が表示されます。
作業を特定のボード列に分類すると、プロセスの各領域の作業量が表示されます。 このビューでは、作業がスムーズに移動している場所、ブロックがある場所、作業が行われていない場所に関する分析情報が提供されます。 データの表形式ビューを理解するのは難しいですが、視覚的なCFDは、作業プロセスで何が起こっているのか、その理由を確認するのに役立ちます。
問題を特定し、適切なアクションを実行する
CFD は、次の質問に対する回答を提供します。 回答に基づいて、システム内で作業を移動するプロセスを調整できます。
チームは時間に合った作業を完了しますか?
この質問は、固定期間 CFD にのみ適用されます。 ボードの最後の列の作業の曲線 (または進行) を見ることで理解を得ることができます。
このシナリオでは、イテレーションの作業範囲を減らすことを検討できます。 このアクションは、作業が安定したペースで続行されると仮定して、作業が十分に迅速に完了していないことを明らかにする場合に適しています。 このシナリオは、作業が過小評価され、次のスプリントの計画に組み込まれる必要があることを示すことができます。
ただし、作業が十分に迅速に完了しない他の理由がある可能性があります。 これらの理由は、グラフ上の他のデータを調べることで判断できます。
作業の流れはどのように進行していますか?
チームは安定したペースで作業を完了していますか? 指示する 1 つの方法は、グラフ上のさまざまな列間の間隔を確認することです。 それらは、最初から最後まで、互いに類似または均一な距離ですか? 列は複数日にわたってフラットラインに表示されますか? それとも、膨らんでいるように見えますか?
むら、または不均一性は、平らな線や膨らみを示すためのリーン用語です。 「ムラ」は、システム内におけるムダ（無駄）の一種を示します。 システムの不均衡が原因で、CFD に膨らみが生じます。
フラットラインとバルジのCFDの監視は、制約理論プロジェクト管理プロセスの重要な部分をサポートしています。 システムの最も遅い領域の保護は 、ドラムバッファーロープ プロセスと呼ばれ、作業の計画方法の一部です。
2 つの問題は、フラットラインとバルジとして視覚的に表示されます。
チームが作業項目の状態を定期的に更新しない場合は、フラットな線が表示されます。
作業の追跡と管理に使用するボードは、作業を 1 つの列から別の列に移行する最も迅速な方法を提供します。
また、1 つ以上のプロセス間の作業に計画よりも長い時間がかかる場合にも、フラットな線が表示されます。 1 つまたは 2 つのパーツのみに問題がある場合は、バルジが発生するため、システムの多くの部分にフラットな線が表示されます。
フラットライン
バルジは、作業がシステムの一部に構築され、プロセスを移動しない場合に発生します。
たとえば、テストに時間がかかるが、開発にかかる時間が短い場合にバルジが発生する可能性があります。 その結果、開発状態で作業が蓄積されます。 バルジは、後続のステップに問題があることを示し、必ずしもバルジが発生しているステップであるとは限りません。
バルジ
フローの問題を修正する方法
次のアクションを実行することで、タイムリーな更新が不足している問題を解決できます。
- 毎日のスタンドアップを保持する
- その他の定期的な会議の開催
- 毎日のチームリマインダーメールのスケジュール設定
全身的なフラットラインの問題は、そのような問題はまれですが、より困難な問題を示しています。 フラットラインは、システム全体の作業が停止していることを示します。 基になる原因には、次の問題が考えられます。
- プロセス全体のブロック
- 時間がかかるプロセス
- ボードに取り込まれていない他の機会に移行する作業
全体システムのフラットライニングの一例は、特徴機能のCFDに発生する可能性がある。 機能は複数のストーリーで構成されているため、機能作業はユーザー ストーリーの作業よりも時間がかかる場合があります。 このような状況では、(前の例のように) 傾向が予想されるか、問題がよく知られており、チームによって既に指摘されています。 既知の問題である場合、問題解決はこの記事の範囲外です。
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 を制限し、古いバグを修正する作業を行いました。 標準偏差はその日付より後に縮小され、予測可能性が向上します。