Developer Productivity/Experience関連で2022年1月~4月に読んだリソース

2022年1月~4月に読んだDeveloper Productivity / Developer Experience関連の書籍や記事のまとめ
最後は息切れしたので後で追記する。そして書籍も色々読んでたが手を広げすぎてどれも読み終わってないので5月こそ読み切る...

The SPACE of Developer Productivity: There's more to it than you think - Microsoft Research

LeanとDevOpsの科学の著者でもあるNicole Forsgren氏が筆頭著者の論文。開発者の生産性を計測するためのフレームワークについて述べられている。
まだまだ実用例を聞くことは少ないが、個人的にはかなり納得度も高く、どこかでこのフレームワークを元に開発者の生産性について考えてみたい。
SPACEについては別途メモを書いてる
開発者の生産性を測るためのフレームワークSPACEについて

Creating a Culture of Engineering Productivity at Netflix - DevInterrupted

NetflixのProductivity Engineeringチームの話。
この記事では、Productivity Engineeringチームの役割について、Netflixの開発者が可能な限り効率的かつ効果的に作業出来るようにすることであり、範囲はコーディング、テスト、デバッグ、依存関係管理、デプロイ、アラート、モニタリング、パフォーマンス、インシデント対応までと述べられており、かなり幅広い && やはりPlatform Engineeringと被るなーという印象。
そしてSPACEの論文でも似た内容は存在しているが、生産性の測定は難しく、どの組織においても万能な測定方法は存在しないとした上で、NetflixのProductivity Engineeringチームではインパクトと結果に焦点を当てるべきというスタンス。
また何よりも顧客満足度を重視し、何かをどのように提供するかも重要だが、提供されたもののインパクトが最終的にもっと重要というのは、最終的なアウトカムやインパクトを計測で重視するのは、一つの生産性の測り方として個人的には納得度は高い。

そして生産性指標の利用方法に関しては、生産性をチーム間で比較することはよく言えば茨の道、悪く言えばモラルに関わる危険なことであり、生産性の測定はコンテキストが全てと述べている。
実際チーム間で顧客基盤やチームの役割や立場も異なるので一概に比較されてしまうのはハレーションを生んでしまう可能性が大いにあるのは理解に容易い。というか自分が雑な指標で生産性を比較されても納得出来るとは思えないし、チームトポロジーで言うところの、ストリームアラインドチームとイネーブリングチームの生産性を同一の指標で比較しても意味があると感じることは難しい。
顧客満足度(CSAT)を測定していたとして、Netflixでも、業界全体でも、社内チームの満足度は顧客対応チームの満足度よりも低くなる傾向があることが分かってるとあるように顧客満足度であってもチーム間のコンテキストの違いによるブレは発生してしまう。

やはり基本は同一チームの過去との比較に使うのが現実的で、厳密に比較するのではなく明らかに躓いてるチームを発見する手法の一つ程度に捉えておくのが無難かなという感想を持った。
ただ同一チームであってもメンバーの変化など、当然当時と全く同じ状況であることは稀なので、これも結局コンテキストを踏まえなければとまとめる必要があり生産性の計測は難しい...
four keysのような指標とは異なり、特定企業を超えて横断的に用いられるベストプラクティスのようなものが開発者の生産性計測の分野にまだ存在しない(ように個人的には思っている)のもコンテキスト依存が強いのが大きな理由。実際にSPACEでも具体的に計測すべき指標については明言していない。
ちなみに記事内でもSPACEについても一瞬触れられており、気に入ってるとの発言をしているが、それ以上の話はなかったのは残念。
蛇足だが、以下の文章がインパクトと結果に焦点を当てるべきを上手く表現してて気に入った

If you're running around a track super-fast, but you're on the wrong track, does it matter?

エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blog

Google CloudでFour Keysを測定・可視化する話。便利そうで羨ましい

