TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン

TiDD初心者が陥りやすいアンチパターンを更に見つけたのでメモ。

【参考】
バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索

Agile開発の肝はイテレーションにあり: プログラマの思索

【1】WF型開発のプロマネとしてバリバリ腕を鳴らしている人がRedmineでタスク管理を運用していると、共通した特徴がある。
それは、工程単位にRedmineプロジェクトやRedmineバージョンを割り当てていること。

例えば、プロマネが1個のプロジェクトだけを抱えているなら、Redmineプロジェクトは1個だけだが、Redmineバージョンを設計、開発、テスト障害、本番障害のように工程単位にアサインしている。
大規模プロジェクトで、プロマネが複数チームをマネジメントしているなら、Redmineプロジェクトを課題、設計、開発、テスト障害、本番障害のように工程単位にアサインして、チケットのカテゴリをチーム単位にアサインしている。
この手法の弱点について考えてみる。

【2】前者の場合、設計のバージョンの成果物は設計書だけであり、機能ごとの設計書のタスクがチケットにアサインされている。
最初は、設計書が書き終わるごとにチケットが終了していくので、順調にタスクが消化されているように見える。
しかし、バージョンの納期があまり明確でない。
実際のSW開発では、出来上がった設計書から順に開発していくので、設計バージョンが50％でも次の開発バージョンに含まれるチケットに手を付けていく。
じきに、設計バージョンはプロジェクト後半になっても進捗率が100％にならないまま、ずっと残る。
同様に、開発バージョンも、保留となった機能の実装のチケットが残ったままになるから、進捗率は100％にならずに、プロジェクトが終わっても残ったままになる。

あるいは、レビューで指摘を受けて手戻り作業が発生したり、仕様変更が発生して複数の設計書を修正する場合、そのチケットをどのバージョンに入れてよいか分からない。
実際、仕様変更が発生した場合、設計書だけでなく、ソースも直すし、テストケースも修正しなければならない。
だから、設計バージョンや開発バージョン、テスト障害のバージョンまで関係するから、きちんとした運用ルールが無ければ、どこのバージョンに入れて良いか分からない。

一番困るのは、ビルドモジュールからチケットへ辿りにくいことだ。
工程単位にバージョンをアサインしている場合、プロジェクト後半では、テストで見つけたバグ修正もあれば、顧客から要望が上がった機能追加もあるだろうし、設計が間違っていたという名の仕様変更のチケットもビルドモジュールに反映されているから、どのRedmineバージョンがビルドモジュールに紐づいているのか、が分からない。

すなわち、Redmineバージョンは、チケットのカテゴリのような単なる符号に過ぎず、ビルドモジュールに関連付けされてない。
従って、RedmineロードマップやRedmineの変更履歴が、実際のリリース計画やリリース履歴に対応付けされてない。

結合テストやシステムテストのようにプロジェクト後半のテスト工程では、いつリリースしたモジュールにどんな修正が反映されているのか、という変更管理をきちんと行うのが重要。
しかし、Redmineバージョンが変更管理におけるベースラインの意味と一致していないため、リリース計画に基づかない行き当たりばったりのパッチの集合体であるビルドモジュールが出来上がってしまう。

この手法は、突然発生した仕様変更やどの工程にも属さないタスクを管理しにくい点と、ビルドモジュールからのトレーサビリティが運用されていない点が最大の弱点だ。

【3】後者の場合も前者と似たような状況になる。
課題、設計、開発、テスト障害、本番障害ごとにRedmineプロジェクトを作っているので、各工程でそれぞれのチケットを書けば良い。
だから、最初はチケットに書かれたタスク(設計書を作る、機能を実装する、バグを直す)をこなしていけるので、順調に進むように見える。
しかし、前者と同様に、例えば、設計プロジェクトにあるRedmineバージョンをどのように対応付けるのかが分かりづらい。
設計だけ終わっても、実装が終わらなければ、モジュールが出来上がらないのだから、リリースとは言えない。
リリースと言えないのだから、バージョンを付ける必要もない。

