エンジニアのプロセスを分析するエレガントな方法はありますか？

コミットを測定することは不適切であるという感情がたくさんあります。

次のような、コミットよりも多くのソースを引き込もうとする研究が行われましたか？

• ブラウジングパターン
• IDEの作業（事前コミット）
• アイドルタイム
• マルチタスク

これらの対策を行う簡単な方法は考えられませんが、何らかの研究が行われたかどうかは疑問です。

個人的な注意として、パフォーマンス評価にこれらを使用するかどうかに関係なく（または使用しない場合）、自分の「メトリック」を反映することは価値があると考えています。IEあなたの習慣を反映する偏りのない方法。しかし、これはQ＆Aを超えた議論の問題です。

あなたがそれをエレガントだと思うかどうかはわかりませんが、ワッツ・ハンフリーは、あなた自身の生産性を測定することについてのPersonal Software Processと呼ばれる本全体を書きました。彼は、デスクでの時間対中断、さまざまな種類のソフトウェアライフサイクルアクティビティに費やした時間、コード量ごとの欠陥などの入力のメトリックを概説しました。短いバージョンを提供する技術レポートがあります：

http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm

開発者コードの品質のようなものを見たい場合、Chidamber＆Kemererはオブジェクト指向コードのいくつかのメトリックを提案しました。

オブジェクト指向コードのメトリック

• 継承ツリーの深さ、
• メソッドの重み付き数、
• メンバー関数の数、
• 子どもの数
• オブジェクト間の結合。

コードのベースを使用して、彼らは、共変分析を使用して、これらのメトリックを欠陥密度および保守作業に関連付けようとしました。後の研究では、数百のSource Forge Javaプロジェクトで同様の分析を行い、CKメトリックスと、後で提案されたいくつかの追加メトリックスに対する特性を決定しました。

コードレビューのコンテキストで発生するメトリック

欠陥は、多くの基準で分類できます。

• 重大度：（メジャー、マイナー、化粧品、調査/不明）、
• タイプ（論理、タイプミス、スペル、コーディング標準違反など）、
• 起源/相の封じ込め（要件、設計、コードなど）。

また、準備率と検査率（レビュアーごとの時間、コードの行ごとの時間）と欠陥密度（KLOC（千行のコード）ごと、インスペクター/レビュアーの時間ごと）もあります。

これらの値を管理図にプロットすることで、プロセスの範囲内にあるかどうかを確認できます（たとえば、KLOCあたり平均25個の欠陥があるグループに欠陥がないことを発見する200行のコードを検査するチームが誤動作している可能性があります）。

その他の指標

以下を含むその他の指標

• 推定値の調整に役立つ獲得値
• スクラムまたはかんばんを使用している場合の速度。
• 仕事パレート、ジュラン、Demming、石川品質と生産工学から、そして他の人は想像力の少しを持つソフトウェア開発に多少のポータブルです。

分析の制限

メトリックの値には非常に大きな制限があります。開発者ごとに修正されたバグはほとんど何でも意味する可能性があり、その測定値を罰したり報いたりし始めると、バグはより多く、より細かくなり、修正された難しいバグと簡単なバグの組み合わせもチームチェリーが選ぶと変化します最も多くを競うために。

また、一定の注意散漫があり、潜在的な焦点と楽しさが失われますが、これは侵入的な測定に伴う可能性があります。あなたは、ワーズワースのような湖の詩人よりも優雅な（そして感情的に負担がかかる）ことはできないと言いました、

      Sweet is the lore which Nature brings;
      Our meddling intellect
      Mis-shapes the beauteous forms of things:--
      We murder to dissect.

ソフトウェアは正確には自然ではありませんが、高校の英文学のクラスの何かを使うことは決してないと思ったので、ある程度の自由度を与えてください。

アジャイルは、一元化された大きなプロセスに対する反応と見なされる場合があります。時々、その作業モードでは非常に多くの分析作業が必要になるため、ソフトウェアの作成中にフローに到達する能力がすべて失われてしまいます。

必要に応じて適応できる基本的なツールを盗むことを目的として、標準的なソフトウェアエンジニアリングの実践から別の分野に向かう別の回答を追加したいと思います。品質保証担当者は、ソフトウェア開発者と同様に、生産、歩留まり、および欠陥の検出と防止に関心があります。

http://en.wikipedia.org/wiki/Seven_Basic_Tools_of_Quality

管理図が好きです。

http://en.wikipedia.org/wiki/Control_chart

アクティビティを実行する、メトリックをプロットする、別のアクティビティを実行する、そのメトリックをプロットするなど。たとえば、1日あたりのコミットのプロット。チャートは、最小から最大の範囲のデータを散布します。おそらく後で結果を特徴付けて、値が低い場合は何かが進行を妨げていると判断し、値が高すぎる場合は作業は高速でずさんな方法で開始されることを判断できます。労働者にどのようにスピードアップまたはスローダウンを促すかはあなた次第です。

個人的な指標は、「...のときに最も生産性が高いと感じる」などの質問から始めて、自分で相関させることができます。

• コードを開始する前に、完全なユースケースを作成します。
• コードの前にユニットテストを書いてください。
• 利害関係者と頻繁に確認して、要件が変更されないことを確認し、廃止された計画に向けて行われた作業に大規模な手直しを作成します。
• できるだけ多くのコードを変更します。
• 私が変更を依頼した部分について最も専門的なチームメンバーに明確に定義された変更を委任します。
  • 私のチームに完全な概要を提供しますが、優先順位を付けて現在のスプリントで終わらせることができます。
  • 変更するディレクトリ、ファイル、クラス、メソッド、方程式、変数、ドキュメントなどの階層リストからリファクタリングパスを開始します。
  • 高レベルの問題を調査して先行技術のソリューションを見つけ、より良いソリューションを作成するために必要な範囲と重要な改善を推定します。

私たちが測定するのは、あなたが制限要因であると判断したものに基づいて問題を攻撃する可能性があることです

または、パレート図に基づく優先順位の複数の要因。

http://en.wikipedia.org/wiki/Pareto_chart