アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる１４のベストプラクティス

■ 第1部　ソフトウェアアジリティの概要
第1章アジャイルメゾットの概要
1.1　ソフトウェアエコノミーでの競争力
　　　　1.1.1　ソフトウェア開発メゾットは業界とともに進化してきた
1.2　アジャイルメゾットへの入り口
1.3　アジャイルスケールアップ
1.4　メゾットの概要
　　　　1.4.1　アジャイルマニフェスト
1.5　アジャイル適用のトレンド
1.6　ソフトウェアアジリティのビジネス上のメリット
　　　　1.6.1　生産性の向上
　　　　1.6.2　品質の向上
　　　　1.6.3　チームの士気と満足度の向上
　　　　1.6.4　タイムツーマーケットの向上
1.7.　XP、スクラム、RUPの概観
　　　　1.7.1　エクストリームプログラミング（XP）
　　　　1.7.2　スクラム（Scrum）
　　　　1.7.3　ラショナル統一プロセス（RUP）
1.8　まとめ

第2章　なぜウォーターフォールは正常に機能しないのか？
2.1　ウォーターフォールモデルの問題
2.2　ウォーターフォールの仮説
2.3　アジャイルメゾットを使用した修正

第3章　XPの本質
3.1　XPとは何か？
3.2　XPの何がそれほど議論の的となっているのか？
3.3　XPの何がそれほど過激（エクストリーム）なのか？
3.4　XPの基礎的な理念
3.5　XPの価値、原則、そしてプラクティス
　　　　3.5.1　XPの5つの中核的な価値
　　　　3.5.2　基本原則
　　　　3.5.3　XPにおける鍵となる12のプラクティス
　　　　3.5.4　ペアプログラミングについての覚書
3.6　XPのためのプロセスモデル
3.7　XPの適用可能性
3.8　推奨する読み物

第4章　スクラムの本質
4.1　スクラムとは何か？
4.2　スクラムにおける役割定義
4.3　スクラム哲学のルーツ
4.4　スクラムの価値、原則、そしてプラクティス
4.5　スクラムの主要なプラクティス
4.6　スクラムの基本原則：経験に基づいたプロセスのコントロール
4.7　スクラムのプロセスモデル
4.8　スクラムと組織的な変革
4.9　この方法論の適用可能性
4.10　推奨する読み物

第5章　RUPの本質
5.1　RUPとは何か？
5.2　RUPの重要な特徴
5.3　RUPの起源
　　　　5.3.1　RUPの原則およびプラクティス
　　　　5.3.2　反復：RUPの基本理念
　　　　5.3.3　アーキテクチャ駆動とユースケース中心
　　　　5.3.4　RUPのプロセスモデル
　　　　5.3.5　時間軸
　　　　5.3.6　作業分野軸
　　　　5.3.7　RUPのライフサイクルの反復タイプ
5.4　アジャイルとしてのRUPのバリエーション
　　　　5.4.1　オープン統一プロセス（Open Unified Process：OpenUP）
　　　　5.4.2　アジャイル統一プロセス（Agile Unified Process）
　　　　5.4.3　メゾットの適用性
5.5　推奨する読み物

第6章　リーンソフトウェア、DSDM、FDD
6.1　リーンソフトウェア開発
　　　　6.1.1　リーンソフトウェア開発に関する推奨する読み物
6.2　ダイナミックシステム開発メゾット（DSDM）
　　　　6.2.1　背景
　　　　6.2.2　DSDMの基本的な理念
　　　　6.2.3　DSDMの中核プラクティス
　　　　6.2.4　DSDMへのアクセス
6.3　フィーチャー駆動開発（FDD）
　　　　6.3.1　FDDのベストプラクティス

第7章　アジャイルの本質
7.1　アジャイルの本質で何を変えようとしているのか？
　　　　7.1.1　新たな成功の指標
　　　　7.1.2　管理に対する文化の違い
　　　　7.1.3　要求、アーキテクテャ、設計へのアプローチの違い
　　　　7.1.4　コーディングと実装プラクティスの違い
　　　　7.1.5　テスト品質保証（QA）プラクティスの変化
　　　　7.1.6　計画作りとスケジュール管理の新たな方法
　　　　7.1.7　最も大きな変化―スコープ対スケジュールは、スケジュールの勝利！
7.2　アジャイルのハートビート：短いタイムボックスにおける正常に動くコード
　　　　7.2.1　タイムボックス内で作業する
　　　　7.2.2　小さい一口大のチャンク単位で開発する
7.3　まとめ

