XPのイテレーション

前置きとして，基本的に僕はXPが嫌いです。OSのXPじゃなくって，eXtream ProgramingのXPね。理由はいろいろありますが，それはまたそのうち。ちなみに全く否定している訳じゃないです。

さて，XPの中で好きなものの中にイテレーションがあります。２週間ごとに顧客にリリースするとかって言うやつです。「顧客への」リリースは信じていませんが，イテレーション自体は，悪くはないです。リリースが大きなマイルストーンだとすると，イテレーションは小さなマイルストーンになります。プロジェクトないだけに通用するマイルストーンとも言えます。「プロジェクトにXPなんて全く使ってないよ」という人にとっては，自分の中で適切に設定した目標と置き換えても良いかも知れません。

さて，イテレーションのメリットですが，僕は単に実装とテストの間隔を短くできるということだと思います。他のメリットを主張する人がいますが，僕は最近は個の考えに落ち着いています。実装とテストの間隔があくと、実装者の記憶が曖昧になり，テストの盲点に気づきにくくなること，バグが見つかってもそんな前の実装，思い出せないよ，と言うことです。今日書いたコードを明日直すのは簡単ですが，一月前のコードは難しいです。また，その間にコードに依存性が増えると，修正によるテストケースが増えます。これは，人は神ではないので，すべての依存性を考えてできるとは思いませんが，なるべく速い段階での修正が重要です。

かなり前に，「ゴール」と言う本を読みました。プロジェクト管理の小説風の本ね。その本の中では「在庫は悪だ」というようなことが書いてありました。デバッグされていなコードは，顧客にリリースできない在庫です。コードを在庫のまま抱えていても生産性の向上にはつながりません。
ちょっと抽象的なので，ボトルネックと言うか、作業が中断された状態の方が良いかも知れません。ソフトを作るときに，コードを書いてデバッグしてリリースします。デバッグからリリースまでを短くすることはそれはそれで良いのですが，コードを書いてからデバッグがされるまでにボトルネックがあると最近特に思います。まあ，頭で分っていてもそのボトルネックをどう取り去るかは、まだ，試行錯誤中なんですがね。そもそも，テストをちゃんとやることも大変なのに・・・。

さて，今のプロジェクトで，一部のコードをブランチで実装して，次の次のリリースで統合しようと言う動きがありました。これ自体は悪い考えではないのですが，プロジェクトの人数が少ないので，ブランチでのテストに工数をさけません。つまり大量の在庫が生じる訳で，その後のフローで在庫が減ると言う道筋がありませんでした。なので、僕はその案を否定しましたが，やっぱり，テストは難しい。