ソフトウェア開発のパフォーマンスを測定する方法は？
ソフトウェア開発チームのパフォーマンスを測定するいくつかの方法を探しています。ビルドツールを使用することをお勧めしますか？ Hudsonを自動ビルドツールとして使用します。 Hudsonのレポートから情報を取得し、そこから各プログラマーの進捗状況を取得できるかどうか疑問に思います。
ビルドツールを使用して、個々のプログラマのパフォーマンスを測定しないでください。チーム全体を確実に測定することも、各プログラマーの進捗を確実に測定することもできますが、そのようなツールではパフォーマンスを測定することはできません。一部のモジュールは他のモジュールよりも複雑であり、一部のプログラマーは他のプロジェクトを担当しています。これは推奨される方法ではありません。
このようなパフォーマンスメトリックの主な問題は、人間が自分のパフォーマンスを測定して、その正確なパフォーマンスメトリックを最大化するシステムを非常にうまくプレイできることです。通常、価値のある何かを犠牲にします。
ハドソンビルドを使用して、プログラマの出力に関する統計を収集するとします。あなたは何を探すことができますか、そしてプログラマーがそれを理解した後に測定することの意図しない副作用は何でしょうか？
- コード行 （開発者はボイラープレートコードの山、およびその他の不必要なオーバーエンジニアリングを単に解き放つか、単にすべてのいまいましい方法を単にインライン化する）
- 単体テストの失敗（単体テストを作成しないでください。失敗しません）
- 単体テストcoverage（コードを実行する弱いテストを作成しますが、実際には適切にテストしません）
- コードで見つかったバグの数（コーディングを行わないでください。バグは発生しません）
- 修正されたバグの数（作業する簡単/些細なバグを選択してください）
- 自分の推定値に基づいてタスクを完了する実際の時間（より多くのスペースを与えるために、より高い推定値）
そしてそれは続きます。
ポイントは、whatが何であれ、人間（プログラマーだけでなく）は、まさにそれを満たすように最適化するのが得意です。
それでは、開発者のパフォーマンスをどのように見るべきでしょうか？まあ、それは難しいです。そして、それは人間（そして彼らが引くBS）を理解するのが得意な人間のマネージャーを含み、誰の文脈で各人を主観的に見ることができます/ where /彼らが良い仕事をしているかどうかを把握するために何をするか。
誰が演技しているのか、演じていないのかを把握した後、あなたがすることはまったく別の質問です。
（私はこの考えのラインを信用することはできません。それはもともとジョエル・スポルスキーからです。 Here および here ）
番号。
そのようなメトリックは失敗する運命にあります。さまざまな人がコードのさまざまな部分、さまざまなクラスの問題に取り組んでおり、絶対測定はせいぜい誤解を招くだけです。
開発者のパフォーマンスを測定する方法は、仕事をうまくこなし、要件を正確に反映する優れた仕様を持ち、それらの仕様に対して全員の進捗を慎重に追跡する優秀なマネージャーを持つことです。
正しくするのは難しいです。ソフトウェアソリューションは機能しません。
開発者のパフォーマンスを測定する方法を決定する際には、コード行、チェックインの数、修正されたバグの数などの従来の方法のほとんどが今日のソフトウェアエンジニアリングの概念に主観的であることが証明されているため、非常に慎重なアプローチが必要だと思います。プロジェクトの個々のKPIを測定するのではなく、チームのパフォーマンスアプローチを重視する必要があります。ただし、商用開発環境で作業する場合は、個々の開発者の次の要因を追跡し、よく見ることが重要です。
- コードレビューのコメント–各プロジェクトでは、特定の期間に実施する必要があるコードレビューの数を決定できます。コードレビューに基づいて、個人はコーディング標準の改善について意見を受け取ります。同じ個人のコードのコードレビューの繰り返しの問題に注意を喚起する必要があります。自動コードレビューツールまたは手動コードレビューを使用できます。
- テストのカバレッジとテストの完全性。 –対象となる％は事前に決定する必要があり、特定の開発者がそれを頻繁に試行しない場合は、注意する必要があります。
- 複雑なタスクにサインインし、それほど苦労せずにそれらを提供する意欲
- ユーザーストーリーで「完了」と定義されているものを達成する
- 各技術分野の習熟レベル。
一部のプロジェクトでアジャイルアプローチを使用すると、開発チームの測定値と期待されるパフォーマンスがリリースに基づいて決定されます。リリース計画ごとに、期待されるパフォーマンスのためにチームメンバーと交渉されるさまざまな「契約」があります。複雑なアルゴリズムがリリースされるリリースでは、UI関連の測定値を遵守する理由がないため、このアプローチはより成功します。
ソフトウェア開発者のパフォーマンス/進捗を測定する方法としてビルドツール情報を使用することはお勧めしません。交絡問題のいくつか：おそらく、1つのタスクが別のタスクよりもかなり難しい。おそらく、1つのタスクが「実装スペース」よりも「設計スペース」に多く関与している可能性があります。おそらく（おそらく）より効率的なソリューションはより良いソリューションですが、そのより良いソリューションは、はるかに多くのコード行を提供するひどく非効率的なソリューションよりも少ないコード行を提供します。等.
ソフトウェア開発者のKPIといえば。 www.smartKPIs.comはあなたにとって良いリソースかもしれません。よく文書化されたパフォーマンス測定のユーザーフレンドリーなライブラリが含まれています。現時点では、73の機能領域と83の産業とサブカテゴリにグループ化された3300を超えるKPIの例をリストしています。
ソフトウェア開発者向けのKPIの例は、このページで入手できます www.smartKPIs.com-application development これらには以下が含まれますが、これらに限定されません。
- 欠陥除去効率
- データの冗長性
パフォーマンス測定の例に加えて、www.smartKPIs.comには、実際のKPIの使用を示すパフォーマンスレポートのカタログも含まれています。このような情報技術のレポートの例は、www.smartKPIs.com-実際のKPI-情報技術で入手できます。このWebサイトは毎日新しいコンテンツで更新されるため、随時追加コンテンツを確認してください。
パフォーマンス測定の例は意思決定を知らせるのに役立ちますが、各パフォーマンス測定は、各組織の目的と優先順位に基づいて選択およびカスタマイズする必要があることに注意してください。
おそらく、チームがスケジュールをどれだけうまく追跡しているかを測定する方がよいでしょう。チームメンバー（またはチーム全体）が一貫して遅れている場合は、パフォーマンスを改善するために協力する必要があります。
近道をしたり、開発者のパフォーマンス/進捗を測定するための迅速で簡単な方法を探したりしないでください。開発者の出力に影響する多くの要因があります。多くの人々がさまざまなメトリックを試してみました...
生成されるコード行-開発者が非効率なガベージを大量に生成することを奨励します.
開発者をレビューするとき、あなたは本当に彼らの仕事がどれほど良いかを見て、会社が必要とするものと会社がその個人を置いた状況/位置の文脈で「良い」を定義する必要があります。 。
これを行うには多くの異なる方法があります。主題について書かれた本全体。ハドソンからのレポートを使用することもできますが、それは誤報につながり、粗雑な結果をもたらすと思います。本当に、タスク追跡の方法論が必要です。
これは古い質問ですが、まだできるのは、Agile Software Developmentから Velocity を借りることです。各タスクに重みを割り当て、各スプリントでどれだけの「重み」を計算するかを計算します（または反復または使用するDLCを問わず）。もちろん、これには、前述のコメンターのように、開発者が作業しているかオンラインでチャットしているかを積極的に追跡する必要があるという事実が伴います。
開発者がレスポンシブに作業していることがわかっている場合は、そのvelocityを使用して、チームが実行できる作業の見積もりを提供できます。いずれかの反復でこの数値が（かなり）低下した場合、推定が不十分であるか、チームの作業が少なくなっています。
最終的に、 KPIs を速度とともに使用すると、開発者（またはチーム）ごとにパフォーマンスに関する洞察を得ることができます。
チームの全員から360のフィードバックを受け取ります。すべてのチームメンバーが自分ががらくただと思うなら、おそらくそうです。
多くの企業がリリース管理ツールをセットアップするときに犯すよくある間違いがあります。 Salesforceリリース管理ツールキットは、今日の市場で入手可能な最高のツールキットの1つですが、セットアップの重要な手順に従わないと、間違いなく非常に悪い結果になります。使用できるようになりますが、完全には使用できません。リリース管理プロセスをビジネスプロセスから分離して確立することは、最も悪い間違いの1つです。リリース管理ツールは、企業の戦略、目標、ガバナンス、変更管理、およびその他の側面と連携して機能します。リリース管理のプロセスは、ビジネスの全員が同じページにいるように形成する必要があります。
リリース管理の目標リリース管理の主な目標は、リソースに依存しない信頼性の高い反復可能なプロセスの一貫したセットを持つことです。これにより、最も有利なビジネス価値を達成できると同時に、利用可能なリソースの利用を最適化できます。ほとんどの組織は、短期間で高収益のビジネスプロジェクトを実行することに重点を置いていることを考慮すると、アプリケーションのデリバリバリューチェーンを最適化して、ビジネスバリューのデリバリに遅れがないことを確認することが不可欠です。
たとえば、force.com移行ツールキットを取り上げます。このツールはガバナンスに優れていることが証明されています。リリース管理ツールは、ガバナンスの最適な可視性と説明責任を可能にする必要があります。
プロセスとリリースサイクルリリース管理プロセスは、ビジネス全体で一貫している必要があります。さまざまなツールユーザー間でプロセスを合理化および標準化する必要があります。これは、タスクの効率的な完了を可能にする同じプラットフォームとリソースを使用するためです。ビジネスの部門ごとに異なるプロセスがあると、ツール管理に重大な障害が発生する可能性があります。ユーザーのさまざまなセットは、他のユーザーが何をしているかを可視化する必要があります。前述のように、可視性はあらゆるビジネスプロセスで非常に重要です。
リリースサイクルに関しては、異なるユーザーセットのすべての要件を追跡する1つの集中システムを持つことも不可欠です。また、ソフトウェア開発チームがビジネスから要求された機能と変更を理解できるように、このシステムを集中化する必要があります。ビジネスが最大限の利益を享受できるようにするには、リクエストを優先事項にする必要があります。運営チームは、ビジネス要件のレビューに加えて、ビジネスが行う必要がある最も適切な変更の優先順位付けにも関与するため、重要です。
Salesforceシステムに発生する変更は非常に注意が必要な場合があるため、ビジネスとITの間で定期的に会合を開くのは良いことです。これは、ビジネスにメリットをもたらすシステムへの最適な変更を決定するのに役立ちます。機能を実装するコストと価値を考慮することにより、運営委員会は、行うべき最も重要な機能の変更を決定するタスクを持ちます。ここでも良い研究 http://intersog.com/blog/tech-tips/how-to-manage-millennials-on-software-development-teams
通常、パフォーマンス測定のためにメトリックを直接使用することは悪い考えであり、チームを地面に走らせる簡単な方法の1つです。
現在、オンタイムに完了したプロジェクトの割合、コードが完了に向かうにつれて解約する割合などのメトリックを使用できます。これは幅広い分野です。
次に例を示します。
ミッションクリティカルなバグの60％はJoeによって作成されました。これは単純で簡単なメトリックです。ファイアージョー、そうですか？
しかし、待ってください、まだあります！
ジョーはシニア開発者です。彼は毎回、非常に信頼性の高いコードを書くことを信頼されている唯一の男です。彼はbestであるため、ミッションクリティカルなソフトウェアの約80％を書いています。
メトリックは、開発者の悪い測定値です。
私の経験と、チームのパフォーマンスを測定する上で非常に価値のあるプロセスをどのように学んだかを共有します。認めなければならないのは、ほとんどの部門が同じことをしているが、開発者のパフォーマンスを評価する責任があるまで、実際には洞察を得ることができないからです。
プロジェクトごとに、プロジェクトの要件に関する議論でチームを楽しませ、それらが関係するように、誰もが何をすべきかを知っています。コラボレーションによる同じ議論で、プロジェクトをタスクに分割し、それらのタスクに重み付けします。これまでは、各タスクに貢献度があるプロジェクト完了率を100％と見積もっていました。さて、これはしばらくは機能しましたが、最善の解決策ではありませんでした。ここで、タスクを正確にするために重みまたはポイントに基づいて、相対的な測定値を使用してタスクを比較し、たとえば重みを区別します。ユーザーデータを収集するWebフォームを開発する必要があります。タスクは次のようになります
1. User Interface - 2 Points
2. Database CRUD - 5 Points
3. Validation - 4 Points
4. Design (css) - 3 Points
この戦略を使用すると、完了した量とタスクフォースで何が保留されているかを週ごとに概算できます。また、誰が最高の成績を収めたかを特定することもできます。
すべての開発者がすべてのテクノロジーに満足しているわけではないなど、この戦略にはまだいくつかの課題があります。一部の人は、2015年の高い割合のポイントがそのセクションにあり、自分ができることをするという理由だけでテクノロジーを学ぶことに興奮しています。
KPIを追跡するのは自分自身のためではなく、洞察のために追跡することを忘れないでください。