チケットドリブン開発を導入するには
プログラマではあれば、チケットドリブン開発は情報のフローがはっきりしており、馴染みやすい考え方だろう。
しかし、このような仕組みをプロジェクトに導入するにはさまざまな困難がつきものである。そこで、まずは「ソースをコミットするときはチケットを書く」というところからはじめるとよい。これを足がかりに、「ソースを編集する前にはチケットを書く」「会議の内容はチケットにばらして登録する」というように他の業務にも拡大していく。
また、チケットドリブン開発ではRSSリーダが必須となる。作業の指示や報告にチケットを発行していくと、1日で非常に多くのチケットが流れることになる。Tracでは、チケットリストをRSSとして出力する機能があるので、これを使いRSSリーダでチケットを読むようにするとよい。新規チケットが発行されたときなど、Webをチェックしなくても作業内容を把握することができるからだ。
- コミュニケーションの齟齬によるバグの発生を低減できる
- 作業の見える化によって進捗の把握や引き継ぎが容易となる
- 「ソースをコミットするときにチケットを書くこと」からはじめ、他の業務にも適用していく
- チケットはRSSリーダで読む
チケットドリブン開発のポイント
筆者の経験から
筆者は、昨年まで札幌に住みながら東京が中心の仕事をしていた。それらの仕事はネットを経由して行っていたため、日常のコミュニケーションはSkypeやテキストチャットが主体で、会議にはWebカム経由で参加をしていた。
そのため、必然的に情報をすべてネットに集めないと作業ができない状況にあった。また複数の仕事を同時に行っているため、メールやチャットで断続的に情報をもらうと把握がむずかしかった。
そこで「作業依頼はすべてTracのチケット経由で行ってもらい、チャットやメールで作業依頼されても、チケットにならない限り作業をしない」と明示したのがチケットドリブン開発のはじまりである。
作業の依頼主も非常に好意的で、この無茶な要求を受け入れてくれたため、遠くはなれた環境でも、開発がスムーズに行うことができた。またソースの資料はTracにチケットという形で蓄積されているため、引き継ぎも容易に行うことができた。
このようなチケットドリブン開発は、作業の依頼主の協力が不可欠である。また作業の見える化による、進捗把握の容易さ、引き継ぎの容易さなどを考えると依頼主側にも多くのメリットがある。
これを機会にぜひチケットドリブン開発をはじめてみてはいかがだろうか? タイトルへ戻る