「アジャイルプラクティス」を少しずつだけれど読み進めていて...

普段から何とかしないなぁ、と思うことのヒントが書いてあったので残しておこう。日ごろのプロジェクトは、普通のウォーターフォール型の開発プロセスをベースにフェーズ単位でプロジェクトをキャリーする。システム特性から、いわゆるシステム化要件を決定するフェーズでそんなところまで？と言われそうな設計をWBSに折り込み、実際のプロジェクトで進めている。同じカテゴリのソフトウェアでも、ベンダによりカスタマイズの柔軟性に差があり、柔軟性の高いソフトウェアは、それなりにプログラミングをすることになる。
プログラミングをするということ、つまりシステムを開発すると言うことは、要求仕様を満たすように動作するか確認する必要があり、テストも結合レベル(＝テストの観点)によりひとつのプログラムを結果的に何回もテストすることになる。

特に不具合(＝バグ)やベンダーのアップデートが出ると、再テストが必要で、今どきなら自動テストをしたくなるのだけれど、まだそこまでできていない。自由度の高いベンダは、フレームワークで開発できるので、プラグインを入れて、環境作ればできるんじゃないの？とつらつらと思っていたけれど、「アジャイルプラクティス」の4章を読んで、なんだできるんじゃないと。
例えば、
　「いつでもりりーすできるようにしておく」は、CVSやsubversionなど構成管理ができるバージョン管理ツールを利用する前提で、UTが終わったソースコードを登録するようにすれば、それだけ見ても、進捗がわかる。あ、えっと、進捗を把握したいのではなくて、UTが終わったらチェックインするというプロセスが定義されていて、そのルールでプロジェクトが運用できることが大事ということ。