記事”ソフトウェア開発でメトリクスが重要でない理由(ビジネス目標とペアラーを付けない限り)”で述べたように、メトリクスを選択するには、ビジネスが本当に答える必要がある特定の質問をサポートするためにかなりの思考と注意が必要です。 ここに重大なポイントはある:測定はビジネス質問に答える方法としてだけ設計されるべきである。 そして、それらの質問は決してありません、”私たちは今までどのように多くのKLOCsですか？”
この記事では、前のものが中断した場所を取り上げ、最初にすべてのチームが使用を開始すべき特定の指標について議論するか、少なくとも顕著なパフォーマ この記事のタイトルは、”違いを生むことができる9つの指標があると主張していることに注意してください…”—本当に重要なのは、本当に違いを生む その使用はあなた次第です。 次に、この記事では、これらの指標を組み合わせて意味を作成し、ビジネス価値仮説を策定してテストする方法を説明することで締めくくります。
まず正しいことを測定する
ここでは、プロセスと本番環境を段階的に改善するために、継続的に監視する必要がある9つの客観的な指標（箇条書き これらの数字の改善は、あなたの顧客満足度が飛躍的に上昇することを保証するものではありません。 しかし、少なくともこれらは測定するのが正しいものです。 この記事の後のセクションでは、”それをすべて一緒に入れて、”あなたは理由が表示されます。
アジャイルプロセスメトリクス
アジャイルプロセスとリーンプロセスの基本的なメトリクスは、リードタイム、サイクルタイム、チーム速度、オープン/クローズ率です。 これらの指標は、計画を支援し、プロセス改善に関する意思決定を通知します。 彼らは成功や付加価値を測定するものではなく、ソフトウェアの客観的な品質とは何の関係もありませんが、とにかく測定する必要があります。 私は以下の理由を説明します。
- リードタイム—アイデアから配信されたソフトウェアに移行するのにかかる時間。 顧客への応答性を高めたい場合は、通常、意思決定を簡素化し、待機時間を短縮することによって、リードタイムを短縮するように努めてください。 リードタイムにはサイクルタイムが含まれます。
- サイクルタイム—ソフトウェアシステムに変更を加え、その変更を本番環境に提供するのにかかる時間。 継続的な配信を使用しているチームは、サイクルタイムを数ヶ月ではなく数分または数秒で測定できます。
- Team velocity—チームが通常イテレーション（別名”スプリント”）で完了するソフトウェアの”ユニット”の数。 この数値は、反復の計画にのみ使用する必要があります。 メトリックは非客観的な推定値に基づいているため、チームの速度を比較することはナンセンスです。 速度を成功の尺度として扱うことは不適切であり、特定の速度を目標にすることは、推定と計画のための価値を歪めます。
- オープン/クローズレート—特定の期間内に報告され、クローズされた生産問題の数。 一般的な傾向は、特定の数字よりも重要です。
これらの指標のいずれかまたはすべてが予想される範囲外または驚くべき方向の傾向にある場合は、原因を想定しないでください。 チームに話をし、全体の話を得て、チームに懸念の原因があるかどうか、もしそうなら、それを修正する方法を決定させます。
数値から根本原因を知ることも仮定することもできませんが、これらの指標は、本質的なプロセスが注意を必要とする場所についての洞察を与えま たとえば、いくつかのイテレーションで高いオープン率と低いクローズ率は、生産の問題が現在新しい機能よりも優先度が低いこと、またはチームが問題のク あなたは数字から根本的な原因を知ったり仮定したりすることはできません。
生産分析
- 平均故障間隔(MTBF)
- 平均回復/修復時間(MTTR)
どちらも、現在の運用環境でのソフトウェアシステムのパフォーマンスの全体的な尺度です。
- アプリケーションのクラッシュ率—アプリケーションが失敗した回数を、アプリケーションが使用された回数で割ったもの。 このメトリックは、MTBFおよびMTTRに関連しています。
これらの三つの指標のいずれも、影響を受ける個々の機能やユーザーについて教えてくれないことに注意してください。 それでも、数字が小さいほど、より良いです。 最新の運用監視ソフトウェアでは、個々のプログラムやトランザクションに関する詳細なメトリックを収集するのは非常に簡単ですが、（クラウドベー
私たちはソフトウェアが決して失敗しないようにしたいと思っていますが、それは統計的にありそうもありません。 私たちのソフトウェアが失敗したとき、我々はそれが任意の重要なデータを失うことはありませんし、瞬時に回復したいと思いますが、それは達成する しかし、あなたのソフトウェアがあなたの収入源であるならば、その努力は価値があります。
MTBFやMTTRを超えて、個々のトランザクション、アプリケーションなどに基づいて、よりきめ細かな測定が行われ、提供されるビジネス価値と障害を修復するコ トランザクション処理アプリケーションが100回に1回クラッシュしたが、1秒か2秒で回復し、重要な情報を失わない場合は、その1%のクラッシュ率で十分な可能性があります。 しかし、各クラッシュが一日100,000のトランザクションを実行し、back100の販売を失い、バックエンドで修復するために$50の費用がかかるアプリのものであ それを修正すると、一番下の行に大幅に影響します。
セキュリティメトリクス
セキュリティは、ソフトウェア品質の側面であり、後で（または遅すぎる）まで見落とされることがよくあります。 セキュリティ解析ツールは、より専門的な評価やストレステストに加えて、ビルドプロセスで使用することができます。 セキュリティ要件は、多くの場合、単純で一般的な感覚ですが、ソフトウェア開発チームは、それらとそれらから派生したメトリックに留意する必要が
セキュリティ慣行と関連する指標のすべての範囲は、この記事の範囲を超えていますが、アジャイルプロセスメトリクスと生産メトリクスと同様に、顧客の全体的な満足度に大きな意味を持ついくつかの特定の指標があります。
- エンドポイントインシデント—エンドポイントの数(モバイルデバイス、ワークステーションなど)）一定期間にわたってウイルス感染を経験したことがありますか？
- MTTR（平均修復時間）—セキュリティメトリクスでは、これはセキュリティ侵害の発見と展開された作業救済の間の時間です。 上記の実稼働MTTRメトリックと同様に、セキュリティMTTRは特定の時間間隔で追跡する必要があります。 MTTRの値が時間の経過とともに小さくなると、開発者はバグやその修正方法などのセキュリティ問題をより効果的に理解できるようになります。
これらの両方の指標では、時間の経過とともに数値が小さくなると、正しい方向に移動していることを意味します。 より少ないエンドポイントインシデントシ MTTRの値が小さくなるにつれて、開発者はバグなどのセキュリティ問題を理解し、それらを修正する方法においてより効果的になってきています。
ソフトウェア開発にセキュリティメトリクスを適用する方法は、記事”Application Security for Agile Projects and Security Threat Models:An Agile Introduction”を参照してください。
ソースコードメトリックに関するメモ
今日では、ソースコードスキャナをビルドパイプラインに差し込み、一連の客観的なメトリックを生成するのは簡単です。 これらの指標の相対的な重要性については、経験的な平均値と推奨範囲、および論理的な議論があります。 しかし、実際には、これらのツールは、コーディングスタイルの強制、特定のアンチパターンのフラグ付け、外れ値と傾向の特定に最も役立ちます。
それは数字にハングアップする価値がないだけです。 ここでは、説明のために、例です。
NPATHの複雑さが5200万のようなばかげたメトリックを持つクラス内のメソッドを見つけたとします。 つまり、コード内のすべてのパスを完全に実行するには、5200万のテストケースが必要です。 コードをより単純な構造にリファクタリングすることはできますが、その前にビジネスへの影響を検討してください。 古い醜いコードは十分に機能する可能性があります（テストカバレッジは不十分かもしれませんが）。 チームにアンチパターンを呼び出して、それを繰り返さないようにすることは貴重な学習ですが、それを修正することは、関連するビジネス指標に針を動かすことはおそらくありません。
チームがコードが適用されるコンプライアンスとルールのレベルに同意するのが最善ですが、外れ値を調べたり、トレンドブリップを心配したりすると、多くの時間を無駄にする可能性があることに注意してください。
そして、それをすべて一緒に入れてください: 成功は究極の指標
品質指標とユーザー分析を追跡および測定するための自動化されたツールを使用することの喜びは、本当に重要な指標である成功メトリ
成功のための指標の使い方
企業には目標があります。 目標は、”成功はどのように見えるか”などの質問を意味します。”または”これは顧客の行動にどのように影響しますか？”適切に定量化された質問は、指標を意味します。
別の言い方をすれば、メトリックは、特定のビジネス目標をサポートする仮説をテストするために、質問に答えるためにのみ使用されるべきです。 そして、これは、質問と回答が肯定的な変化を促進するのに役立つ限り、これを行う必要があります。
さて、すべてのプロジェクトは一般的に不変の目標、質問、仮説、したがってメトリックのセットを持っていませんか？
はい、しかしビジネスの観点からのみ。 ユーザーエンゲージメント、成約率、収益生成などのビジネスレベルの尺度は、ビジネスが現実の世界でどのように行っているかについてのフィードバッ ビジネスに影響を与えるソフトウェアの変更は、これらの種類の指標にも影響します。
より細かいレベルの解像度では、すべての機能とユーザーストーリーに独自の成功メトリックがあります。 決して配信されない機能のためのスプリントで十の物語のうち九つを完了することは無駄であり、成功ではありません。 顧客が望んでいない、または使用しない物語を提供することは無駄であり、成功ではありません。 ユーザーの幸福のいくつかの側面を向上させる物語を提供することは成功です。 なぜなら、うまくいかなかったことを学び、ビジネス仮説を無効にし、他の道を追求するためのリソースを解放したからです。
価値仮説を定式化する方法
価値仮説は、特定の特徴の提供の結果として起こると思うことについての声明です。 ソフトウェア、望ましい結果、およびメトリック間の関係は、機能（またはシステム、またはストーリー、またはアップグレードなど）の価値仮説を形成します。). この仮説は、対象となる指標がどのように変化すると予想されるか、どの時間枠にわたって、そしてどれだけ効果的であると考えられるかを表現す この機能やストーリーは、その価値仮説を策定するために、ビジネスに関して作成または改善することを意図している特定のものを把握するために、最低でも、チームと製品所有者に話をする必要があります。 あなたは、”なぜ”数回（3歳のように）、固定されていない仮定の層を剥がす必要があるかもしれません。 ビジネス価値が何であるべきかを理解したら、質問に答える指標につながる質問を始めることができます。
例えば、eコマースチェックアウトプロセスの速度を向上させるための”技術的な”話は、より速いチェックアウトがより多くの販売につながるという基礎的な前提として持つことができる。 しかし、なぜ私たちはそれを考えるのですか？ 多くの人々はチェックアウトプロセスの間に彼らの買物車を放棄しているか。 それがコンセンサスである場合（そのコンセンサスはベースラインデータに裏打ちされているため）、価値仮説は、”チェックアウトプロセスが速くなるとカート放棄率が低下し、売上高が増加し、ユーザーエクスペリエンスが向上すると信じています。”
あなたはおそらく、ユーザーがより迅速なチェックアウトを好きになると仮定することができますが、彼らが気づいたかどうかを尋ねることは害 カート放棄率と売上高は、新しいプロセスが所定の位置にある前と後に、一定期間測定することができます。 カート放棄率が低下し、販売が増加した場合（統計的変動を超えて）、証拠は仮説を支持し、さらに速度の向上が保証されているかどうかを検討するかもしれ そうでない場合は、このメトリックを背景にフェードインして（または気が散る場合は削除して）、次の仮説に注意を向けます。 カート放棄率が減少しても売上が変わらない場合は、より長い期間測定するか、カート放棄と売上との間の想定されるリンクを再考してください。 言い換えれば、メトリックを使用して学習し、改善を促進するために有用であることが証明されている限りのみです。
場合によっては、仮説が明らかに間違っている可能性があるため、メトリックを削除します（ソフトウェアの変更を元に戻します！）数日後。 他のケースでは、仮説が正しいかもしれないので、私たちは何年もこの分野の改善を推進し続けています。
メトリックの効果的な使用のための六つのヒューリスティック
私たちは、主観的なソフトウェアメトリクスが古いの伝統的な、客観的な品質メトリクスよりもビジネスの成功のためにはるかに重要であるかを見てきました。 機能に関連するビジネス指標を見つけて測定するために必要な努力は、得られた洞察と学習機会によって上回ります。 ビジネスの状況や機会は絶えず変化するため、脆弱な可能性のある数式を要約するのではなく、焦点と柔軟性を維持するための6つの経験則、またはヒューリスティクスがあります。 彼らは高品質のソフトウェアとビジネスの成功への旅にあなたを導くのに役立ちます！
- メトリクスはあなたに物語を伝えることはできません。
- 雪片を比較するのは無駄です。
- ほとんど何でも測定できますが、すべてに注意を払うことはできません。
- ビジネスの成功指標は、ソフトウェアの改善を促進します。
- すべての機能は値を追加します。
- 今重要なものだけを測定します。