また、リリース予定バージョンをビルドモジュールのリリースタグ(SubversionのTagみたいなもの)に対応付けた場合、複数のプロジェクト間で同じようなバージョンを作って、同期させるのが面倒。
実際のビルドモジュールには、設計プロジェクトの仕様変更もあれば、本番障害プロジェクトのバグ修正もあるだろうし、課題プロジェクトにある顧客の要望対応も含まれているだろう。
それらの対応が含まれているビルドモジュールから、チケットやバージョンへ辿っていくのが面倒なのだ。

つまり、プロジェクト間の横断的なチケット管理がやりづらい。

また、本番運用モジュールと新規開発中のモジュールは、それぞれリリースブランチとtrunkに分けてソース管理しているだろうから、各プロジェクトのチケットと対応しているSCMリポジトリが、Redmineプロジェクトと1対1対応していない時が多いだろう。
だから、モジュールに含まれているソース修正はどんなチケットの集まりなのか、が判別しにくい。

また、仕様変更のチケットは既に稼働中だから本番障害プロジェクトに置くべきなのか、それとも顧客から上がった要望だから課題プロジェクトに置くべきなのか、運用ルールがはっきりしない。
つまり、工程とチケットが関連していない場合、チケット登録が非常にやりにくい。

この方法の弱点は、複数プロジェクト間でバージョンを同期しづらい点と、ビルドモジュールからのトレーサビリティを運用しにくい点があげられる。

【4】BTSプロジェクトとリリース予定バージョンに関するチケット駆動開発本来の考え方は明確だ。
BTSプロジェクトは、SCMリポジトリ(つまりリリースするビルドモジュール)に1対1対応させる。
リリース予定バージョンは、ビルドモジュールのバージョンに対応付ける。

前者の理由は、SW開発の最終成果物であるビルドモジュールとチケットに書かれたタスクを紐づけるようにトレーサビリティを実現できることだ。
後者の理由は、ビルドモジュールからのトレーサビリティが実現できるだけでなく、リリース予定バージョンの集合が将来のリリース計画や過去のリリース履歴になるように自然に対応付けるためだ。

チケット駆動開発では、BTSバージョンをXPのイテレーション、Scrumのスプリントに紐づける。
更に、BTSプロジェクトをリリースするビルドモジュールの単位、つまりSCMリポジトリの単位に紐づける。
これによって、イテレーション単位に機能拡張していく開発スタイル、つまりXPの小規模リリースを容易に実現できる。
ソフトウェア開発を花壇のガーデニングのように、手入れしながら少しずつ育てていく開発スタイルへ持っていける。

Agile開発では、顧客に価値あるソフトウェアを早く届けることを最優先にする。
その意味は、動くビルドモジュールを確実に頻繁にリリースすることだ。

工程単位にBTSプロジェクトやBTSバージョンを割りつけると、最終的な成果物であるビルドモジュールへの対応付けがあいまいになってしまう。
設計が終わっても動くシステムは出来ておらず、リリースしたとは到底言えない。
開発が終わっても、単体テストがまともに終わっていないモジュールは品質が悪く、顧客にとって価値あるソフトウェアとは到底言えない。

そういうアンチパターンを見ていると、チケット駆動開発はTracのチケット管理から生まれたゆえにチケット管理が重要に見えるけれども、実はイテレーション管理(BTSのリリース予定バージョンの管理)こそがAgile開発の運用の肝なのだと実感できる。

実際のソフトウェア開発は、設計も開発もテストも同時並行しながら試行錯誤しながら作っていくものだ。
実際に作ってみて設計の不備が分かり、システムへの理解を深める。
実際にテストして動かしてみて、顧客が本来どんな動作を期待していたのか、を理解するようになる。
突発的なタスクの発生や、仕様変更はソフトウェア開発では日常茶飯事だ。

チケット駆動開発でAgileに開発していると、工程単位に綺麗に作ろうとするWF型開発は、SW開発の現場にそもそもマッチしていないのではないか、と思う。