和智 右桂 翻訳
和智 右桂 原著
髙木 正弘 翻訳
髙木 正弘 原著
Kenneth S. Rubin 著
岡澤 裕二 翻訳
岡澤 裕二 原著
角 征典 翻訳
角 征典 原著
「スクラムの適用が一番うまくいくのは、関わっている人(深く関わっていない人も含めて)全員が、その本質についてよく理解しているときだ。」と言われます。
本書は「スクラムの全体像と詳細の両方を理想的に概観でき、しかも読みやすい」「次世代のスクラム実践者にとって、基礎文献となるに違いない」と、世界中の名だたるスクラムマスタから絶賛された一冊であり、まさしくスクラムの成功を強力に導ける書籍です。
1.1 スクラムとは何か?
1.2 スクラムの起源
1.3 なぜスクラムなのか?
1.4 ゲノミカ社の顛末
1.5 スクラムは役に立つか?
複雑な領域
込み入った領域
単純な領域
カオスな領域
無秩序
割り込み駆動の作業
1.6 終わりに. .
第I 部コアコンセプト
第2章スクラムフレームワーク2.1 概要
2.2 スクラムの役割
プロダクトオーナー
スクラムマスター
開発チーム
2.3 スクラムのアクティビティと作成物
プロダクトバックログ
スプリント
スプリントプランニング
スプリントの実施
デイリースクラム
完成
スプリントレビュー
スプリントレトロスペクティブ
2.4 終わりに
3.1 概要
3.2 変動性と不確実性
役立つ変動性を受け入れよ
イテレーティブでインクリメンタルな開発を採用せよ
検査、適応、透明性を通じて変動性を活用せよ
あらゆる形の不確実性を同時に削減せよ
3.3 予見と適応
選択肢を広げておく
事前に正しく行うことは不可能だと認める
適応型で探索型のアプローチを好む
経済的に妥当なやり方で変化を受け入れる
予見的な事前の作業と適応型のジャストインタイムの作業とのバランスを取る
3.4 検証による学び
重要な想定をまず検証する
複数の学習ループを並行して活用する
すばやいフィードバックのためのワークフローをまとめる
3.5 仕掛中の作業(WIP)
作業は経済的に妥当なサイズにまとめよ
在庫を認識し、適切な流れで管理せよ
作業者の手待ちではなく、作業の手待ちに注目せよ
遅延コストを考慮せよ
3.6 進捗
リアルタイムの情報に適応して再計画せよ
動作する資産を検証することで進捗を測れ
価値に主眼を置いたデリバリーに集中せよ
3.7 作業効率
すばやく進め、しかし、あわてるな
品質を作り込め
必要最低限の儀式を行え
3.8 終わりに
4.1 概要
4.2 タイムボックス化
WIPに上限を設ける
優先順位付けを強制する
進捗状況を可視化する
不必要な完璧主義を避ける
締めくくりの促進
予測可能性を改善する
4.3 短期間
計画の立てやすさ
すばやいフィードバック
投資収益率の改善
損失の限定化
熱狂を取り戻す
頻繁なチェックポイント
4.4 不変のスプリント期間
一定したリズムの利点
簡潔なプランニング
4.5 ゴールを変えない
スプリントゴールとは?
相互コミットメント
変更と明確化
変更の影響
実利的であるべし
スプリントの中止
4.6 完成の定義
「完成の定義」とは
「完成の定義」は時間と共に改善されていく
「完成の定義」と受け入れ条件
「完成」と「完全に完成」
4.7 終わりに
5.1 概要
5.2 対話する
5.3 改良し続ける
5.4 ユーザーストーリーとは何なのか
カード
対話
確認
5.5 詳細化のレベル
5.6 うまく書けたユーザーストーリーとINVEST
独立している
交渉できる
価値がある
見積もり可能
適切な大きさ(ほどほどに小さく)
テスト可能
5.7 非機能要件
5.8 学習のためのストーリー
5.9 ストーリーの収集
ユーザーストーリー記述ワークショップ
ストーリーマッピング
5.10 終わりに
6.1 概要
6.2 プロダクトバックログアイテム
6.3 よいプロダクトバックログの特徴
適切な詳細度
創発的
見積もり
優先順位付け
6.4 グルーミング
グルーミングとは
誰がグルーミングするのか
いつグルーミングするのか
6.5 準備完了の定義
6.6 フローの管理
リリースフローの管理
スプリントフローの管理
6.7 どんなプロダクトバックログをいくつ用意するか?
プロダクトとは何か
大規模なプロダクト―階層化バックログ
複数チーム―単一のプロダクトバックログ
単一のチーム―複数のプロダクト
6.8 終わりに
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.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.1 概要
10.2 主な責任
コーチ
サーバントリーダー
プロセスの権威者
防御壁
インペディメントの除去
チェンジエージェント
10.3 特性とスキル
博識
質問力
辛抱強い
協力的
保護力
透明性
10.4 一日の様子
10.5 役割を果たす
誰がスクラムマスターになるべきか?
スクラムマスターはフルタイムジョブか?
スクラムマスターを他の役割と組み合わせる
10.6 終わりに
11.1 概要
11.2 役割別のチーム
11.3 主な責任
スプリントの実施
日々の検査と適応
プロダクトバックログのグルーミング
スプリントプランニング
プロダクトとプロセスの検査と適応
11.4 特性とスキル
自己組織化
機能横断的な多様性と十分な能力
T型スキル
銃士の姿勢
広帯域のコミュニケーション
透明なコミュニケーション
適切な規模
集中とコミットメント
持続可能なペースで仕事する
長寿
11.5 終わりに
12.1 概要
12.2 フィーチャーチームかコンポーネントチームか
12.3 複数チーム間での調整
スクラムオブスクラム
リリーストレイン
12.4 終わりに
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.1 概要
15.2 ポートフォリオプランニング
15.3 プロダクトプランニング(エンビジョニング)
ビジョン
概要レベルのプロダクトバックログ
プロダクトのロードマップ
15.4 リリースプランニング
15.5 スプリントプランニング
15.6 デイリープランニング
15.7 終わりに
16.1 概要
タイミング
参加者
プロセス
16.2 スケジューリングの戦略
ライフサイクル収益で最適化する
遅延コストを算出する
見積もるのは正確性であって、精度ではない
16.3 インフローの戦略
経済的フィルターの適用
追加と取り出しのバランスを取る
創発的なチャンスへのすばやい対応
小さめなリリースを頻繁に行うための計画
16.4 アウトフローの戦略
作業者の手待ちではなく、作業の手待ちに注目せよ
WIPを制限する
チーム全員の準備が整うのを待つ
16.5 仕掛品の戦略
限界費用を使う
16.6 終わりに
17.1 概要
タイミング
参加者
プロセス
17.2 SR4Uの例
17.3 ビジョンづくり
17.4 概要レベルのプロダクトバックログの作成
17.5 プロダクトロードマップの定義
17.6 その他のアクティビティ
17.7 経済的に理にかなったエンビジョニング
現実的な信頼の閾値を目指す
注目するのは短期間だけ
すばやく動く
検証による学びに投資する
インクリメンタルに出資する
早めに学んでピボットする(フェイルファースト)
17.8 終わりに
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.1 概要
タイミング
参加者
プロセス
20.2 スプリントプランニング
20.3 フローの管理
並列作業とスウォーミング
どの作業から着手すべきか
どのようにタスクを計画すべきか
どの作業を完了させるべきか
誰が作業をするのか
20.4 デイリースクラム
20.5 タスクの実行(技術的プラクティス)
内容についてのお問い合わせは、正誤表、追加情報をご確認後に、お送りいただくようお願いいたします。
正誤表、追加情報に掲載されていない書籍内容へのお問い合わせや
その他書籍に関するお問い合わせは、書籍のお問い合わせフォームからお送りください。
本書の書影(表紙画像)をご利用になりたい場合は書影許諾申請フォームから申請をお願いいたします。
書影(表紙画像)以外のご利用については、こちらからお問い合わせください。
刷数は奥付(書籍の最終ページ)に記載されています。
書籍の種類:
書籍の刷数:
本書に誤りまたは不十分な記述がありました。下記のとおり訂正し、お詫び申し上げます。
対象の書籍は正誤表がありません。
発生刷 | ページ数 | 書籍改訂刷 | 電子書籍訂正 | 内容 | 登録日 | ||||||
---|---|---|---|---|---|---|---|---|---|---|---|
1刷 | 241 14.8の3行目 |
2刷 | 済 |
|
2014.07.22 |
disktnk さん
2015-03-21
バックログとかデイリースクラムといった手法の解説や、スクラムマスターやプロダクトオーナーといったメンバーの役割の解説など、スクラムに必要な知識はほぼ全て詰め込まれている。また、チームが採用した各スクラム手法は結果として同じであっても、自己組織化していくまでのプロセスは十人十色であり、そのプロセスの大切さを繰り返し説いている。スクラム参考書として最適だと思った。訳もこなれていて読みやすい。
ふらく さん
2015-03-09
スクラムのバイブル。とりあえずでスクラムを含むアジャイル開発を始めてしまった結果失敗し、二度とアジャイル開発では行わないと思う前に読んでください。これを読み、学習する事で随分マシになります。なんとなくで始めると失敗します。←本当にあった話(笑…えない
Arata Fujimura さん
2014-08-05
スクラムを実践する上で非常に有益な内容だった。何度も読み返したい。