生産性の指標。ソフトウェアのパフォーマンス測定について知っておくべきことは何ですか?

ソフトウェア開発者としてフルタイムの仕事に就くには、特定のプログラミング言語、ツール、テクノロジに関する実践的なスキルと知識が鍵となりますが、この職業で成功するための前提条件としてさまざまな意味でみなされるもう 1 つの貴重な指標があります。生産性。今日のビジネス環境においてパフォーマンス指標はソフトウェア開発チームにとって本質的に重要であるため、生産性の測定はすべてのプロのソフトウェア開発者が理解し、考慮する必要があるものです。

開発者としての生産性が重要なのはなぜですか?

アジャイル開発、DevOps、ソフトウェアリリースサイクルの縮小の時代において、開発者は製品の新しいバージョンをできるだけ早く出荷する必要があるため、企業は複数の異なる生産性指標を使用して、個々のプログラマーとチーム全体のパフォーマンスを評価します。これを開発者の観点から見ると、パフォーマンス測定は多くの貴重な目的に役立ち、プログラミング スキルの進歩を追跡するのに役立ち、それによって一貫した専門的な成長を達成することができます。生産性の高いプログラマーは、最終的に驚くべき給与のオファーを受け取り、最もエキサイティングなプロジェクトに携わることができます。しかし、たとえあなたが必ずしも成績優秀者ではなく、ソフトウェア開発の仕事に就いてそれなりの成功を収めたいだけだとしても、ただし、パフォーマンス指標と、それが仕事でのインプットの生産性を測定するためにどのように使用されるかについて、少なくとも基本的な理解を持っている必要があります。それが今日私たちが話すことです。

ソフトウェア開発の生産性測定基準

ソフトウェア開発の生産性指標とは何ですか?

ソフトウェア開発メトリクスは、開発者のパフォーマンス、作業の質、生産性を追跡するために定量的な測定を適用できるプログラミング作業の領域です。すべての生産性指標は、開発プロセスからデータを取得し、それを使用して生産性を測定することに基づいています。ソフトウェア開発に関連するものは簡単で単純なものはほとんどないため、プログラミングの生産性の測定も業界全体で非常に一貫性がなく、断片的であると言えます。簡単に言えば、さまざまなチームや企業がまったく異なるパフォーマンス指標を使用し、さまざまな角度からこの問題にアプローチすることができます。したがって、ソフトウェア開発チームが使用する可能性のあるすべての指標をわざわざ学習する必要はありません。

ソフトウェア開発の生産性指標にはどのような種類がありますか?

当然のことながら、さまざまなレベルや角度でパフォーマンスを測定するための、複数の異なる生産性指標が存在します。このような生産性指標の最も一般的なタイプは次のとおりです。

• サイズに焦点を当てた正式な指標。

これらの指標は、コード行数 (LOC)、コード命令の長さ、コードの複雑さなど、プログラマーの作業結果のサイズを測定することに焦点を当てています。これらの指標は、今日のソフトウェア開発業界では時代遅れであると考えられることが増えています。

• 時間と機能に焦点を当てた生産性指標。

ウォーターフォール ソフトウェア開発で使用される伝統的な生産性指標には、アクティブ日数、一定期間内に出荷される機能の範囲、コード チャーン レート、割り当てられたタスクの数などがあります。

• アジャイル開発プロセスのメトリクス。

スプリント バーンダウン レポート、ベロシティ、リード タイム、サイクル タイムなどのアジャイル開発プロセスの指標は、おそらく今日ソフトウェア開発チームの間で最も一般的に使用されている指標です。アジャイル指標については、この記事の後半で詳しく説明します。

• 運用分析メトリクス。

この一連のメトリクスは、現在の運用環境におけるソフトウェアのパフォーマンスの測定に焦点を当てています。ここで最もよく使用される指標は、平均障害間隔 (MTBF)、平均復旧時間 (MTTR)、およびアプリケーションのクラッシュ率です。

• メトリクスのテスト。

ソフトウェア テストには、自動テストの割合、コード カバレッジなど、システム テストの品質を測定するための独自の指標セットがあります。

• 顧客満足度の指標。

最後に、ソフトウェアの究極の指標はエンド カスタマー エクスペリエンスであり、顧客エフォート スコア (CES)、顧客満足度スコア (CSAT)、ネット プロモーター スコア (NPS) などの一連の指標も存在します。その他。

アジャイル ソフトウェア開発の指標

