チームの生産性を測定する方法は？
当社の上級管理職は、ソフトウェアチームが次の年に「15％生産性を高める」という目標を提示しました。ソフトウェア開発環境での生産性の測定は非常に主観的ですが、それでも一連のメトリックを考え出す必要があります。
チームの生産性を測定するために、どのような種類のデータを収集できますか？
私はこのサイトで非回答を書かないように一生懸命努力していますが、この場合、私はそうしなければならないと私は信じています。それが唯一の正しい答えです。しかし、私は道具と「できない」以上のことであなたを助けようとします。
真剣に考えると、開発者の生産性を測定する有効な手段はありません。これは管理者が対処するのが難しいことを知っていますが、それは事実です。現場での経験豊富な人々からのリンクをいくつか紹介します。いくつかの例について：
ビジネス価値の測定が難しいだけでなく、タイムラグもあります。したがって、チームが構築していたソフトウェアのリリースから数年後まで、チームの生産性を測定できない場合があります。
なぜ生産性の測定がそれほど魅力的であるかがわかります。それができれば、今よりもはるかに簡単かつ客観的にソフトウェアを評価できます。 しかし、誤った対策は事態を悪化させるだけです。これは、私たちが無知を認めなければならないところだと思います。
昔ながらの生産性から始めましょう。プログラマの生産性を測定するのはかなり難しいです。 考えられるほとんどすべてのメトリック（デバッグされたコードの行、関数ポイント、コマンドライン引数の数）は、ゲームにささいなことであり、それは非常に2人のプログラマが同じことをするように言われることは非常にまれなので、大規模なプロジェクトで具体的なデータを取得するのは困難です。
また、その増加の責任者を尋ねます。何 彼らは取ることができる措置 ？
マネージャがこれらの目標を設定したのは私の経験です。なぜなら、彼らは開発チームに関してどの目標を設定するかについての手がかりがないからです。たぶん、あなたはそれで彼らを助けることができます。
あなた（またはチーム）が真剣にターゲットを取りたいと思っているが、それらは [〜＃〜] smart [〜＃〜] である必要があること、または意味がないことを説明します。 SMARTであるいくつかのターゲットを提案します。 build/CI server はありますか？そうでない場合、1つを設定することはSMART目標です。そうである場合、何らかの方法で 品質統計を表示する ？ありません。そうでない場合、その設定も= SMARTゴール。
もしそうなら、あなたは非常に測定可能なものがあります：コードの品質です。多分あなたの技術的負債の格付けを下げることはSMART=ゴールであり、人々がたるんでいると仮定していない限り、それは今度は生産性を改善します。解決：可視性。
彼らがあなたが実際に達成できる目標をあなたに与えるのを手伝ってください。今から1年もの間証明できない、または反証できない目標がある場合や、システムを改善するのではなくシステムのゲームに時間を費やすことになる場合には、満足感はありません。
私の最も生産的な日々の1つは、1000行のコードを捨てることでした。
— Ken Thompson, designer of the original Unix operating system
ソフトウェアの生産性を測定することは、それほど正確ではありませんが、それほど難しいことではありません。プログラマーを調査し、非生産的なタスクに費やされている作業時間のパーセンテージとその割合を尋ねます。個人の生産性の問題ではなく、非生産的な割り当てられた作業タスクに焦点を合わせてもらいます。次に例を示します。
- ソース管理の更新が遅いのを待っています
- 要件の変更
- 中断が多すぎます
- コンパイルが遅すぎる
- 回帰テストの実行
- 重要な作業を行った後のマーケティングキャンセルプロジェクト
- ステータスの更新に時間をかけすぎている
- QAまたはフィールドから報告された予期しないバグに時間をかけすぎている
- 他のチームからの依存関係を待つ
- スパゲッティコードの解明
ただし、 オブザーバー効果 のため、生産性が15％増加しなかったと経営陣に怒らせるなど、これらの調査結果をプログラマーへの報酬や結果に関連付けることは不可能です。 suspectのように数字が使用されている場合でも、システムはゲームを実行し、完全に役に立たない指標になります。
あなたができることは、応答を使用して生産性を正しい方向に動かします。最悪の2つか3つを選び、それに多くの努力を注ぎます。改善は、個々の苦情の多くについて数値で簡単に測定でき、うまくいけば、来年再び調査を行うときに、いくつかの苦情がリストに表示されなくなるか、少なくとも少数のプログラマーによって報告されるようになります。
つまり、定量化できなくても正しい方向の動きを観察することができます。
他の人が示唆しているように信じられないほど不正確であるプログラマーのメトリックに焦点を合わせるのではなく、次のような非コードのことを提案してみてください。
- みんなのPC（xはあなたが持っている以上のもの）とクアッドコア用のXGbメモリ
- すべてに2モニター（すでに2を取得している場合は3）
- マネージャー、サポート、営業など、常に電話で話している大声の従業員から離れたデスク
- より良いスペック
- 複数のプロジェクト間でのコンテキスト切り替えが少ない、または仕様の変更による
- 会議を減らし、スタッフを会議に招待する際の焦点/配慮を改善
これらの事柄のそれぞれが実際にプログラマーの生産性を高める理由を詳しく説明してください。
これらは、プログラマーの生産性を向上させることができるもののタイプであり、LOCやバグカウントに関して達成できない目標を設定しようとするものではありません。
pdrの回答 に同意します。それは行く方法です。しかし、ここに別のテイクがあります。
ほとんどのプロセス改善努力は、あなたがそうであるように、何を測定すべきかを決定し、次に現在のオペレーションをベースライン化することから始める必要があります。
ベースラインとして何を使用しますか？
まだ11または12を実行していない場合は、さらに2を実行するだけで、15％向上します。