The SPACE of Developer Productivity - ACM Queue

overview

What is the SPACE framework?

SPACE is a developer productivity framework, encapsulating key research findings.
Led by Nicole Forsgren of the DORA team, SPACE offers a comprehensive view of productivity beyond DORA metrics.
It outlines five critical productivity dimensions (Satisfaction & Well-being, Performance, Activity, Communication & Collaboration, Efficiency & Flow) across three organizational levels (individual, team, system).

SPACEフレームワークとは何か？

SPACEは開発者の生産性フレームワークで、主要な研究結果を包括している。
DORAチームのNicole Forsgrenによって率いられたSPACEは、DORA指標を超えて生産性の包括的な視点を提供する。
それは、3つの組織レベル（個人、チーム、システム）にわたる5つの重要な生産性の次元（満足度とウェルビーイング、パフォーマンス、アクティビティ、コミュニケーションとコラボレーション、効率性とフロー）を概説している。

S/P/A/C/E

Satisfaction and Well-being: Recognizes the emotional and psychological aspects of productivity, emphasizing that a satisfied and well-being-focused work environment contributes significantly to overall productivity.
Performance: Measures the outcomes and results of development work, focusing on the quality and effectiveness of the software produced.
Activity: Looks at the actual tasks and work done by developers, including coding, debugging, and other development-related activities.
Communication and Collaboration: Highlights the importance of teamwork and effective communication among developers, which are crucial for successful software development.
Efficiency and Flow: Focuses on the ability of developers to work in a state of flow, where they are fully immersed and efficiently progressing through tasks.
満足度とウェルビーイング: 生産性の感情的および心理的側面を認識し、満足でウェルビーイングに焦点を当てた作業環境が全体的な生産性に大きく貢献することを強調します。
パフォーマンス: 開発作業の成果と結果を測定し、生産されたソフトウェアの品質と効果に焦点を当てます。
アクティビティ: 開発者によって行われる実際のタスクと作業、コーディング、デバッグ、その他の開発関連活動を見ます。
コミュニケーションと協力: チームワークと開発者間の効果的なコミュニケーションの重要性を強調します。これらは成功したソフトウェア開発に不可欠です。
効率とフロー: 開発者がタスクを通じて完全に没入し、効率的に進行するフローの状態で作業できる能力に焦点を当てます。

Myths and Misconceptions about Developer Productivity

Myth: Productivity is all about developer activity

Productivity myths suggest activity equals productivity, leading to potential overwork and dissatisfaction.
Activity metrics are unreliable for assessing true productivity due to measurement errors and overlook collaboration benefits.

Myth: Productivity is only about individual performance

Success involves both individual and team contributions, requiring a balanced measure of performance.
Focusing solely on personal productivity can detriment team productivity, emphasizing the importance of team-focused activities.

Myth: One productivity metric can tell us everything

The belief in a universal productivity metric is misleading; productivity is multifaceted and context-dependent.

Myth: Productivity Measures are useful only for managers

Despite misconceptions, productivity measures can be valuable for developers for personal insight and communication.

Myth: Productivity is only about engineering systems and developer tools

Human factors like work environment and culture significantly impact productivity, highlighting the importance of "invisible" work like morale building and mentoring.

神話：生産性は開発者の活動についてのみである

生産性の神話は、活動が生産性に等しいと示唆しており、過労と不満を招く可能性がある。
活動指標は、測定エラーや協力の利点を見落とすため、真の生産性を評価するには信頼性がない。

神話：生産性は個々のパフォーマンスについてのみである

成功には個人とチームの両方の貢献が含まれ、パフォーマンスのバランスの取れた測定が必要である。
個人の生産性にのみ焦点を当てることは、チームの生産性を損なう可能性があり、チーム中心の活動の重要性を強調している。

神話：1つの生産性指標がすべてを教えてくれる

普遍的な生産性指標への信念は誤解を招くものであり、生産性は多面的で文脈に依存している。

神話：生産性の指標はマネージャーにのみ有用である

誤解にもかかわらず、生産性の指標は個人の洞察とコミュニケーションのために開発者にとって価値がある。

神話：生産性はエンジニアリングシステムと開発者ツールについてのみである

職場環境や文化のような人間的要因は生産性に大きな影響を与え、士気の向上やメンタリングのような「目に見えない」仕事の重要性を強調している。

Framework in Action

