要約: アジャイル指標はソフトウェア開発ライフサイクルのさまざまな段階を通じて生産性へのインサイトを提供し、製品の品質評価とチームのパフォーマンス追跡を支援します。
指標には慎重な扱いが必要です。
かつてのようにプロジェクトで一切のデータを追跡しなければ、リリースに向けて順調に進んでいるのか、または効率が向上しているのかを知ることは困難です。反対に、統計を武器にチームを競争させたり週末の労働を正当化したりするようなプロジェクトの苦しさも、多くの人が経験しています。ほとんどのチームと指標が愛憎関係にあるのも無理はありません。
しかし、指標をうまく活用する方法があります。 アジャイル指標を追跡し共有することで、混乱を減らし、開発サイクル全体でチームの進捗 (や後退) を把握することができます。次に、その方法を説明します。
ビジネスを理解する
作業を「完了」するだけでは十分とは言えません。重要なのは、適切な製品を適切なタイミングで適切な市場向けに構築することです。プログラム全体を順調に進めるには、常に関連するデータを収集し分析する必要があります。アジャイル プログラムでは、ビジネス指標とアジャイル指標の両方を追跡することが重要です。ビジネス指標ではソリューションが市場のニーズに対応しているかどうかを重視し、アジャイル指標では開発プロセスのさまざまな側面を測定します。
「プログラムのビジネス指標はロードマップに根差したものであるべきだ」
ロードマップのイニシアチブごとに、プログラムの目標に対応する複数の主要業績指標 (KPI) があります。また、エンド ユーザーの導入率や自動テストでのコードの使用割合など、それぞれの製品要件の成功基準もあります。これらの成功基準をプログラムのアジャイル指標に取り込みます。チームが成熟するほど、適応力が高まり進化することになります。
アジャイル KPI 指標を使用してデリバリーを最適化する方法
スプリントバーンダウン
スクラムチームは開発活動を、時間枠を設けた複数のスプリントに分割します。チームは、スプリントの開始時にスプリント中に完了できる作業量を予測します。その後、スプリントバーンダウンレポートにより、スプリント全体の作業の完了を追跡します。x 軸は時間を、y 軸は未完了の作業量をストーリーポイントまたは時間数で示します。目標は、スプリント終了時までに、予測したすべての作業を完了することです。
常に予測どおりに作業を完了しているチームは、組織内で強力なアジャイルのお手本となります。ただし、実際にはまだ完了していない項目を数に入れて数字をごまかさないように注意しましょう。短期的にはうまくいっているように見えますが、長い目で見れば学習と改善の妨げとなります。
- チームがスプリントを次々と早期終了するのは、十分な作業を行っていないから。
- チームのスプリントの予測が外れ続けるのは、コミットする作業量が多すぎるから。
- バーンダウンラインが徐々に低下するのではなく急低下するのは、作業を細かく分割していないから。
- プロダクトオーナーがスプリントの途中でスコープを追加または変更してしまう。
エピックおよびリリースバーンダウン
エピックおよびリリース (あるいはバージョン) バーンダウンチャートは、スプリントバーンダウンよりも大きな作業群で開発の進捗を管理するものとして、スクラムチームとカンバンチームの両方の開発で参考とされます。(スクラムチームの) スプリントには複数のエピックやバージョンの作業が含まれることがあるため、個々のスプリントとエピックおよびバージョンの両方の進捗を追跡することが重要です。
「スコープクリープ」とは、定義済みのプロジェクトに追加要件が投入されることを指します。たとえば、チームが会社の新しい Web サイトを構築している場合、初期要件の策定後に新しい機能を要求することをスコープクリープと呼びます。スプリント中のスコープクリープは好ましくありませんが、エピックやバージョン内でのスコープ変更はアジャイル開発ではよくあることです。プロジェクトの進行とともに、プロダクト所有者が学習内容に基づいて作業の追加や削除を決定することがあります。エピックおよびリリースバーンダウンチャートにより、全員がそのエピックやバージョン内の作業の状況を認識します。
- 作業に変更が生じても、エピックおよびリリース予測が更新されない。
- 複数のイテレーション期間にわたって進捗がない。
- スコープクリープの頻繁な発生 (プロダクト所有者が作業群によって解決しようとしている問題を完全に把握していない可能性がある)。
- スコープの成長にチームの対応が追いついていない。
- チームがエピックの開発全体を通して増分リリースを出荷していない。
ベロシティ
ベロシティとはスクラムチームがスプリント中に完了する平均作業量をストーリーポイントまたは時間数で表したものであり、予測に非常に役立ちます。プロダクト所有者はベロシティを使用して、チームがどれくらいの速さでバックログを処理できるかを予測します。レポートでは予測される作業と完了した作業を複数のイテレーションにわたって追跡しているため、イテレーションが多いほど予測精度が向上します。
例えば、プロダクトオーナーがバックログで 500 のストーリーポイントを完了したがっているとします。開発チームは一般的にイテレーションごとに 50 のストーリーポイントを完了することがわかっています。したがって、プロダクトオーナーは目的の作業に 10 のイテレーションが必要と考えるのが合理的です。
時間とともにベロシティがどのように進化するかを監視することが重要です。新規チームでは、関係や作業プロセスの最適化に伴い、ベロシティの向上が期待できます。既存チームでは、ベロシティの追跡によって常に一貫したパフォーマンスを確保するとともに、特定のプロセスの変更が向上につながるかどうかを確かめることができます。平均ベロシティが低下する場合、通常はチームの開発プロセスの中に非効率的な部分があることを示しており、次のふりかえりで課題として挙げる必要があります。
長期にわたってベロシティが一定しない場合、必ずチームの見積もりを再度行ってください。チームのふりかえりで、次の質問をします。
- この作業の見積もり段階で考慮に入れなかった、予想外の開発上の課題はあったか? これらの課題を発見するために、作業をより適切に分割するにはどうすればよいか?
- チームに無理を強いるような外部からの業務上の圧力があるか? 開発ベストプラクティスを遵守することが結果として困難になっているか?
- チームとして、スプリントの予測に力を入れすぎているか?
ベロシティはチームごとに異なります。チーム A のベロシティが 50 でチーム B のベロシティが 75 でも、チーム B の方が処理能力が高いわけではありません。各チームの見積もりに対する考え方がそれぞれ異なるため、ベロシティもそれに応じて異なります。チーム間でベロシティを比較したいという誘惑に負けないでください。チームごとのストーリーポイントの解釈に基づき、労力と成果のレベルを測定します。
管理図
管理図では、個々の課題のサイクル時間 (「対応中」から「完了」までの合計時間) に注目します。チームのサイクル時間が短いほど処理能力が高く、多くの課題のサイクル時間が一貫しているほど作業のデリバリーが予想しやすいことになります。サイクル時間はカンバンチームの主な指標ですが、最適化されたサイクル時間はスクラムチームにとっても有用です。
サイクル時間を測定すると、変更の結果をすぐに確認して調整できるため、チームのプロセスを柔軟かつ効率的に改善できます。最終目的は、作業タイプ (新機能、技術的負債など) にかかわらず、一貫して短いサイクル時間を実現することです。
管理図は最初は無秩序に見えます。外れ値はそれほど気にする必要がありません。読み取るべきものはトレンドです。次の 2 つに注意しましょう。
- サイクル時間の増大 - サイクル時間が長くなると、チームが苦労して得たアジリティが損なわれます。チームのふりかえりで時間が長くなった理由を突き止めましょう。ただし、1 つ例外があります。チームの「完了」の定義が拡大された場合、おそらくはサイクル時間も長くなります。
- 不規則なサイクル時間 – 目標はストーリー ポイント値が同程度の作業項目について一貫したサイクル時間を実現することです。管理図で各ストーリー ポイント値の一貫性をチェックしましょう。サイクル時間がストーリー ポイント値の大小にかかわらず不規則である場合、ふりかえりで予測が外れた理由を分析し、将来の見積もりを改善します。
累積フロー図
累積フロー図は左から右まで平坦な状態が理想です。任意の色の逸脱や差は不足やボトルネックがあることを示しているため、図全体で色付きの部分を平坦にする方法を考えましょう。
- 障害となる課題があると、プロセスの部分によって大規模な余剰や不足が生じます。
- 未チェックのバックログの増加。これは、古い、または優先順位が低い課題をプロダクト所有者がクローズしない場合に発生します。
その他の指標
有用な指標はここで挙げたものに限りません。例えば、品質はアジャイルチームにとって重要な指標です。アジャイル開発に適用できる従来の指標は多くあります。
- 見つかった不具合の数
- 開発中
- 顧客へのリリース後
- チーム以外から
- 将来のリリースまで先延ばしにされた不具合の数
- カスタマーサポートの依頼件数
- 自動化テストのカバー率
アジャイルチームはリリース頻度やデリバリー速度にも着目する必要があります。各スプリントの終了時には、ソフトウェアを本番にリリースする必要があります。実際にはどれくらいの頻度で行っているでしょうか？ほとんどのリリースのビルドが出荷されていますか？また、緊急の修正を本番にリリースするのにどれくらいの時間がかかりますか？リリースは容易ですか、それとも苦労を伴いますか？
コンテキストでインサイトを見つける
インサイトは、スプリントの計画中、日常的なスタンドアップへの参加、デリバリーの最適化などでチームが必要とする指標にアクセスするための優れたツールです。インサイトは Jira のボード、バックログ、デプロイのビューの右上隅にあります。
インサイトによって、次の指標を可視化したスナップショットが得られます。
- スプリントの進捗
- 課題タイプの内訳
- スプリント コミットメント
- デプロイ頻度
- サイクルタイム
これらの指標を使用して、チームのパフォーマンスを継続的に最適化します。インサイトの詳細をご確認ください。
結論
アジャイル指標および KPI 指標はチームのカルチャー構成の一端を担っているにすぎません。チームのパフォーマンスを定量化し、測定可能な目標を設定するのに役立ちます。指標は重要ですが、とらわれないようにしてください。リリース プロセスを通じてチームの信頼関係、製品品質、開発スピードを向上するには、ふりかえりでチームのフィードバックに耳を傾けることも同じくらい重要です。定量的なフィードバックと定性的なフィードバックの両方を活用して変更を促進しましょう。
関連リソース
