No Ticket, No Commit! #tidd

_shimadaさんが公開したNo Ticket, No Commitの画像を見つけたのでリンクしておく。
チケット駆動開発を実践しているチームならば、RedmineやTracのWikiにこの画像を張って、チケット駆動開発の唯一の規律である「No Ticket, No Commit!」を徹底させるといいと思う。

Twitter / @_shimada: @akipii TYPOでDevelopmentから"e"が抜けてました >< 修正版です http://gyazo.com/3f9088870decdeda66c7da5c8d952475.png

Twitter / @_shimada: @akipii 著書、参考にさせてもらってます！自分とこのプロジェクトRedmineのhomeに貼るために作りました。某レコード屋さんのインスパイアものなので、この画像は出所不明瞭なpublic domainという扱いでお願いします。（笑

チケット駆動開発の良い点は、チームでソフトウェア開発する経験が少ない若手や自分でプロジェクトを仕切った経験が少ない新米プロジェクトリーダーにとって、良い習慣を身に付ける格好の場であること。
下記のポイントは実践しているだろうか？

バグ報告票(チケット)を他人にも分かりやすく書いているか？
バグの修正と検証は必ず担当者を代えて、成果物をチェックしているか？
バグ修正したソースは必ずコードレビューを実施しているか？
バグを修正する前に、必ず同類バグ調査を実施して、影響範囲を見極めているか？
バグ検証では、残存バグや同類バグが他にないか、デグレしていないか、という観点でテストしているのか？

RedmineやTracは本来はBTSだから、障害管理のフローに慣れれば、ソフトウェア開発の基本フローが身につく。

プロジェクト内部の作業を実施する前に、必ずチケットに作業内容を起票しているか？
作業履歴や仕様確認のやり取りは、チケットのコメントで残しているのか？
自分が担当のチケットに対して、作業状態や進捗率、実績工数を常に最新化しているか？
チケット集計機能を使って、自分やチームの状態を把握しているか？
ロードマップや変更履歴を見て、チームのゴールやチームにおける自分の役割を自覚しているか？

チケット駆動開発はプロジェクト管理をサポートするので、作業履歴をチケット上に残すことによって、報告・連絡・相談が自然に身に付く。

SCMコミットログにチケットNoを必ず書く運用ルールを徹底しているか？
チケットが1回のコミットで完了するなら「fixes #チケットNo」、複数回のコミットが必要なら「refs #チケットNo」で使い分けてコミットしているか？
コミットする単位は、ビルドエラーが出ないだけでなく、JUnitも通り、機能的にリリースできるレベルのものであるか？

「No Ticket, No Commit! 」の運用ルールでBTSとSCMを連携させることによって、トレーサビリティが実現でき、そのおかげで開発者自身も、他の人がどんな意図で修正したのか、その修正はリファクタリングしても大丈夫なのか、を自然に考える習慣が身に付く。

チケットにプロジェクトのタスク、リスクを全て載せて見える化しているか？
チケットの棚卸しは定期的に行っているか？
リリース計画を意識しながら、チケットの作業順序を決めているか？
リリース計画に基づいて、リリース予定バージョンを意識しながら、チケットを取捨選択しているか？
RedmineやTracの優れたチケット集計機能とチケットの属性の関連を意識して、チケットの属性を決めているか？

チケット駆動開発を運用できれば、新米プロジェクトリーダーでも、チケットの作業順序や担当を色々試すことによって、プロジェクトの回し方が分かってくる。
そして、プロジェクトのリスクを把握する予兆をチケット集計結果から嗅ぎ取ることができる。
更には頻繁なタスクの変更をリリース計画に取り込んで最新化することで、リリース計画の重要性を身をもって経験できる。
羅針盤があるからこそ、チームのゴールも分かるし、メンバーにゴールを共有してもらうこともできるのだ。

チケット駆動開発は仕事をさばく仕組み　#agileto2010 #tidd: プログラマの思索にも書いたけれど、良い習慣を身につけた開発者は品質の良いプログラムを自然に書けるようになるから必ず成長すると確信している。
なぜなら、チケット管理システムに含まれる障害管理、プロジェクト管理の機能に慣れれば、ソフトウェア開発のベストプラクティスを自然に身につけることができるからだ。