Satisfaction: Perceptual measures about code reviews can indicate developers' perspectives on their work, including learning, mentorship opportunities, or the ability to shape the codebase. High numbers of code reviews per developer may signal dissatisfaction if perceived as disproportionate.
Performance: Code-review velocity measures the speed of reviews, reflecting both individual and team constraints, such as policy-imposed review durations.
Activity: The number of code reviews completed is an individual metric that shows productivity and contribution to the final product.
Communication and Collaboration: The quality or thoughtfulness of code reviews serves as a qualitative measure of how well developers collaborate and communicate through code.
Efficiency and Flow: The timing and batching of code reviews can affect workflow and system throughput. Metrics that measure the impact of code-review timing on efficiency and the flow of work are crucial.
満足度: コードレビューに関する知覚的指標は、学習機会、メンターシップの機会、またはコードベースを形成する能力など、開発者が自分の仕事をどのように見るかを示すことができます。開発者一人当たりのコードレビューの数が多い場合、不均等に認識されると不満のサインとなるかもしれません。
パフォーマンス: コードレビューの速度はレビューの速さを測定し、個人とチームの制約を反映します。例えば、レビューポリシーによる持続時間など。
アクティビティ: 完了したコードレビューの数は、生産性と最終製品への貢献を示す個人指標です。
コミュニケーションと協力: コードレビューの質や思慮深さは、開発者がコードを通じてどのように協力し、コミュニケーションをとるかの定性的な測定値です。
効率とフロー: コードレビューのタイミングとバッチ処理は、ワークフローとシステムスループットに影響を与える可能性があります。効率と仕事の流れに対するコードレビューのタイミングの影響を測定する指標は重要です。

How to Use the Framework

Diverse Metric Selection: Teams should select metrics from multiple dimensions of the SPACE framework, ensuring a broad understanding of productivity. For instance, alongside activity metrics like commits, include metrics from different dimensions such as productivity perception and pull request merge time.
Inclusion of Perceptual Measures: Incorporate perceptual measures, like survey data, to capture a more comprehensive view of productivity, acknowledging the value of individuals' experiences and insights.
Balanced View Through Metrics in Tension: Employing metrics from various dimensions may create tension, but this is intentional to provide a balanced perspective of the work and systems, facilitating smarter decisions and trade-offs.
Consideration of What Metrics Signal: Metrics indicate what an organization values; thus, the choice of metrics influences behaviors and priorities within the team and the broader organization.
多様な指標の選択: チームはSPACEフレームワークの複数の次元から指標を選び、生産性の広範な理解を確保するべきです。例えば、コミットのようなアクティビティ指標の横に、生産性の認識やプルリクエストのマージ時間など異なる次元からの指標を含めます。
知覚的指標の含有: 個人の経験や洞察を認め、生産性のより包括的なビューを捉えるために、アンケートデータのような知覚的指標を組み込みます。
緊張を通じたバランスの取れたビュー: 様々な次元からの指標を使用することは緊張を生み出すかもしれませんが、これは意図的で、仕事とシステムのバランスの取れた視点を提供し、より賢い決定とトレードオフを促進します。
指標が示すものの考慮: 指標は組織が何を価値あると考えているかを示します。したがって、指標の選択はチーム内およびより広い組織内の行動や優先順位に影響を与えます。

What to Watch For

Metric Overload: Having too many metrics can cause confusion and demotivate, as striving to meet a lengthy list of targets may seem unachievable. Aim for a balanced number of metrics across dimensions for a holistic view.
Imperfect Proxies: No metric perfectly captures productivity; some can be misleading or reflect multiple factors beyond the intended measure, such as retention reflecting more than satisfaction.
Privacy and Anonymity: Ensure developer privacy by reporting only anonymized, aggregate results at the team or group level. Individual analyses should be optional and respect legal and ethical standards.
Bias and Norms: Be aware of biases and cultural norms that may influence metrics, such as gender disparities in peer reviews or cultural differences in self-reporting.
メトリックの過多: 多すぎるメトリックは混乱を招き、動機を低下させる可能性があります。目標の長いリストを満たすことが達成不可能に思えるかもしれません。包括的な視点を促すために、少数のメトリックを少なくとも三つの次元で目指します。
不完全な代理: どのメトリックも生産性を完全には捉えられません。いくつかは誤解を招くか、意図された尺度を超えた複数の要因を反映する可能性があります。例えば、保持は満足度以上のものを反映するかもしれません。
プライバシーと匿名性: 開発者のプライバシーを確保するために、チームまたはグループレベルでのみ匿名化された集約結果を報告してください。個人分析は任意であり、法的および倫理的基準を尊重すべきです。
バイアスと規範: ピアレビューの性別差や文化的差異による自己報告など、メトリックに影響を与える可能性のあるバイアスや文化規範に注意してください。