project-management - ソフトウェア開発のパフォーマンスを測定する方法は?

Question

ソフトウェア開発チームのパフォーマンスを測定するいくつかの方法を検討しています。ビルドツールを使用するのは良い考えですか? Hudson を自動ビルドツールとして使用します。ハドソンのレポートから情報を取得し、そこから各プログラマーの進捗状況を取得できないかと思います。

score 64 · Accepted Answer

このようなパフォーマンスメトリクスの主な問題は、人間が自分のパフォーマンスを測定してその正確なパフォーマンスメトリクスを最大化するシステムをゲームするのが非常に得意であることです。通常、他の価値のあるものを犠牲にしています。

hudson ビルドを使用して、プログラマーの出力に関する統計を収集するとしましょう。何を探すことができますか? また、プログラマーが手がかりを得ると、それを測定することの意図しない副作用は何でしょうか?

コード行(開発者は大量のボイラープレートコードやその他の不必要なオーバーエンジニアリングを大量に作成するか、単にすべてのメソッドをインライン化するだけです)
単体テストの失敗 (単体テストを作成しないでください。失敗することはありません)
単体テストカバレッジ(コードを実行する弱いテストを作成しますが、実際には適切にテストしません)
コードで見つかったバグの数 (コーディングを行わないでください。バグは発生しません)
修正されたバグの数 (取り組みやすい/些細なバグを選択してください)
自分の見積もりに基づいてタスクを完了する実際の時間 (より多くの余地を与えるために、より高い見積もりをする)

そしてそれは続く。

要点は、何を測定しようとも、人間 (プログラマーだけでなく) はまさにそれを満たすために最適化するのが得意だということです。

では、開発者のパフォーマンスをどのように見るべきでしょうか? まあ、それは難しいです。人間の管理者は、人々 (および彼らが取得する BS) を理解するのが得意で、誰が、どこで、何をしているのかという文脈で各人を主観的に見て、彼らが良い仕事をしているかどうかを判断できます。 .

ただし、誰がパフォーマンスを行っている/していないかを把握した後で何をするかは、まったく別の問題です。

(この考え方を信用することはできません。元は Joel Spolsky によるものです。こちらとこちら)

score 46 · Accepted Answer

ビルドツールを使用して、個々のプログラマのパフォーマンスを測定しないでください。チーム全体を測定することはもちろん、各プログラマーの進捗状況を測定することもできますが、そのようなツールで彼らのパフォーマンスを測定することはできません。一部のモジュールは他のモジュールよりも複雑であり、一部のプログラマーは他のプロジェクトを任されています。これは推奨される方法ではありません。また、プログラマーがずさんなコードを作成して、最も多くの作業を行ったように見せることを助長します。

score 12 · Accepted Answer

いいえ。

そのような指標は失敗する運命にあります。さまざまな人がコードのさまざまな部分、さまざまなクラスの問題に取り組んでおり、絶対的な測定値はせいぜい誤解を招くものです。

開発者のパフォーマンスを測定する方法は、仕事をうまくこなす優れたマネージャーを持ち、要件を正確に反映した優れた仕様を持ち、それらの仕様に対して全員の進捗状況を注意深く追跡することです。

正しく行うのは難しいです。ソフトウェアソリューションは機能しません。

score 10 · Accepted Answer

コード行、チェックイン数、バグ修正数などの従来の方法のほとんどは、今日のソフトウェアエンジニアリングの概念では主観的であることが証明されているため、開発者のパフォーマンスを測定する方法を決定する際には、非常に慎重なアプローチが必要だと思います。プロジェクトの個々の KPI を測定するのではなく、チームのパフォーマンスアプローチを重視する必要があります。ただし、商用開発環境で作業することは、個々の開発者の次の要因を追跡して詳しく調べることが重要です。

コードレビューコメント – プロジェクトごとに、特定の期間に実施する必要があるコードレビューの数を決定できます。コードレビューに基づいて、個人はコーディング標準の改善についてコメントを受け取ります。同じ個人のコードのコードレビューの繰り返しの問題に注意を向ける必要があります。自動コードレビューツールまたは手動コードレビューを使用できます。
テストカバレッジとテストの完全性。– カバーされる割合は事前に決定する必要があり、特定の開発者が頻繁に失敗した場合は、対処する必要があります。
複雑なタスクにサインインし、それほど苦労せずに実行する意欲
ユーザーストーリーで「完了」と定義されていることを達成する
各技術分野の習熟度。

一部のプロジェクトでは、アジャイルアプローチを使用して、開発チームの測定値と期待されるパフォーマンスがリリースに基づいて決定されます。各リリース計画では、期待されるパフォーマンスについてチームメンバーと交渉するさまざまな「契約」があります。リリースされる複雑なアルゴリズムがあるリリースでは、UI 関連の測定に固執する理由がないため、このアプローチはより成功していると思います。

score 5 · Accepted Answer

