5 つの役立つアジャイル指標

統計やチャートは優れたツールです。アジャイルにぜひ役立てましょう。

Dan Radigan Dan Radigan
Browse topics

指標には慎重な扱いが必要です。

データを一切追跡しないため、リリースに向けて順調に進んでいるのか、進行に伴い効率化が進んでいるのかを判断するのが困難なプロジェクトにかかわった経験は誰にでもあるでしょう。一方で、統計を武器にチームを競争させたり週末の労働を正当化したりするようなプロジェクトの苦しさも、多くの人が経験しています。ほとんどのチームと指標が愛憎関係にあるのも無理はありません。

しかし、指標をうまく活用する方法があります。アジャイル指標を追跡し共有することで、混乱を減らし、開発サイクル全体でチームの進捗 (や後退) を把握することができます。その方法を以下で説明します。

ビジネスを理解する

作業を「完了」するだけでは十分とは言えません。重要なのは、適切な製品を適切なタイミングで適切な市場向けに構築することです。プログラム全体を順調に進めるには、常にデータを収集し分析する必要があります。アジャイルプログラムでは、ビジネス指標とアジャイル指標の両方を追跡することが重要です。ビジネス指標ではソリューションが市場のニーズに対応しているかどうかを重視し、アジャイル指標では開発プロセスのさまざまな側面を測定します。

プログラムのビジネス指標はロードマップに根差したものであるべきです。

ロードマップのイニシアチブごとに、プログラムのゴールに対応する複数の主要パフォーマンス指標 (KPI) があります。また、エンドユーザーの導入率や自動テストでのコードの使用割合など、それぞれの製品要件の成功基準もあります。これらの成功基準をプログラムのアジャイル指標に取り込みます。チームが成熟するほど、適応力が高まり進化することになります。

アジャイル指標を使用してデリバリーを最適化する方法

次のアジャイル指標は、ソフトウェアのデリバリーに焦点を当てています。スクラムチームでもカンバンチームでも、アジャイル指標により開発プロセスを的確に把握できるようになり、ソフトウェアのリリースが容易になります。

スプリントバーンダウン

スクラムチームは、時間枠を設けた複数のスプリントに開発活動を分割します。チームはスプリントの開始時に、その枠内に完了できる作業量を予測します。その後、スプリントバーンダウンレポートを使用して、スプリント全体にわたり作業の完了状況を追跡します。x 軸は時間を、y 軸は未完了の作業量をストーリーポイントまたは時間数で示します。ゴールはスプリント終了時までに、予測したすべての作業を完了することです。

社内では、常に予測どおりに活動しているチームがアジャイルのお手本となります。ただし、実際にはまだ完了していない項目を数に入れて数字をごまかさないように注意しましょう。短期的にはうまくいっているように見えますが、長い目で見れば学習と改善の妨げとなります。

注意すべきアンチパターン
  • 十分な作業を行っていないため、チームがスプリントを次々と早期終了する。
  • コミットする作業量が多すぎるため、チームのスプリントの予測が外れ続ける。
  • 作業を細かく分割していないため、バーンダウンラインが徐々に低下するのではなく急低下する。
  • プロダクト所有者がスプリントの途中でスコープを追加または変更してしまう。

エピックおよびリリースバーンダウン

エピックおよびリリース (またはバージョン) バーンダウンチャートは、スプリントバーンダウンよりも大きな作業群で開発の進捗を管理するものとして、スクラムチームとカンバンチームの両方の開発で参考とされます。(スクラムチームの) スプリントには複数のエピックやバージョンの作業が含まれることがあるため、個々のスプリントとエピックおよびバージョンの両方の進捗を追跡することが重要です。

「スコープクリープ」とは、定義済みのプロジェクトに追加要件が投入されることを指します。たとえば、チームが会社の新しい Web サイトを構築している場合、初期要件の策定後に新しい機能を要求することをスコープクリープと呼びます。スプリント中のスコープクリープは好ましくありませんが、エピックやバージョン内でのスコープ変更はアジャイル開発ではよくあることです。プロジェクトの進行とともに、プロダクト所有者が学習内容に基づいて作業の追加や削除を決定することがあります。エピックおよびリリースバーンダウンチャートにより、全員がそのエピックやバージョン内の作業の状況を認識します。

注意すべきアンチパターン
  • チーム作業の進行に合わせて、エピックまたはリリース予測が更新されない。
  • 複数のイテレーションにわたり進捗が見られない。
  • スコープクリープが常態となっている (プロダクト所有者が一連の作業によって解決しようとしている問題を完全に理解していないことが原因と考えられる)。
  • チームが飲み込めるより早くスコープが拡大する。
  • エピックの開発中、増分リリース (インクリメント) が配信されない。

ベロシティ

ベロシティとはスクラムチームがスプリント中に完了する平均作業量をストーリーポイントまたは時間数で表したものであり、予測に非常に役立ちます。プロダクト所有者はベロシティを使用して、チームがどれくらいの速さでバックログを処理できるかを予測します。レポートでは予測される作業と完了した作業を複数のイテレーションにわたって追跡しているため、イテレーションが多いほど予測精度が向上します。

