Redmine もっと手軽にプロジェクト管理

Redmine -もっと手軽にプロジェクト管理!

今自分のプロジェクトでのMVPを挙げろって言われたら、優秀なPMでもなく、エンジニアでも
なくRedmineですって挙げてしまうかもしれない。それぐらいここ数年はこのアプリにお世話に
なっている。本とか読んで使うというより実践あるのみでずっと使ってきたけど、使い方とかで
他と違う点があったりしないかとか思って本書を読んでみました。

全体的に読んでみた印象としては本書は、Redmineをこれから導入しようとしてるところでも、
イマイチ使い方がうまく行かなかったところでも有用な情報が入ってると思いました。

ちなみに、自分が使っているPJでは大体最高３０人〜４０人ぐらいの規模まで使っているし、
小さいPJでも使ってる。慣れてないメンバーが入ってきてもすぐに使い方は覚えれるし、
使いこなせばこなすほど、こなれてくるでしょう。

いくつかポイントと思った点を挙げておきます。

・そもそもプロジェクトの運営をRedmineに合わせてしまう。

下手に進捗報告はメールで、とかではなく、チケットにタスクの進捗状況を書き込むとか。
進捗の％の定義など、情報が分散しないという定義の元で、ある程度PJごとに
ルールを決めた方がいいでしょう。
せっかくRemineを使うならチケットドリブンでやるぐらい決めて
書かれてないタスクはタスクじゃないぐらいのルールを最初に決めたいところ。
例えば、１機能分の実装チケットがあって、
着手10％、着手中50％、実装完了レビュー待ち80％とか、
そういうルールをあらかじめ決めてしまう。
こういうタスクの進捗状況が見えて、
誰がどれくらいのチケットを持ってるかという見える化が進むと
今度はPMだけじゃなく、開発者同士でタスクのバランスが見えてくるので、
開発者同士でのチケットの
やり取りもできるようになったりします。
自分も開発しながら仕様変更があったり、
追加などがあった場合は、チケットに追記して、他の機能と連携が必要になったりしたら、
そのチケットにwatcherでメンバーを追加したりなどして使っています。

・プロジェクトマネージャの負荷軽減とプログラマの生産性向上

マネージャはチケットを切ってタスクを管理して、開発者は進捗状況や課題などを
そのチケットに記入してマネージャとやり取りすればいいので、
メールやMTGでの報告や進捗の管理などが不要になる。

・チケットの粒度

ある程度慣れてるメンバー同士であれば、チケットベースでチケットとして
挙げる粒度もやりながら、慣れて行くということは可能ですが、
初めてRedmineを使うとかいった場合は、チケットの粒度が問題です。
どのくらいの粒度でチケットにするかは難しいですが、
まずは以前からやっていた単位から落としてみるのがいいかと思います。
スケジュ−ル表に書かれてる担当者ベースとかで。粒度自体もPJごとに相談するぐらいでも
問題ないと個人的には思ってます。
後は、Redmineを使う場合はカスタマイズ機能が充実しているので、
使いながらやり方を模索するというスタイルも取りやすいかと思います。

プラグインなどの機能を含めると全体のほんの少ししか使ってなくても、
充分に今は恩恵を受けていると思います。
Redmineじゃなくても同等の機能があるものであれば、何でもいいかとは思いますが、、、

今後はEclipseとかとの連携や、プラグイン機能などをもっと使っていきたいと思うところ。
この手のツールは使いやすいけど、メンバーの意識とか使い方を徹底する
ことの方が重要かもしれないですね。
他のツールでは、trac、jira、影舞などを使ったことがありますが、
今のとこredmineが一番しっくりきてる感じ。