開発効率が高いエンジニアを真似することから始めるエンジニア組織の改善サイクルに参加しました。オンライン開催。簡単に所感をまとめます。
所感
PR を目標設定の指標にしている模様。PR から個人の活動がここまで分析できるのは興味深い...！「途中のコードでもプロダクションコードに混ぜることを許容する文化」はちゃんとテストがあるからこそ実現できるものなのかもしれない。
タスクの細分化を徹底しているようで、おそらく作業着手する前にしっかりプランニングしているんだと思う。自分のチームでも PR をいくつかに分けて出してくれるひともいるけど、このあたりは個人の裁量になってしまっているのでチームの中で仕組み化できるとよさそう。PR を小さくするとレビューしやすくていい。Files changed 100 over とか来るとツラい...。
一応、スクラムで開発しているけどちゃんとベロシティ計測できてないのでなんとかしないとなぁ...。
以下、メモから抜粋。
- 開発アクティビティ可視化
- いかにベロシティを最大化するか
- チームによって性格が違う
- 課題解決型チーム
- 事業目標推進型チーム
- プルリク作成数
- リードタイム (マージするまでの時間)
- Four Keys
- デプロイ頻度
- リードタイム
- 変更障害率
- 平均修復時間
- 課題
- リリース作業が煩雑
- デプロイに時間がかかる (30分〜1時間)
- 切り戻しにも時間がかかる
- ジョブ実行中にデプロイできない
- リリース前 QA の負荷が高い
- リリース自動化
- インフラ構成変更 (デプロイ時間短縮)
- 自動テスト
- E2E テスト/UI差分検知
- 検証環境の取り合い
- ブランチごとに検証環境を作成したい
- E2E テストで品質担保
- リリース頻度が増えたことでリリース内容が共有できないこともあったり
- 目標管理/育成
- PR 数
- 最初のコミットから PR 作成までの平均時間
- PRに対する平均コメント数
- コメントで仕様すり合わせしていないか
- 事前に口頭で話した方が早くないか
- 定点観測
- メンバー参画直後は一時的に数値が低下する
- 2-3週間で戻るなら問題なし
- メンバー参画直後は一時的に数値が低下する
- 1つの PR は数時間で終わる粒度で分解する
- リファクタリングは別 PR にする
- リファクタリングも成果に表れるのでいい
- 既存に影響がない PR はどんどんマージする
- issue ベース
- タスクを細分化する
- PR はタスクごと
- PR の詳細はタスクを見れば分かるように
- 自動テスト
- 途中のコードでもプロダクションコードに混ぜることを許容する文化
