アジャイル指標を定義する正しい方法

アジャイル メトリクスは、アジャイル プロジェクト チームの進捗と成功を追跡するために使用される測定値です。

メトリクスを正しく定義すると、チームのパフォーマンス、品質、テスト効率、または全体的な有効性と、それが時間の経過とともにどのように変化するかについての洞察が得られます。

アジャイル メトリクスの最終的な目標は、チームが改善の余地がある領域を特定し、チームの進歩に合わせてより良い製品につながるデータ主導の意思決定を行えるようにすることです。

ほとんどの場合、企業はバニティ メトリクスまたは生の数値のいずれかを左から右に順調に増加するメトリクスを定義します。一部のダッシュボードでは見栄えが良いかもしれませんが、通常はチーム自体にとっては役に立ちません。

彼らの目的は、何らかの形でチームを支援することではなく、むしろリーダーシップのためにいくつかのレポートを作成し、その後いくつかの戦略的決定を下すことです。残念ながら、この特定の決定が存在する理由を理解していないのはチームです。

このような間違った指標を満たすための柵の中で、チームは指標を適切に見せるために独自のプロセスを偽装します。しかし、チームの成果はまったく向上していません。

基本的な指標

メトリクスを分離する方法はたくさんあります。おそらく最も基本的なものはトップダウンとボトムアップです。

➡️ トップダウンの意味: 私たちのリーダーは、皆さん全員に満たしてほしい指標を作成し、最終的な目標はそれらの緑色の領域に収まることです。あなたが彼らのようなチームであろうとなかろうと、私たちは気にしません。これが私たちが追跡したいものです。

➡️ ボトムアップとは、次のことを意味します。 私たちチームはこれらの分野で改善する必要があり、そのためにはこれらのことに焦点を当てる必要があります。したがって、私たちは、目標に向けたチームの進捗状況を追跡できるようにする指標を定義し、それが時間の経過とともにどのように正確に私たちの仕事を改善したかをリーダーシップとして示すことができます。

良い指標の定義

それでは、適切な指標には何を含めるべきでしょうか、あるいはそれをどのように説明すればよいのでしょうか?

最も重要な特性は、 行動を変えること です。これは、指標の結果を見るたびに、改善するためにチーム内で何を変更する必要があるかが明らかになることを意味します。

それなら、それは 単純 でなければなりません。関係するすべての聴衆が理解できるように、いくつかの簡単な文で説明できない場合は、何かがあまり良くありません。

優れた指標は、時間の経過とともに 比較できる ものです。結果のスナップショットを一度に取得し、しばらくしてから再度実行します。並べて置きます。 2 つの結果を相互に比較できない場合は、このメトリクスをもう一度考えてみる必要があります。

最後に、純粋な数値よりも、可能であれば、比率またはパーセントにします。 「スプリント中に新たに未解決の欠陥が 10 件発生した」というだけでは、あまり意味がありません。通常1つ持っているのか、100人持っているのかによって異なります。

これらの定義基準をすべて満たしていると思われる指標の例をいくつか紹介します。彼らは特にアジャイルチームを念頭に置いています。パフォーマンス、品質、士気という 3 つの主要なカテゴリがあります。

メトリクスのカテゴリ

パフォーマンス指標

目標は、チームがスプリント内でコミットされたストーリーにどの程度追いついているかを理解することです。オーバーコミットメントが通常どおりではないか、またはスプリントからスプリントへの引き継ぎストーリーが標準であるかどうかを評価します。

アジャイル パフォーマンスの観点から、チームはスプリントの開始時にコミットした計画されたスプリント コンテンツを提供するよう努めるものとします。

これは、スプリント中のストーリー交換に柔軟性を持たないという意味ではありません。しかし、それは常に交換につながる交渉であるべきであり、追加ではありません。誰かがスプリント内に新しいストーリーを追加したからといって、チームのキャパシティが拡大するわけではありません。

私たちはこのようなケースに注意し、チーム全員がスプリントに向けて持っている能力を守るように導くためにこの指標を導入しました。

これにより、チームの信頼性と予測可能性が高まります。

#1. スプリントのキャパシティと提供されたストーリー ポイント

スプリント容量とスプリント全体で配信されたストーリー ポイント (SP) コンテンツの履歴を確認します。

• スプリントごとに多少のずれがあっても問題ありません。どの方向への大きなジャンプも、何かが間違っていることを示しています。
• 合計スプリント キャパシティ – 1 人のチーム メンバーが利用可能な日が合計キャパシティに 1 追加されます。たとえば、チームに 10 人がいて、全員がフル スプリントに参加できる場合、スプリントの合計キャパシティは 100 です。

