最も有用なソフトウェア開発メトリックは何ですか？
チームのソフトウェア開発プロセスを改善し、時間の見積もりを改善し、プロジェクトの実行中に対処する必要がある特殊なケースの変動を検出するために使用できるメトリックを追跡したいと思います。
各回答を1つの指標に限定し、その使用方法を説明して、良い回答に投票してください。
（出典： osnews.com ）
ROI。
ソフトウェアによってもたらされた収益の合計額から、ソフトウェアを作成するためのコストの合計額を差し引いたもの。総コストのパーセンテージでコストを分類し、投資収益率の観点から最もパフォーマンスが低く、最も高価な領域を分離します。可能であれば、その問題領域を改善、自動化、または排除します。逆に、投資収益率が最も高い領域を見つけて、その効果をさらに増幅する方法を見つけます。 ROIの80％がコストまたは労力の20％から発生している場合は、その特定の領域を拡大し、残りを比較して最小限に抑えます。
費用には、給与、ライセンス、法定費用、ハードウェア、事務機器、マーケティング、生産、流通、およびサポートが含まれます。これは、会社全体の場合はマクロレベルで、チームまたは個人の場合はミクロレベルで実行できます。また、収益に加えて、時間、タスク、および方法にも適用できます。
これは、すべての詳細を無視することを意味するのではなく、すべてを定量化してから、最良の（客観的な）結果が得られる領域に集中する方法を見つけます。
逆コードカバレッジ
テスト中に実行されなかったコードの割合を取得します。これはShafaが述べたものと似ていますが、使用法が異なります。テスト中にコード行が実行された場合、テストされる可能性があることがわかります。ただし、コード行が実行されていない場合は、テストされていないことが確実にわかります。単体テストの対象となるこれらの領域をターゲットにすると、品質が向上し、カバーされているコードを監査するよりも時間がかかりません。理想的には両方を行うことができますが、それが起こることは決してありません。
「私のチームのソフトウェア開発プロセスを改善する」：欠陥の発見と修正率
これは、コミットまたは検証された修正の数に対して発生した欠陥またはバグの数に関連しています。
これは2つのことを提供するため、非常に重要な指標の1つであると言わざるを得ません。
修正率が低いということは、チームが他のこと（おそらく機能）に取り組んでいることを示しています。バグ数が多い場合は、開発者にいくつかの欠陥に対処してもらう必要があるかもしれません。
検索率が低い場合は、ソリューションが優れていてバグがほとんどないか、QAチームがブロックされているか、別の焦点を当てていることを示しています。
見つけたバグの原因と種類を追跡します。
バグソースは、バグが導入された開発フェーズを表します。 （例：仕様、設計、実装など）
バグタイプは、幅広いスタイルのバグです。例えば。メモリ割り当て、条件が正しくありません。
これにより、開発のその段階で従う手順を変更し、コーディングスタイルガイドを調整して、過剰に表現されたバグタイプを排除しようとすることができます。
見積もりのあるタスクを実行するのにかかる時間を追跡します。彼らが十分に下回っていた場合は、その理由を質問してください。それらが十分に終わっている場合は、その理由を質問してください。
ネガティブなことをしないでください。タスクが失敗したり、見積もりを大幅に下回ったりしても問題ありません。あなたの目標は、見積もりプロセスを継続的に改善することです。
速度：特定の単位時間あたりの特徴の数。
フィーチャをどのように定義するかはあなた次第ですが、ほぼ同じ桁数である必要があります。そうでない場合、速度はあまり役に立ちません。たとえば、ストーリーやユースケースによって機能を分類できます。これらはすべてほぼ同じサイズになるように分解する必要があります。反復ごとに、実装（完了）されたストーリー（ユースケース）の数を把握します。機能/反復の平均数はあなたの速度です。機能ユニットに基づいて速度がわかれば、それを使用して、機能に基づいて新しいプロジェクトを完了するのにかかる時間を見積もることができます。
[編集]または、複雑さの尺度としてファンクションポイントやストーリーポイントなどの重みを各ストーリーに割り当て、完成した各機能のポイントを合計して、ポイント/反復で速度を計算することもできます。
ソースコード内のクローン（類似のコードスニペット）の数を追跡します。
クローンを見つけたらすぐにコードをリファクタリングして、クローンを取り除きます。
平均関数長、または関数長のヒストグラムで、より良い感触を得ることができます。
関数が長いほど、その正しさがわかりにくくなります。コードに長い関数がたくさん含まれている場合は、そこにいくつかのバグが隠れていることは間違いありません。
スクラムを使用している場合は、バックログ。各スプリント後の大きさはどれくらいですか？一定の割合で縮小していますか？または、（a）そもそも考えられなかったものが原因で、バックログにプッシュされているものです（「監査レポートには、誰も考えていない別のユースケースが必要です。バックログに追加するだけです。 "）または（b）約束された機能の代わりに、日付を満たすために作業を行わず、バックログにプッシュします。
ファンインとファンアウトが私のお気に入りです。
ファンイン：このモジュールを使用/認識している他のモジュール/クラスの数
ファンアウト：このモジュールは他にいくつのモジュールを使用/認識していますか
私は特にメアリーポッペンディークが好きで使用しています 推奨 。このシステムは、パッケージとして取得する必要がある3つの全体的な測定に基づいています（したがって、3つの回答を提供するつもりはありません）。
- サイクルタイム
- 製品コンセプトから最初のリリースまで、または
- 機能のリクエストから機能の展開まで、または
- バグ検出から解決まで
- ビジネスケースの実現（これがなければ、他のすべては無関係です）
- P＆Lまたは
- ROIまたは
- 投資の目標
- 顧客満足
- 例えば ネットプロモータースコア
私たちが最終的な目標であるユーザーに価値を提供し、迅速に対応できるかどうかを知る必要はありません。
ソースの一部がレビューを受けたかどうか、もしそうなら、どのタイプかを追跡します。その後、レビュー済みコードと未レビューコードで見つかったバグの数を追跡します。
これにより、見つかったバグに関して、コードレビュープロセスがどの程度効果的に機能しているかを判断できます。
クラス間の相互依存。コードがどれだけ緊密に結合されているか。
コミットごとの失敗したテストまたは壊れたビルドの数。
時間の見積もりを改善する
Joel Spolskyのエビデンスベースのスケジューリングは、それ自体がmetricではありませんが、まさにあなたが望むもののように聞こえます。 http://www.joelonsoftware.com/items/2007/10/26.html を参照してください
QAでの指標の追跡は、かなり前から基本的な活動でした。しかし、多くの場合、開発チームは、これらのメトリックがビジネスのすべての側面にどの程度関連しているかを十分に検討していません。たとえば、欠陥率、有効性、テストの生産性、コードカバレッジなどの一般的な追跡指標は、通常、ソフトウェアの機能面で評価されますが、ソフトウェアのビジネス面での重要性に注意を払う人はほとんどいません。
ソフトウェアのビジネス面に多くの価値を追加できる他のメトリックもあります。これは、ソフトウェアの全体的な品質ビューを見るときに非常に重要です。これらは大きく次のように分類できます。
- ビジネスアナリスト、マーケティング、営業担当者が捉えたベータユーザーのニーズ
- 製品管理チームによって定義されたエンドユーザーの要件
- ピーク負荷時のソフトウェアの可用性と、エンタープライズITシステムと統合するソフトウェアの機能の確保
- 大量トランザクションのサポート
- ソフトウェアが提供する業界に応じたセキュリティの側面
- 競合他社と比較した、必須機能と便利な機能の可用性
- そしてもう少し…。
チームのソフトウェア開発プロセスを改善する
指標はチームのソフトウェア開発プロセスを改善するために何もできないことを理解することが重要です。それらを使用できるのは、使用している特定のメトリックに関して、開発プロセスの改善に向けてどれだけ進んでいるかを測定することだけです。おそらく私はセマンティクスについて悩んでいますが、あなたがそれを表現している方法は、ほとんどの開発者がそれを嫌う理由です。指標を使用して結果を測定するのではなく、指標を使用して結果を導き出そうとしているようです。
別の言い方をすれば、100％のコードカバレッジとお粗末な単体テスト、または素晴らしい単体テストと80％未満のカバレッジが必要ですか？
あなたの答えは後者でなければなりません。完璧な世界が必要で、両方が必要な場合もありますが、最初に単体テストに焦点を合わせ、そのときにカバレッジを取得することをお勧めします。
QAチームによってバグが報告されるたびに、その欠陥が開発者による単体テストから逃れた理由を分析します。
これを永続的な自己改善の練習と考えてください。
前述の指標のほとんどは興味深いものですが、チームのパフォーマンスを向上させるのに役立ちません。問題は、開発フォーラムで管理に関する質問をすることです。
いくつかの指標は次のとおりです。プロジェクトスケジュールレベルおよび個人レベルでの見積もり/対/実績（ジョエルの証拠に基づく方法への以前のリンクを参照）、リリース時に削除された欠陥の割合（私のブログを参照： http：// redrockresearch .org /？p = 58 ）、スコープクリープ/月、および全体的な生産性評価（パトナムの生産性指数）。また、開発者の帯域幅を測定することもできます。
私は欠陥解決効率の測定基準が好きです。 DREは、見つかったすべての欠陥に対するソフトウェアリリース前に解決された欠陥の比率です。ソフトウェアの本番環境へのリリースごとに、このメトリックを追跡することをお勧めします。
同様の行の数。 （コードのコピー/貼り付け）
おそらくあなたはテストすることができます CodeHealer
CodeHealerは、ソースコードの詳細な分析を実行し、次の領域の問題を探します。
- 監査未使用または到達不能コード、識別子としてのディレクティブ名とキーワードの使用、より高いスコープで同じ名前の他のものを隠す識別子などの品質管理ルール、もっと。
- チェック初期化されていない、または参照されていない識別子、危険な型キャスト、自動型変換、未定義の関数の戻り値、未使用の割り当て値などの潜在的なエラー。
- メトリクス循環的複雑度、オブジェクト間の結合（データ抽象化結合）、コメント比率、クラス数、コード行などのコードプロパティの定量化。
コードカバレッジ率
スクラムを使用している場合は、毎日のスクラムがどのように進んだかを知りたいと思います。人々は彼らが成し遂げると言ったことを成し遂げていますか？
個人的には苦手です。私は慢性的に毎日をひっくり返します。