ソフトウェア開発者のパフォーマンス/進捗状況を測定する方法としてビルドツール情報を使用することはお勧めしません。交絡する問題のいくつか: あるタスクが別のタスクよりかなり難しい可能性があります。おそらく、1 つのタスクが「実装空間」よりも「設計空間」に大きく関与している可能性があります。おそらく (おそらく) より効率的なソリューションの方が優れたソリューションですが、より優れたソリューションは、より多くのコード行を提供する非常に非効率的なソリューションよりもコード行数が少なくなります。等

score 4 · Accepted Answer

ソフトウェア開発者でKPIといえば。www.smartKPIs.com が参考になるかもしれません。これには、十分に文書化されたパフォーマンス測定値のユーザーフレンドリーなライブラリが含まれています。現時点では、3300 を超える KPI の例がリストされており、73 の機能領域と 83 の業界およびサブカテゴリにグループ化されています。

ソフトウェア開発者向けの KPI の例は、このページwww.smartKPIs.com - アプリケーション開発で入手できます。

欠陥除去効率
データの冗長性

パフォーマンス指標の例に加えて、www.smartKPIs.com には、実際の KPI の使用を示すパフォーマンスレポートのカタログも含まれています。www.smartKPIs.com - 実際の KPI - 情報技術この Web サイトは新しいコンテンツで毎日更新されるため、追加のコンテンツがないか時々確認してください。

パフォーマンス指標の例は意思決定の情報を提供するのに役立ちますが、各パフォーマンス指標は、各組織の目的と優先順位に基づいて選択およびカスタマイズする必要があることに注意してください。

score 2 · Accepted Answer

チームがスケジュールをどの程度追跡しているかをより適切に測定することをお勧めします。 チームメンバー（またはチーム全体）が一貫して遅れている場合は、パフォーマンスを向上させるためにチームメンバーと協力する必要があります。

score 2 · Accepted Answer

開発者のパフォーマンス/進捗状況を測定するためのショートカットや迅速で簡単な方法を探してはいけません。開発者の出力に影響を与える多くの要因があります。多くの人がさまざまな指標を試しているのを見てきました...

生成されたコードの行-開発者が非効率的なガベージを解き放つことを奨励します複雑さの測定-過剰な分析とリファクタリングを奨励します生成されたバグの数-人々が本当に単純なタスクを探してテスターを憎むことを奨励します...リストは続きます。

開発者をレビューするときは、彼らの仕事がどれほど優れているかを実際に見て、会社が必要としているものと、会社がその個人をどのような状況/位置に置いているかという文脈で「良い」を定義する必要があります。進捗状況は、同等の考慮と思考で評価する必要があります。

score 1 · Accepted Answer

チームの全員から 360 度のフィードバックを受け取ります。チームメンバー全員があなたのことをクズだと思っているなら、あなたはおそらくクズです。

score 1 · Accepted Answer

これは古い質問ですが、それでも、アジャイルソフトウェア開発からVelocityを借りることができます。そこでは、各タスクに重みを割り当て、各スプリント (またはイテレーションまたは使用する DLC) でどれだけの「重み」を解決するかを計算します。）。もちろん、これは、前述のコメンターのように、開発者がオンラインで作業しているか、オンラインでチャットしているかを積極的に追跡する必要があるという事実に伴います。

開発者が迅速に作業していることがわかっている場合は、それを信頼してvelocity、チームが実行できる作業量を見積もることができます。いずれかの反復でこの数が (かなり) 減少した場合は、推定が不十分であるか、チームの作業量が少なかったかのいずれかです。

最終的に、KPIとベロシティを併用することで、開発者ごと (またはチームごと) のパフォーマンスに関する洞察を得ることができます。

score 1 · Accepted Answer

それぞれが書いたコードの行数を確認します。

次に、下の 70% を発射します.. 90% ではありません!... 毎日!

（よくわからない人のために、はい、冗談です。ここで真剣な答えです）

score 1 · Accepted Answer

多くの企業がリリース管理ツールをセットアップする際に犯しがちな間違いがあります。Salesforce リリース管理ツールキットは、現在市場で入手できる最高のものの 1 つですが、セットアップの重要な手順に従わないと、非常に悪い結果が生じることは間違いありません。あなたはそれを使用するようになりますが、完全な容量ではありません. ビジネスプロセスから切り離してリリース管理プロセスを確立することは、犯してはならない最悪の間違いの 1 つです。リリース管理ツールは、企業戦略、目的、ガバナンス、変更管理、およびその他の側面と密接に関連しています。リリース管理のプロセスは、ビジネスの全員が同じ認識を持つように形成する必要があります。

リリース管理の目標リリース管理 の主な目標は、リソースに依存しない、信頼性が高く反復可能なプロセスの一貫したセットを持つことです。これにより、利用可能なリソースの使用率を最適化すると同時に、最も有利なビジネス価値を実現できます。ほとんどの組織が短期間で収益性の高いビジネスプロジェクトを実行することに重点を置いていることを考えると、アプリケーションの配信バリューチェーンを最適化するには、ビジネス価値の配信に障害がないことを確認することが不可欠です。

