先日、ふとこんなことを思い、つぶやいたところ、さかばさんが拾ってくれて、いろいろ話しをしました。
チケット駆動開発(TiDD)について思うこと - Togetterまとめ
話の続き
本来のチケット駆動開発(TiDD)とは何なのか？ - Togetterまとめ
チケット駆動開発は、そろそろScrum+XPと合流してもいいと思うんだけどなぁ
僕自身は純粋なアジャイル開発や、チケット駆動開発をしているわけではないのですが、いろいろ思うところがあって、こういう発言をした次第です。
あと、チケット駆動開発自体を否定しているわけではなく、自分自身も(チケット駆動と明示してませんが)同じようなことをやっていて、良さを実感しているので、そのあたり誤解しないでもらえるとうれしいです。
思うところというのは、チケット駆動開発が開発サイクルをもち、それがアジャイルであること。自分の中でのチケット駆動開発の良さは、プロセスに限らず柔軟に対応できるところで、この発言に集約していると思ってます。
なので、TiDDのキモはこの3つだと思ってる。1.チケット(タスク)が見えることによる作業量の把握。2.終わりが見えることでの精神的安定。3.チケットとバージョンの連携によるトレーサビリティ。
開発サイクルについては、今あるサイクルに合わることで、従来型でもアジャイルな開発でもできると思っています。
チケット駆動開発が、アジャイル開発サイクルをもつことへの違和感はこんな感じです。
- 全般的に開発者に向いており、顧客への価値が見えない
- Redmineやバージョン管理ツールに強く依存していて、「ツールより対話を」と反しているように見える
- 対話のきっかけとしてのツール、という解釈もできるが
このことから、チケット駆動開発がアジャイルであるというよりは、チケット駆動開発を使うことでアジリティが向上する可能性がある。くらいのニュアンスがいいと思ってます。
なので、フレームワーク(枠組み)とみるより、実装と見たほうがしっくりきました。
そのあたりは、さかばさんのとも合うのかと思います。フレームワークは一つで、実装はいろいろという感じで。
