No Ticket, No Commit! #tidd
_shimadaさんが公開したNo Ticket, No Commitの画像を見つけたのでリンクしておく。
チケット駆動開発を実践しているチームならば、RedmineやTracのWikiにこの画像を張って、チケット駆動開発の唯一の規律である「No Ticket, No Commit!」を徹底させるといいと思う。
チケット駆動開発の良い点は、チームでソフトウェア開発する経験が少ない若手や自分でプロジェクトを仕切った経験が少ない新米プロジェクトリーダーにとって、良い習慣を身に付ける格好の場であること。
下記のポイントは実践しているだろうか?
バグ報告票(チケット)を他人にも分かりやすく書いているか?
バグの修正と検証は必ず担当者を代えて、成果物をチェックしているか?
バグ修正したソースは必ずコードレビューを実施しているか?
バグを修正する前に、必ず同類バグ調査を実施して、影響範囲を見極めているか?
バグ検証では、残存バグや同類バグが他にないか、デグレしていないか、という観点でテストしているのか?
RedmineやTracは本来はBTSだから、障害管理のフローに慣れれば、ソフトウェア開発の基本フローが身につく。
プロジェクト内部の作業を実施する前に、必ずチケットに作業内容を起票しているか?
作業履歴や仕様確認のやり取りは、チケットのコメントで残しているのか?
自分が担当のチケットに対して、作業状態や進捗率、実績工数を常に最新化しているか?
チケット集計機能を使って、自分やチームの状態を把握しているか?
ロードマップや変更履歴を見て、チームのゴールやチームにおける自分の役割を自覚しているか?
チケット駆動開発はプロジェクト管理をサポートするので、作業履歴をチケット上に残すことによって、報告・連絡・相談が自然に身に付く。
SCMコミットログにチケットNoを必ず書く運用ルールを徹底しているか?
チケットが1回のコミットで完了するなら「fixes #チケットNo」、複数回のコミットが必要なら「refs #チケットNo」で使い分けてコミットしているか?
コミットする単位は、ビルドエラーが出ないだけでなく、JUnitも通り、機能的にリリースできるレベルのものであるか?
「No Ticket, No Commit! 」の運用ルールでBTSとSCMを連携させることによって、トレーサビリティが実現でき、そのおかげで開発者自身も、他の人がどんな意図で修正したのか、その修正はリファクタリングしても大丈夫なのか、を自然に考える習慣が身に付く。
チケットにプロジェクトのタスク、リスクを全て載せて見える化しているか?
チケットの棚卸しは定期的に行っているか?
リリース計画を意識しながら、チケットの作業順序を決めているか?
リリース計画に基づいて、リリース予定バージョンを意識しながら、チケットを取捨選択しているか?
RedmineやTracの優れたチケット集計機能とチケットの属性の関連を意識して、チケットの属性を決めているか?
チケット駆動開発を運用できれば、新米プロジェクトリーダーでも、チケットの作業順序や担当を色々試すことによって、プロジェクトの回し方が分かってくる。
そして、プロジェクトのリスクを把握する予兆をチケット集計結果から嗅ぎ取ることができる。
更には頻繁なタスクの変更をリリース計画に取り込んで最新化することで、リリース計画の重要性を身をもって経験できる。
羅針盤があるからこそ、チームのゴールも分かるし、メンバーにゴールを共有してもらうこともできるのだ。
チケット駆動開発は仕事をさばく仕組み #agileto2010 #tidd: プログラマの思索にも書いたけれど、良い習慣を身につけた開発者は品質の良いプログラムを自然に書けるようになるから必ず成長すると確信している。
なぜなら、チケット管理システムに含まれる障害管理、プロジェクト管理の機能に慣れれば、ソフトウェア開発のベストプラクティスを自然に身につけることができるからだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- プロジェクトのリスクはコストの増減で管理する(2021.04.08)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
「Redmine」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- Redmine 4.1.2がリリースされた(2021.03.21)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
「ソフトウェア工学」カテゴリの記事
- なぜInfrastructure as Codeが必要なのか?(2021.04.18)
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
「プロジェクトファシリテーション」カテゴリの記事
- プロジェクトのリスクはコストの増減で管理する(2021.04.08)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- プログラマとスクラムが社会実装を変えていく #Findy_GovTech(2021.03.02)
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
「チケット駆動開発」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
「Agile」カテゴリの記事
- Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine(2021.04.18)
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- 要件定義プロセスはDXで終焉するのか(2021.04.01)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
最近のコメント