エクストリームプログラミングの概要
輪読しているので自分の担当章をqiitaにまとめてみます。
エクストリームプログラミングの実践
- XPは以下に示す複数のシンプルなプラクティスから構成される
- プラクティスが相互作用し、単なる集合以上のものとなっている
チームメンバーとしての顧客
- 顧客と開発者は親密に仕事をするのが良い
- チームの一員であり身近な存在
- 顧客とは？
- 仕様の定義とその優先順位の決定権を持つ個人またはグループ
ユーザーストーリー
- 計画を練るには仕様要求の概略をある程度知っておく必要があるが詳しく把握する必要はない
- 作業量を見積もれる情報があれば十分
- 仕様要求の詳細はプロジェクトが進むにつれて変わるものである
- 顧客と話し合うことで「仕様要求の概略」をつかむが、「仕様要求の詳細」を詰めることはしない
短期間のリリースサイクル
- 動くソフトウェアを2週間間隔でリリースしていく
イテレーションプラン
- イテレーションごとに小さな機能をいくつか実装していく
- 開発者が作成した見積もりをベースに顧客が複数のユーザーストーリーを選ぶ
- 開発者は前回のイテレーションを参考に次回のイテレーションの仕事量を見積もる
- 顧客はその範囲を超えない範囲でストーリーを選択する
- イテレーションがスタートしたらストーリーや作業の優先順位の変更はしない
- 開発者は自由にストーリーをタスクに分解し、合理的な順序で実装していく
リリースプラン
- 6回分程度のイテレーションを1つにまとめたプランのことである
- およそ3ヶ月単位
- イテレーションプラン同様に前回のリリースでこなした仕事量を参考に次回のリリースでの仕事量を見積もる
- リリースの内容は不変不動のものではなく、顧客はいつでも内容を変更できる
受け入れテスト
- ストーリーの受け入れテストは実装直前か実装と並行して作られる
- 自動的に繰り返し実行できるようにスクリプト言語で書かれる
- 自動的に繰り返し行うことでシステムが顧客の要求通りに動くかをチェックできる
ペアプログラミング
- 納品するコードはすべてペアを組んだプログラマが実装する
- 2人は役割を頻繁に交代できる
- ペアそのものも、少なくとも1日に1回組み替える
- イテレーションの間にチームの全員が他のメンバーとペア組み、作業内容のほぼすべてに関わることになる
- ペアを組み替えていくことでチーム内に知識が広まる
テストファーストの開発
- 納品するコードにはすべて、失敗するユニットテストをパスさせる目的で書かれる。
- テストする機能が組み込まれていないユニットテストを書いておく
- 次にそのテストをパスさせるためのコードを記述する
- これを繰り返すことでテストケースがコードともに形成されることになる
- 個別にテストできるようにモジュールに分割されたコードは独立性（分離性）が高いものになる
共同所有権
- 共同作業をしているペアにはどんなモジュールでもチェックし、かつ、それを改善する権利がある
- しかし個人がモジュールや技術に対して責任を負うことはない
- 最終的にチームの誰もが技術を等しく共有することになる
- とはいえ、XPは専門家の必要性を否定しているわけではない
継続的なインテグレーション（統合）
- プログラマは担当しているコードを1日に数回システムにチェックインしながら作業を進める
- 先にチェックインした人が勝ちで、他の人はそれをマージする
- XPチームはソースコードコントロールをブロッキングしない
持続可能なペース
- ソフトウェアプロジェクトは短距離競走ではなくマラソン
- 全力疾走するチームはゴール前に燃え尽きてしまう
- 素早くフィニッシュするには持続可能なペースで走り、活力と集中力を維持しなければならない
- XPのルールでは残業は許されない
- ただしリリース最後の週は例外
オープンワークスペース
- チームはオープンな部屋でともに作業する
- 各ペアは他のペアの会話も聞こえる程度の距離にいて、別のペアが困っているときには気づけるようになっている
- 気が散るかもしれない、と心配するかもしれないが事実は逆である
- ミシガン大学の研究でこういう環境では効率が2倍になるという結果が示された
計画ゲーム
- 本質はビジネス側と開発側の責任の切り分けにある
- ビジネス側（つまり顧客）は各機能のビジネス的な重要度（価値）を決定
- 開発者側はその機能を組み込むために必要なコストを見積もる
- 直前のイテレーションの完了にかかった期間を参考に、開発者は顧客に見積もりを提示する
- 顧客はその見積もりを超えないように調整しながら、組み込むたいストーリーを選択する
- こういったシンプルなルールを採用しリリースを頻繁にすると顧客と開発者はプロジェクトのリズムに適用できる
- そうすることでプロジェクトにかかる時間と費用を割り出すことができる
シンプルな設計
- 現在のイテレーションで計画しているストーリーにだけ焦点を絞り、将来組み込むことになるかもしれないストーリーについてあれこれ心配しない
- イテレーションごとにシステム設計を現行のストーリーの処理に最適な設計に変えていく
- 開発チームがまずすることは、最初に与えられたストーリーの一群を考えられる限り最もシンプルな方法で正常に動作させることである
- 3つのXPスローガン
- 何とか動くだけの最もシンプルなものを考えよう
- あとで必要になんてならないよ
- 同じことは2度しない
リファクタリング
- コードは劣化するものであるので、頻繁にリファクタリングをすることで劣化を防ぐ
メタファー
- メタファーはジグソーパズルの絵の役割を果たす
- ピースの形のみでパズルを完成させることはできるが難しい
- パズルの絵の全体像そのもが見えていればパズル解決はずっと楽になる
- メタファーはシステム全体をつなぐ大きな絵柄である
- 個々のモジュールの位置や形状を明らかにするシステムのビジョンと言える