たとえば、プロダクト所有者がバックログで 500 のストーリーポイントの完了を目指しているとします。開発チームは一般的にイテレーションごとに 50 のストーリーポイントを完了することがわかっています。したがって、プロダクト所有者は目的の作業に 10 のイテレーションが必要と考えるのが合理的です。

時間とともにベロシティがどのように変化するかを監視することが重要です。新規チームでは、関係や作業プロセスの最適化に伴い、ベロシティの向上が期待できます。既存チームでは、ベロシティの追跡によって常に一貫したパフォーマンスを確保するとともに、特定のプロセスの変更が向上につながるかどうかを確かめることができます。平均ベロシティが低下する場合、通常はチームの開発プロセスの中に非効率的な部分があることを示しており、次のふりかえりで課題として挙げる必要があります。

注意すべきアンチパターン

長期にわたってベロシティが一定しない場合、必ずチームの見積もりを再度行ってください。チームのふりかえりで、次の質問をします。

  • この作業の見積もり段階で考慮に入れなかった、予想外の開発上の課題はあったか? これらの課題を発見するために、作業をより適切に分割するにはどうすればよいか?
  • チームに無理を強いるような外部からの業務上の圧力があるか? 開発ベストプラクティスを遵守することが結果として困難になっているか?
  • チームとして、スプリントの予測に力を入れすぎているか?

ベロシティはチームごとに異なります。チーム A のベロシティが 50 でチーム B のベロシティが 75 でも、チーム B の方が処理能力が高いわけではありません。ベロシティと同様に、各チームの見積もりに対する考え方もそれぞれ異なるからです。チーム間でベロシティを比較したいという誘惑に負けないでください。チームごとのストーリーポイントの解釈に基づき、労力と成果のレベルを測定します。

管理図

管理図では、個々の課題のサイクル期間 (「対応中」から「完了」までの合計時間) に注目します。チームのサイクル期間が短いほど処理能力が高く、多くの課題のサイクル期間が一貫しているほど作業のデリバリーが予想しやすいことになります。サイクル期間はカンバンチームの主な指標ですが、最適化されたサイクル期間はスクラムチームにとっても有用です。

サイクル期間を測定すると、変更の結果をすぐに確認して調整できるため、チームのプロセスを柔軟かつ効率的に改善できます。最終ゴールは、作業タイプ (新機能、技術的負債など) にかかわらず、一貫して短いサイクル期間を実現することです。

注意すべきアンチパターン

管理図は最初は無秩序に見えます。外れ値はそれほど気にせず、以下の 2 点に注意してトレンドを読み取りましょう。

  • サイクル期間の増大 - サイクル期間が長くなると、チームが苦労して得たアジリティが損なわれます。チームのふりかえりで時間が長くなった理由を突き止めましょう。ただし、1 つ例外があります。チームの「完了」の定義が拡大された場合、サイクル期間も長くなります。
  • 不規則なサイクル期間 – ゴールはストーリーポイント値が同程度の作業項目について一貫したサイクル期間を実現することです。管理図で各ストーリーポイント値の一貫性をチェックしましょう。サイクル期間がストーリーポイント値の大小にかかわらず不規則である場合、ふりかえりで予測が外れた理由を分析し、将来の見積もりを改善します。

累積フロー図

累積フロー図はカンバンチームの重要リソースであり、チーム全体の作業フローの一貫性を確保するのに役立ちます。Y 軸が課題数、X 軸が時間、色がさまざまなワークフローステータスを表しており、不足やボトルネック、作業、WIP 制限を視覚的に表現します。

累積フロー図は左から右まで平坦な状態が理想です。任意の色の逸脱や差は不足やボトルネックがあることを示しているため、図全体で色付きの部分を平坦にする方法を考えましょう。

注意すべきアンチパターン
  • 障害となる課題があると、プロセスの部分によって大規模な余剰や不足が生じます。
  • 未チェックのバックログの増加傾向。これは、古い課題や優先順位が低い課題をプロダクト所有者が解決しない場合に発生します。

その他の指標

有用な指標はここで挙げたものに限りません。たとえば、品質はアジャイルチームにとって重要な指標です。アジャイル開発に適用できる従来の指標は多くあります。

  • 見つかった不具合の数
    • 開発中
    • 顧客へのリリース後
    • チーム以外から
  • 将来のリリースまで先延ばしにされた不具合の数
  • カスタマーサポートの依頼件数
  • 自動化テストのカバー率

アジャイルチームはリリース頻度やデリバリー速度にも着目する必要があります。各スプリントの終了時には、ソフトウェアを本番にリリースする必要があります。実際にはどれくらいの頻度で行っているでしょうか? ほとんどのリリースのビルドが出荷されていますか? また、緊急の修正を本番にリリースするのにどれくらいの時間がかかりますか? リリースは容易ですか、それとも苦労を伴いますか?

指標はチームのやり方を固めるための一部にすぎません。チームのパフォーマンスを定量化し、測定可能なゴールを設定するのに役立ちます。指標は重要ですが、とらわれないようにしてください。リリースプロセスを通じてチームの信頼関係、製品品質、開発スピードを向上するにはふりかえりでチームのフィードバックに耳を傾けることも同じくらい重要です。定量的なフィードバックと定性的なフィードバックの両方を活用して変更を促進しましょう。