Redmineのチケット管理のアンチパターン事例

チケット管理のアンチパターン事例が公開されていたのでメモ。
二つの記事共にとても参考になる。

【参考】
redmineを使ったチケット管理の失敗のさせ方 - 文系プログラマによるTIPSブログ

チケット管理のアンチパターンとベストプラクティス - Javaプログラマーのはしくれダイアリー

二つの記事に記載されているアンチパターン、プラクティスのタイトルだけを拾ってみた。
タイトルを見るだけでも、ああそうだなあ、とうなずくものがある。

(引用開始)
【チケット管理のアンチパターン１】
・進捗率をユーザの裁量で更新させる
・対象バージョン「なるはや」
・チケットの内容が途中から変わる
・増殖するプロジェクト固有のトラッカー
・「本日は打ち合わせありがとうございました」
・対象バージョンの書式がバラバラ
・チケットに添付されまくる仕様書
・チケットの題名が「仕様調査依頼」
・社内redmineと社外redmineのテーマが同じ
・既に退場した人のユーザが沢山残っている
・ステータス「保留」
・「単体テスト」と「単体試験」
・wikiにある「チケットの更新フロー」
・何故か私はこのチケットが終了できないんですよね
・乱立するredmine
(引用終了)

(引用開始)
【チケット管理のアンチパターン２】
・運用フローが複雑
・使われていない項目がある
・テンプレートがない
・抜け穴が多い（チケットが起票されない）
・チケットのコメント数が多い
・チケットがポエムになっている
・チケットのコメントで別の問題解決が進行している
・チケットの粒度が大きい
・チケットからの外部リンクが死ぬ
・日々集計されていない
・チケット棚卸しマンがいない
・チケットに対して作業しているのにチケットが更新されない
・一見してチケットの主張がわからない、解決に必要な情報が不足している
(引用終了)

(引用開始)
【チケット管理のプラクティス】
・運用フローはシンプルにする、もしくは分担を明確にする
・使われていない項目は無くす、もしくは必須とする
・テンプレートを用意する。オリジナリティがあるチケットが生まれてきた場合は新たなテンプレートを検討する
・チケット起票を作業の開始とする、もしくはタスク一覧などと１：１の関係にしておく
・チケットのコメント数が多い場合は別チケットにするなど趣旨の整理をする
・チケットにポエムが書かれた場合はヒアリングし、wikiに書くなどする
・別の問題が進行し始めた場合、別チケットを起票しリンクする
・外部リンクはなるべく死なせないするためN年後生きているかなどを考える
・チケットの集計は日次や週次で行う
・チケット管理棚卸し会を開く、もしくは棚卸しマンを呼ぶ
・進めているチケットに対して更新をルール化する（１日１回など）
・障害チケットにexerciseとactualとexpectedを。タスクにはstoryとgoalを書く
(引用終了)

「本日は打ち合わせありがとうございました」「チケットがポエムになっている」「ステータス「保留」」「乱立するredmine」は、すぐに笑い出してしまった。
似たような例として、「チケットタイトル：お世話になっております」(@agilekawabataさん)もある。

また、チケットにメール文化を持ち込ませないようにすれば、メール本文よりもチケットの文章量は10分の一に削減できる、と@g_maedaさんが言っていたことも思い出す。

チケット管理のプラクティス、アンチパターンは、僕も過去に何度も書いてきたし、Redmine勉強会でも数多くの事例が披露されてきたが、もう一度、整理して経験知としての知識体系にできたらいいなあ、と思う。