第8章　アジャイルのスケールアップに挑む
8.1　メゾット自体に存在する明らかな阻害要因
　　　　8.1.1　小さなチーム
　　　　8.1.2　顧客の巻き込み
　　　　8.1.3　同一地点
　　　　8.1.4　自然発生するアーキテクチャ
　　　　8.1.5　要求分析と仕様文書の欠落
　　　　8.1.6　文化的環境と物理的環境
8.2　企業における阻害要因
　　　　8.2.1　プロセスマネージメントとプロジェクトマネージメントの組織
　　　　8.2.2　既存のフォーマルなポリシーとプロジャージャ
　　　　8.2.3　企業文化
　　　　8.2.4　固定期間内に特定機能を出荷しろという命令
　　　　8.2.5　開発組織と、ユーザー・顧客代表チームの摩擦
　　　　8.2.6　プロダクトラインではなく職務で組織が分けられる
　　　　8.2.7　地理的に分散化が進む
8.3　まとめ

■ 第2部　スケールアップ可能な7つのプラクティス
第9章　定義/ビルド/テストコンポーネントチーム
9.1　定義/ビルド/テストコンポーネントチームとは何か？
　　　　9.1.1　簡単なストーリーのライフサイクル
9.2　サイロ化した職務別部門を取り除く
9.3　アジャイルコンポーネントチームの役割と責任
9.4　自己組織化、自己管理する
　　　　9.4.1　定義/ビルド/テストコンポーネントチームを作る
　　　　9.4.2　チーム（バス）の中に適切な人を揃えている
　　　　9.4.3　管理されているのではなくリードされている
　　　　9.4.4　ミッションを理解している
　　　　9.4.5　継続的にコミュニケーションしコラボレーションする
　　　　9.4.6　結果に対して説明責任を持つ
9.5　分散したチーム

第10章　2レベル計画作りと追跡

10.1　一般化したアジャイルフレームワーク
　　　　10.1.1　反復を定義する
　　　　10.1.2　反復の解剖学
　　　　10.1.3　リリースの定義
　　　　10.1.4　リリースを解剖する
　　　　10.1.5　リリースを計画する
　　　　10.1.6　要求をリリースに割り振る
　　　　10.1.7　リリース計画
10.2　まとめ：2レベル計画作り

第11章　反復型開発の習得
11.1　反復：アジリティのハートビート
11.2　標準的な2週間の反復
11.3　反復計画と実行
11.4　反復計画作り
　　　　11.4.1　反復計画ミーティングの準備
　　　　11.4.2　参加者
　　　　11.4.3　反復計画ミーティング
　　　　11.4.4　結果：反復計画
　　　　11.4.5　追加の反復計画ガイドライン
　　　　11.4.6　分散チームにおける反復計画作り
11.5　反復の実行
　　　　11.5.1　責任を負う
　　　　11.5.2　開発
　　　　11.5.3　ストーリーの提供
　　　　11.5.4　ストーリーの完了の宣言
　　　　11.5.5　反復を受け入れる
11.6　反復の追跡と調整
　　　　11.6.1　デイリースタンドアップミーティングでの追跡
　　　　11.6.2　デイリースタンドアップミーティングのガイドライン
　　　　11.6.3　反復のステータスを追跡する
　　　　11.6.4　バーンダウンチャートで追跡
11.7　反復のケイデンスカレンダー

第12章　頻繁な小規模リリース
12.1　小さなリリースの利点
12.2　リリースを定義し、スケジュールする
　　　　12.2.1　スケジュール駆動リリース
　　　　12.2.2　最も単純なモデル：固定され、周期的なリリース
　　　　12.2.3　フィーチャセットの見積り
12.3　リリースを計画する
　　　　12.3.1　参加者
　　　　12.3.2　準備
　　　　12.3.3　リリース計画のプロセス
　　　　12.3.4　結果：リリース計画
　　　　12.3.5　リリース計画の補足
12.4　リリースの追跡
　　　　12.4.1　リリースステータスレビューへの準備
　　　　12.4.2　リリースステータスレビューミーティング
　　　　12.4.3　成果物および文書
12.5　リリースロードマップ
12.6　アジリティのスケールアップレビュー：大規模案件でのリリース計画と追跡
　　　　12.6.1　アジャイルをスケールアップするために、組織を編成する
　　　　12.6.2　複数チームにおけるリリース計画作り
　　　　12.6.3　リリース追跡

第13章　コンカレントテスティング
13.1　アジャイルテスト入門
　　　　13.1.1　本質的にテスト可能なシステムの構築
13.2　アジャイルテストの原則
13.3　単体テスト
　　　　13.3.1　反復の繰り返しの中での単体テスト
　　　　13.3.2　単体テストとテスト駆動開発
13.4　受入テスト
　　　　13.4.1　自動化された受入テストの例：FITアプローチ
13.5　コンポーネントテスト
13.6　システムテストとオアフォーマンステスト
13.7　まとめ：アジャイルテスト戦略の要約
　　　　13.7.1　反復とリリーステストのパターン