たとえば、force.com 移行ツールキットを考えてみましょう。このツールはガバナンスに優れていることが証明されています。リリース管理ツールは、ガバナンスにおける最適な可視性と説明責任を可能にする必要があります。

プロセスとリリースサイクル リリース管理プロセスは、ビジネス全体で一貫している必要があります。さまざまなツールユーザー間でプロセスを合理化し、標準化する必要があります。これは、同じプラットフォームとリソースを使用して、タスクを効率的に完了できるようにするためです。ビジネスの部門ごとに異なるプロセスを使用すると、ツール管理で重大な失敗につながる可能性があります。さまざまなユーザーのセットが、他のユーザーが何をしているかを可視化する必要があります。前述のように、可視性はあらゆるビジネスプロセスにおいて非常に重要です。

リリースサイクルに関しては、さまざまなユーザーセットのすべての要件を追跡する 1 つの集中型システムを持つことも不可欠です。また、このシステムを一元化して、ソフトウェア開発チームがビジネスから要求された機能や変更を把握できるようにする必要もあります。ビジネスが最大限の利益を享受できるようにするには、要求を優先する必要があります。運営チームを持つことは重要です。なぜなら、それはビジネス要件のレビューに関与するだけでなく、ビジネスに必要な最も適切な変更の優先順位付けにも関与するからです。

Salesforce システムに必要な変更は非常に難しい場合があるため、ビジネス部門と IT 部門の間で定期的にミーティングを行うことをお勧めします。これは、ビジネスに利益をもたらすシステムに加える最適な変更を決定するのに役立ちます。機能を実装するためのコストと価値を考慮して、運営委員会は最も重要な機能の変更を決定する役割を担っています。ここでも良い研究http://intersog.com/blog/tech-tips/how-to-manage-millennials-on-software-development-teams

score 1 · Accepted Answer

これにはさまざまな方法があります。主題について書かれた本全体。Hudson からのレポートを使用することもできますが、それは誤った情報につながり、大雑把な結果をもたらすと思います。本当に、タスク追跡方法論が必要です。

score 0 · Accepted Answer

私の経験と、チームのパフォーマンスを測定する上で非常に価値のあるプロセスをどのように学んだかを共有します. 認めざるを得ないのは、私が KPI の追跡に陥ったのは、ほとんどの部門が同じことをするという理由だけでしたが、開発者のパフォーマンスを評価する責任を負うまで実際には洞察を得られなかったからです。何度も読んだ後、次のソリューションで進化しました。

プロジェクトごとに、プロジェクトの要件に関するディスカッションでチームを楽しませ、何をすべきかを全員が理解できるようにします。コラボレーションによる同じディスカッションでは、プロジェクトをタスクに分割し、それらのタスクに重みを付けます。以前は、プロジェクトの完了を 100% と見積もっていましたが、各タスクにはパーセンテージの貢献度があります。これはしばらくの間うまくいきましたが、最善の解決策ではありませんでした。ここで、タスクを正確にするために重量またはポイントに基づいて、相対的な測定値を使用してタスクを比較し、たとえば重量を区別します。ユーザーデータを収集するための Web フォームを開発する必要があります。タスクは次のようになります

 1. User Interface - 2 Points
 2. Database CRUD  - 5 Points
 3. Validation     - 4 Points
 4. Design (css)   - 3 Points

この戦略を使用すると、完了した量とタスクフォースで保留中のものについて、週ごとの概算を正確に特定できます。誰が最高のパフォーマンスをしたかを特定することもできます。

この戦略では、すべての開発者がすべてのテクノロジに慣れているわけではないなど、まだいくつかの課題に直面していることを認めなければなりません。2015 年のポイントの高い割合がそのセクションに該当することを知ったという理由だけで、技術を学ぶことに興奮している人もいます。

KPI はそれ自体のために追跡するのではなく、洞察のために追跡することを忘れないでください。

score 0 · Accepted Answer

通常、パフォーマンス測定にメトリクスを直接使用することは悪い考えであり、チームを苦境に陥れる簡単な方法の 1 つと見なされます。

これで、予定どおりに完了したプロジェクトの割合、コードが完了に向かっているチャーンの割合などの指標を使用できます。これは幅広い分野です。

次に例を示します。

ミッションクリティカルなバグの 60% は Joe によって作成されました。これは単純明快な指標です。ファイアー・ジョーですよね？

しかし、待ってください。

Joe はシニア開発者です。彼は、常に超信頼性の高いコードを書くと信頼されている唯一の人物です。彼は最高の.

メトリクスは、開発者の悪い測定値です。

project-management - ソフトウェア開発のパフォーマンスを測定する方法は?

15 に答える 15

Related

Reference