リーダーに聞くな、チケット管理システムに聞け
Redmineは使い込むほど面白い機能がふんだんにある。
ラフなメモ書き。
【元ネタ】
期日が間近のRedmineチケットをメールで通知する: プログラマの思索
期日が間近のチケットをメールで通知する(リマインダ機能) ? Redmine.JP
Class: Mailer ? Documentation by YARD 0.8.6.1
チケットが更新されずに放置されると、リーダー一人で修正するのは結構大変だ。
むしろ、放置されたチケットを毎朝通知して、担当者が棚卸しすべきだろう。
普通は、毎朝、誰かがクエリでフィルタリングして、棚卸しすべきチケットを一覧にしてメールで通知する運用になるだろう。
だが、そのような運用は、Redmine自らが通知すればいいはずだ。
リーダーに聞かずとも、Redmineに全ての作業情報があるのだから、チケット管理システム自身に聞けばいいだけのことだ。
現在のRedmineには、期日が間近になったチケットを通知する機能がある。
できれば、この機能をさらにカスタマイズすればいい。
30 6 * * * root cd /path/to/redmine ; rake redmine:send_reminders days=3 RAILS_ENV=production
Sends reminders to issue assignees Available options:
:days => how many days in the future to remind about (defaults to 7)
:tracker => id of tracker for filtering issues (defaults to all trackers)
:project => id or identifier of project to process (defaults to all projects)
:users => array of user/group ids who should be reminded
Class: Mailer ? Documentation by YARD 0.8.6.1のソースを見ると、上記のオプションが使える。
更に、ステータス、開始日、カテゴリ、担当者などを検索条件に入れて、メール本文にチケットの属性をもっと増やして通知すればいいだろう。
チケット管理システム自身が通知する機能は、最終的には、ベースラインごとのメトリクス情報を出力する機能に発展できるだろう。
つまり、リリース日やマイルストーンのようなベースラインごとに、その時点のチケット集計情報から得られる進捗や品質、工数の情報を一括集計して出力する機能になってくる。
上記の機能は、メールで出力するわけだが、用途によっては、PDFなり紙の帳票で出力してもいい。
そのような機能は最終的には、チケット管理システムがソフトウェア開発のERPとなり、ベースラインごとの情報を出力して、リーダーやPM、経営者が分析する情報の元ネタになるだろう。
色々考えてみる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
コメント