ソフトウェア開発プロジェクトでは、ソフトウェアの品質向上に時間をかけるか、より価値のある機能のリリースに集中するかという議論が頻繁に行われます。通常、機能を提供するというプレッシャーが議論を支配し、多くの開発者はアーキテクチャやコードの品質に取り組む時間がないと不満を訴えています。この議論は、品質向上によってコストも増加するという前提に基づいており、これは私たちの一般的な経験です。しかし、直感に反する現実として、内部的なソフトウェア品質は新しい機能の開発を遅らせる無駄を排除し、ソフトウェアの機能強化のコストを削減します。

リモートワークとオフィスワークという単純な二分法はありません。チームの分散にはいくつかのパターンがあり、それぞれに異なるトレードオフと、それに適した効果的な手法があります。決定的な証拠を得るのは不可能ですが、私の感覚では、ほとんどのグループはオフィスワークの方が生産性が高いです。しかし、分散型ワークモデルを使用することで、より幅広い人材プールにアクセスできるため、より生産性の高いチームを構築できます。

テクノロジーは常にスマートになり、より強力になっています。これらのテクノロジーが導入されると、組織の生産性が向上するどころか低下することがよくあります。これは、テクノロジーによって開発者の複雑さと認知的オーバーヘッドが増加し、その効率が低下するためです。この記事では、シリーズの最初のものとして、開発者の効率を最大化するフレームワークを紹介します。調査を通じて、開発者が1日に200回行うマイクロフィードバックループを含む、主要な開発者フィードバックループを特定しました。これらは、開発者にとって迅速、シンプル、そしてインパクトのあるものになるように最適化する必要があります。いくつかの組織がこれらのフィードバックループを使用して全体的な効率と生産性を向上させた方法について考察します。

経営陣はメトリクスを好みます。「現状を測定するための数値が必要です。数値は人々を集中させ、成功を測定するのに役立ちます。」という考えです。善意に基づいていますが、数値による管理は直感に反して問題のある行動につながり、最終的にはプロジェクト全体と組織の目標から逸脱します。メトリクス自体は悪いものではありませんが、多くの場合、不適切に使用されています。このエッセイでは、経営陣による従来のメトリクスの使用によって引き起こされる多くの問題を示し、これらの機能不全に対処するための代替案を示します。

開発者生産性の測定は困難な課題です。開発サイクル時間とスループットに焦点を当てた従来のメトリクスには限界があり、他に目を向けるべき明確な答えはありません。定性的メトリクスは、開発者自身から得られたデータを使用して開発者生産性を測定し理解するための強力な方法を提供します。組織は、システムからのデータではなく、人間からのデータを使用して開発者生産性を測定することに優先順位を置くべきです。

ソフトウェア開発者の生産性を向上させるにはどうすればよいですか？

ソフトウェアプロセス、設計プラクティスなどについて、多くの感情的な議論を見ます。ソフトウェア業界はソフトウェア開発の有効性の基本的な要素の一部を測定する能力が欠如しているため、これらの議論の多くは解決できません。特に、生産性を合理的に測定する方法がありません。

ソフトウェアの世界で一般的に受け入れられている信念の1つは、才能のあるプログラマーの方が生産性が高いということです。生産性を測定できないため、これは証明できない信念ですが、妥当なように思えます。結局のところ、ほとんどすべての人間の努力は、他の人よりも優れた人がいることを示しており、しばしば著しく優れています。プログラマー自身も一般的に観察していますが、常に自分自身をより才能のあるカテゴリーにいると考えている人によって言及されるようです。

ソフトウェアを適切に設計する価値はありますか？

多くの人は、アジャイルプロジェクトで固定価格契約はできないと考えています。アジャイルプロセスのポイントは将来を予測できないことなので、これは不合理な推測ではありません。しかし、これは固定価格のアジャイル契約を策定できないという意味ではありません。実際には、固定スコープ契約を策定できないという意味です。

私のお気に入りの名言の1つは、「苦痛であれば、より頻繁に行う」です。表面上はナンセンスに聞こえますが、深く掘り下げると貴重な意味が得られます。

ショッピングウェブサイトのソフトウェアを作成するチームを想像してみてください。チームのアウトプットを見ると、過去四半期に作成した新機能の数、またはページ読み込み時間の短縮などのクロスファンクショナルな指標を考慮するかもしれません。しかし、アウトカム指標は、売上高の増加や製品に関するサポートコール数の減少を考慮します。アウトプットではなくアウトカムに焦点を当てることで、ソフトウェアのユーザーや顧客の有効性を向上させるための機能の構築が促進されます。

ペアプログラミングに関する一般的な誤解のいくつか。

DevOpsレポートの現状は、調査データの統計分析を使用して、ソフトウェアデリバリー組織の効果的なプラクティスを決定する年間レポートです。主な著者は、Nicole Forsgren、Jez Humble、Gene Kimです。

私は、「管理者はより多くの機能を望んでおり、品質を気にしていない」という理由で不満を抱いている開発者に頻繁に出会います。これを聞くと悲しくなります。なぜなら、これを聞くと、開発者、管理者、そして顧客がすでに敗北していることがわかるからです。彼らの敗北は、状況を「トレード可能な品質仮説」という観点から枠組み化することによって引き起こされています。