Tracに有ってRedmineに無い機能
最近、Tracの情報がネットで溢れている。
Tracはプロジェクト管理機能を持つBTSとして一番有名なので、数々のプラグインが作られている。
その中で、Tracにはあるものの、Redmineには無い優れた機能についてメモしておく。
#誰か実装してくれないかな。
【元ネタ】
trac + TracBurndownプラグインでスクラム開発のすすめ
バグ収束曲線やバーンダウンチャートを描画するQuery Chart マクロ
メールをTracに蓄積 - MailArchiveプラグイン
【1】バグ収束曲線、バーンダウンチャート
バグ収束曲線は、累積バグ数と累積バグ解決数を日別にグラフ化したもの。
ソフトウェアメトリックスの中ではおそらく最も有名だろう。
特に、組み込み系の開発チーム、品質保証部の人達がよく使っているだろう。
バグをたくさん出した後にバグが減ると品質の歩溜りにいったと見なすことが多い。
バーンダウンチャートはバグ収束曲線とは逆に、残チケット数を日別にグラフ化したもの。
プロジェクトファシリテーションの実践で、プロジェクトの見える化の例としてよく使われる。
ソフトウェア開発の進捗管理は、残工数で測定する場合が多いから、バーンダウンチャートはまさにぴったりと言える。
プロジェクトリーダーとしては、これらのグラフは、システムの品質や進捗管理にまさに直結する重要な機能。
残念なことに、Redmineには上記機能がデフォルトではない。
でも、サマリ欄にチケットの作業状態の集計が表示されるから、原理的には実装可能のはず。
【2】コードレビュー
Redmineとは別に、下記のコードレビューWebシステムを導入しようとしていたが、未だインストールできてない。
PerlやPythonのライブラリのインストールは、Rubyよりもはるかに難しい。。
コードレビューは、プログラムの品質チェックだけでなく、コーディングルールや設計思想をメンバー全員で共有することが重要だ。
これによって、メンバーのスキルが底上げされるだけでなく、信頼感も醸成される。
GoogleやMSがコードレビューを真面目にやっている事実からしても、開発プロセスの中でも大事な工程の一つと言える。
しかし、プロジェクトがデスマーチになるほど、コードレビューはおきざりになりがち。
また、コードレビューするために大量に紙で印刷して準備するのも面倒。
だから、Web上でコードレビューのコメントを気軽に書いて、チャットし合うような雰囲気で使いたい。
できれば、レビューコメントもチケットのように、作業状態(修正前・修正済み)や重要度、優先度などの種別があるとなお良い。
そうすれば、レビューで指摘した箇所がクリティカルなのか、指摘された箇所は既に修正されたのか、を追跡できる。
Redmineにもリポジトリ欄があり、ソース差分を表示できるのだから、そこにコメントを付ける機能を実装すればいいだけ。
【3】メールのアーカイブ化
メーリングリストのメールなどをTracへ保管し、Tracで表示・検索できるプラグインがある。
このプラグインの利点は、インシデント管理に使えることだ。
顧客からの要望や障害の指摘などは、必ずメールベースで行うのが普通だろう。
電話対応では、いつ何を話したか、開発者も顧客も膨大な業務で忘れるから、必ずログとして残るメールを使うだろう。
以前は、メールのやり取りが増えると、インシデント管理するために、メールからExcelの管理台帳へコンバートして、要望を一つずつ手作業で追跡していた。
しかし、毎日のメールが20通以上に増えるともはや手作業では、作業漏れなどが発生して、管理できなくなる。
でも、このプラグインをうまく使えば、メールを分別して履歴として残して追跡すれば、インシデントのライフサイクルを管理できるだろう。
このインシデントが、プログラム修正につながる要件へ発展するから、要件管理にもなるかもしれない。
実際は、このインシデントから変更要求が確定すれば、チケットに起票して、その後はチケット駆動開発のワークフローに乗る。
できれば、メールに作業状態(受付・担当・着手中・終了)や重要度、優先度があれば更に管理しやすくなるだろう。
いずれの機能もTracで実装できるのだから、Redmineでも実装可能のはずだろう。
色々試してみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」の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)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
コメント