自分が今いるチームは、3か月半ぐらい前にTracを導入して、チケット駆動開発に移行しました。
今では、チケットを中心に作業を進め、進捗の報告もチケット上で行っています。
そんなチケットですが、より作業がスムーズに進むよう3タイプの人を意識して書くように工夫しています。
同僚、先輩 → 詳細に書く
同僚や先輩に向けてチケットを書くときには、できるだけ詳細に書くように注意しています*1。
バグ報告のチケットなら、
- 発生手順（どういう前提条件で、どう操作をすれば発生するのか）
- 根本原因（ただの単純ミスなのか、設計上の問題なのか）
- 修正方法（どのクラスを直すか、水平展開のポイントはどこか）
といった点を詳細に書いています。
Trac導入前だと、これらを口頭で説明したり、手書きのメモで箇条書きにして渡したりしていました。
でも、これだと相手に意志がうまく伝わらず、直したと言われてもチェックしたら直っていなかったということが多々ありました。
特に自分の場合、口頭だと説明を端折りがちなので、余計にうまくいってなかったのかもしれません。
なので、同僚や先輩へは、詳細になっているか、作業をするにあたって不足している情報がないかを意識して書くようにしています。
上司 → 要点と結論を重視
上司に向けて書くチケットの場合、詳細の前に要点と結論だけを書くようにしています。
例えば、修正判断を仰ぐようなバグ報告なら
といった点をシンプルに書きます。
Trac を導入してしばらくは詳細だけを書いていたんですが、それだと「結論はなんなの？」ということとともに、改めて上のようなポイントを聞かれました。
詳細は必要だけれども、そもそも判断してほしいことと、判断材料はなんなのか。
それがあったので、上司へは最初に要点と結論を書くようにしています。
あとで見る人 → ドキュメントの隙間を意識
「あとで見る人」というのは、未来の自分や同僚、上司、もしくは新しくプロジェクトに入る人を指しています。
こういう人に向けては、ドキュメントだけではわからないようなところを意識して書いています。
具体的には、以下のような点を残すようにしています。
- このチケットの経緯
- 作業内容（同じようなことをやるときに、具体的に何をやればいいのかわかるように）
- メールでのやり取りがあれば、そのコピペ*4
- 参考にしたURL,書籍
- 細かいメモ
- 検索用キーワード*5
Trac導入前は、ドキュメントに残っていないような点を確認しようと思ったら、関係者に聞いて回るしかないという状況になっていました。
しかも、それで相手が覚えていればラッキーですが、「なんだっけ・・・？」ということも頻繁ありました。
これだと手間がかかってしょうがないし、最悪以前やったのと同じことをやり直すなんてこともありました。
そういった無駄をなくすために、あとで見るという点も意識して書くようにしています。
チケット駆動開発を、広めたい！
チケット駆動開発になってからは、チームとして仕事がスムーズに進むようになりました。
例えば、質問をするときも「チケットXXX番なんですが〜」だけで「ああ、あれね〜」とテンポよく話が進むようになりました。また、ほかの人の詳細な状況がわかるので、それに対して提案をしたり、フォローをしたりといった、細かい連携ができるようになりました。
ただ、自分の現状で残念な点が一つ。
それは、まだ自分たちのチーム（現状3名）だけしか使っていないということ。
ほかのチームやプロパーさんとの調整は、従来通り口頭やメールで行っているのが現状です。
もったいないなぁという気がします。
なので、今後はチケット駆動開発を広めて、もっともっとスムーズに作業ができるようにできればと思います（でも、どうすればいいんだろ・・・）。
*1:また、自分がやることになるチケットもできるだけ詳細に書いています。これは、自分が忙しくなったり、休んだりしてほかの人にチケットを巻き取ってもらうときに、スムーズにお願いできるように（口頭で伝えなくても済むように）するためです。あと、後述のあとで見る人のためでもあります。
*2:システムが止まる、データが狂う(これが発生すると永続的な問題になり、最悪システムをリカバリするしかなくなる)、など
*3:表示が間違っている、ほとんどのユーザが行わない条件でのみ発生する、など
*4:メールのままだと受け取った人以外が経緯を知ることができないので、チケットに移しておく
*5:バグが再発したときや、似たようなことがあったときに、素早く探せるようにしておく
