Redmine運用例

Redmineの運用例をリンクしておく。
一つは、Ruby1.9の開発。
もう一つは、SKIP(Rails製SNS)。

【SKIP】
SKIP ... 情報共有ソーシャルウェア

SKIP - 概要 - SKIP - Redmine

SKIP - ロードマップ - SKIP - Redmine

SKIP - 変更記録 - Redmine

SKIP - サマリ - Redmine

SKIP - 経過時間 - レポート - SKIP - Redmine

Redmineで最も重要な画面は、サマリの画面だ。
そこからバージョン項目の右にある虫眼鏡をクリックすると、ステータスごとのチケット集計数が表示される。

SKIP - サマリ(バージョン単位) - 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)に対し、方針が決定されるまで、色んなステークホルダーとやり取りして仕様を固めていく必要がある。
その場合に、他のステークホルダーがチケットを担当している状態を明確化するために、ステータスを作る時が多い。

上記のようなワークフローは、実際の現場で運用しながら作られたものなので、どんな開発プロセスや開発体制になっているのか、を考える参考資料になりうる。

ワークフローこそ厳格にプロセス管理すべき対象。
ワークフロー管理がプロジェクト管理の要だと思う。