redmineで案件を回したいんですよ!!

redmine さんでどうやったら綺麗にプロジェクトとが回るか考えてみた。

やりたい要件。

・五月雨式に案件が降ってくるのが困る。
・その修正は、ただの思いつきなのか、戦略なのか明確にしたい。
・修正点や活動の記録がほしい。
・できれば、ソース管理とかと連動してくれたらいいな。
・運用フェーズも、新規大型リリースフェーズも、インフラアラートもすべてできないと嫌だ。
・エスカレーションするんだってばさ!!
・複雑奇っ怪なワークフローは No Thank you

サブプロジェクトかトラッカーか

例えば、企画と開発とデザインとサポートがあったとして、こいつらは、サブプロジェクトにするべきかどうか。

ほげほげプロジェクト
	+企画サブプロジェクト
	+開発サブプロジェクト
	+デザインサブプロジェクト
	+サポートサブプロジェクト

or

ほげほげプロジェクト
	トラッカーに 企画,開発,デザイン,サポートを作成する

ここら辺のドキュメントというか、プラクティスがなかった。
みんなどうしているんだろうね。。。

なんつーか、サブプロジェクトにするのは違う気がするんだよね。
もし、サブプロジェクトにしたら、企画サブプロジェクトのトラッカーは何になるんだろう。

わからなかったので、twitter でつぶやいたら、 教えてもらった。
結局は、そのプロジェクトに関わる人数によって決まるらしい。

プロジェクトの多くの人が参加するならば、サブプロジェクトとして切り離せばいいし、そうでなければ、トラッカーでやるのが正しいらしい。
よって、ここではトラッカーを採用したい。

エスカレーション

もう一つ必要になるのがエスカレーションだ。
例えば、ユーザさんからサポートメールがありました。
なので、サポートのトラッカーに記録しました。
調査してみると、どうやらバグっぽいので、開発者にエスカレーションします。
みたいな、、、

これをどうやって表現するんだろう。
redmineによるタスクマネジメント実践技法にも、エスカレーションすればー的なことは書いてあるけど、どうやってエスカレーションするのかはあまり書いてなかった。。。

結局、考えた末に行き着いたのが、チケットをコピーするでした。

サポート案件のチケットをコピーして、トラッカーとかを開発に書き換えて新規チケットとする。
↓
んで、それをもとに開発する。
↓
開発が終われば、開発チケットを閉じる
↓
サポートがお客様に連絡して、サポートチケットを閉じる。

どのトラッカーにするべきか

うーん、個人的に、todo、企画要望、サポート、設計、アイディアメモとかにしたいなーと思う。

理由としては、基本的にエスカレーションを前提において設計したいからかな。

◆トラッカー

・todo
開発者が主に使う。
作業をエスカレーションされた先


・企画要望
企画者が主に使う。


・サポート
サポートが主に使う。


・システム
社内テストで見つかったバグ
インフラシステムアラートなどを記録。
場合によっては外注さんもここで。
(これらはトラッカーをわけてもいいけど、あまり増やしたくないんだな)


・アイディアメモ
	いつかやりたいね系の話を入れる。

◆作業分類

・その他
・テンプレート
・デザイン
・プログラム
・調査
・打ち合わせ

トラッカーとワークフロー

ざっくりワークフローを書いてみる。

â—†todo

エスカレーションされた案件を開発者が自己管理するために使います。
または、個別のメモがわりとしても使えます!!
かってに、子チケットとか関連チケットとかどんどん増やして、自分が使いやすいように使えばいいぢゃなイカ。


ステータス:新規
↓
ステータス:対応中
↓
ステータス:終了

◆企画要望

新しい、企画やら案件やらを管理するトラッカー
ITILで言うところの 変更要求、変更管理に近いと思う。


ステータス:新規

カスタムフィールド
・必要な理由
・やるメリットと利益
・やらないリスク
・利益の測定方法
↓

ステータス:開発見積もり済み
実装難易度とかをベースに工数を見積もります。

カスタムフィールド
・見積もり
↓

どの案件をやるか決める会議          → ステータス:却下
ITILでいうところの CAB ですね、、、

現在抱えている必須タスクの進捗と、
そして、案件のメリット、デメリットを考えて、実施を決定します。
(最優先でタスクが来れば既存テスクが遅れるのは当然ですね)

↓
ステータス:開発中
開発にエスカレーションします。
ここで、todo もしくは システムにチケットコピーします。
[開発終了]
↓
ステータス:開発終了
↓
動作確認               → 問題あれば ステータス:開発中に戻す
↓
ステータス:確認終了 
↓
本番適応して確認してもらいます。
動作確認               → 問題あれば ステータス:開発中に戻す
↓
ステータス:終了
↓
1ヶ月後ぐらいに、、、
効果を測定する
↓
ステータス:終了 効果測定済み
最初に想定していた利益がでたかどうかをここで見る。

◆サポート

・お客様からの問い合わせ系全般
ITILで言うところの インシデントに近いと思う。

ステータス:新規
↓
サポートで解決できたか？→ ステータス:終了
↓
緊急性があるバグっぽいか？ No→  企画要望またはアイディアメモへ
                                 ステータス:終了
Yes
↓
ステータス:開発中
開発にエスカレーションします。
ここで、todo もしくは 設計にチケットコピーします。
[開発終了]
↓
ステータス:開発終了
↓
動作確認               → 問題あれば ステータス:開発中に戻す
↓
ステータス:確認終了
↓
本番適応して確認してもらいます。
お客様に連絡が必要であれば連絡します。
動作確認               → 問題あれば ステータス:開発中に戻す
↓
ステータス:終了

◆システム

・社内テストで見つかったバグ
・インフラのシステムアラート
・外注案件などもここかな、、
・その他、システムよりのトラブル全般を扱います
(本当はトラッカー分けたほうがいいのかなー)
ITILで言うところの インシデントにもっとも近いと思う。

ステータス:新規
↓
それが問題で対応の必要があるか？               No -> 却下
↓
ステータス:開発中
開発にエスカレーションします。
ここで、todo もしくは システムにチケットコピーします。
[開発終了]
↓
ステータス:開発終了
↓
動作確認               → 問題あれば ステータス:開発中に戻す
↓
ステータス:確認終了 
↓
本番適応して確認してもらいます。
動作確認               → 問題あれば ステータス:開発中に戻す
↓
ステータス:終了

◆アイディアメモ

いつかやりたいね系

ステータス:新規
↓
↓                  →却下 (これって必要？)
↓
ステータス:終了

とりあえず、こんな感じかなぁ。。。
まずは、redmine でワークフローを作ってテストしてみようー

ロール

ロックマンのロールちゃんはかわいいけど、ここでいうのは、権限という意味でのロールですね。
私の考えるポリシーは、外に厳しく中に甘い。外はキツキツ、中は甘甘(これを聞いてエロを想像した人は心が汚れています)。

なんで、全員管理者特権でもいいんぢゃない？って思ってますよ!!
イタヅラは怖い？バックアップと操作ログとればいいでしょw

企画者向けのトラッカーだったとしても、開発者もどんどん POST してもいいと思うし、開発者向けのトラッカーでも、サポートの人が POST してもいいと思う。
あと、管理者による割り当てとか、なんかそーゆーの嫌いなんだよね、、、せっかく 「どの案件をやるか決める会議」 があるんだから、自分でチケット引き受けて回していけばいいぢゃない。

各社がどんな感じでredmine で案件を回しているのか、プラクティスが知りたいね、、、
redmine 勉強会とか、近々開催されないものか。
sibuya.trac とかにいけば意見を聞けるんだろうか、、、