Redmine運用例
Redmineの運用例をリンクしておく。
一つは、Ruby1.9の開発。
もう一つは、SKIP(Rails製SNS)。
【SKIP】
SKIP ... 情報共有ソーシャルウェア
SKIP - ロードマップ - SKIP - Redmine
SKIP - 経過時間 - レポート - SKIP - Redmine
Redmineで最も重要な画面は、サマリの画面だ。
そこからバージョン項目の右にある虫眼鏡をクリックすると、ステータスごとのチケット集計数が表示される。
面白いと思うのは「実装完了」というステータスがあることだ。
他のチケットの状態遷移の履歴を見ると、下記のフローが正常フローのように見える。
新規→担当→解決→実装完了→終了
「実装完了」ステータスの意味を第三者の視点で考えると、「開発もテストも終わったが、リリースしていない」状況と考えられる。
おそらく、本番リリースしたかどうかを区別するために作られたのではないかと思われる。
この手法は実際の開発現場ではよくある。
開発チーム内部でバグ修正とその検証が完了してビルドできたとしても、顧客が確認できる環境へリリースしなければ、本当に完了したことにはならない。
つまり、開発完了と本番リリース完了にタイムラグがある場合は、それに応じたステータスを作って管理したいものだ。
【Ruby1.9】
Ruby 1.9 - 概要 - Ruby Issue Tracking System
Ruby 1.9 - ロードマップ - Ruby Issue Tracking System
Ruby 1.9 - サマリ Ruby Issue Tracking System
Ruby 1.9 - 変更記録 Ruby Issue Tracking System
同様に、Ruby 1.9 のバージョン項目の右にある虫眼鏡をクリックしてみる。
Ruby 1.9 - サマリ(バージョン単位) - Ruby Issue Tracking System
面白いと思うのは、「Fixed(解決)」ステータスが無く、「Third Party's Issue」ステータスがあることだ。
他チケットの正常フローの履歴を見ると殆どが「New(新規)→Closed(完了)」になっている。
第三者の視点でワークフローを類推すると、登録されたチケットは自発的に誰かが解決してCloseされていくようだ。
そのチケットが環境の不具合と判明した場合、「Third Party's Issue」ステータスに振られているようだ。
つまり、他のステークホルダーへ確認あるいは担当してもらう場合に特別なステータスをアサインしていると考えられる。
この手法は、変更管理やインシデント管理でよく現れる。
特に変更管理では、変更要求(RFC)に対し、方針が決定されるまで、色んなステークホルダーとやり取りして仕様を固めていく必要がある。
その場合に、他のステークホルダーがチケットを担当している状態を明確化するために、ステータスを作る時が多い。
上記のようなワークフローは、実際の現場で運用しながら作られたものなので、どんな開発プロセスや開発体制になっているのか、を考える参考資料になりうる。
ワークフローこそ厳格にプロセス管理すべき対象。
ワークフロー管理がプロジェクト管理の要だと思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 文化は組織構造に従う(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)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- yWriterは映画の脚本を作るためのアプリだったのではないか(2021.01.05)
- カンバンはステータス名が大事(2021.01.02)
コメント