Backlogチケットの棚卸しにて、進捗が途中で止まっていたチケットの解消、担当者不在チケットの解消まで実施していました。
- 担当者無しチケットへの自動定期アサインにて棚卸しの効率化を図ってみた | DevelopersIO - https://dev.classmethod.jp/
- 年単位で停留していた課題を「対話型ファシリテーションの手ほどき」参考に棚卸しした記録 | DevelopersIO - https://dev.classmethod.jp/
他によくある例としてコンテキストが不明瞭で進まないチケット、という事例が存在します。チケット起票時に記載してほしいことを明示する場合には要記載内容の導線を記載したテンプレートの利用が好ましいでしょう。BackLogは種別毎に課題テンプレートが設定可能になっています。
課題のテンプレート – Backlog ヘルプセンター - https://support-ja.backlog.com/
サービス開発室で利用頻度の高い種別にはテンプレート適用済みでしたが、用途不明で過去数年の登録チケット数一桁の種別や、用途上GitHubのIssueとの二重管理になる種別もありました。管理の手間を減らすため、今回はこの2点の種別を削除しました。実際に種別を削除した場合の動作例となります。
種別を削除する
Backlogの種別は既に登録されている記事の有無によって削除時の処理が変わってきます。存在しなければ消滅するだけですが、存在している場合は種別の移行先の選択が必要です。
登録記事がある場合は以下のダイアログが表示されます。
そして、削除した場合にSlack連携を行っていると以下のように通知が届きます。
種別が変わったページを纏めて通知するのではなく、各ページがそれぞれ種別変更を行ったと通知が届くため、Slack連携による操作時通知を確認に用いている場合は事前に削除することを周知しておきましょう。
あとがき
今回の種別整理にてフリーフォーマットでのチケットは基本発行されなくなりました。出来ることなら、コンテキストが常に明確になるようなテンプレートへ更新したいところですが、汎用的な構成は中々難しいものです。
種別の変更操作は変更する理由の記述までカバーされていません。更新理由を逐次確認している場合、種別変更後に種別削除によるものとコメントしておく方が無難でしょう。
4
