エクストリームプログラミング
- 作者: ケントベック,シンシアアンドレス,Kent Beck,Cynthia Andres,角征典
- 出版社/メーカー: オーム社
- 発売日: 2015/06/26
- メディア: 単行本
- この商品を含むブログ (3件) を見る
第2版は読んでいた。新訳本も読んでみる。 改めて、10年以上前からこんなことを言ってたなんで、すごい。 と同時に、自分自身、自分の周りの進歩の無さに愕然とするな。
エスクトリームプログラミング
第2版への序文
- テスト: 早めに、こまめに、自動化
- インクリメンタルな設計
- デイリーデプロイ
- 顧客参加
- 継続的インテグレーション
- 短期間の開発サイクル
- インクリメンタルな計画つくり
第1版への序文
- Just In Time Software
- ソフトウェアのデリバリーは難しい
- XPとは成功を収めた多くの開発者たちのプラクティスを組み合わせ、開発アプローチとして表現したもの
はじめに
- どんな状況でも必ず改善できる
- どんなときでもあなたから改善を始められる
- どんなときでも今日から改善を始められる
第1章 XPとは何か
- XPとはソーシャルチェンジ
- ソフトウェア開発の哲学
- 軽量である
- あいまいで急速に変化する要件に対応する
- 充足の精神
第2章 運転を学ぶ
- 運転のメタファー
- 顧客はシステムの内容を「運転」する
- チーム全体は開発プロセスを「運転」する
第3章 価値、原則、プラクティス
- プラクティスは日常的な取り組み
- 価値とはある状況における好き嫌いの根源にあるもの
- 価値がプラクティスに目的をもたらすように、プラクティスは価値の説明責任を果たしている
- 価値は普遍的
- プラクティスは状況によって大きく異なる
- 価値とプラクティスのギャップを埋めるのが原則（principles）
第4章 価値
- 開発を導く5つの価値
- コミュニケーション
- シンプリシティ
- フィードバック
- 勇気
- リスペクト
- シンプリシティを達成すれば、必要なコミュニケーションも少なくなる
- フィードバックはコミュニケーションに欠かせない
- フィードバックはシンプロシティにも影響する
- 勇気のみでは危険
- 勇気持てば、コミニュケーション強化、シンプリシティ促進、フィードバックが生まれる
第5章 原則
- 人間性（Humanity）
- 妻とだけ話す私生活のこと、信頼できる人とだけ話す個人的なこと、誰とでも話せる一般的なこと
- 経済性（Economics）
- 相互利益（Mutual Benefit）
- 自己相似性（Self-Similariry）
- 改善（Improvement）
- 完璧なプロセス、設計、ストーリーは存在しないが、それぞれを「完璧にやる」ことはできる
- 多様性（Diversity）
- みんなをリスペクトして、自分の言い分を主張すれば、ストレスのかかる状況であってもコミュニケーションは円滑になるはず
- ふりかえり（Reflection）
- 流れ（Flow）
- 機会（Opportunity）
- 冗長性（Redundancy）
- 失敗（Failure）
- 品質（Quality）
- 品質は制御変数ではない
- ベイビーステップ（Baby Steps）
- 責任の引き受け（Accepted Responsibility）
- 責任は割り当てるのではなく、引き受けることしかできない
第6章 プラクティス
- プラクティスの相互作用がその効果を増幅させる
第7章 主要プラクティス
- 全員同席（Sit Together）
- クライアントが主張する問題が何であろうと、それは常に人の問題である
- 全員同席して、あらゆる感覚を使ってコミュニケーションすることの大切さ
- チーム全体（Whole Team）
- 情報満載のワークスペース（Informative Workspace）
- 15秒で状況を把握できるようにすべき
- いきいきとした仕事（Energized Work）
- 疲労した状態ではバリューを奪っていることさえ気付かない
- ペアプログラミング（Pair Programming）
- ペアとパーソナルスペース
- ストーリー（Stories）
- ストーリーカード
- 週次サイクル（Weekly Cycle）
- 計画づくりは必然的なムダのひとつ
- チームや個人が実験をするための手軽で頻繁で予測可能なプラットフォームでもある
- 四半期サイクル（Quarterly Cycle）
- チームのふりかえりに適した間隔
- ゆとり（Slack）
- 10分ビルド（Ten - Minute Build）
- 継続的インテグレーション（Coutinuoous Integration）
- テストファーストプログラミング（Test - First Programming）
- 動かないコードの作者を信頼するのは難しい
- インクリメンタルな設計（Incremental Design）
第8章 始めてみよう
- 週次サイクルでひとりで始めよう
- 変化に取り組むときは、一度にひとつずつ着手すると簡単
第9章 導出プラクティス
- 本物の顧客参加（Real Customer Involvement）
- インクリメンタルなデプロイ（Incremental Deployment）
- チームの継続（Team Continuity）
- チームの縮小（Shrinking Teams）
- 根本原因分析（Root - Cause Analysis）
- 5回のなぜ
- コードの共有（Shared Code）
- コードとテスト（Code and Tests）
- コードとテストだけを永続的な成果物として保守すること
- その他のドキュメントについてはコードとテストから生成すること
- 単一のコードベース（Single Code Base）
- デイリーデプロイ（Daily Deployment）
- 交渉によるスコープ契約（Negotiated Scope Contract）
- 利用都度課金（Pay - Per - Use）