2021 年の Accelerate State of DevOps Report で、燃え尽き症候群とチームのパフォーマンスについて発表 | Google Cloud Blog

2021年のAccelerate State of DevOps Reportの概要紹介記事。
一番のトピックは、four keysとして今まで知られてきたが、信頼性が5番目の指標として登場したこと。この辺りはおそらくSREの影響。冷静に考えれば今までのfour keysはMTTRも含まれてはいるが、開発~リリースまでのデリバリーのパフォーマンスという側面が強く、とはいえ実際の開発サイクルの中には運用は開発、リリースと合わせて大きな要素(正直他に何がある?レベル)なわけで、運用面の話を含めるために信頼性をfour keysにも取り入れるのは妥当な話に聞こえる。
そしてチームがデリバリーのパフォーマンスと運用のパフォーマンスの両方を重視する場合に、組織的なパフォーマンスが最も高くなることが報告されています。というのも、まぁそうだろうなという感想。ということで個人的にも組織のパフォーマンス向上に貢献するためにもfour keysだけでなく運用やSREの領域にもより踏み込んでいかなければなーという気持ちを持った。

How to Measure and Improve Developer Productivity - Incredibuild

指標の例が色々あげられていたが、単純にLOCの話はその通りだなと。LOC以外でもgit baseのメトリクスの多くも同じような性質を持っていて単純な増減では生産性を測れない。アクティビティメトリクス単体の利用が推奨されない・難しいのはまさしくこれ

  • LOC → counting the number of lines of source code
  • LOC で生産性を測定するには、開発段階に基づいた重み付けが必要
    • 新しい機能が追加されたとき、開発開始時にはコーディング量が多くなる
    • 共通ライブラリを作成したり、コード部分を 1 つにまとめたりすることは LOC 指標では悪いこととみなされる

Mercari Engineering blog

メルカリの Developer Productivity Engineering チームの取り組みについて。Platform engineeringとDeveloper productivityは関連性高い(特に規模が大きくなってきたら)のでまた本業で必要になったタイミングで見直したい

社内 Platform チームの Product Management

上同

Bottleneck #01: Tech Debt

組織がスケールする上でのボトルネックについてまとめたシリーズ記事のうちの技術負債回
four keysのようなパフォーマンス指標や可視化の話ではないが、ProductivityやExperienceを維持/改善しながらも組織をスケールする際には、ここで述べられている内容の対処は求められるので、Productivityの観点でも大事な話

- 代表的な技術負債
  - Code quality
    - テストしにくいコード、理解しにくいコード、ドキュメント化が不十分なコード
   - ドメインモデルや関連するデータモデルが現在のビジネスモデルに合っていないとか
  - Testing
    - テストがない。テストの割合がおかしい(テストピラミッド)
    - 開発時にフィードバックを得るスピードが遅くなり、結果デプロイ頻度が落ちたり
  - Coupling
    - モジュール間での結合度が強いと、チーム間でブロックし合う可能性が高まったり、結果デプロイの頻度減少や変更のリードタイムが長くなる
    - 解決策の1つはマイクロサービス化だが複雑性をもたらす
    - モノリス内で明確な境界を設定するだけなら、もっと簡単な方法があるはず
      - memo: 多分モジュラーモノリスとかの話
  - Unused or low value features
    - 機能が増えれば増えるほど、開発者が考慮する条件やエッジケースが増え、開発スピードを低下させる
    - 実験(機能)がうまくいっているかどうか、常に再評価し、ダメなら削除
      - チームが判断するのは難しいので、機能の価値を定量化する客観的なデータがあれば容易に
  - Out of date libraries or frameworks
    - レガシーなフレームワークやライブラリをいつまでも使う
    - 開発者の満足度やストレス度、セキュリティ、スキルセット面での採用の問題
  - Tooling
    - 最適でない他社製品や、メンテナンスに手間がかかるツール。より効率的なツールが市場に出てきている可能性
  - Reliability and performance engineering problems
    - カスタマーエクスペリエンスやスケールアップの能力に影響を与える可能性
    - 早すぎる最適化で無駄な労力を費やすケースも
  - Manual processes
    - 手作業
  - Automated deployments
    - デプロイ自動化。four keysの話
  - Knowledge sharing
    - ドキュメントがない、または見つけられない
