TiDDを実践して気付いたことpart6～TiDDでAgile開発を実践して分かってきたこと

Redmineによるチケット駆動開発(TiDD)を実践して気付いたことをもう一度まとめてみる。

TiDDをAgile開発として運用するには、下記の運用ルールが最低限必要だと思う。

１・チケットをXPのタスクカードのように扱う
２・チケット集計結果をXPのタスクボードのように扱う
３・ロードマップをリリース計画のように扱い、小規模リリースを運用する

１によって、XPのタスクカードをTiDD上で実現できる。
更に、XPのストーリーカード、ScrumのバックログもBTSチケットで表現可能だから、Agile開発のタスクや要望は全て、TiDD上で実現できるはず。
また、チケットに構成管理情報を付与できるから、成果物の変更もチケットで追跡できる。

２によって、PFのかんばんをTiDD上で表現できる。
つまり、タスクの作業状態、イテレーションの進捗管理は全て、TiDD上でリアルタイムにモニタリングできる。
これを実現できるのも、チケットに進捗情報を付与できて、チケット集計を自動化できるおかげだ。

３によって、XPの小規模リリースを実現できる。
つまり、２～４週間のイテレーションで、小刻みに機能拡張してリリースを繰り返すことを制御できるようになる。
XPの計画ゲームは、どのバージョンにどの機能をリリースしていくか、というリリース計画の作業に落とし込める。
３の性質によって、TiDDはAgile開発プロセスを実装できるだけでなく、自然に繰り返し開発にもなる。

そして、Agile開発の最大の特徴である繰り返し開発の運用が難しい理由は、下記でまとめられると思う。

１・繰り返し開発はイテレーション管理が難しい
２・繰り返し開発において、インクリメンタル型開発と反復型開発を混同してる
３・繰り返し開発は並行開発でもあるため、並行開発の制御が難しい

１は、短いサイクルで頻繁にリリースを繰り返すために、各イテレーションのタスク管理が煩雑になるから。
本番リリースのタイミングはWF型開発よりも頻繁だから、たとえ小規模の改善であっても、開発チームに対するプレッシャーも大きい。
更に、リファクタリングや度重なる機能改善のため、ソース管理も難しくなる。

２は、繰り返し開発を使い分ける戦略を開発チームが持っていないことに尽きる。
Agile開発の基本は、リリースを最優先にするインクリメンタル型開発。
だからこそ、リリースする機能(スコープ)を制御することを重視する。

しかし、システム全体を少しずつ作り上げる反復型開発では、リリースのタイミングは随分後のため、度重なる仕様変更や手戻り作業を制御できず、スコープをどんどん膨らましてしまいがち。
むしろ、反復型開発は、テスト工程のように品質を作りこむ状況の方が扱いやすい。

３は、インクリメンタル型開発が実は並行開発でもあるという事実を理解していないことに尽きる。
一度リリースしたシステムはそれで終わりではなく、運用保守モードとして生き続ける。
更に、裏では次の新規開発を進めているから、2系統のコードラインを常時保守し続けている。
組込製品やパッケージ製品ファミリーの開発では、更にたくさんのコードラインを同時に保守し続けるため、品質管理が難しく、そのコストも大きい。

本番ブランチの障害修正は、裏で開発中のtrunkにも影響し、マージ作業が発生する。
そのタイミングを忘れずに管理していくのは、ツールによるサポートがなければ非常に煩雑になる。
それらを、TiDDはタスク管理でサポートするし、GitやMercurialはPullやPushでサポートする。

上記がTiDDでAgile開発を実践して分かってきたことだが、まだまだノウハウがあると思うので探っていきたい。