スプリントごとにスプリント容量と完了した SP を検証します。チームが（計画中に）通常完了できる量を大幅に上回る SP に取り組んでいる場合、このリスクをチームに高めます。

目標は、計画された SP の合計がスプリントごとの完了した SP の合計以下になることです。

チームが (スプリントの終わりに向かって) 計画されたすべてのストーリーを完了し、チームに追加のストーリーを受け入れる能力がまだある場合は、計画よりも多くの SP を完了することができます。

• チームが計画よりも少ない SP を繰り返し提供する場合、チームは計画を修正し、次のスプリントに取り込む SP を減らす必要があります。

monday.com、Atlassian Jira Software、Asana などのツールはすべて、スプリントの各ストーリーごとにストーリー ポイントを保存および抽出する簡単な方法を提供します。各スプリント計画の後にそれを自動的に生成することもできます。

#2. バーンダウンチャート

これは、おそらくほとんどのスクラム チームがダッシュボードのどこかに隠しているメトリクスの 1 つです。これは持っていても無駄だとさえ思われるかもしれないことに私も同意します。チームがそれを考慮することはほとんどありません。むしろ、マネージャーは、ストーリーが高いレベルからどのように見えるか、およびストーリーがどのようにうまく進んでいないかを指摘することを好みます (すべてのストーリーがスプリント全体の始まりであるため)。

私が強調したいのは、それにもかかわらず、チームとして自分自身の利益のためにバーンダウン チャートを確認する必要があるということです。 すべてのストーリーがスプリント全体を通じてオープンされ、スプリントの最終日のみクローズされる場合、チーム内およびスプリント目標の完了に向けた不確実性が生じます。

• スプリント ボードで完了したストーリーを確認します。
• たとえスプリントの開始時に開始されたとしても、スモール ストーリーがまだ公開されている理由をチームに確認してください。
• チームと協力してその考え方を構築し、必要以上にストーリーを公開し続けないようにしてください。
• 理想的なバーンダウン チャートは通常、理論上の状態です。ただし、それに近づけば近づくほど、より効果的なストーリー処理が可能になります。

Asana のようなアジャイル管理ツールを使用すると、スプリントごとにバーンダウン チャートを自動的に生成できます。

#3. スプリント目標の完了

これは、各スプリント中に完了したスプリント目標の割合を追跡します。

スプリントの目標は、たとえば、 Confluence ページ /Jira Software などのスプリントごとに個別に文書化します。ステータスは、スプリント内で満たされたかどうかに関係なく割り当てられます。

チームがスプリント内のすべてのストーリーを完了できなかったとしても、スプリント目標を達成することはできます (たとえば、サイド ストーリーのみが欠落しているなど)。

各スプリントでスプリント目標を 100% 完了することを目指します。そうでない場合は、チームが何を妨げているのかを調べてください。

• 各スプリントに並列トピックが多すぎる場合は、その量を減らしてください。
• スプリント中に追加されるアドホック ストーリーが多すぎる場合は、元のスプリントの目標に影響を与えないように、これを減らしてください。
• スプリントの目標が大きすぎる場合、または難しすぎる場合は、よりシンプルにしてください。いずれにせよ、大きなスプリント目標を設定しながら、スプリントの終わりまでにそれを達成できないのは意味がありません。

コード品質メトリクス

これにより、時間の経過とともにコードがどれほど優れているかが追跡されます。これは健全な開発プロセスを維持し、問題の解決に費やす時間を短縮するのに役立ちます。または、開発およびテスト活動中にコードの実行を待機することによって生じる開発者のアイドル時間。

#1. 自動テスト

開発者は変更を加えるたびに自動化された単体テストを作成します。

• 自動テストによってコード カバレッジを測定します。Azure Pipelines または SonarCloud を使用してテストを実行します。カバー率 85% を目指します。 90% を超えると実際には効率的ではありません。
• 自動化された単体テストの作成が、新しいストーリーの完了定義の一部であることを確認してください。
• バックログの技術的負債のストーリーの一部として、古いコードのテスト範囲を確認します。

#2. コードの複雑さ

時間の経過とともにコードに生じている不必要な複雑さを評価し、技術的負債のストーリーによって積極的に修正します。または、可能であればそれらの発生を防ぎます。

コード標準とガイドラインを定義して、それらに従うように開発者を教育します。コードの複雑さの不当な増加を最小限に抑えるために、コーディング ルールを遵守するようにしてください。チームの経験に基づいてガイドラインを定期的に更新します。

コードの臭いを特定する – 重複したコード、長いメソッド、未使用の変数など、コード内の潜在的な問題の指標。

ピアレビューは、新しく作成されたコードにコード標準が適用されていることを確認するものとします。

