請負プロジェクトでTracとHudsonを導入してみたふりかえり。

 

まずは、Trac。

開発初期からまずTracを導入。

最初は、wikiとしてのみ活用。特に強制した訳ではなく、おそらく一番Teamが書きやすい理解しやすいのがwikiだからだと思う。Teamが問題事項や気づきなどを共有し始める。

ここで注意したのが、Team全員にadmin権限を付与したこと。機能が制限されていると思うとどうしても管理者（プロジェクトリーダー）にコントロールされているように感じてしまうため（自分の場合がそうだった）、人の領域に入る気がしてwikiを記載するのに気が引けてしまったので、Team全員にadmin権限をつけることでそれを回避したかった。自己組織化に必要な要素の「透明性」と「権限委譲」をしたかったため。

プロジェクトの進捗やタスクは、別途WBSで管理。マイルストーンやタスクはそちらを参照。Teamで共有したい情報は、wikiへ記載といった感じ。

請負プロジェクなので、見積もりを基準にして開発が進む。

開発当初に見積もりを破棄していきなりScrumを導入する勇気がなかった、もてなかった。

理由は、進捗や全体像をタスクやvelocityから把握するやり方に自身がなかったのと、Agileの知識が全くないTeamにいきなりScrumを導入するのはリスクが高いと感じたため。

まずはプロジェクトにTrac導入を行って、Teamで情報共有すればプロジェクト開発はもっと楽しい物になるというところを理解してもらおうといった魂胆で導入してみた。

開発が終わってみて思うのは

・wikiが開発当初より充実していて、次回同じプロジェクトの改訂などが会った場合、wikiを見ればどういったプロジェクトだったすぐに思い出せること。

・途中参加のメンバーにプロジェクトの説明をする際に、まずはwikiを見てもらうことでスムーズに参加してもらえたこと

・admin権限の付与がよかったのか、皆wikiに記載していってくれたこと

 

つづいてHudson。

Hudsonは、プログラミング開始と同時に導入。当初は、コミット→ビルドして失敗していたらメールで通知という機能のみ使用。

導入当初、皆ビルドしてからコミットするのは常識だと考えていたため大して役に立つと思っていないようだったが、プロジェクトが終わってみると全員がHudsonからメールを受け取ることになった。。。恐るべし。

開発が進むにつれ、unitテスト実施、findbugs、checkstyleもコミットと同時に実行するようにしたためプロジェクトの最後に一斉に修正する必要がなくunitテストがいつ壊れたか分からないといった状況にもならなかった。

こちらも導入しない理由が見当たらない。No Risk, High Returnといった感じ。

次回も引き続き利用して、最終的にはScrumを導入できれば。。。