Redmine1.4におけるNo Ticket, No Commitの強化
Redmine1.4の機能改善において、No Ticket, No Commitの強化につながる機能があったのでメモ。
【元ネタ】
Redmine 1.4新機能紹介: チケットとリビジョンの関連づけの追加・削除 | Redmine.JP Blog
Twitter / @mkinside82: Commit Relation Editor - Plugins - Redmine
チケット駆動開発の基本ルールは@machuさんが提唱された「No Ticket, No Commit」にある。
この運用ルールは本来、障害管理において、どの障害に対してソースの修正がなされたのか、その修正履歴とバグチケットを紐づける運用から生まれた。
そこから、「チケット無しでソースのコミット不可」の運用ルールとなり、チケット駆動開発では、成果物の変更があったら必ずチケットに作業履歴を残す運用へ発展していく。
つまり、「No Ticket, No Commit」は成果物の変更のトレーサビリティを保証してくれる非常に重要な運用ルール。
この運用ルールがあるからこそ、開発者は変更管理を意識しなくても、変更管理を厳格に運用できる。
しかし、コミット時にチケットのNoを間違えたり、他のチケットNoも追加したくなる場合は多い。
GitやMercurialがコミット履歴の改変を行える方向へ進化したように、チケットとソースの紐づけも後から修正できるようにしたいと思うのはとても自然だ。
Mercurialの黒魔術: プログラマの思索でも書いたように、マージ作業のUndoやRedoができるればマージ作業の修正ミスを恐れることなくマージ作業ができる。
同様に、チケットと成果物のトレーサビリティの保証も、RedoやUndoができれば、BTSにたまったチケットのデータを保守することで、意味ある作業情報を蓄積できるようになる。
既に@haru_iidaさんが Commit Relation Editor pluginを公開されていたが、その機能とRedmine本家の機能がほとんど同じらしい。
記事を読む限り、画面UIはとても使いやすそうだ。
こういう細かい機能改善が積み重なることによって、ツールが使いやすくなるだけでなく、ソフトウェア開発のベストプラクティスがツールの1機能として実現されていくのだろう。
それによって、ツールの運用に慣れれば、自然にソフトウェア開発の良い習慣が身につくようになるのだろう。
更に、世の中の問題をできるだけソフトウェアで解決できる問題へ変換することによって、プログラマが活躍できる場が増えていくのだろう。
Redmineの機能はまだまだ進化する余地がたくさんあるように思う。
| 固定リンク
「Redmine」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
- PMO観点でRedmineの使い方とは何か(2020.12.20)
- 若手プロジェクトリーダー向けのRedmine教育資料の構想(2020.12.24)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
コメント