自分が今いるチームは、3か月半ぐらい前にTracを導入して、チケット駆動開発に移行しました。今では、チケットを中心に作業を進め、進捗の報告もチケット上で行っています。そんなチケットですが、より作業がスムーズに進むよう3タイプの人を意識して書くように工夫しています。詳細に書く同僚や先輩に向けてチケットを書くときには、できるだけ詳細に書くように注意しています*1。発生手順(どういう前提条件で、どう操作をすれば発生するのか)根本原因(ただの単純ミスなのか、設計上の問題なのか)修正方法(どのクラスを直すか、水平展開のポイントはどこか)といった点を詳細に書いています。Trac導入前だと、これらを口頭で説明したり、手書きのメモで箇条書きにして渡したりしていました。これだと相手に意志がうまく伝わらず、直したと言われてもチェックしたら直っていなかったということが多々ありました。自分の場合、口頭だと説明を端折りがちなので、余計にうまくいってなかったのかもしれません。同僚や先輩へは、詳細になっているか、作業をするにあたって不足している情報がないかを意識して書くようにしています。上司に向けて書くチケットの場合、詳細の前に要点と結論だけを書くようにしています。影響度(システム全体に影響がある*2のか、あまり重要でない問題*3なのか)修正工数(原因から考えてどのぐらいか)といった点をシンプルに書きます。導入してしばらくは詳細だけを書いていたんですが、それだと「結論はなんなの?」ということとともに、改めて上のようなポイントを聞かれました。詳細は必要だけれども、そもそも判断してほしいことと、判断材料はなんなのか。それがあったので、上司へは最初に要点と結論を書くようにしています。「あとで見る人」というのは、未来の自分や同僚、上司、もしくは新しくプロジェクトに入る人を指しています。いう人に向けては、ドキュメントだけではわからないようなところを意識して書いています。具体的には、以下のような点を残すようにしています。細かいメモ検索用キーワード*5Trac導入前は、ドキュメントに残っていないような点を確認しようと思ったら、関係者に聞いて回るしかないという状況になっていました。それで相手が覚えていればラッキーですが、「なんだっけ・・・?」ということも頻繁ありました。これだと手間がかかってしょうがないし、最悪以前やったのと同じことをやり直すなんてこともありました。いった無駄をなくすために、あとで見るという点も意識して書くようにしています。チケット駆動開発を、広めたい!チケット駆動開発になってからは、チームとして仕事がスムーズに進むようになりました。質問をするときも「チケットXXX番なんですが〜」だけで「ああ、あれね〜」とテンポよく話が進むようになりました。ほかの人の詳細な状況がわかるので、それに対して提案をしたり、フォローをしたりといった、細かい連携ができるようになりました。自分の現状で残念な点が一つ。それは、まだ自分たちのチーム(現状3名)だけしか使っていないということ。ほかのチームやプロパーさんとの調整は、従来通り口頭やメールで行っているのが現状です。もったいないなぁという気がします。今後はチケット駆動開発を広めて、もっともっとスムーズに作業ができるようにできればと思います(でも、どうすればいいんだろ・・・)。*1:また、自分がやることになるチケットもできるだけ詳細に書いています。これは、自分が忙しくなったり、休んだりしてほかの人にチケットを巻き取ってもらうときに、スムーズにお願いできるように(口頭で伝えなくても済むように)するためです。あと、後述のあとで見る人のためでもあります。クラスがリファクタリングされていました。etc)を、すごく検索しやすくするツールを作りました。タグから、どのフレームワークについてよく質問されているのかプログラミング言語ごとに分析してみた月別アーカイブはてなブログをはじめよう!chiheisenさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。