チケット駆動開発が進むべき道

さかばさんのBlogにTiDD(チケット駆動開発)の分析が書かれているのでメモ。

【元ネタ】
必然から生まれたチケット駆動開発 - XP祭り関西2009 その３-: ソフトウェアさかば

TiDD：チケット駆動によるアジャイル開発法: ソフトウェアさかば

TiDD：チケット駆動開発: ソフトウェアさかば

[TiDD] チケット駆動開発とXPの共通点: ソフトウェアさかば

[TiDD]チケット駆動開発と見える化: ソフトウェアさかば

[TiDD] チケット駆動開発によるフロントローディング: ソフトウェアさかば

[TiDD] プラクティスから方法論へ: ソフトウェアさかば

TiDDとアジャイル開発に強い関連性があると色んな観点から分析されている。
TiDDはまだ定義すらない曖昧な概念であり、プロセスですらない。
今後進むべき方向は、方法論やベストプラクティス集を定義することだろう。

僕はTiDDを実践してみて、TiDDはアジャイル開発のベストプラクティス集みたいなものだと直感している。
それは丁度、オブジェクト指向のデザインパターンのようなもの。
目に見えないけれど誰もが理解できる抽象概念でありながら、実際のプログラミング言語で実装して試すことができる。

そして、方法論よりもベストプラクティス集の方が現場でははるかに役立つ。
オブジェクト指向の方法論はRUPだと思うが、あまりにも重過ぎる。
確かにその内容は勉強に値するし、なるほどと思う部分は多々あるけれど、実際の現場で試そうとするとあまりにもハードルが高い。

アジャイル開発もウォーターフォール型開発やRUPなどの重厚プロセスのアンチテーゼとして生まれたが、誰にでも使えるように抽象化するほど、現場で運用する時のギャップが大きくなる。
TiDDはBTSというツールに依存しすぎている、という批判を受けた時があったけれど、現場ですぐに実践できるなら、僕はそれでいいと思う。

実際のソフトウェア開発で、目の前にあった問題を解決しようとしたら、RedmineやTestLinkのようなツールが必要だっただけ。
むしろ、それらのツールが持つ機能が一つのベストプラクティスなのだ、と気付き、過去に読んだ本の専門用語が対応する経験を通じて、プロセス改善におけるツールの重要性を感じている。

アジャイル開発がこれだけ注目され、その有効性が理解できているのに実践できないのは、単に技術力がないだけなのだ、と直感している。
ソフトウェア開発の諸問題はTiDDのような技術力で全てカバーできるという確信を更に考察していきたい。