«前の日(06-04) 最新 次の日(06-06)»

fkino diary


2007年06月05日

_ Rails for Java Developers

読みました。

Rails for Java Developers(Stuart Halloway/Justin Gehtland)

JavaとRubyのコードの比較みたいな話はちょっと微妙だったのですが、Rails全般について幅広く取り上げられていて、Tips的な内容も多かったので、純粋にRailsの解説書として役に立っています。

Automationのところで、CIツールとしてCerberusが取り上げられていたんだけど、CruiseControl.rbよりもこっちの方がメジャーなんだろうか?

Tags: Ruby
本日のツッコミ(全1件) [ツッコミを入れる]

_ かくたに [Cerberusは、cc.rbよりは歴史がある。出版時点ではcc.rbはまだ認知されてなかったかも。]


2008年06月05日

_ ソフトウェアプロジェクトの救済入門—危機的状況に陥ったプロジェクトを救う実践的アプローチ

読みました。

ソフトウェアプロジェクトの救済入門―危機的状況に陥ったプロジェクトを救う実践的アプローチ(E.M.Bennatan/富野 壽/荒木 貞雄)

これはなかなかタイムリーで為になりました。

この本の対象としているプロジェクトは割と大きめのプロジェクトだと思うのですが、うちでやっているような比較的小規模のプロジェクトにも適用できるところはたくさんあると思います。

プロジェクトが危機的な状況に陥らないようにすることは当然大切なのですが、成功率が10%台と言われているようなITプロジェクトにおいて、危機的状況から抜け出すためのプラクティスを持っていないというのは危うすぎるのではないかと感じています。

この本ではプロジェクトの救済には10個の段階があると書かれているのですが、Step1が「中断」で、いきなりハードルが高い。プロジェクトを止めずに、対策を打とうとしてズルズル行くプロジェクトをたくさん見てきました。今まで見てきた中で、プロジェクトを止める*1という決断をできたプロジェクトマネージャはいませんでした。プロジェクトを止めるというのは勇気のいる決断で、とても恐いことなんだと思います。しかし、製造業の世界では「ラインストップ」と言われるように、やっぱりそういう決断が必要なときはあると思います。

この本によると、プロジェクトを止めた後、プロジェクトやチームを評価し、実現性のある最小ゴールを定義します。そして、チームを再編成して、リスクの分析と計画の立て直しをやって、最後に再び危機的な状況に陥るのを防ぐための仕組みをつくって、ライン再開となるわけです。これを2週間以内にやれって書いてあります。

riueさんも書いておられるように、"Catastrophe Disentanglement" を「救済」と訳したのは上手いと思いました。「火消し」と言っていないのがいいですね。

Tags: PM book

*1 「やめる」じゃなくて「とめる」です