アジャイル開発「エクストリーム・プログラミング（XP）」の価値を再認識する
初めてのアジャイル開発 〜スクラム、XP、UP、Evoで学ぶ反復型開発の進め方〜
―――――――――――――――
――――アジャイル開発――――
―――――――――――――――
複雑に考えることは簡単である。
単純に考えることは非常に難しい。
―カーバー・ミード
アジャイル開発「エクストリーム・プログラミング（XP）」の価値を再認識する。
僕の勤める現場では、実際には、前回書いた「スクラム」と
今回の「エクストリーム・プログラミング」を組み合わせている。
「エクストリーム･プログラミング」は
【これらのプラクティスの多くは相乗的に働く。つまり、いずれかのプラクティスを取り除く方向にXPをカスタマイズするのはリスクが高い。】とされているが、現場のリソース上、ペアプログラミング等一部実施できていない部分があるが、ほぼ「スクラム」と組み合わせて実施している。
また、タスク管理や情報共有をtarcやIRCで行っていたりしており、若干自分たちの環境に合うようにアレンジしている部分もある。
以下はアウトプットである。
※導入理由や根拠は前回の文章の「スクラム」の回を見てください。（省略してますけど・・・）
――――――――
―――目次―――
――――――――
●基礎
●１２の基本プラクティスを推奨
●手法の概要
●概論
●ライフサイクル
●基本プラクティス
●その他のプラクティスおよび価値
●価値
●ありがちな間違いと誤解
――――――――
―――内容―――
――――――――
●基礎
エクストリーム・プログラミング（XP）は有名なアジャイル手法であり、協調と、初期の素早いソフトウエア作成、巧妙な開発プラクティスに重点を置いている。その基礎は、「コミュニケーション」「シンプルさ」「フィードバック」「勇気」の４つの価値である。
●１２の基本プラクティスを推奨
IIIDの他に、以下の１２のプラクティスを推奨している。
１．計画ゲーム
２．小規模で頻繁なリリース
３．システムのメタファ
４．シンプルさ
５．テスティング
６．頻繁なリファクタリング
７．ペアプログラミング
８．チームでのコードの所有
９．継続した結合
１０．持続可能なペース
１１．チーム全体が一緒に
１２．コーチング規約
これはジグソーパズルに良く似ている。小さいピースがたくさんある。ひとつ一つは意味がないように見えるが、組み合わせると全体像が見えてくる。
これらのプラクティスの多くは相乗的に働く。つまり、いずれかのプラクティスを取り除く方向にXPをカスタマイズするのはリスクが高い。
●手法の概要
タイムボックスを利用したイテレーション期間は１〜３週間を奨励している。
XPの儀式度は低い。
最近ではより大きいチームにも適用されてきている。
●概論
ケント･ベックが作り上げたXPというIIID手法は、価値の高いソフトウエアを素早く作成し、熟練した持続可能なソフトウエア開発技法を使い、変化に柔軟に対応することで、顧客の満足度を上げられることを主張している。
「プログラミング」という言葉は名称に入っていることからわかるように、XPは、変化する要求に（プロジェクトの後半においても）自信をもって対応し、なおかつ品質の高いコードを作成できるようなプラクティスを、プラグラマ向けに提示している。
これらのプラクティスには、テスト駆動開発、リファクタリング、ペアプログラミング、継続した統合などがある。
他のアジャイル手法と対照的なのは、XPのプラクティスが本当の意味で開発者によって採用されていることである。開発者は、XPのプラクティスがプログラマにとって意味のある実践的な技法だと感じているのである。
XPはコミュニケーションやチームを特に重視している。
XPが独特なのは、プログラムコードとテスト以外には詳細な作業成果物を要求しない点にある。ただ、詳細作業成果物を作成してはいけないわけではない。その多くは少なくとも次のイテレーションで行う使用については詳細に記述するよう推奨している。XPはそれとは逆に、要求や設計に関しては「口頭のコミュニケーション」を重視する。例えば機能は、紙のインデックスカードを使ったストーリーカードに、「最も安い料金を探す」のように手書きで要約する。そして、作業が始まったら、プログラマはプロジェクトルームに常駐している顧客と話して、機能の詳細を教わる。
典型的な小規模プロジェクトを素早く成功させるために、コードとテストに注力し、それ以外にドキュメントのオーバーヘッドをできるだけ避けるほかに、健全で規律ある方法はあるだろうか。
XPが前提としているのは、コードを書いては修正するというずさんな（ハッカーな）プログラミング方法ではない。素早いコード作成と口頭のコミュニケーションに注力し、他のオーバーヘッドを排除し、成功を収めるための新しい体系化された持続可能な方法が存在することを前提としている。
XPプロジェクトは常に、きわめて規律のある（しかもアジャイルな）ソフトウエア開発のプラクティスと価値を実践しているのである。
XPは、４つの本質的な方法で、ソフトウエアプロジェクトを改善する。つまり、コミュニケーション、シンプルさ、フィードバック、勇気である。 XPのプログラマは、仲間のプログラマや顧客とコミュニケーションする。設計をシンプルでスッキリさせておく。１日目からソフトウエアのテストを開始してフィードバックを得る。できるだけ早く顧客にシステムを引き渡し、提案された変更を実装する。XPプログラマは、これを土台として、変化する要求や技術に勇気を持って対応していく。
XPの「エクスストリーム」という言葉は「ソフトウエア開発」に役に立つことならば、やってやりすぎることはない」というベックの信念に由来している。つまり、役に立つことが分かっているプラクティスを「ダイヤル10まで上げて」すなわち最大（エクスストリーム）のレベルで、目いっぱい適用すると言うことである。その例をいくつか挙げてみる。
※テストは役に立つ。だから、（ほとんど）すべてのコードの単体テストを書き、すべての機能の受け入れテストを書く。
※コードレビューは役に立つ。特にコードを書いてからレビューするまでの期間が短いほど高い効果を発揮する。だから、ペアプログラミングによって常にリアルタイムでコードレビューを実施する。
※チームメンバー全員のコードの結合を頻繁に行うと役に立つ。だから、継続した結合プロセスを自動的にビルド専用マシンで年中無休で実行する。
※短期のイテレーションと早い段階でのフィードバックは役に立つ。だから、可能ならイテレーションの長さを１週間から３週間にする。
※顧客の参加の度合いが高まることは役に立つ。だから、顧客にプロジェクト専任者をだしてもらい、開発者と共通のプロジェクトルームに常駐してもらう。
※コミュニケーションは役に立つ。だから、全員同じ場所に集まり、ペアプログラミングを行い、オンサイトの顧客に参加してもらい、計画や方向の決定や評価に頻繁に顧客を巻き込む。
●ライフサイクル
１．多くのプロジェクトと同じように、XPも「探索」から始めることが出来る。
２．「リリース計画ゲーム」では、顧客との開発者はストーリーカードとおおよその見積もりを完成させ、その後、次のリリースで行う作業を決定する。
３．「イテレーション計画ゲーム」では、次のイテレーションに向けて顧客が実装対象のストーリーを選択する。XPでは時間外労働に強く反対している。時間外労働が行われると、プロジェクトが機能障害に陥っていて、メンバーの不満がだんだん大きくなり、生産性や品質が低下している証拠だとみなされる。
４．開発者は、決められたタイムボックスの期間中にストーリーを実装する。
５．リリースに向けての作業が終わらなければ、次のイテレーションに向けてステップ３に戻る。
●基本プラクティス
・チーム全体が一緒に、あるいはオンサイトの顧客
プログラマと顧客からなるチーム全体が共通のプロジェクトルームで一緒に作業する。要求とその優先順位を決定する権限を持つことが求められる。このプラクティスの目的は、失敗プロジェクト調査では毎度お馴染みの指摘事項「プロジェクトを成功させるために最も重要なことは、顧客にもっと参加してもらうことだ」に対応することにある。
・小規模で頻繁なリリース
進化型出荷。あらゆるプロジェクトに適用できるわけではない。一つのリリースサイクルをさらに複数の短いイテレーションに分割することと混同してはならない。
・テスティング：受け入れテストと顧客テスト
XPはテスティングのプラクティスを非常に重要視している。すべての機能は自動化された受け入れ（機能）テストに組み入れる必要がある。受け入れテストは顧客と協力して作成する。顧客はテストに使える内容の受け入れ基準定義書を作成する。これがXPの顧客テストと呼ばれているものである。
・テスティング：テスト駆動開発と単体テスト
単体テストは、ほとんどのコードに対して作成され、テスト駆動開発（およびテストファースト開発）のプラクティスに従って実施される。この中には、テスト対象のコードよりも先にプログラマが単体テストを書くというプラクティスもある。これは「コード→テスト」ではなく「テスト→コード」というサイクルである。受け入れテストおよび単体テストはすべて、年中無休の「継続した結合」のプラクティスのビルドおよびテストのサイクルに組み込んで、自動的に実行する。
・リリース計画ゲーム
リリース計画ゲームの目標は、顧客にとってソフトウエアの価値が最大になるよう、次の運用リリースのスコープを定義することである。（１）まずリリース日を設定する。それから優先順位の高い順にカードを追加していき、その見積もり時間の合計がリリース日までの利用可能工数（時間）に達するまで続ける。（２）まず次のリリースで必要だと思うカードを選択する。それから見積もり時間の合計を算出して、それを基準にリリース日を割り出す。
・イテレーション計画ゲーム
顧客はイテレーションで実装するストーリーカードを選択する。そのストーリーカードごとに、プログラマがストーリーを実現するためのタスクリストを（カードまたはホワイトボード上で）作成する。タスクの見積もりが半日〜２日の間いｎ収まらなければ、リファクタリングを行う。
・シンプルな計画
将来の変更の可能性を推測して設計しない。今すぐ必要でない汎用のコンポーネントを作成しない。コードの重複をなくし、クラスやメソッドが比較的少なく抑えられた、簡単に理解できる設計をするべきである。
・ペアプログラミング
アプリケーションコードは必ず、２人のプログラマが１台のコンピュータに向かって作成する。定期的に交代しながら交互のコーディングする。ペアは、タスクが変われば頻繁に組みなおされる。見ている側の人は、リアルタイムコードレビューを行っていることになり、おそれくは入力している人よりも幅広い考えが出来る（テストなどについて考えられる）。メンバーが相互に学習すること。もっと規律を持ってプラクティスを遵守し、だらだらせずにもっと多くの時間を実際のプログラミングに割くよう仲間同士でプレッシャーをかけ合うこと。リアルタイムのコードレビューによって欠陥を削除すること。そして、ペアの一人が行き詰まったときでも先に進み続けられる根気と洞察力を持つこと。
・頻繁なリファクタリング
XPのリファクタリングとは、すべてのテストが通ることを確認しながら、きめ細かいコードや大規模な設計要素を単純化する、継続的な努力のことである。XPでは「大量の」リファクタリングが想定されている。このプラクティスは継続した設計改善とも呼ばれる。このプラクティスの目標は、単純で分かりやすい最小限のコードにすることである。
・チームでのコードの所有
XPの価値体系は、チーム全体が嚮導ですべてのコードに責任を持つことであり、そのため、プログラマのペアはどのコードでも改善することができる。そのため、プログラマのペアはどのコードでも改善することが出来る。「あの人のコードだからあの人の問題だ」という考え方は容認されない。そうではなく、問題点や改善できる点が見つかると、それは見つけた人の責任となる。こういった文化により、個人でコードを所有した場合に変更要求によって生じるボトルネックを避け、開発速度を上げることができる。もともと自分が書いていないコードを変更することによる明らかな危険を、XPでは他のプラクティスによって緩和している。単体テストや受け入れテストが存在することが保証されていて、継続したビルドプロセスが自動的に実行され、コードに問題が起きた場合にはそれがわかるようになっている。共通のコーディング規約が守られているため、どのコードも似たようなものになっている。
・継続した結合
チェックインされたコードはすべて、ビルド専用マシンで継続的に結合テストが繰り返される。
・持続可能なペース
頻繁に時間外労働をしているということは間違いなく、より深刻な問題を抱えている徴候だと考えてよい。またそれは、幸福で創造的な開発者とその健全な家族、あるいは品質が高く保守しやくいコードには決してつながらない。だからXPでは時間外労働を善しとしない。むしろ「時間外労働なし」を勧めている。
・コーディング規約
コードの共有所有や、頻繁なリファクタリング、ペアプログラミングのパートナーの頻繁な組み換えを行うには、全員が同じコーディングスタイルに従う必要がある。
・システムのメタファ
設計をうまく伝えるために、システム全体や各サブシステムを覚えやすいメタファで表現し、主要なアーキテクチャのテーマを描写する。
●その他のプラクティスおよび価値
・オンサイトの顧客代理
XPを適用したいと思っていても、プロジェクトルームで専任で仕事をしてくれる「最高の」顧客が見つからないことも多い。この場合の一般的な解決方法は、チームと一緒にプロジェクトルームで作業をし、その領域や要求についてきちんとした（本当の顧客のように理想的でなくても）知識を持ち、最高の顧客を代表する顧客代理を任命することである。
・顧客の待機
オンサイトの顧客が居ない場合には、顧客の代表者とすぐに話ができるよう手はずを整えておくことが大切である。
・変化を受け入れる
XPが広めようと質得るもっとも重要な心構えは、要求や設計やコードの変化と戦うのではなく、変化を受け入れ、それに対応して素早く行動できるようになると言うことである。
・立候補のみ（責任の受け入れ）
タスクを人に割り当てるのではない。イテレーション計画ゲームの途中で、人がタスクを選択する、つまり立候補するのである。その結果、他人からタスクを割り当てられた場合に比べて、真剣に取り組むようになり、より高い満足感とタスクの達成へのコミットメントが得られるようになる。
・非常に身軽なモデリング
XPでは、開発のかなり早い段階からプログラミングすることと、事前の設計作業を「エクスストリーム（極限）」に避けることを奨励している。プログラミング前に設計ついて考えることは（ホワイトボードにスケッチやメモを書く程度にして）１０分か２０分も実施すれば十分で、それ以上の時間を費やすことはやりすぎだと考えている。
・最低限の、あるいは「かろうじて足りる」文章
XPにはコードを早く作成するという目標があるため、不必要な要求や設計、管理ドキュメントを作成することは認められていない。XPは反文書主義ではないが、文書を作成するのにはコストがかかるし、その分のコストをプログラミングにかけた方がおそらく有効である。
・測定基準
XPでは、毎日、進捗と品質を測定するよう推奨している。正確な測定が要求されているのではなく、「役に立ちそうなものの中でもっとも単純なものを用いる」ということである。たとえば、完了したタスクとストーリーの数や、実行したテストの数と成功率などである。
・壁に貼った分かりやすい表
収集された測定結果は、毎日更新し、全員に見やすいように表にして壁に張り出す。
・トラッキングと毎日のトラッカー
タスクやストーリーの進捗状況を定期的に収集するのはトラッカーの責務である。「XPはコンピュータではなく人を対象としているのだ」。テストの測定値などはソフトウエアを使って自動的に収集するべきである。
・インクリメンタルなインフラ
他の反復型のプロセスと同じように、XPでも、初期のイテレーションでバックエンドのインフラ（たとえば永続化層など）を実装の主な対象にするのではなく、各イテレーションのユーザー機能要求をなんとか満たせるだけのものをまず実装するよう勧めている。
・共通のプロジェクトルーム
共通のプロジェクトルームで実施する。ソフトウエア開発という生産活動はXPではチームスポーツと考えていることに留意すべきだ。
・毎日のスダンドアップミーティング
スクラムと同様に、毎日、短時間のスダンドアップミーティングを行い、状況を報告する。短時間で終わらせるために立ったままで行う。
・理想エンジニアリング時間（Ideal engineering hours:IEH）
タスクの見積もり（おそらくはストーリーカードの見積もりも）は、IEHを単位として行う。IEHとは、中断されずに集中してそのタスクだけに取り組んだ場合に、完了までにかかる時間である。
・ストーリーの見積もり
比較的大きいストーリーを見積もる場合、XPを実践する人によっては、IEDや日のレベルではなく、１週間、２週間、３週間という粗いレベルでの見積もりを推奨している。
●価値
「プラクティス」はやるべきことを示している。価値は「プラクティス」を正しく実践できるかどうかを判断するための指針を示している。
・コミュニケーション
XPでは、プロジェクトが難局に陥ったときには、たいていその裏にコミュニケーションの問題があると考えている。
・シンプルさ
つまり「何とかうまくいく中で、もっともシンプルなことをする」ということ。これはソフトウエアの設計だけではなく、要求やプロジェクトマネジメントの「ツール」などにも適用される。ソフトウエアの設計では、XPは、考えうる変更を推測して設計したり（「将来のための補強」）、現在の要求には今すぐ必要でない汎用のコンポーネントを作成したりすることを否定している。
・フィードバック
この価値は、品質や適応性を向上する。短いイテレーションを行うと、顧客は部分的なシステムが少しずつ進化するのを見る（そしておそらく動かしてみる）機会が与えられ、要求を明確にしたり見直したりすることが出来る。また、頻繁な運用リリースのプラクティスによって、エンドユーザーからのフィードバックが受けられる。
・勇気
早く開発し、早く変更する勇気は、他の価値はプラクティスによるサポートや最新の技術があってこそ得られる。
●ありがちな間違いと誤解
誤り：オンサイトの顧客がいない。代わりに次回のイテレーションについて書かれた仕様書を使っている。― アジャイルや反復型のプロジェクトでこのアプローチをとってもうまくいくが、しかし、その場合のプロジェクトは、XPというよりも進化する要求をドキュメントにまとめることを認めているほかの手法（UPなど）にもとづいたものになっている。詳細な仕様記述を避け、口頭で要求を伝え、顧客がオンサイトで常駐することがXPの基本である。
誤り：補いあっていない一部のプラクティスだけを適用する。やってみる前にカスタマイズする。― XPのプラクティスの大半は、全体として相乗効果をもたらすものであり、他のプラクティスを補ったりサポートしたりしているものを取り除くことは間違いである。たとえば、テスティングや、継続し結合、コーディング規約なしにコードを共同所有することは出来ない。オンサイトの顧客がいなければ、要求文書を最低限に抑えることは不可能である。テストがなければ頻繁なリファクタリングはうまく行かない。そのためベックは、厳格になるつもりはないのだが、一般には基本プラクティスをすべて（あるいはほとんど）採用するよう推奨しているのである。ベックの言葉を借りると、「カスタマイズしようとする前に、XPをすべて実施するべきだ」となる。
誤り：XPとは反復型開発に最低限の文書と単体テストを加えたものなのだ― 多少融通がきくにしても、これだけのプラクティスはXPプロジェクトであるとはいえない。XPは、共通のプラクティスをもつ他のIIID手法より厳格である。スクラムやUPやDSDMなどの進化型手法は、最初はこれらのプラクティスだけで実施することが出来る。XPの特徴は、より多くのプラクティスが必要なことである。たとえば、ペアプログラミング、オンサイトの顧客、顧客が作成する受け入れテストなどがある。
誤り：最初に単体テストを書いていない― テストファースト開発は、一見したものよりも複雑な次元のものであり、XPの重要なプラクティスである。テストを最初に書くと、設計をどのように思いつき、明確化し、単純化するかが変わってくる。テストファーストには興味深い心理的な満足感がある。テストを書き、それを通す。そこにはプラクティスを持続させるだけの達成感がある。
誤り：顧客が判断を下さない― XPは顧客を中心に進められる。
誤り：顧客自信のテストがない― ロン・ジェフリーズの言葉だが、「[イテレーションごとに]っ客自身が行う受け入れテストを準備できないことが、XPで最も良く見られる間違いの一つである」。
誤り：リファクタリングを最小限に抑える― XPがプログラミング前の設計に時間をかけることを避けるのは、比較的大規模なリファクタリング（たとえば全工数の25%をリファクタリングにあてる）を実施すれば、これを埋め合わせることが出来ると考えているからだ。ベックの真意は、プログラミング前の設計とリファクタリングの両方を避けることが出来ないので、どちらかを選んで実施する必要があると言うことだ。
誤り：オンサイトの顧客は一人だけでなければならない― 顧客のチームを全体として捉える必要があり、計画ゲームに参加する多数の顧客からの要求が出てくることもあると強調している。その結果、「オンサイトの顧客」のプラクティスは「チーム全体が一緒に」に変更された。
誤り：粒度の細かい多数のタスクカード― ほとんどのタスクカードは、工数が１〜２日の範囲に収まるように作成するべきである。ほとんどが「数時間」レベルだと不必要な情報管理が発生してしまう。
誤り：一人のパートナーと長時間ペアを組みすぎる― XPのペアは、頻繁に組み替える。たいていは２日以下である。さまざまな人とペアを組むことで、知識をいきわたらせることも出来る。
誤り：顧客やマネジャーがトラッカーを務める― プログラマは進捗の遅れを報告しづらくなる。
誤り：QAチームが組み込まれていない― 多くの組織には品質保証（QA）チームが独立して存在し、そういった組織では、完成したシステムを「壁越しに投げ込み」（チームを超えて）品質チェックを行っている。そうではなく、少なくとも一人QA担当者がプロジェクトに専任で参加し（チーム全体のプラクティス）、通常は顧客と協力して受け入れテストを作成しなければならない。
誤り：開発後に設計ドキュメントを作成するのは間違いだ―
XPはドキュメントの作成に反対しているのではなく、プログラミングを優先している（それだけでうまくいくなら）だけである。目的を達成する方法の中で最もシンプルな方法をとることを目標とする。
誤り：図を書くのはよくない― XPではモデリングや図の作成を、プログラミング前の１５分間など、最小限に抑えるよう助言しているが、少しであればかまわない。
誤り：ペアを組むプログラマが若いメンバーばかりである― 他人と密接に協力して仕事をするだけの忍耐力がなかったり技術・知識が不足知るためである。
誤り：新人同士のペア― パートナーを組む２人のうち１人は、ペアプログラミングの経験が必要である。
誤り：片方のパートナーが早く進みすぎる― ペアプログラミングを行うときには、仕事の速い、あるいは経験豊富なほうのパートナーは、相手とのスピードや理解の格差に気を使い、作業や説明のスピードを落とす必要がある。
誤り：見ている側から画面がみづらい― 説明の必要はないだろうが、驚くほど頻繁に見かける問題である。
誤り：学習しようとしない、説明しようとしない― ペアプログラミングを成功させるには、心を開いて学習する、またはパートナーに丁寧に説明する姿勢が必要である。
誤り：顧客を含むチーム全員がXPとその導入理由について要点を知らされているわけではない― 説明の必要はないだろう。
誤り：チームに異議を唱える人がいる― XPは、コミュニケーションやコラボレーション、開発文化によって成り立つ。それを受け入れたくない一匹狼のプログラマは、チームの文化やプロジェクトの進捗の妨げになる可能性がある。
誤り：スタンドアップミーティングが長すぎる― 時間は２０分以内、内容はタスクの状態に制限し、設計や要求についての議論は行わない。
誤り：一つの大きな「バグフィックス」ストーリーにまとめる― 不具合が溜まってきた場合にも、一つのタスクや１枚のストーリーカードにまとめるべきではない。関連するもとのカードと一緒にしておくべきである。
誤り：受け入れテストの専任の担当者がいない― 顧客と協力して受け入れ基準から実行可能なテストコードを作るには、専任のメンバーが一人必要である。例外は非常に小規模なプロジェクトだけで、その場合にはテスト担当者（テスター）がそのロールを兼任できる可能性がある。
誤り：オンサイトの顧客とビッグボスが緊密に協力していない― XPは「ビッグボス」、つまりプロジェクトの目標やマイルストーンを最終的に承認する、あるいは責任をとる人についても言及している。オンサイトの顧客とビッグボスは、ともに利害関係者として、意見が一致していなければならない。
誤り：受け入れテストを書いている顧客とテスト実行後のレビュー担当者が別人である― 船頭多くして船山に上る、という古典的な問題である。
誤り：イテレーションが長すぎる― XPのイテレーションは１〜３週間にするべきである。
誤り：イテレーションでタイムボックスが使われていない― もともと予定した期間内に目標が達成できそうにない場合に、イテレーションの期間を延長するのは考え違いである。一般的に望ましい方法は、イテレーションの目標を削るか簡単にすることである。また、見積もりがずれた理由も分析する。
誤り：イテレーションの最後に結合テストの済んだベースラインができあがらない― イテレーションとは終了日に成功させることだけではない。すべてのソフトウエアを統合し、テストし、ベースラインとして登録することが目標である。
誤り：イテレーションの最後に必ず製品リリースが作成される― イテレーションの終わりに作成されベースラインとして登録されるソフトウエアは、出荷可能なコードというよりは内部リリースである。確かに、反復開発の一つの目標は、すべてのイテレーションのリリースを製品として出荷できるほど安定したものにすることかもしれないが、通常はそこまでする必要はない。
誤り：予測型計画― 長期プロジェクトの開始時に、イテレーションの回数、各イテレーションの長さ、各イテレーションで行う作業について信頼できる正確な計画を作成しようとするのは誤りである。この方法はアジャイルのアプローチである適応型計画とは正反対である。XPのチームと顧客は次のイテレーションの計画を立て、それからイテレーションごとに最新のフィードバックにもとづいて計画を適合させていく。