第14章　継続的インテグレーション
14.1　継続的インテグレーションとは？
　　　　14.1.1　非継続的インテグレーション：何が問題なのか？
14.2　継続的インテグレーション
14.3　継続的インテグレーションへの3つのステップ
　　　　14.3.1　ソースコード統合
　　　　14.3.2　自動化されたビルド管理
　　　　14.3.3　自動化された検証テスト
14.4　継続的インテグレーションの成功とは？

第15章　継続的な考察と適応
15.1　反復ふりかえり
　　　　15.1.1　反復ふりかえりの形成
　　　　15.1.2　定量的評価
　　　　15.1.3　定性的評価
　　　　15.1.4　アクションの呼びかけ
15.2　リリースふりかえり
　　　　15.2.1　定量的評価
　　　　15.2.2　定性的評価
　　　　15.2.3　リリースふりかえりによる組織の問題の表面化

第3部　アジャイルな企業を作る
第16章　意図的なアーキテクチャ
16.1　ソフトウェアアーキテクチャとは何か？
16.2　アジャイルとアーキテクチャ
　　　　16.2.1　エクストリームプログラミング：アーキテクチャは現れ出る
　　　　16.2.2　スクラム
　　　　16.2.3　FDDにおけるアーキテクチャ
　　　　16.2.4　RUP：アーキテクチャ中心
16.3　リファクタリングと大規模システム
16.4　何を構築しているのか？
16.5　企業レベルのシステムのためのアジャイルなアーキテクチャアプローチ
　　　　16.5.1　コンポーネントベースのシステム：組織はアーキテクチャに従う
16.6　アーキテクチャ助走路の構築
　　　　16.6.1　アーキテクチャの壊れやすく一時的な性質
　　　　16.6.2　アーキテクチャ助走路の延長
　　　　16.6.3　プロダクトバックログを利用したリファクタリング
　　　　16.6.4　アーキテクチャ助走路を延長する：反復と同期する
　　　　16.6.5　アーキテクチャ助走路の延長：リーン、ブル型のアプローチ

第17章　リーン開発要求のスケールアップ：ビジョン、ロードマップ、およびジャストインタイムの詳細化
ジャストインタイムの詳細化
17.1　概要：要求ピラミッド
　　　　17.1.1　ステークホルダーのニーズ
　　　　17.1.2　ソリューションフィーチャ
　　　　17.1.3　ソフトウェア要求
　　　　17.1.4　従来の要求開発のアプローチ
17.2　アジャイルにおける要求開発とは何が違うのだろうか？
　　　　17.2.1　XPにおける要求開発
　　　　17.2.2　スクラム、プロダクトオーナー、そしてプロダクトバックログ
　　　　17.2.3　RUPにおける要求定義
17.3　スケーラブルで、アジャイルな要求開発のアプローチ：ビジョン、ロードマップ、そしてジャストインタイムの詳細化
　　　　17.3.1　ビジョンがなくてはならない
　　　　17.3.2　ロードマップ
　　　　17.3.3　ジャストインタイムの詳細化
　　　　17.3.4　ユーザーストーリーによる詳細化
　　　　17.3.5　ユースケースを用いた詳細化
　　　　17.3.6　受入テストケースの詳細化
17.4　まとめ

第18章　システムオブシステムとアジャイルリリーストレイン
18.1　アジャイルコンポーネントのリリーススケジュール
　　　　18.1.1　アジャイルリリーストレインを導く教訓
　　　　18.1.2　アジャイルリリーストレインの原則
18.2　アジャイルリリーストレイン
　　　　18.2.1　リリーストレインは同期している
　　　　18.2.2　トレインはビジョン、テーマ、そしてエンドツーエンドのユースケースによって走る
　　　　18.2.3　リリーストレインを順調に、遅れないように保つ
　　　　18.2.4　進行方向とベロシティを計画する
　　　　18.2.5　システムレベルのパターンの観察
　　　　18.2.6　相互依存の管理
　　　　18.3リリーストレインについてのふりかえり

