プロジェクト管理サーバーのメトリクスは教科書みたいだ
プロジェクトが一段落したから、メトリクスを出力してみた。
その時に気付いたことをメモ。
【元ネタ】
プログラマの思索: プロジェクト管理サーバーとは
プログラマの思索: アジャイル開発の弱点をプロジェクト管理サーバーが助ける
【各種ツール】
BitNami :: Trac
All In One TestLink JP
TestLinkCnvMacro
StatCVS - Repository Statistics
StatSVN - Repository Statistics
Tracから、カテゴリ、マイルストーン、解決方法、種類などの観点のチケット集計結果。
TestLinkにあるテスト実績からTestLinkCnvMacroを使って、テストケースの成功・失敗・ブロックの累積グラフ、曜日別・時間別・ピーク時間別のテスト実績、そしてテスター毎の生産性グラフ。
SVNリポジトリやCVSリポジトリから、StatSVNやStatCVSを使って、システム全体・サブシステム毎のLOCの累積グラフ、プログラマ毎の生産性グラフ。
これらのメトリクスは、上記ツールですぐに出力できる。
そのメトリクスを印刷して、メンバーにメトリクスの意味を説明したら、「まるで教科書みたい!」と言われた。
理由は、基本・応用・高度情報処理試験でSW工学や信頼度成長モデルの問題が出てくるが、実際の現場では今まで使ったことがなかったから、とのこと。
メンバーのその言葉を聞いて、SW工学の座学だけ知っていても、実際の現場で使えなければ無意味なんだな、と思った。
普通の現場にいるSEやPGは、基本・応用・高度情報処理試験の知識をどれだけ現場で使いこなせているのだろうか?
実際は、それらの知識は殆ど役立っていないのではないか?
普通の現場リーダーは、コストと納期に追われて、従来と変わらないKKDのプロジェクト管理しか知らない。
だから、現場で得られたメトリクスとSW工学の知識を組み合わせて、事実に基づいた意思決定を行うというマネジメントの基本スキルを普通の現場リーダーは知らない。
チケット駆動開発は、メトリクス出力を背後で自動集計する機構があるから、このメトリクスを正しく分析することで、効果的な意思決定を行うことができる。
更には、僕が考えるプロジェクト管理サーバーのインフラがあれば、プロジェクトマネージャにとって必要なマネジメント情報はいつでもすぐに得られるし、そこから良質の意思決定ができるようになるだろう。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある(2020.12.11)
「Redmine」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
- PMO観点でRedmineの使い方とは何か(2020.12.20)
- 若手プロジェクトリーダー向けのRedmine教育資料の構想(2020.12.24)
「ソフトウェア工学」カテゴリの記事
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
- なぜなぜ分析、FMEA、FTAの違い(2020.06.09)
「TestLink」カテゴリの記事
- テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか(2020.11.02)
- TestLinkにExcelのテスト項目書をインポートする方法(2017.06.01)
- TestLink Tutorialのリンク(2016.03.12)
- TestLinkで手動テストや自動テストの結果を統合してレポートさせる手法(2016.01.31)
- エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること(2015.03.14)
コメント