4この広告は、90日以上更新していないブログに表示しています。さんでどうやったら綺麗にプロジェクトとが回るか考えてみた。・五月雨式に案件が降ってくるのが困る。・その修正は、ただの思いつきなのか、戦略なのか明確にしたい。・修正点や活動の記録がほしい。・できれば、ソース管理とかと連動してくれたらいいな。・運用フェーズも、新規大型リリースフェーズも、インフラアラートもすべてできないと嫌だ。youサブプロジェクトかトラッカーか例えば、企画と開発とデザインとサポートがあったとして、こいつらは、サブプロジェクトにするべきかどうか。企画,開発,デザイン,サポートを作成するここら辺のドキュメントというか、プラクティスがなかった。みんなどうしているんだろうね。なんつーか、サブプロジェクトにするのは違う気がするんだよね。サブプロジェクトにしたら、企画サブプロジェクトのトラッカーは何になるんだろう。結局は、そのプロジェクトに関わる人数によって決まるらしい。プロジェクトの多くの人が参加するならば、サブプロジェクトとして切り離せばいいし、そうでなければ、トラッカーでやるのが正しいらしい。よって、ここではトラッカーを採用したい。エスカレーションもう一つ必要になるのがエスカレーションだ。ユーザさんからサポートメールがありました。サポートのトラッカーに記録しました。調査してみると、どうやらバグっぽいので、開発者にエスカレーションします。みたいな、、、これをどうやって表現するんだろう。redmineによるタスクマネジメント実践技法にも、エスカレーションすればー的なことは書いてあるけど、どうやってエスカレーションするのかはあまり書いてなかった。結局、考えた末に行き着いたのが、チケットをコピーするでした。サポート案件のチケットをコピーして、トラッカーとかを開発に書き換えて新規チケットとする。↓んで、それをもとに開発する。開発が終われば、開発チケットを閉じる↓サポートがお客様に連絡して、サポートチケットを閉じる。どのトラッカーにするべきかうーん、個人的に、todo、企画要望、サポート、設計、アイディアメモとかにしたいなーと思う。理由としては、基本的にエスカレーションを前提において設計したいからかな。・todo開発者が主に使う。・サポートサポートが主に使う。・システム社内テストで見つかったバグインフラシステムアラートなどを記録。場合によっては外注さんもここで。(これらはトラッカーをわけてもいいけど、あまり増やしたくないんだな)・アイディアメモいつかやりたいね系の話を入れる。・打ち合わせトラッカーとワークフローざっくりワークフローを書いてみる。◆todoエスカレーションされた案件を開発者が自己管理するために使います。個別のメモがわりとしても使えます!!かってに、子チケットとか関連チケットとかどんどん増やして、自分が使いやすいように使えばいいぢゃなイカ。↓ステータス:開発見積もり済み実装難易度とかをベースに工数を見積もります。現在抱えている必須タスクの進捗と、そして、案件のメリット、デメリットを考えて、実施を決定します。開発にエスカレーションします。システムにチケットコピーします。本番適応して確認してもらいます。効果測定済み最初に想定していた利益がでたかどうかをここで見る。インシデントに近いと思う。開発にエスカレーションします。設計にチケットコピーします。お客様に連絡が必要であれば連絡します。インシデントにもっとも近いと思う。開発にエスカレーションします。システムにチケットコピーします。本番適応して確認してもらいます。(これって必要?)↓ステータス:終了とりあえず、こんな感じかなぁ。ワークフローを作ってテストしてみようーロールロックマンのロールちゃんはかわいいけど、ここでいうのは、権限という意味でのロールですね。私の考えるポリシーは、外に厳しく中に甘い。外はキツキツ、中は甘甘(これを聞いてエロを想像した人は心が汚れています)。あるんだから、自分でチケット引き受けて回していけばいいぢゃない。勉強会とか、近々開催されないものか。SSLクロス開発をすると、問題になるのがライブラリです。