チケット管理のアンチパターンとベストプラクティス

主語がでかいタイトルですが、自分なりに考えようという目的です。
自分の思考の整理。
何か意見があればガンガンコメントなりツイートなりして欲しい。


前提として、
チケット管理システムは２つぐらいしか使ったことがないので、そちらに偏ってしまうかも。
ちなみにRedmineとBacklog。
（今がRedmineだから多分それに偏る気が）

　アンチパターン

アンチパターンというのかは分からないけど
今まで困ったこと、やりにくいと感じたこと、ダメだこりゃ、と思ったこと。


・運用フローが複雑

フローが複雑だと途端に人は面倒になる。なるべく抜け道を探し秩序が乱れる。
抜け道が見つかると割れ窓理論とかいうやつで、どんどんぐちゃぐちゃになる。
誰もフローに乗ってくれない状態になる。


・使われていない項目がある


なぜあるのかわからない項目。重要そうだけど埋めなくても良い項目。
誰かが埋めてくれるだろう、他の人も埋めてないし大丈夫だろうってなる。


・テンプレートがない


チケットはある程度パターン化されているはず。なのにテンプレートがない。
フリーフォーマットはチケットの書き方に一貫性がなくなり属人的になりやすい。


・抜け穴が多い（チケットが起票されない）


メールでやり取りして解決しちゃいました。
バグ見つけたんで直しときました。
口頭でやりとりして解決しちゃいました。

その時は早くて良いんだけどね。
それ、半年後に経緯を同じように誰が見ても理解出来るのか、ということにはならないか。


・チケットのコメント数が多い


やたら長いやり取りがされているのは、一概には言えないんだけど危険なサインなんじゃないかと思っている。



・チケットがポエムになっている


ポエムは僕みたいにブログに書こう。
もしくは飲み屋で一杯交わしながら、だ。


・チケットのコメントで別の問題解決が進行している


コメントの内容とチケットのタイトルが一致していなければそのサイン。
ゴールが間違っているか、ゴールはもう到達していませんか。
本当は終わっているのにそんなに工数かけてやるなよ！みたいなことになっちゃいそう。


・チケットの粒度が大きい


１つのチケットで複数の問題を解決しようとしている場合など。
「チケットのコメントで別の問題解決が進行している」にも通ずるけど。
１つのチケットで例えば１ヶ月かかるとか。そしたら、その間の進捗はどうやって管理していこう。
プロセスはちゃんと見えるだろうか。


・チケットからの外部リンクが死ぬ


「こちらのファイルサーバーは権限なくて私見られないんですよね・・・」
「404 not found」


・日々集計されていない


誰がどれだけのことをやっているのか。どれぐらい残っていてどれぐらいに終わりそうか。
そのぐらいの起票ペースで終息に向かっているのか増加しているのか。みたいな。


・チケット棚卸しマンがいない


無駄な時間に思えて人と対話して問題を見つめ直す作業は大事。
棚卸しマンは喋ってないでコード書けよという気持ちになる方もいるかもしれませんが、
あまりに対話のないチームだと大事に思えてきたりもする。


・チケットに対して作業しているのにチケットが更新されない


これもおそらく「デカすぎるチケット問題」だと思う。
チケットに対して細微な作業にどうしてもなってしまうので
わざわざチケット更新する必要もないしなぁ。
すると、「何してるかわからないけど時間かかって作業してる人」が生まれる。


・一見してチケットの主張がわからない、解決に必要な情報が不足している


何言ってんだ？このチケット。
あぁ、事象はわかったけどテストデータないじゃん、これじゃあ原因つかめないよ（怒り）

　ベストプラクティス

一応、アンチパターンに対してのアンサーとして書いてみてます。



・運用フローはシンプルにする、もしくは分担を明確にする


なるべく理解しやすいフローにする。不必要な流れは出来るだけカットする。
どうしても入ってくるフローは明確に役割を分けることで本来のその人の関心ごとに集中出来る。はず。


・使われていない項目は無くす、もしくは必須とする


そもそも必要ないんなら削ってしまう。それかバリデーションチェックしよう。


・テンプレートを用意する。オリジナリティがあるチケットが生まれてきた場合は新たなテンプレートを検討する


作業工程、作業タスクなどである程度パターン化出来るはず。あらかじめ用意しておく。


・チケット起票を作業の開始とする、もしくはタスク一覧などと１：１の関係にしておく


こういう作業があるのは分かりましたが、一体どこから始めれば・・・とならないように
３分間クッキング並みに「こちらにすでにご用意したチケットがあります」と渡してあげる。

それか、チケット駆動的にチケットを起票するところから作業スタートすることを習慣化する。
（これをチケット駆動開発というのかはわからないけど）


・チケットのコメント数が多い場合は別チケットにするなど趣旨の整理をする


そのチケットの本当にやるべきことって何？をいつも考えてチケットを切ることを恐れない。
チケットを切りやすい雰囲気を作る、とか大事なのかなぁと思う。


・チケットにポエムが書かれた場合はヒアリングし、wikiに書くなどする


ポエム書くな！で一蹴するのは結局理解されないきがするので、
FAQなり作ってしまうのが建設的かなと思う。
もしくは口頭レベルで済ませる。よっぽどしょうもなかったら。


・別の問題が進行し始めた場合、別チケットを起票しリンクする


脱線したら必ず別のチケットを起票する。必ずリンクさせる。


・外部リンクはなるべく死なせないするためN年後生きているかなどを考える


これに関してはそうしたほうが良い、とは思うけど、何がベストかは考えるのが難しい。
自分でコントロールできるリンクであれば常にリダイレクトを仕込むとかする。


・チケットの集計は日次や週次で行う


必ず統計を取り傾向と対策をアレしよう。
ただ、手作業じゃなくて自動化したほうが良い。


・チケット管理棚卸し会を開く、もしくは棚卸しマンを呼ぶ


デイリースタンドアップでも良いし、ちょっとした時間で良いのでやるだけで
作業理解度が変わってくると思う。


・進めているチケットに対して更新をルール化する（１日１回など）


まぁ厳密にやらなくても良いとは思うのだけど、
人によってチケット管理システムの使い方や頻度がバラバラというのはなるべく避けようという話。


・障害チケットにexerciseとactualとexpectedを。タスクにはstoryとgoalを書く


僕の勝手な思いつき。

障害チケット起票をするときにはexercise(何をしたか)、actual(実際どうなったか)、expected(どうなってほしいか)
を書けば良いと思う。
タスクにはこれこれこういう話がありまして、このタスクはこうなればおしまいです。ぐらいあれば良いかなぁ。

　この記事を読んだ人は

こんな記事も気になります。多分。
変なバイアス入らないようにこの記事書き終わってから読んだ。

色んな考えがあるけど、まぁ似通ってるかなぁ。

チケットをすばやく作成するためのベストプラクティス５つ

Redmineの使い方ベストプラクティスを考えてみる

チケット駆動開発はチケット管理ツールから離れて定義できるか

Redmineチケットの担当者を固定にする手法はWBS駆動に凝り固まり過ぎ

チケット駆動開発の理想と現実