Azure Ado や SonarCloud のダッシュボードやレポートなどのツールを使用して、コードの問題を発見します。

#3. 導入の手動手順

コードをテスト環境または運用環境にリリースするためにチームが実行する必要がある手動ステップの数を追跡します。

• 私たちの目標は、時間をかけてここで 0 を達成することです。
• 導入/リリース パイプラインを自動化ロードマップまで引き上げるために、必要に応じて技術的負債ストーリーを作成します。スプリントからスプリントへのプロセスで、残りの手動ステップを徐々に減らします。

士気の指標

これは、チームが自分たちの仕事や毎日扱うプロセスについてどのように感じているかを追跡するための指標です。

#1. スプリントの遡及履行

次のスプリントで実際に完了したアクションアイテムの数を追跡できます。

• スクラム マスターは、レトロスペクティブ ミーティングの結果をチームのページに収集して、合意されたアクション アイテムを追跡するものとします。
• その後、チームは進捗状況を追跡します。
• プロジェクト管理者は、アクション アイテムが進捗しているかどうか、またはチームがアクション アイテムを完了するのを妨げているものは何かを確認できます。次に、チームが合意されたアクション項目を進められるように環境を修正します。

前のスプリントのアクション アイテムの少なくとも 33% または 1 つ (どれが高いかによる) が次のスプリントに採用されます。

それ未満の場合は、チームが合意した改善を実装できるようにするために変更が必要です。

プロジェクト管理ツールには、スプリントの振り返りアクティビティ用にすぐに使用できるテンプレートが含まれています。以下は monday.com からの例です。

#2. チームのコラボレーション

トラックペアプログラミング。

• ストーリーごとに自然なカップルを形成して協力し、観察、知識、成功を共​​有します。さまざまなチーム メンバーが所有するストーリーの下にサブタスクを作成します。

同業他社の取り組みからコードレビューを追跡します。

• ピアは、他の人のストーリー出力をレビューするように求められるか、積極的に行動を起こします。

メトリクスは、monday.com/Asana/Jira Software ボードのサブタスクから抽出できます。

スプリント内のストーリーの少なくとも 50% はチーム メンバーによって共有されるものとします。少ない場合は、理由を調査し、適切な措置を講じてください。

自主的なピアレビューの場合は、専用のサブタスクを使用してストーリーを追跡します。最初は、この方法でレビューされたコード ストーリーの 20% から始めるのが良いでしょう。スプリントを重ねるごとに、チームがより協力的に作業するよう奨励し、やる気を起こさせ、目標としてスプリントごとのコード ストーリーの 50% に向けて増やしていきます。

#3. 技術的負債と新機能の物語

チームに自分たちの借金問題を解決する機会を与えると、チームの仕事に対する満足度が高まります。

• それどころか、段階的に解決する計画がないまま技術的負債の問題が積み重なると、時間の経過とともにチームのやる気が失せてしまいます。そして、解決策はより不安定で複雑になり、大幅なやり直しがなければ解決するのが困難になります。

たとえ利害関係者やエンドユーザーが気づいていなくても、ソリューションで何がうまく機能しないのかはチームが最もよく知っています。このようなストーリーは、開発チーム自体に最も大きな影響を与えます。利害関係者にとって、それらは目に見えないものかもしれません。だからこそ、開発活動を整理整頓するのに役立つストーリーに取り組む機会をチームに与えることが重要です。

目標は、時間の経過とともに発生した技術的負債の案件がどれだけ解決されるか、またそのような案件の未処理の案件が増加するばかりかどうかを追跡することです。

チームはストーリーにバックログ内の TechDebt としてラベルを付け、チームからの優先順位を与えることができるため、ストーリーがトップになってスプリントで選択されるようになります。

プロジェクトがどの状態にあるか、およびバックログで特定された技術負債の数に応じて、スプリントごとに技術負債バックログが 10% を超えて増加しないようにする必要がある場合があります。

技術的負債のストーリーに優先順位を付けてスプリントに組み込むことで、技術的負債のバックログの増加を抑制し、チームが各スプリントの 10 ～ 20% の時間で技術的負債のストーリーに取り組むことができるようにします。

最後の言葉

リーダーがそれを望んでいるからでも、チームが自分たちの成功を測ろうと決めたからでも、すべてのプロジェクトには最終的に何らかの指標が必要になります。

できる最善のことは、すぐに選択して使用できるメトリクスのライブラリの構築を開始することです。早いほど良い。そして、それを行う際には、何よりも行動を変える指標を常に重視するようにしてください。

次に、スプ​​リントを台無しにする可能性がある不健全なプロセスを確認します。