開発者に説明責任を負わせる基準
私は1時間あたりのコード行について質問し、新しいものを引き裂きました。だから私の成熟したフォローアップの質問はこれです：
コード行ではない場合、リモートプログラマの効果を（時間/日/時間の単位で）測定するための適切なメトリックは何ですか？
16年の間に、あなたが探しているような実用的な測定基準を実際に見つけたことはありません。
基本的に有用であるためには、測定可能、代表的、ゲーム不可能である必要があります（つまり、システムは賢い開発者がプレイすることはできません）。ソフトウェア開発内の変数が多すぎて、このように部分的に機能するものとして測定可能ではありません。
最も近いのは、見積もりに対する進捗状況です。つまり、合意された見積もり内で完了したタスクの数です。ここでの秘訣は、（a）十分かつ公正な見積もりを取得すること、および（b）開発者を非難できない、または非難すべき正当な理由で見積もりが超過した場所を理解することです（つまり、予想よりも本当に複雑でした）。最終的には、開発者を激しくプッシュしすぎると、生産性の向上のためではなく、タイムスケールのパディングのために、見積もりが常に満たされるレベルまで徐々に上昇していく可能性があります。
見積もりの面で反対に行き過ぎると（提供するプレッシャーを減らすために削減）、研究が生産性を向上させず、チームの士気に影響を与える可能性が高いことが示された電話による納期を作成します（詳細については、Peoplewareを参照してください） ）。
しかし、本質的には、少し間違った問題を見ているのでしょうか。生産性の測定に関して、リモートプログラマが他のプログラマと異なるのはなぜですか？非リモートプログラマの生産性をどのように測定しますか？
彼らがリモートで働くことを信頼しないことについてであるなら、それは基本的により広い信頼の問題です。彼らが家で仕事をすることを信頼しないなら、あなたはその信頼を確立するか、彼らに家で仕事をさせないか、または彼らが意図されているときに実際に働いていることを自分自身に満足させる何らかの方法を見つける必要があります。
メトリックは工場で最もよく機能し、プログラマーは組立ラインで作業しません。
生産性を測定したいという欲求を完全に理解しています。
しかし、かかりつけの医師と心臓外科医に同じ指標を使用しますか？ミケランジェロがシスティーナ礼拝堂の絵を描いたり、メキシコの男性が黒いベルベットのエルビスの絵を描いたりしてはいかがですか？
ルイ・ド・ブロイは短すぎる博士論文を書いたので、審査官たちはそれを却下しました。ただし、ド・ブロイは高貴な貴族であり、彼らには良い言い訳が必要でした。それで、審査官はそれを拒否しなかっただけでなくアインシュタインに送り、彼はそれをノーベル委員会に紹介し、ド・ブロイは5年後にノーベル物理学賞を受賞しました。
数値測定は、鉄の鋳造や車のドアのボルトのねじ込みなど、反復的な作業に最適です。しかし、以前に行われたコードを繰り返す場合は、プログラマーは必要ありません。コピーして貼り付けるだけです。プログラミングは基本的に創造的な分野であり、生産性はあなたが何をしているかに完全に依存します。
ある日、私は1000行のコードをクランクアウトしました。今日、私は座標幾何学のバグを修正するつもりです、そしてコードは縮小するかもしれません。 Linuxカーネルドライバーのバグを修正する必要がある場合、新しいコードの行を作成せずに、デバッグに終日費やす可能性があります。
プログラマの生産性の測定は非常に、非常に、非常に主観的です。
ジョーが生産的であるかどうかを知りたい場合は、ジョーが何をしているかを知っていて、同じ分野で熟練しているサリーとラルフを見つけて、彼らに尋ねてください。
私が今まで見た中で最高の数値システムは、アジャイルの計画ポーカーポイントです。それはジョーとサリーとラルフにジョーの次の仕事がどれほど難しいと思うかを尋ねる空想的な方法です。その後、各チームメンバーの週あたりの生産性を測定できます。しかし、それでも、チームの見積もりを調整するのにはしばらく時間がかかり、数値はあいまいで簡単に破棄されます。
多くの人がスケジュールの計画を立てるために生産性の見積もりを求めています。これは、「MS Projectにプラグインして、クリティカルパスを確認し、出荷日がある」という理論のようなものです。私はその仕事を見たことがありません。未知数が多すぎるだけです。それが必要な場合は、ウォーターフォールを使用し、すべてを事前に設計し、変更要求を許可せず、とにかく失望する準備をしてください。
私が使用する唯一の測定基準は動作するソフトウェアの量彼が特定の金額に対して生成したもの=私が投資したものです。
そのスケジュールに関係なく、リモートで作業しているかどうかに関係なく、彼/彼女が取った休止の数、彼女/彼が使用した方法論、または労働時間の数。
実用的なソフトウェアとは：
必要な品質レベルを満たす、ユーザー/顧客によって定義された機能のリスト
金額：
ユーザー/顧客が定義された機能+メンテナンスコストに対して支払った金額
したがって、それはそれがどのように構築され、どの程度の作業品質が生み出されるかに直接関係がありますが、ソースコード行のメトリックにバインドされていません。
一部のタスクにかかる時間を見積もるには、経験豊富な開発者またはチームリーダー（これらのリモートプログラマーとは関係ない）が必要です。有効性は、必要な時間と見積もりを比較することによって測定されます。見積もりが適切であることを確認するために、ランダムにいくつかのタスクを選択し、管理下にある社内チームによって実行させることができます。
生産性を測定するもう1つの興味深い方法は、マネージャーが1日にレビューする自動化可能なテストをカウントすることです。開発者は以下を取得します。
- 自動化可能なテストを記述（およびレビューに合格）し、それを回帰テストスイートに追加するためのポイント
- それらを成功させるためのポイント。他の回帰テストの失敗は引き起こしません。
開発者とマネージャーは、次の方法でシステムを共同で改善できます。
- 開発とテストの重要な分野について共同で合意する
- テストスイートを個別に確認して実行する。
- ビジネス上の利点は限られているが、その機能を提供するために必要な多くの開発とテストを必要とする機能を構築しないことを決定する。 （最も生産的なコード行は、ビジネス上の利点がないため、記述しないことを決定した行です）。
- システムをアーキテクチャー（model-view-controllerなど）に分割し、システム全体を壊すことなく段階的な機能開発を容易にします。
次の理由により、開発者はメトリックをゲームできません。
- 冗長なテストはマネージャーのレビューによってブロックされます。
- きめの細かいテストは、マネージャーのレビューによってブロックされる場合があります。
- きめの細かいテストは、システムの品質を向上させます。
次の理由により、マネージャーはメトリックをゲームできません。
- あまりにも多くのテストを拒否すると、開発者の消耗につながります。
- あまりにも多くのテストを要求すると、それ以降の期限を拒否するのが難しくなります。
開発者はマネージャをねじ込むことができません。
- テストで提供される機能の各ユニットも、回帰スイートに合格する必要があります。つまり、開発者は他のコードを壊すことなく慎重に開発する必要があります。
- 新しいテストと回帰テストに合格することで、仕事の主張を証明できる必要があります。
なぜならマネージャーは開発者を台無しにすることができないからです。
- 要求された機能の各ユニットには、主要なテストケースと、作業を完了するために必要なテストケース数の見積もりを含める必要があります。
- あなたが明らかに多くの仕事を求めているとき、積極的なスケジュールや無料残業を求めるのは難しいです。
マネージャーにとってのもう1つの大きなメリットは、新しい開発者を招き入れ、システムを黙って破壊するコードを提供できないことを知っていることです（回帰テストスイートがそれをキャッチするため）。
マネージャーの大きな欠点は、彼のシステムが機能の1ページの説明にあるよりも複雑であることを認めざるを得ないことです。もう1つの欠点は、この方法の透過性により、開発者がビジネスの失敗を責めることが難しくなることです。
確かに、パフォーマンスを評価するためにあらゆる種類の複雑なメトリックを考案することは可能ですが、結局のところ、判断の大部分は主観性とコードベースに近い人々からの入力に依存する必要があります。
たとえば、一部のチームでは、内部的に目立たない保守不可能なスロップを非常に速い速度でクランクアウトすることがかなり可能であり、これは必要な期限と仕様を満たすことさえできます。しかし、そのような作業スタイルから生じた技術的負債は、チームが堅牢で保守可能なものを作り出したが、数週間で期限を遅らせた場合よりも悪いのでしょうか。場合によります。
質問の目的が何らかの生産性の問題を解決することである場合、私は次のように言いますマネージャーがチームの作業を容易にするために実際に行うことは、チームを評価するために使用される測定手法と同じかそれ以上に重要です。双方向の通りです。言い換えれば、測定基準は問題ないと言っていますが、チームからより多くの情報を得たい場合、最終的な問題は、マネージャーがチームの生産性を確保するために可能なすべてのことを行っているかどうかです。
これは、仕様を書いたり、チームを見つけたり、仕様を「壁越しに」投げたり、ストップウォッチをクリックしたりするだけではありません。
いくつかのアイデア：
- 実装された機能
- 修正されたバグ（後でQAによって再開されたバグも説明）
- ユーザーの苦情が解決されました（2と同じではないことに注意してください。1つの重大なバグは首の痛みかもしれませんが、100のタイプミスはそれほど重要ではないかもしれません）
また追跡したいかもしれません：
- テストによるコードカバレッジ
- 内部ドキュメントによるコードカバレッジ
- 外部（ユーザー）ドキュメントによる機能範囲
お客様が測定するのと同じ方法で測定します。関数コードの面では、小規模です。
短い目標（1〜2週間）を作成し、プログラマーが目標を達成するかどうかを確認し、満足のいく方法でそれを行います。
不正なコードを前もって見つけることができるため、コードのピアレビューを強くお勧めします。
製品/サービスの売上率はどうですか。
時々それは総の手数料/パーセンテージと呼ばれていると聞いた
人々は良い製品を購入しませんか？
企業は製品（またはおそらくサービス、これについても同じ違い）を販売したい
したがって、それが必要な場合は、それを測定します。
良いレビューを受けてよく売れる車をデザインする人は本当に良い仕事をしたと言っているようなものです。
今度はこの指標を採用し、プログラミングチームは2つの理由で営業担当者とやり取りすることになります。
配信不足をプロミング
製品を効果的に顧客に販売していない
コード/プログラミングを書くことは、ハンマーを釘に付けるようなものではありません。一般的に「書くこと」と同じように、それはあなたが典型的にメトリックを適用できるものでもありません-私の意見では。
あなたは彼らのチェックイン、またはピアレビュー、コードレビューを通じて彼らが何をしたかを単に見ることができませんでしたか？
あるいは、問題を修正する実際のコードとソリューションを実際に作成している場合は、