『エッセンシャルスクラム』

https://gyazo.com/f6c787fea9f7e10c6f608ba7eb1aac20

第1章イントロダクション

1.1 スクラムとは何か？

1.2 スクラムの起源

1.3 なぜスクラムなのか？

1.4 ゲノミカ社の顛末

1.5 スクラムは役に立つか？

複雑な領域

込み入った領域

単純な領域

カオスな領域

無秩序

割り込み駆動の作業

1.6 終わりに. .

第I 部コアコンセプト

第2章スクラムフレームワーク

2.1 概要

2.2 スクラムの役割

プロダクトオーナー

スクラムマスター

開発チーム

2.3 スクラムのアクティビティと作成物

[プロダクトバックログ

スプリント

スプリントプランニング

スプリントの実施

デイリースクラム

完成

スプリントレビュー

スプリントレトロスペクティブ

2.4 終わりに

第3章アジャイルの原則

3.1 概要

3.2 変動性と不確実性

役立つ変動性を受け入れよ

イテレーティブでインクリメンタルな開発を採用せよ

検査、適応、透明性を通じて変動性を活用せよ

あらゆる形の不確実性を同時に削減せよ

3.3 予見と適応

選択肢を広げておく

事前に正しく行うことは不可能だと認める

適応型で探索型のアプローチを好む

経済的に妥当なやり方で変化を受け入れる

予見的な事前の作業と適応型のジャストインタイムの作業とのバランスを取る

3.4 検証による学び

重要な想定をまず検証する

複数の学習ループを並行して活用する

すばやいフィードバックのためのワークフローをまとめる

3.5 仕掛中の作業（WIP）

作業は経済的に妥当なサイズにまとめよ

在庫を認識し、適切な流れで管理せよ

作業者の手待ちではなく、作業の手待ちに注目せよ

遅延コストを考慮せよ

3.6 進捗

リアルタイムの情報に適応して再計画せよ

動作する資産を検証することで進捗を測れ

価値に主眼を置いたデリバリーに集中せよ

3.7 作業効率

すばやく進め、しかし、あわてるな

品質を作り込め

必要最低限の儀式を行え

3.8 終わりに

第4章スプリント

4.1 概要

4.2 タイムボックス化

WIPに上限を設ける

優先順位付けを強制する

進捗状況を可視化する

不必要な完璧主義を避ける

締めくくりの促進

予測可能性を改善する

4.3 短期間

計画の立てやすさ

すばやいフィードバック

投資収益率の改善

損失の限定化

熱狂を取り戻す

頻繁なチェックポイント

4.4 不変のスプリント期間

一定したリズムの利点

簡潔なプランニング

4.5 ゴールを変えない

スプリントゴールとは？

相互コミットメント

変更と明確化

変更の影響

実利的であるべし

スプリントの中止

「完成の定義」とは

「完成の定義」は時間と共に改善されていく

「完成の定義」と受け入れ条件

「完成」と「完全に完成」

4.7 終わりに

5.1 概要

5.2 対話する

5.3 改良し続ける

5.4 ユーザーストーリーとは何なのか

カード

対話

確認

5.5 詳細化のレベル

5.6 うまく書けたユーザーストーリーとINVEST

独立している

交渉できる

価値がある

見積もり可能

適切な大きさ（ほどほどに小さく）

テスト可能

5.7 非機能要件

5.8 学習のためのストーリー

5.9 ストーリーの収集

ユーザーストーリー記述ワークショップ

ストーリーマッピング

5.10 終わりに

第6章 プロダクトバックログ

6.1 概要

6.3 よいプロダクトバックログの特徴

適切な詳細度

創発的

見積もり

優先順位付け

6.4 グルーミング

グルーミングとは

誰がグルーミングするのか

いつグルーミングするのか

6.5 準備完了の定義

6.6 フローの管理

リリースフローの管理

スプリントフローの管理

6.7 どんなプロダクトバックログをいくつ用意するか？

プロダクトとは何か

大規模なプロダクト―階層化バックログ

複数チーム―単一のプロダクトバックログ

単一のチーム―複数のプロダクト

6.8 終わりに

第7章見積もりとベロシティ

7.1 概要

7.2 いつ何を見積もるのか

ポートフォリオバックログの見積もり

プロダクトバックログの見積もり

タスクの見積もり

7.3 PBIの見積もりの考え方

チームで見積もる

見積もりはコミットメントではない

正確性か精度か

相対サイズの見積もり

7.4 PBIの見積もりの単位

ストーリーポイント

理想日

7.5 プランニングポーカー

見積もりの尺度

やってみよう

メリット

7.6 ベロシティとは

7.7 ベロシティの幅の算出

7.8 ベロシティの予想

7.9 ベロシティへの影響

7.10 ベロシティの誤用

7.11 終わりに

第8章技術的負債

8.1 概要

8.2 技術的負債の行く末

予測不可能な臨界

デリバリーに要する時間の長期化

不具合の多発

開発およびサポートのコストの増加

プロダクトの退化

予測可能性の減少

伸び悩み

募る不満

顧客満足度の減少

8.3 技術的負債を生む要因

納期を守るためのプレッシャー

ベロシティの偽装

テストを減らせばベロシティが向上するという神話

負債が生む新たな負債

8.4 技術的負債の管理

8.5 技術的負債の発生の管理

優れた技術的プラクティスの活用

厳しい完成の定義の使用

技術的負債の経済的意味についての適切な認識

8.6 技術的負債の可視化

ビジネスレベルでの技術的負債の可視化

技術者レベルでの技術的負債の可視化

8.7 技術的負債の返済

すべての技術的負債を返済すべきというわけではない

ボーイスカウトルールに従う（負債を見つけたらその場で返済する）

技術的負債の返済はインクリメンタルに

金利の高い技術的負債から返済する

技術的負債を返済しながら顧客に価値をもたらす作業も行う

8.8 終わりに

第II 部役割

第9章プロダクトオーナー

9.1 概要

9.2 主な責任

経済性の管理

プランニングへの参加

プロダクトバックログのグルーミング

受け入れ条件の定義と検証

開発チームとの協力

ステークホルダーとの協力

9.3 特性とスキル

ドメインスキル

対人スキル

意思決定力

説明責任力

9.4 一日の様子

9.5 誰がプロダクトオーナーになるべきか？

社内開発

商用開発

外部委託開発

コンポーネント開発

9.6 その他の役割との組み合わせ

9.7 プロダクトオーナーチーム

プロダクトオーナープロキシ

チーフプロダクトオーナー

9.8 終わりに

第10章スクラムマスター

10.1 概要

10.2 主な責任

コーチ

サーバントリーダー

プロセスの権威者

防御壁

インペディメントの除去

チェンジエージェント

10.3 特性とスキル

博識

質問力

辛抱強い

協力的

保護力

透明性

10.4 一日の様子

10.5 役割を果たす

誰がスクラムマスターになるべきか？

スクラムマスターはフルタイムジョブか？

スクラムマスターを他の役割と組み合わせる

10.6 終わりに

第11章開発チーム

11.1 概要

11.2 役割別のチーム

11.3 主な責任

スプリントの実施

日々の検査と適応

プロダクトバックログのグルーミング

スプリントプランニング

プロダクトとプロセスの検査と適応

11.4 特性とスキル

自己組織化

機能横断的な多様性と十分な能力

T型スキル

銃士の姿勢

広帯域のコミュニケーション

透明なコミュニケーション

適切な規模

集中とコミットメント

持続可能なペースで仕事する

長寿

11.5 終わりに

第12章スクラムチームの構成

12.1 概要

12.2 フィーチャーチームかコンポーネントチームか

12.3 複数チーム間での調整

スクラムオブスクラム

リリーストレイン

12.4 終わりに

第13章マネージャー

13.1 概要

13.2 チームを編成する

境界を定める

明確なゴールを定める

チームの体制を決める

チームの構成を変更する

チームに権限を持たせる

13.3 チームを育てる

チームを活気づける

能力を伸ばす

機能エリアのリーダーシップを発揮する

チームの安定を保つ

13.4 環境を合わせてなじませる

アジャイルの価値を広める

組織内のインペディメントを取り除く

社内調整

対外調整

13.5 価値創造の流れを作る

全体的な視点で考える

財政の管理

評価や報告の管理

13.6 プロジェクトマネージャー

スクラムチームにおけるプロジェクト管理の責務

プロジェクトマネージャーの役割を残す

13.7 終わりに

第III 部プランニング

第14章スクラムのプランニングの原則

14.1 概要

14.2 事前にきちんと計画を作れると思うな

14.3 事前のプランニングのやりすぎに注意

14.4 プランニングの選択肢は、最終責任時点まで変更可能にする

14.5 計画を守ることよりも、計画の調整や再計画を重視する

14.6 計画の一覧をきちんと管理する

14.7 早めにリリース、頻繁にリリース

14.8 早めに学び、必要ならピボットする

14.9 終わりに

第15章さまざまなレベルでのプランニング

15.1 概要

15.2 ポートフォリオプランニング

15.3 プロダクトプランニング（エンビジョニング）

ビジョン

概要レベルのプロダクトバックログ

プロダクトのロードマップ

15.4 リリースプランニング

15.5 スプリントプランニング

15.6 デイリープランニング

15.7 終わりに

第16章ポートフォリオプランニング

16.1 概要

タイミング

参加者

プロセス

16.2 スケジューリングの戦略

ライフサイクル収益で最適化する

遅延コストを算出する

見積もるのは正確性であって、精度ではない

16.3 インフローの戦略

経済的フィルターの適用

追加と取り出しのバランスを取る

創発的なチャンスへのすばやい対応

小さめなリリースを頻繁に行うための計画

16.4 アウトフローの戦略

作業者の手待ちではなく、作業の手待ちに注目せよ

WIPを制限する

チーム全員の準備が整うのを待つ

16.5 仕掛品の戦略

限界費用を使う

16.6 終わりに

第17章エンビジョニング（プロダクトプランニング）

17.1 概要

タイミング

参加者

プロセス

17.2 SR4Uの例

17.3 ビジョンづくり

17.4 概要レベルのプロダクトバックログの作成

17.5 プロダクトロードマップの定義

17.6 その他のアクティビティ

17.7 経済的に理にかなったエンビジョニング

現実的な信頼の閾値を目指す

注目するのは短期間だけ

すばやく動く

検証による学びに投資する

インクリメンタルに出資する

早めに学んでピボットする（フェイルファースト）

17.8 終わりに

第18章リリースプランニング（長期計画）

18.1 概要

タイミング

参加者

プロセス

18.2 リリース制約

すべてを固定

スコープと期日を固定

スコープを固定

期日を固定

品質を可変に

制約の見直し

18.3 プロダクトバックログのグルーミング

18.4 リリース可能な最小限のフィーチャー（MRF）の見直し

18.5 スプリントマッピング（PBIの割り当て）

18.6 固定期日のリリースプランニング

18.7 固定スコープのリリースプランニング

18.8 コストの算出

18.9 コミュニケーション

固定スコープのリリースにおける進捗の把握

固定期日のリリースにおける進捗の把握

18.10 終わりに

第IV 部スプリント

第19章スプリントプランニング

19.1 概要

タイミング

参加者

プロセス

19.2 スプリントプランニングの手法

二部構成のスプリントプランニング

一部構成のスプリントプランニング

19.3 キャパシティの決定

キャパシティとは？

ストーリーポイントを使ったキャパシティ

作業時間を使ったキャパシティ

19.4 プロダクトバックログアイテムの選択

19.5 自信の獲得

19.6 スプリントゴールの洗練

19.7 コミットメントの最終決定

19.8 終わりに

第20章スプリントの実施

20.1 概要

タイミング

参加者

プロセス

20.2 スプリントプランニング

20.3 フローの管理

どの作業から着手すべきか

どのようにタスクを計画すべきか

どの作業を完了させるべきか

誰が作業をするのか

20.4 デイリースクラム

20.5 タスクの実行（技術的プラクティス）