『エクストリームプログラミング』
https://gyazo.com/9a48c7897c6fca6b3443cf10d6aaeaaf
推薦の言葉
日本語版の推薦の言葉
XPシリーズについて
第2版への序文
第1版への序文
はじめに
第1章 XPとは何か
第I部 XPの探求
第2章 運転を学ぶ
第3章 価値、原則、プラクティス
第4章 価値
4.1 コミュニケーション(Communication)
4.3 フィードバック(Feedback)
4.4 勇気(Courage)
4.5 リスペクト(Respect)
4.6 その他の価値
第5章 原則
5.2 経済性(Economics)
5.3 相互利益(Mutual Benefit)
5.4 自己相似性(Self-Similarity)
5.5 改善(Improvement)
5.6 多様性(Diversity)
5.8 流れ(Flow)
5.9 機会(Opportunity)
5.10 冗長性(Redundancy)
5.11 失敗(Failure)
5.12 品質(Quality)
5.13 ベイビーステップ(Baby Steps)
5.14 責任の引き受け(Accepted Responsibility)
5.15 結論
第6章 プラクティス
第7章 主要プラクティス
7.1 全員同席(Sit Together)
7.2 チーム全体(Whole Team)
7.3 情報満載のワークスペース(Informative Workspace)
7.4 いきいきとした仕事(Energized Work)
7.6 ストーリー(Stories)
7.7 週次サイクル(Weekly Cycle)
7.8 四半期サイクル(Quarterly Cycle)
7.9 ゆとり(Slack)
7.10 10 分ビルド(Ten-Minute Build)
7.12 テストファーストプログラミング(Test-First Programming)
7.13 インクリメンタルな設計(Incremental Design)
7.14 それから……
第8章 始めてみよう
8.1 プラクティスのマッピング
8.2 結論
第9章 導出プラクティス
9.1 本物の顧客参加(Real Customer Involvement)
9.2 インクリメンタルなデプロイ(Incremental Deployment)
9.3 チームの継続(Team Continuity)
9.4 チームの縮小(Shrinking Teams)
9.5 根本原因分析(Root-Cause Analysis)
9.6 コードの共有(Shared Code)
9.7 コードとテスト(Code and Tests)
9.8 単一のコードベース(Single Code Base)
9.9 デイリーデプロイ(Daily Deployment)
9.10 交渉によるスコープ契約(Negotiated Scope Contract)
9.11 利用都度課金(Pay-Per-Use)
9.12 結論
第10章 XPチーム全体
10.1 テスター
10.2 インタラクションデザイナー
10.4 プロジェクトマネージャー
10.5 プロダクトマネージャー
10.6 経営幹部
10.7 テクニカルライター
10.8 ユーザー
10.9 プログラマー
10.10 人事
10.11 役割
第12章 計画:スコープの管理
第13章 テスト:早めに、こまめに、自動化
第14章 設計:時間の重要性
14.1 シンプリシティ
第15章 XPのスケーリング
15.1 人数
15.2 投資
15.3 組織の規模
15.4 期間
15.5 問題の複雑さ
15.6 解決策の複雑さ
15.7 失敗の重大さ
15.8 結論
第16章 インタビュー
第II部 XPの哲学
第17章 はじまりの物語
第18章 テイラー主義とソフトウェア
第20章 XPの適用
20.1 コーチの選択
20.2 XPを使うべきではないとき
第21章 エクストリームの純度
21.1 認証と認定
第22章 オフショア開発
第23章 時を超えたプログラミングの道
第24章 コミュニティーとXP
第25章 結論
訳者あとがき
索引
第一版目次
序文
まえがき
第1セクション 問題
第1章 リスク:基本的な問題
私たちの使命
第2章 開発のエピソード
第3章 ソフトウェア開発の経済学
オプション
例
第4章 4つの変数
変数間の相互作用
スコープに着目する
第5章 変更のコスト
第6章 運転の取得
第7章 4つの価値
コミュニケーション
シンプル
フィードバック
勇気
実践における価値
第8章 基本原則
第9章 基本に戻る
コーディング
テスト
ヒアリング(リスニング)
設計
結論
第2セクション 解決策
第10章 概略
短期リリース
シンプルな設計
テスト
継続した結合
40時間労働
オンサイトのユーザ(顧客)
コーディング規約
第11章 各実践がどのように機能するか
計画ゲーム
短期リリース
メタファ(比喩)
シンプルな設計
テスト
リファクタリング
ペアプログラミング
共同所有
継続した結合
40時間労働
オンサイトのユーザ(顧客)
コーディング規約
結論
第12章 管理戦略
測定値
コーチング
トラッキング
介入
第13章 ファシリティ戦略
第14章 ビジネス上と技術上の責任を分ける
ビジネス
開発
どうすべきか
テクノロジの洗濯
難しいならどうするか
第15章 計画戦略
計画ゲーム
イテレーション計画
一週間の計画
第16章 開発戦略
継続した結合
共同所有
ペアプログラミング
第17章 設計戦略
動作するもっとも単純なこと
何がもっともシンプルか
これはどのように機能するのか
設計における図の役割
システムアーキテクチャ
第18章 テスト戦略
誰がテストを書くのか
他のテスト
第3セクション XPを実装する
第19章 XPを採用する
第20章 XPを改良する
テスト
設計
計画
管理
開発
トラブルが起きたときは
第21章 理想的なXPプロジェクトのライフサイクル
探検
計画
最初のリリースへのイテレーション
稼働(運用)への移行
メンテナンス(保守)
終り
第22章 人の役割
プログラマ
ユーザ(顧客)
テスタ
トラッカ
コーチ
コンサルタント
上司
第23章 20-80ルール
第24章 XPを難しくするもの
第25章 XPを試すべきでないとき
第26章 現場でのXP
固定価格
アウトソーシング
インソーシング
時間と成果物
完成報酬
早期の完了
フレームワーク
パッケージ製品
第27章 結論
期待
解説付き参考文献
用語集
あとがき
索引
hr.icon
人生曲がった一冊tkskkd.icon
参考として1stと2ndの目次を出して比較したいなー。そのうちやる。tkskkd.icon
概念としてのeXtreme Programing or エクストリームプログラミングから書籍として『エクストリームプログラミング』の話を移動してきました koma.icon