チケット駆動開発の普及はタンポポでいい

Redmineやチケット駆動開発の普及はどうすればいいか、聞く時がある。
自分の考えをメモ。

Redmineによるチケット駆動開発の普及は、僕はそれほど考えていなかった。
周囲が注目して自然に普及していった感じ。

自分のプロジェクトで、RedmineのVer0.6.3の頃から運用してみて、プロジェクト終了後も成功事例の一つとしてイントラで公開していた。
その理由は、僕自身がその事例を参照したかったのもあるし、他人に説明する時に、実際のRedmineを見てもらった方が理解しやすいからだ。

僕のRedmineでは、ロードマップがリリース履歴になるように、RedmineバージョンがSVNのリリースタグ＋Hudsonのビルド番号としてリネームしている。
そのバージョンに紐づく終了チケットは、リリースに必要なタスク一覧であり、それらチケットには必ずSVNの修正履歴がリンクしていて、どのチケットでどのソースや設計書が修正されたのか、をSVNリビジョンから辿ることができるようにしている。
SVNリビジョンをクリックすれば、ソースのDiffをRedmine上で見れるから、どういう意図でパッチを当てたのか、すぐに分かる。

また、Wikiにプロジェクトで必要な情報の説明やリンク、チケット駆動開発のアイデアを書いて情報共有している。
そして、フォーラムに過去のふりかえりの内容を時系列に並べていて、後から参照できるようにしていた。
だから、開発者は暇な時に、Wikiやフォーラムを結構見ていて、チケット駆動開発の運用ルールをおさらいしたり、過去のふりかえりから自分やチームがどれだけ成長したのか、を確認していたようだ。
特に、過去のふりかえりの履歴は、若手がよく参照していて、モチベーション向上に役立ったみたい。

他チームがRedmineについて質問される時、過去のRedmineのロードマップを見せながら、ロードマップがリリース計画作りであること、リリースするソース修正一覧台帳はExcelではなくRedmine＋SVNで代用できること、実績工数や予定工数の比較はRedmineのWorkTimeプラグインで代用できること、などを話している。

又、Redmineプロジェクトをtrunkやリリースブランチ単位に作っていたので、Redmineプロジェクトをどのように作るべきか、という事例の一つとして紹介していた。

特に、チケットの中身やチケットの粒度は、あれこれ議論するよりも、実際に運用している各チームのRedmineを見て、参考にするなり反面教師にする方が手っ取り早い。

僕は無理にRedmineを他チームに押し付けようとしていない。
むしろ、タンポポのように、やりたい人があちこちに散らばって、実際に実践して広まればいいと思っている。
Redmineでうまくプロジェクト管理できた人もいれば、逆にRedmineが掛け声だけで終わり、使えなかったと言われて終わるかもしれない。

タンポポはその可憐な外見とは裏腹に、例えば砂浜に咲くタンポポは根が5メートル以上まで伸びてしぶとく繁殖すると読んだことがある。
同様に、Redmineが一度プロジェクトに根付けば、今後Redmine無しでプロジェクト管理するのは考えられなくなるはずだ。
一度根を張ったタンポポがしぶとく繁殖するように、Redmineも一度成功すれば、自分たちの運用ルールを作り込みながら、プロセス改善していくチャンスが生まれて、チームが学習して成長する仕掛けが整うはず。

だから、あえてRedmineを普及しようとは思ってないし、タンポポの種のように勝手に飛んで広がっていくだろうと思っている。