タイトル通り計画の話。 ページ数は少なく薄い本。 XPってまだ有効なのだろうか。 9章(全体の約1/3)までちゃんと読んだ。 実践できるかどうか疑問に感じてきたため、それ以降は飛ばし読み。 こういう本読んだことないので新鮮で面白かった。 必要になったとき思い出して読み返してみたい。

友人に、マーチン・ファウラーを勧められ、本を探してました。 タイトル通り、XPの本です。形式的なことよりも、ソフトウェア開発のトピックや、XP開発のトピックに関して、考え方を簡易に説明しています。 自分に気になったトピックをメモしておきます。 ・ソフトウェアをドライブする ・ユーザ ・仕事が多すぎる ・昨日の天気 ・インフラをどのように計画するか ・ストリーのサイズを見積もる ・技術のリスク ・技術のタスク ・イテレーションの進捗チェック ・終止符を打つ ・欠陥を対処する ・パッケージ化 「イテーションの進捗チェック」では、２つの質問だけをすると良いようです。 ---- * 作業に、何日費やしているか。 * 作業を終わらせるために、あと何日必要か。 ---- 本書は、気軽にXPを実践するために心得を得る本だと思います。これからXPを始める方にオススメしますし、XPを実践している方で、コーヒーを飲みながら気軽に読むこともオススメします。 ここからは各トピックの大事な点をメモります。 「プログラマの権利章典」 開発を成功させるためには、プログラマとユーザが自分たちの不安を認識し、権利と責任を受け入れられる文化（環境）を創らなければならない。こうした保証がなければ、自信を持って行うことができない。防御壁の後ろで不安を握りしめながら・・・ しかし、不安が認識され権利が受け入れられれば、自信を持つことがができる。 「ソフトウェアをドライブする」 ソフトウェア開発も、こっちに少し向いてしまったら、あっちに少しハンドルをさばくことがで運転する。 「ユーザ」 ここで言うユーザとは、ビジネスの決定を下す人のことを指している。 （本書では、このユーザが、何度も登場する) 「仕事が多すぎる」 * プライオリティをつけ、いくつかについてはてをつけない。 * 自分で行うべきいくつかについてのサイズを縮小する * いくつかを他の人にやってもらう。 「昨日天気」 (次のイテレーションでどれだけの量の作業を行うかについて） 自分たちの能力を習慣的に過大評価しない。実際の達成結果に基づく。一度過大評価すると、次も同じだけ行わなくてはならない。 「インフラをどのように計画するか」 各イテレーションでそのイテレーションのストーリーを満たす文だけのインフラを構築すれば良い。 「ストーリーの順序」 ストーリーの順序は、通常必要ない。順序における依存はほとんどが間違ったものである。 「技術的リスク」 開発者がナーバスになっていたら、誰もが耳を傾けるべきである。ナーバスになる要因は様々なところにある。 「期日を延期しない」 期日はというものは堅く決められたものだが、スコープは柔軟に変えられるということである。 「技術タスク」 ユーザが関わらない技術的なタスクがある。・・・こうしたこともリストに追加しよう。 「イテレーションの進捗チェック」 2つの質問をする * 作業に、理想日を何日費やしているか。 * 作業を終わらせるために、あと理想日が何日必要か。 「終止符を打つ」 タスクが完了した時に線を消すのは、開発者でなくユーザが行うべきなのだ。 「パッケージ化」 ベックは、6人のプロダクトマネージャーがいるプロジェクトを担当していたことがある。計画会を開く頃には、彼らは、ストーリーを１つとして発表した。

序文に、DEMARCOが機動性について述べている。 「SEIやCMM同様XPは今の世の中に欠くことができない」 この言葉にピンと来る人は、この本を最初に読んでもよいと思います。 そうでない人は、同じシリーズの入門から読まれることをお勧めします。 ps. ケントベックが日本に来た際のXPユーザ会の会合は、 ネクタイ半分、ラフな格好半分と、プログラマのコミュニティとしては、 現状を反映していたような記憶があります。 XPのコミュニティの反映にとっては、大事な１冊だと思います。