今のお客さんの開発に携わり、割とプロジェクト管理に関するルールなども自社ルールに縛られず、お客さんのルールにも縛られずに入れる環境であったので、Redmine入れて管理したいなと思い導入してから約2年。
やってみて、個人的に便利 or あと少し・・・ということを勝手に振り返ります。
ただ、結論的に言えることは「Excel」管理やMSProjectには戻れないなと。
自分がやりやすいやり方に今は行き着いているので、これが正解と捉えず、こういう例もあるんだと捉えていただければ幸いです。
(スクラムっぽくプロジェクトもスプリントも設けて実施していましたが、ここではRedmineの使い方のみに焦点を当てています。)
1.導入した経緯
これまで進捗の管理にはMS Excelを利用してくる場面が多かった。なんでプロジェクト管理の手法が旧態依然のまま誰もが、それに従っていたのかよくわからず、「ルール」という縛りにあがらうことできず過ごしてました。
そこで、まあある意味実験的にいろいろと試すことができる環境に置かれたものだから、「アジャイル」「Lean」というバズワード（まあ、2015年ごろ入れたので、もう普通に使われてますね)に引かれ、「まずは使ってみよう」と自分のチームとお客さんに宣言して利用し始めました。
※かんばんを壁に紙で貼るということも考えましたが、お客さん先で複数ベンダーが入っている関係上、セキュリティ上NGでしたので、Redmineを利用しました。
2.初期のころ
Redmineの入門本を購入し、デフォルトの機能のみで管理してました。
(今考えると無鉄砲で計画性がなかったなと反省・・・)
飯田 治行 大澤 文孝 大和田 裕 小川 明彦 楠川 智久 阪井 誠 内藤 淳
日経BP社 (2015-06-30)
売り上げランキング: 345,042
この本をみながらBitnamiでPCにインストールし、
Redmine運用。
(この当時はVersion 2.6を入れていたはず)
また、全体を通してですが、うちのチームの初期の力ではTDDができなかったので、テスト方法はテストコードによるテストではなく、静的コードチェックと画面を利用したテストが中心です。
どう管理していたの？？
「トラッカー」で作業を分類してました
良かった点１
チケット登録するとき、トラッカー別に「設計」「実装」「テスト」「レビュー」と分けて登録できるので、登録は楽でした。
ある設計のチケットに対し、「実装」トラッカーを子チケットに。
ある「実装」チケットに対し、「テスト」「レビュー」のトラッカーを子チケットに。
先に
WBSのようにチケットを登録し、
ガントチャートやチケット一覧をみながらやれるのかなと思っていましたが・・・。
良かった点２
優先度をつけられるのはメンバにとって良かったらしいです。
どれから着手すべきか口頭で伝えられても忘れてしまうので、書かれているといいらしい。
同じように期日を切ってくれているとメンバ自身でスケジュールコン
トロールするときの一つの目安になっていいみたい。
階層を深くするとチケット一覧を確認しても「？？？」となりよくわからない。
進捗もよくわからないし、チケット数の管理が3桁越えると何が何だかわからず。
当時MAXで500くらいのチケットがアクティブで登録されていました。
やらなければならないタスクをとりあえず書いたのですが、「開始予定日」「完了予定日」でしっかりコン
トロールしないと「未着手」で遅延なのか、「まだやる必要ない」のかをチケット一つずつ内容をみないと行けなかったので、余計な管理工数がかかっていました。
問題点２ チケットの移動に制約が・・・
親子関係、関連付けをチケットにつけていると「ここからここにこのチケットは移動しよう」と思って動かしても、制約違反にかかる。。。移動できないじゃんということが発生。自由にチケット移動できず、どうしましょ、という状態でした。
問題点３ 要件との紐付けをしていなかったので、まとまりがわからず
バグ管理や課題管理で利用している場合には作成したトラッカーに対して、それをこなせば、TODOとしては終わりですが、ソフトウェア開発となるとそうはいかず。
設計チケットをトップに記載したため、「あれ、この設計チケットってどの要件の話だっけ」とか設計チケット通しに関連性をつけていなかったので「このチケット直すとどこに影響するのか？」というのが第三者がみてわからなかった。
完全にチケット管理する前のワークフローなり、トラッカーの付け方の計画ミスでした。
どう解決したの？
プラグインというのを入れるのにこのころは抵抗があり（挙動を自分で管理できなかった)、カスタムフィールド等で解決してました。
解決策１ 親子関係はつけない。カスタムフィールドで管理
とりあえず、親子のチケット関係は外しました。代わりにカスタムフィールドで属性を追加しました。
例えば、「トラッカー」でコン
トロールしていた内容を「作業内容」というカスタムフィールドを作成し、この列挙項目に「設計」「実装」「テスト」などを追加。
また、要件と紐づけるために「画面」とか「要件」というカスタムフィールドを作成し、列挙項目に要件名や画面ID等を描き、このカスタムフィールドでまとめられるようにしました。
解決策２ 題名でも何しているかわかるように
解決策１では管理して、データを収集、集計するためには便利ですが、日々、メンバがチケットを確認する上では「わざわざチケットを開かないとなんの作業かわからない」という問題がありました。そこで、ありきたりですがチケットの題名に【設計作業】や【実装】など接頭に作業内容をつけてなんのチケットを書くかわかるようにしました。
ここまでで良くなったの？
この管理でかつ、途中でRedmineとSVN連係も追加し、約1年はこの設定状態で管理をしました。
手持ちのチケット数が少ないとメンバも余裕があることと、自分自身のスケジュール管理もできていたのですが、追加・変更案件とテストによる指摘事項がチケットに混在してくると「どのチケットからやるの」「優先順位をどうつけるの」というのが錯綜し、若干パニック状態になりました。
また、内部管理はチケットやRedmineの内容で説明すればある程度状況の把握はできていましたが、第三者や上位の管理者に説明するときにスケジュールを数字化するのに一苦労しました。
チケット数の総数、消化数、残数。予定時間と実績時間から想定される予想残工数。バグ発生の予想数、消化予想工数から着地がどれくらいになるのか・・・。チケットから作成するのにデータを抽出し、こねこねしなければならず、プロジェクト管理が楽になったのか？というのが若干疑問でした。
しかし、とは言っても、Redmineに記載された内容がトレースできていたので、「書かれてさえいれば」何に困っていたのか。何がうまく言っていたのかを分析するのには大変助かりました。
つづく