第19章　高度に分散した開発の管理
19.1　大規模になると、すへてのアジャイル開発は分散開発である
19.2　ケーススタディ1：Ping Identity―分散した定義/ビルド/テストコンポーネントチーム
　　　　19.2.1　Ping Identity Corporation事例の背景
　　　　19.2.2　その他の学んだこと
19.3　ケーススタディ2：BMC Software,Inc.―大規模で分散している企業におけるアジャイルへの組織変革
　　　　19.3.1　背景
　　　　19.3.2　IMDにおけるアジャイルへの動き
　　　　19.3.3　結果
　　　　19.3.4　パイロットからプログラムへ：大規模でアジャイルを適応する
　　　　19.3.5　学んだこと：大きな組織でアジャイルプラクティスをスケールアップすること
　　　　19.3.6　次のステップ：初年度のアジャイル適用が成功した後に
19.4　コミュニケーションを強調する
　　　　19.4.1　定期訪問
　　　　19.4.2　コミュニケーションのインフラ
19.5　企業アジリティのためのツールのインフラ
　　　　19.5.1　ソースコード管理
　　　　19.5.2　ネットワークのインフラ
　　　　19.5.3　早い反復でインフラを確立する
19.6　まとめ

第20章　顧客とオペレーションへのインパクトの調整
20.1　セールスとマーケティング組織にとってのアジャイルメゾットの恩恵
20.2　製品マーケティングと製品マネージメントへのインパクト
20.3　より小さくより頻繁なリリース
　　　　20.3.1　より小さくより頻繁なリリースの課題
20.4　アジャイルリリースプロセスの最適化
　　　　20.4.1　リリースオプション1：アジャイルを無視する
　　　　20.4.2　オプション2：アジャイルを追い求める
　　　　20.4.3　オプション3：開発リリースと外部リリースを分割することによる最適化
　　　　20.5セールスとマーケティングのエグゼクティブの視点からのアジリティに関する課題と思い違い

第21章　組織を変化させる
21.1　概要
21.2　なぜアジャイルは組織の変化を必要とするのか？
　　　　21.2.1　経験的なプロセス対計画的なプロセスの適用
　　　　21.2.2　スクラムの禅：邪魔を取り除いた時、チームは仕事をする
　　　　21.2.3　スクラムの禅：場
　　　　21.2.4　行ってみよう：予測しにくくなるがより良い結果が得られる
21.3　スクラムとアジリティに備える
　　　　21.3.1　ソフトウェエアプロセスと組織の両方を「スクラム」化する
　　　　21.3.2　組織の変化のためのスクラムマスターとしての、エグゼクティブのスポンサーシップ
　　　　21.3.3　注意：変化はきつい仕事である
21.4　ソフトウェアの生産性の阻害要因を排除する
21.5　エグゼクティブのためのアジャイルモデルの展開
　　　　21.5.1　アジャイル適用のスポンサーを務める
　　　　21.5.2　エグゼクティブのマネジメントプラクティスとしてのアジャイル
21.6　大規模組織におけるスクラムおよびアジャイルの展開
　　　　21.6.1　概観、評価、そしてパイロットの準備
　　　　21.6.2　パイロットプロジェクト
　　　　21.6.3　組織への展開
　　　　21.6.4　達成による影響
　　　　21.6.5　計測、評価および調整
　　　　21.6.6　拡張と成功
21.7　まとめ

第22章　ビジネスパフォーマンスを計測する
22.1　アジャイル計測：キーとなる違い
22.2　チームのパフォーマンスを計測する
　　　　22.2.1　アジャイルプロジェクト指標
　　　　22.2.2　アジャイルプロセス指標
　　　　22.2.3　結果を評価する
22.3　指標における「プロセス警察」とチームセルフアセスメント
22.4　組織パフォーマンスのスケールアップ：バランスコアカードのアプローチ
　　　　22.4.1　効率
　　　　22.4.2　品質
　　　　22.4.3　価値提供
　　　　22.4.4　アジリティ
22.5　アジャイル指標のスケールアップ：柔軟で自動化された企業レベルで意味のあるBSCの実装
　　　　22.5.1　ステップ1：BSCマトリクス要素の定量化
　　　　22.5.2　ステップ2：アルファベット文字のグレードへ変換
　　　　22.5.3　ステップ3：プロダクトライン、ビジネスユニット、および企業で集約する
結論：アジリティはスケールアップ可能である

参考文献
索引
監訳者あとがき
訳者からのメッセージ

お問い合わせ

内容についてのお問い合わせは、正誤表、追加情報をご確認後に、お送りいただくようお願いいたします。

正誤表、追加情報に掲載されていない書籍内容へのお問い合わせや
その他書籍に関するお問い合わせは、書籍のお問い合わせフォームからお送りください。

利用許諾に関するお問い合わせ

本書の書影（表紙画像）をご利用になりたい場合は書影許諾申請フォームから申請をお願いいたします。
書影（表紙画像）以外のご利用については、こちらからお問い合わせください。