ご覧のとおり、ソフトウェアの生産性指標は複雑なため、簡単に迷ってしまいます。ただし、通常のソフトウェア開発者がよく知っておくべき唯一の指標は、ソフトウェア開発ライフ サイクルのさまざまな部分にわたるチームの生産性測定の標準として、今日ソフトウェア開発チームによって一般的に使用されているアジャイル メトリクスです。最も一般的に使用される主なアジャイル指標をリストしてみましょう。

1. スプリントバーンダウン。

スプリント バーンダウン レポートは、アジャイル スクラム開発チームにとって重要な指標の 1 つです。アジャイルでは、開発プロセスが期限付きのスプリントを通じて編成されるのと同様に、スプリント バーンダウンは、スプリント中のタスクの完了を追跡する方法として使用されます。時間またはストーリー ポイントが測定単位として使用されます。目標は、一貫した進捗を達成し、当初の予測に沿った作業を提供することです。スプリント バーンダウンは、チームが作業のペースを測定し、必要に応じて調整するのに役立ちます。

2. チームのベロシティ。

ベロシティも重要な指標であり、これも測定単位として時間またはストーリー ポイントに基づいています。これは、スプリント中にチームが完了する平均作業量を測定し、プロジェクト全体の見積もりと計画に使用されます。チームが一貫したパフォーマンスを発揮できるようにするには、ベロシティを追跡することが重要です。

3. ストーリーポイント。

個々の開発チーム メンバーのレベルでは、プログラマーが各リリース中に提供するストーリーのサイズがそのプログラマーの生産性の指標となるため、ストーリー ポイントは貴重な指標となります。

4. サイクル管理チャート。

タスクまたは別のバックログ項目の作業が開始された瞬間から完了するまでの合計時間を測定します。サイクルタイムの追跡と制御が可能になり、より予測可能な結果が得られます。

5. スループットと提供される価値。

プロジェクト マネージャーは、開発者に割り当てられたタスクを分析し、それらのタスクに価値を割り当てます。この指標は、チームのスループット、つまり行われた付加価値作業の量を測定するために使用されます。

6. コードチャーン。

コード チャーンは、チーム全体の生産性の測定と個々のプログラマーのパフォーマンスの追跡の両方に使用される、言及する価値のあるもう 1 つの指標です。コード チャーンは、開発者が以前に追加したコード行を削除または変更する頻度、および以前に作成されたコードの何パーセントが最終的に変更または破棄されたかを測定します。

専門家の意見

最後に、いくつかの視点を追加するために、この問題に関する経験豊富なソフトウェア開発業界の専門家によるいくつかの引用を紹介します。「自分の指標を何らかの基準や、さらには別の会社の別のチームのパフォーマンスと「比較」しようとしないことを願っています。私がこれまで働いてきた場所はどこでも、ストーリーポイント、ベロシティ、時間当たりの見積もり、タスクなどの定義に独自のばらつきがあり、ある会社のあるチームのパフォーマンスを別の会社の別のチームのパフォーマンスと直接比較することはほぼ不可能でした。元テクニカル プロダクト マネージャー兼アジャイル コーチのクリフ ギリー氏は次のように述べています。。「私はチームのパフォーマンスを導く際の指標には少し懐疑的です。たった 1 つまたは 2 つの変数に注意を払うと、指標を改善することだけを行っている場合に、(意図的かどうかにかかわらず) 指標のゲームに陥り、改善していると自分を騙すことが非常に簡単になります。たとえば、ベロシティに基づく指標は、チームが小さなストーリーに移行することで「改善」できます (ストーリーごとの作業が減り、より多くのストーリーが完成し、ベロシティが上がります)。ストーリーがビジネス価値の小さな増加をもたらす有用なユーザー ストーリーである場合、それは良いことかもしれません。ストーリーが小さくなり、それ自体では真の価値をもたらさない「技術的な」タスクが多くなったら、それは悪いことかもしれません」と、別の業界専門家エイドリアン・ハワード氏は言う。。「プルベースのシステムで作業する場合、私はスループットとサイクルタイムを重視します。1 つ目はチームの能力に関する一般的な情報を提供し、時間が経つにつれて非常に強力な予測尺度になる可能性があります。2 つ目は、パイプラインの効率の一般的な尺度として役立ちます。サイクル タイムが長い場合は、緩和/活用に向けて取り組むことができる制約があるため、パイプラインの検討を開始する時期です。しかし、指標は単なるツールです。それらの指標に惑わされないでください。また、特定の指標に向けて計画を立て始めないでください。チームとして何を作っているのか、どのように自然に仕事をしているのかを考えてから、人々を中心にシステムを構築してください。メトリクスは、システムが全員の作業をどのようにサポートしているかを確認するのに役立ちます。そうではない」とビデオゲーム開発プロデューサーのデイブ・セラ氏は結論付けた。