- Signs you are approaching a scaling bottleneck
  - Value lead time
    - ユーザーに価値を提供するエンドツーエンドのプロセスと、それが時間とともにどのように推移するかを見る
    - 技術負債溜まりすぎると遅くなる
  - Impact to end user
    - Latency in the systems, customer onboarding time, and quality issues
  - Engineering satisfaction
    - 開発者の不満ベースで技術基盤の問題を見つける
  - Ability to onboard new developers
    - 入社後のプロセスや新メンバーの満足度を見る
  - Degradation in Non-Functional measures
    - 実行時のインフラコスト、パフォーマンス、可用性
- 技術的負債に対するチームのアプローチは、リーダーによって設定された技術戦略から来るものであるべき
  - 意図的 && 明確 && 時間をかけて再評価されるべきもの
  - A tech strategy to limit technical debt impact
    - [https://martinfowler.com/articles/bottlenecks-of-scaleups/phases.html](https://martinfowler.com/articles/bottlenecks-of-scaleups/phases.html)
- How do you address the tech debt
  - 透明性のある情報を共有
    - ビジネスの状況、製品の方向性、現在のスケーリング能力に関する指標、製品に関する顧客の声、カスタマーサポートやオペレーションが見ているもの
    - データに基づいた意思決定を行う
  - すべての製品とその関連システムに明確なオーナーを決める
    - チームが成長した事による、所有権の曖昧さが技術的負債につながる
    - オーナーシップがないと問題を修正するインセンティブが低くなる
      - memo: 誰もオーナーがいない、古いプロダクトや共通コンポーネントはそのうち触らぬ神に祟りなし状態に:innocent:
  - 技術的負債を解決することは、製品開発の自然な流れの一部であるべき
    - エンジニアとプロダクトマネージャーは、技術的負債と機能性の健全なバランスをとる
    - 技術的に健全な製品を維持・継続することは、開発チームの仕事の一部であり、技術的負債に取り組み、継続的に監視するための合意されたプロセスが必要
  - チームのトポロジーを正しく設計する
    - ある領域で技術的負債が継続的に発生しているのであれば、チームの設計が誤っていることを示すかも
    - 強力なオーナーシップと注意が必要なプラットフォームやビジネス能力があるのかも
      - memo: コンプリケイテッド・サブシステムチーム、プラットフォームチーム
  - メトリクス見る
    - よくあるミスやビルドやデプロイの時間を測定したり
    - メトリクスは、マネージャーが監視したりインセンティブを与えたりするためではなく、チームが技術負債について意思決定するためのガイドとして使用する
  - チームの自立度のバランス
    - 自律性が高すぎるとカオスになる可能性
      - memo: 技術負債じゃないが、Spotifyモデル関連でこんな話読んだ記憶。チームが自立しすぎて、全社的な目標と一致しないチームがあったり、全体最適できないとか
    - アーキテクチャーピアレビューなど、軽量なチェックアンドバランス
      - memo: 前職で、標準/推奨技術スタックの統制が曖昧で、何故か1チームだけ別言語を使ってた結果、その言語を書ける人がいなくなり、そもそもシステム捨てることになった
  - どのように対処するかは組織の状況によって異なる
    - 応急処置的なアプローチでなく、反復的&&技術的負債を解決するための投資を開発活動と組み合わせた測定基準に任せることが良い結果をもたらす
- Summary && Memo
  - 慎重な技術的負債をは、アーリーステージのスタートアップにとって必要 && 健全
  - 技術的負債がビジネスを制約するようなサイン(Value Lead Timeやエンジニアリングの満足度)を探す
  - 明確な技術的品質基準を持ち、チームがそれを守ることができるように
  - 技術的負債のプロセスを作成、明確なオーナーシップを持ち、権限のあるチームが透明性のある情報にアクセスし、データに基づいた意思決定を行うことができるように
  - 特に成長過程における重要な瞬間(資金調達、新しい製品の方向性、新メンバー加入)には、技術負債戦略を継続的に再評価する

New data: What makes developers happy at work

ざっくりとしか見てないが生産性と幸福度は高い相関関係にある(らしい、色んな所で読んだ記憶だがどこで読んだか思い出せなかった)ので、開発者の幸福度高い環境を知るのは非常に大事

Maximize Developer Productivity and Engagement with the Developer Experience Engineer

Developer Experience Engineerの定義や重要性について述べてる。
この記事では Developer Experience Engineer の役割を開発者の生産性を最大化し、最大のビジネス価値を生み出すための適切なツール、プロセス、環境を確保することと定義していて、それによりビジネス・収益面でも有意義な結果を得ることが可能だと述べている。
(少なくともこの記事で想定されている)Developer Experience Engineer はエンジニアリングチームの効率を最大化するために標準化と統合を行い、サービスの開発者に適切なプロセスやツールを提供する事で、ビジネス価値の源泉となるソフトウェアをより高速に効率的に生み出す基盤を構築することでビジネスに貢献する。

イメージが難しければ、この記事で想定してるようなDeveloper Experience EngineerはPlatform Engineeringでは?という感じなので、Platform Engineeringや基盤チームを思い浮かべると割と近しいと言って良いはず。
明確に役割・ミッションとして Developer Experience のワード自体は存在してないが、いわゆる基盤・Platform を提供するチームは各チームの開発の効率化や全体最適のために存在してるので実質内包してはいるケースが多いし、実際自分が経験した環境もここでいうDeveloper Experience Engineerに近い役割は担っていた。
例としてインディゴ社が紹介されており、マイクロサービス間のテストに課題を感じており、これらの課題を解決するテスト環境を提供したのが Developer Experience Engineer、DevOpsチームだと述べられている
The successful Developer Experience Engineerなどここで触れてないが興味深い内容はあるので、どこかでDeveloper Experience Engineerとは?みたいな内容でまとめる際に再度参照したい。

Maximizing Developer Effectiveness

開発者の生産性、効率を何をどうして改善していくのかの話。Feedback Loopsはfour keysのデプロイまでのリードタイムに内包されるので、four keysをトラックする際にも一緒に可視化しておくと良さそう
またこのloopの遅さはDeveloper Experienceや満足度にも大きく影響するのでそういう点でも重要度は高い。実際loopが速くなった事により満足度の向上は過去体験しているのでこのあたりへのこだわりはもっていたい。
それ以外にも事例や組織面やそもそもの話など参考になる内容が多くてかなりよかった。

開発者の効率が良い企業と低い企業では、アプローチの仕方に大きな違いがあることを発見

## Day in the life in a highly effective environment
- checks the team project management tool and then attends standup where she is clear about what she has to work on.
- notes that the development environment has been automatically updated with libraries matching development and production, and the CI/CD pipelines are green.
- pulls down the latest code, makes an incremental code change that is quickly validated by deploying to a local environment and by running unit tests.
- depends on another team’s business capabilities for her feature. She is able to find documentation and the API spec through a developer portal. She still has some queries, so she jumps into the team’s Slack room and quickly gets some help from another developer who is doing support.
- focuses on her task for a few hours without any interruptions.
- takes a break, gets coffee, takes a walk, plays some ping pong with colleagues.
- commits the code change, which then passes through a number of automated checks before being deployed to production. Releases the change gradually to users in production, while monitoring business and operational metrics.

## Day in the life in a low effective environment
- starts the day having to deal immediately with a number of alerts for problems in production.
- checks a number of logging and monitoring systems to find the error report as there are no aggregated logs across systems.
- works with operations on the phone and determines that the alerts are false positives.
- has to wait for a response from architecture, security and governance groups for a previous feature she had completed.
- has a day broken up with many meetings, many of which are status meetings
- notes that a previous feature has been approved by reviewers, she moves it into another branch that kicks off a long nightly E2E test suite that is almost always red, managed by a siloed QA team.
- depends on another team's API, but she cannot find current documentation. So instead she talks to a project manager on the other team, trying to get a query. The ticket to find an answer will take a few days, so this is blocking her current task.

## Developer effectiveness
- 効果的であるとはどういうことか
  - 開発者である以上、目的は顧客に最大限の価値を提供すること
  - 効果的な環境は、有用で高品質なソフトウェアを生産する事を容易にし、不必要な複雑さ、軽薄な解約、長い遅延に対処する必要がないようにすることで、価値を高める仕事に集中することができる
	- エンジニアは自分が生産的でないことに無力感(は学習性無力感)を感じるようになる
- 組織は開発者の生産性を測定する方法を探している
  - 一般的なアンチパターンはコード行数などでパフォーマンスの低い開発者を見つけようとすること
  - それよりも、組織がいかに効果的なエンジニアリング環境を提供しているかに焦点を当てる方がよい
- 生産的であることは、開発者のモチベーションを高める。不要な摩擦がなければ、創造的に考える時間を持つことができる

## Case Study: Spotify
- エンジニアを対象としたユーザー調査により以下二つの問題を発見
  - 内部ツールの断片化
    - 内部インフラとツールは、孤立した小さな「島」として構築されており、エンジニアのコンテキスト切り替えと認知負荷につながった
  - 発見性の低さ
    - 技術情報を見つけるための中心的な場所がなく、情報があちこちに散らばっているため、エンジニアはどこから情報を探せばいいのかさえわからない状態だった
- 開発者が多くの決定を個別に行うことを強いられ、それが断片化と重複作業を生み、最終的に製品のエンドツーエンドの納期を損なうという悪循環に陥っていた
- 一貫した開発者体験とエンジニアが必要な情報を見つけるための出発点を提供するプラグインアーキテクチャを備えたオープンソースの開発者ポータル、Backstageを開発した

## How to get started?
- 効果の高い環境とは
  - DevOps文化、継続的デリバリー、製品思考を完全に取り入れた企業
  - AccelerateとState of DevOpsのレポートを読んでいる
- four keysは(リードタイム、デプロイ頻度、MTTR、変更失敗率)は、DevOpsのパフォーマンスを測る素晴らしい指標
  - 現状を把握し、より良くなるために行うべき具体的なことを把握するために、やるべきことがある時期を示すのに有効な測定値
- 開発者の満足度に関する調査など、他の調査源と組み合わせることも必要です。
- 何をすべきかを知るのはとても難しい
- 開発者のフィードバックループを最適化し、高速かつシンプルにすることに注力することをお勧めする
  - フィードバックループの長さ、制約、そして結果の結果を測定
  - 新しいツールやテクニックが導入されたとき、これらの測定基準によって、開発者の効率がどの程度改善されたか、あるいは少なくとも悪化していないことを明確に示すことができる

### Feedback Loops
- マイクロフィードバックループは短ければ短いほど良い
- より早く、より頻繁に検証を受けることで、後々の手戻りを減らすことができる
- 結果を解釈するのが簡単なマイクロフィードバックループは、前後のコミュニケーションと認知的オーバーヘッドを削減する
- マイクロフィードバックループの悪化は、four keysの主要な測定基準(デプロイ頻度とリードタイム)のスコアの低下として現れる
- マイクロフィードバックループはチリも積もれば山となり、開発者のフロー状態をも乱してしまう
- 何をどこまで最適化するかの判断には、個々のチームなどの個別最適かではなく、全体最適、プラットフォーム思考が重要
- 分散システムでがチームの自律性と高速なフィードバックループを維持するのにはコストがかかるが、このコストは開発者の有効性を犠牲にしないための必要経費

## Organizational Effectiveness
- 効果的な組織は、効果性とフィードバックループを最適化するように設計されている
  - 技術、そして開発チームの摩擦を取り除くことがビジネスにとって不可欠であることを、リーダーが認識することから始まる
- リーダーは、常に有効性を測定し、再検討しています。効果的な組織は、4つの主要な測定基準とその状況にとって重要なその他のデータポイントを追跡することによってデータ駆動型の意思決定を行う枠組みを作り上げている
- 測定基準に加え、日々その環境で働く個々の貢献者の声に耳を傾けるオープンなフォーラムを作る
  - 開発者は自分たちが直面している問題を知り、それを解決する方法について多くのアイデアを持っているはず
  - この情報をもとに、エンジニアリングマネージャーは投資の優先順位を決定することができる
  - 大きな問題では、開発者のエクスペリエンスの低下に対処するために、それに見合った大規模な最新化プログラムが必要になるかもしれない
  - しかし多くの場合、継続的な改善を行うためにチームを強化することの方が重要
- 重要な原則は、Developer Experienceを受け入れること
  - Developer Experienceとは、エンドユーザー製品の開発に用いられるのと同じアプローチで、同じ調査、優先順位付け、成果ベースの思考、消費者からのフィードバックメカニズムを適用して、技術的能力を構築することを意味する
- 開発者のモチベーションを上げるために、効果の高い組織はフランチャイズを行っている。つまり開発者は日々の生活を向上させる能力を持つべきということ
  - この組織では、チームが段階的に技術的な改善を行い、技術的負債を管理する方針がある
  - 開発者とプロダクトマネジメントの間には、データに裏打ちされた健全な議論があるはず。チームが明確な目標を持ち、ボトルネックを明確に把握していれば、開発者は問題解決に向けて創造的に行動することができる
  - このような組織は、最高のアイデアを「バブル・トゥ・ザ・トップ」させ、データを使って何がベストかを評価し、ダブルダウンさせる方法を生み出している
- コミットメント、測定、権限委譲の次はスケーリング
  - ある程度の組織規模になると、規模の経済による効率化を図る必要がある
  - そのためにプラットフォーム思考を応用し、効率性の向上に特化した内部プラットフォームを構築する
  - 開発者の効率を向上させるための技術的能力を構築するエンジニアリングチームに投資する
  - また、他の開発チームを消費者とみなし、彼らが提供するサービスを製品のように扱います
    - このチームにはテクニカルプロダクトマネージャーがおり、そのチームが消費者であるチームにどのような影響を与えているかに関連した成功指標を持っている
    - 例えば、観測可能性を重視するプラットフォーム能力チームは、モニタリング、ロギング、アラート、トレース機能を作成し、チームがサービスの健全性を容易に監視し、製品の問題をデバッグできるようにする
- ガバナンスの必要性は高い。しかし高度に効果的な組織では、長時間の承認プロセスではなく、ガードレールを設定・伝達し、チームを正しい方向へ導くというものです。このように実施されると 、効率性の向上に重要な役割を果たす
  - 明確なエンジニアリング目標
  - チームやサービス間のコミュニケーション方法の規定
  - 有用なピアレビューの促進
  - ベストプラクティスをプラットフォーム機能に組み込む
  - アーキテクチャフィットネス機能による制御の自動化

## Case Study: Etsy
- Etsyは「素早く動くことは技術戦略でありビジネス戦略でもある」という信念のもと、開発者の効率性を社風に根付かせることに取り組んできた
- Etsyの重要な指標の1つはリードタイムであり、リアルタイムに測定、監視、表示されている
  - リードタイムがある重要な閾値以上になると、リリースエンジニアリングチームはそれを妥当なレベルまで下げるよう努力する
- またソフトウェアを速く導入することは、物語の半分に過ぎず、本当に効果的であるためには、そのソフトウェアが消費者にとって価値あるものでなければならない。
  - そのためEtsyでは、各機能に測定可能なKPIを設定し、データ駆動型のアプローチをとっている
- コードの変更は一連のチェックを経て、開発者はその変更がパフォーマンス、可用性、障害率などに関するEtsyのSLAを満たしていると確信することができる
- また変更が本番稼動すると、Etsyの実験プラットフォームはユーザー行動の指標を取得することができ、チームはこの指標をもとに、関連するKPIとユーザーの満足度を最適化しながら、製品の改良を繰り返していく
- 最終的にその変更が価値のないものであることが証明されれば、それは一掃され、それによって技術的負債を回避することができるだろう。

### 4 Pillars of Developer Experience
Etsyが取りんでいる開発者体験の主要な柱が以下

- Help me craft products ensures we have the right abstractions, libraries, and scaffolding for product engineers to do their work.
- Help me develop, test, and deploy focuses on product engineers, specifically the development environments themselves (IDEs, linters), unit/integration test patterns/runners, and the deployment tooling and processes.
- Help me build with data focuses on data scientists and machine learning engineers, making sure the entire data engineering ecosystem is set up in a way that is intuitive, easy to test, and easy to deploy.
- Help me reduce toil focuses on the on-call engineers, to make sure we build production systems with the appropriate levels of automation, have runbooks and documentation that is easily accessible and current, and we track and prioritize reducing toil-y activities.

4つの主要な指標を含む測定基準を追跡し、ネットプロモータースコア(NPS)を把握するために開発者に毎月アンケートを実施し、その効果を継続的に検証している

Developer Velocity: How software excellence fuels business performance

Developer Velocity なる指標についてのレポート。
Developer Velocity とはソフトウェア開発を通じて、ビジネスのパフォーマンスを革新的に向上させる能力のことであり、マッキンゼーが Developer Velocity がビジネス指標に与える影響を定量化し、そこから生まれたのがDeveloper Velocity Index (DVI) であり、DVI と主要なビジネスパフォーマンス指標との間に強い相関関係があることも発見したらしい。
DVIは組織がデジタルアイデアを生産に移す能力をどの程度備えているかを示し、また Developer Velocity を達成するために最も重要な要素を特定するのに役立つ
正直これ以上は読めてないので、またどこかでまとめて読む

8 Ways to Enhance Developer Velocity

前述のDeveloper Velocityを高めるためのtipsの話

- Learn to Fail Fast
    - 失敗が早ければ早いほど良い
    - AB テストによる迅速なフィードバック
    - テスト駆動開発(TTD)、静的コード解析、およびシフト・レフト・アプローチにより、開発者は問題を早期に発見し、早期に修正し、より迅速に行動することが出来る
- Build Product and Development Confidence
    - 失敗を許容するだけでなく奨励する文化を作ることで、新しいやり方を試すことができるようになり、その多くが最終的にはより良く、より速くなるかもしれません。
    - エラー許容度、試行錯誤の奨励(ただし、早く失敗することでエラーへの投資を抑制)、新しいアイデアや異端的なアプローチに対するオープンさを維持することで信頼性を高めることができる
    - 開発レベルでは、ペアプログラミングの手法を採用し、コードレビューやデザインレビューでは、できる限り自由に(必要な場合は厳しく)行うことを検討する
- Prototype
    - 失敗したプロトタイプを作って捨てる方がコストがかからないという事実は変わらない
- Cathedral/Bazaar, Yes. Big Ball of Mud, No.
    - 開発者には、明確なアーキテクチャ、優れたプロセス、効果的な継続的内部コミュニケーション、十分に文書化されたリリースノート、そしてずさんな作業を抑止する環境が必要
    - それによりベロシティも向上する
- Manage Technical Debt
    - 技術的負債とは、古いインフラで何年も開発を続けたり、急遽小さな変更を何度も行ったり、適切な計画やツール、ライブラリを持たずに開発した場合に発生するもの
    - 開発者の速度低下
    - 技術的負債とは、開発者が新機能やバグ修正のたびに多大な労力を費やさなければならないことを意味し、開発者のモチベーションを下げ、フラストレーションを高める
    - 技術的負債が大きい製品は、多才で迅速な人材を遠ざけ、開発をスピードアップし、市場投入までの時間を短縮し、最終的に高品質な製品を生み出す新しい技術の活用を難しくする
    - 技術的負債を解消することは、より良い開発者速度を達成するために不可欠
- Manage Code Branches
    - ブランチサイズや生存期間を短く
- Maintain Traceability
    - 問題が発生したときにそれを追跡する能力に自信がある開発者は、新機能やバグフィックスを迅速にリリースすることをためらうことがなくなる
- Beware Your KPIs
    - KPI は進捗の誤った指標にもなり得る
    - 測定値に過度に依存すると、開発者自身が測定値に向かって努力するようになり、測定値が目標に到達するための道具ではなく、目標になってしまう
    例えば、テストにおけるコードカバレッジは重要ですが、それだけを KPI とすると、コードはカバーするが実際のシナリオはカバーしないナイーブなテストになってしまう可能性がある

データで振り返るエンジニア組織の生産性向上 〜NewsPicks & PR TIMES の事例、DevOps の取り組みからデプロイ頻度の計測まで〜

Findy Teams の指標を使ってチームの生産性を改善しよう - ANDPAD Tech Blogも関連

Findy Teams導入の話。Findy Teamsを利用するかは置いておいても、具体的にどの指標を可視化して、どの指標をどのように改善にしたかの話はかなり参考になるのでこのような情報が発信されるのは非常にありがたい

開発パフォーマンス指標とバリューストリームマップでチーム改善をする - $shibayu36->blog;

バリューストリームマップで改善対象・箇所を洗い出した話。単純に可視化しただけだと具体的に問題箇所まではブレイクダウン出来なかったりするので、開発フローのボトルネックを洗い出す際に使う。
チームでやるべきだけどとりあえず試してみたいので自分一人で一回やってみたい

CircleCI レポートにより、成功したソフトウェアチームがより大規模で、広範囲にテストを実施していることがわかった

CI/CD 周りのメトリクスについて

Balancing Safety and Velocity in CI/CD at Slack - Slack Engineering

slackのCI/CD改善の話。規模大きいと大変だなーという雑感想が最初に浮かんだが、かなり参考になる記事だった。

 - マージ前に全てのE2Eを実行することにより、開発者の生産性指標であるvelocityが悪化
   - Test turnaround time (p95)が常に30分以上
     - エンジニアがコードリポジトリにコミットをプッシュしてから、テスト実行が完了するまでの時間
   - Test flakiness per pull request (PR)が50%以上
     - 同じコードを再実行したときに異なる結果になるようなテストの割合を測定
- マージ前に全てのテストを実行する形から、マージ後に実行する2つのパイプラインを追加
  - プリマージパイプライン
    - 開発時に、E2Eのサブセット(<1%)が実行。PRをメインラインにマージするために必須
    - マージやデプロイをブロックするクリティカル度の高い機能・テストが対象
  - ポストマージパイプライン
    - インラインにマージした後、より多くのE2Eテストのサブセット (<10%) をデプロイ前に実行
      - ミディアムクリティカル
  - リグレッションパイプライン
    - メインラインにマージ後、欠陥のあるテストや欠陥のあるテスト実行フレームワークからの偽陰性シグナルを減らすために残りのE2Eテストを実行
      - 2時間おきに実行

Is Developer Productivity Engineering the Next Big Thing in Software?

そもそもDeveloper Productivityとは?その重要度は?的な話について

上記の他にも読んだもの