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 とかにいけば意見を聞けるんだろうか、、、