読みました。アジャイル開発やスクラム開発をしている時に取り入れると良いプラクティスを大量に知ることができて良かった。
印象に残ったのは以下の項目。数字はkindle location
- スクラムの基本は、最も端的にスクラムをどうやるかを理解できる形になっていて良かった 912
- スクラムを成功させるには、「有能なプロダクトオーナーを割り当てる」「バックログリファインメントを行う」「ストーリーを小さく保つ」「デイリースクラムを毎日行う」「スプリント期間は1~3週」「作業をバーティカルスライスにまとめる」「テスト・テスト技術者・品質保証を開発チームに組み入れる」、「完成の定義の明確化」「各スプリントでリリース可能な品質水準を達成する」「毎スプリントでレトロスペクティブ」「レトロスペクティブからの学びを活かす」「有能なスクラムマスターを割り当てる」
- 仕事のできる職能横断的チームには、スキル以外に、拘束力のある決定を下す能力と権限の両方が必要 1350
- 決定を下す能力 = チームに効果的な意思決定を行うのに必要な専門知識が全て揃っている
- 決定を下す権限 = 組織の他の誰かが覆すことができない決定を下す能力。重要なステークホルダーがチームに参加している
- 基本原則：成長マインドセットを培う
- プロジェクトの目的は、動くソフトウェアを作るだけじゃなく、ソフトウェアを作るチームの能力を向上させることもある
- 銀の弾丸に近いソフトウェアプラクティスは、1人1人の開発者が実際の顧客であるシステムの実際のユーザーと定期的に直接交流する 1645
- ただし1回限りの体験では、その時に目撃したユーザーに開発者が固執する場合があるので、定期的に行うことが重要
- 技術的負債の分類法 2413
- 意図的な技術的負債（短期）：たとえば、時間的制約のあるリリースを期限までにデプロイするなど
- 意図的な技術的負債（長期）：たとえば、最初からマルチプラットフォーム対応の設計と構築を行うのではなく、最初は1つのプラットフォームだけをサポート
- 不慮の技術的負債（悪意）：いい加減なソフトウェア開発の習慣のせいで意図せずに発生する技術的負債
- 不慮の技術的負債（善意）：ソフトウェア開発がエラーと隣り合わせの性質であるために意図せずに発生する技術的負債。たとえば「私たちの設計アプローチは思っていたほどうまくいかなかった」「プラットフォームの新しいバージョンのせいで設計の重要な部分が無効になってしまった」
- レガシーな技術的負債：新しいチームに引き継がれた古いコードベースの技術的負債
- チーム間で意味のある生産性の比較は、チームの生産性の向上率 4089
