アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

前から読もう読もうと思っていて、ようやく読めました。
アジャイル開発って聞くと、ちょっと恥ずかしくなる開発者は結構多いはずｗ。
そして苦しんだ人も多いはず。アジャイルという名の仕様変更の嵐に。

そんな悲しい過去を持つ私ですが、本書を読んで思ったことは、、

見積もりは、なるべくプロジェクトメンバー皆でやるべきだ。参加者が多い方が
いい。しかもなるべく直接作業をする人たちが。

デザイナー、プログラマー、PM、アーキテクト、インフラ、DBなどなど。
予算とスケジュールが決めるときは、ざっくりとか言うのが多いかもしれないが、
開発者として正義を持ってタスクの整理とスケジュールをちゃんと決めようじゃない
かと思う。実際きっちりタスクを整理すると思ったより短い工数だったりすることが
多い気がします。
ちなみに皆で見積もりだすときは、MTGのメンバーが多くなると思うので、事前に
そのチーム内でやり方とかを打ち合わせしときましょう。この本にもそんなようなやり方が
紹介されてました。

あと良くあるのが、予算とスケジュールが先に決まっていて、無茶な見積もりでやらされなければ
ならないっていうパターンもあると思いますが、予算とスケジュールの変更ができないのなら、
現実的な機能を削るとか優先順位をつけてもらうとか、正しい交渉を心がけましょう。
もし、それでも毎回不幸になるんであれば、、、その組織にずっといるかどうか自体を
見積もった方がいいのかもしれません。

結局は、個々の持てる力を効率よく最大限生かしましょうっていう、ありふれた言葉に
なってしまいますが、それぞれ各人が自分の持ってる力を伸ばし、PJに生かせるように研鑽しましょう。
腕を磨きましょうってのが大事だと思うし。毎回チューニングしないといけないわけですね。
よく言う「改善」ってやつです。
改善っていつも思うけど、別にない知恵をしぼって新しいこと考えなくても、こういう本とか
ブログで読んだとか、他のプロジェクトでやってることとかを真似してみて、試して改良して、
新しいツール入れて試すとか、ちょっとづつでもいいから
取り入れていってみればいいんだと思うんですが、どうでしょうか。

このお仕事、せっかく結構なストレスを感じながら必死に作ったものでも、バグが多いとか、
思ってたのと違うとか言われて、ぜんぜん評価されなかったりするわけですね。
そういうお仕事なもんだから、スキルが
高くてプログラミング能力も高い優秀な若い人なんかよりも、
肉体労働を耐え抜いたような職務遂行能力の高い人間の方が
良かったりします。どっちかというと自分も肉体労働者よりですし。。
それはそれでいいと思いますが、知力・スキルの高い優秀な人がいなくなるような
環境を作ってしまっては、長い目で見ると全くよくないです。
優秀な人が、新しい事をどんどん取り入れたり、改良をすることで、より良い
開発スタイルを作って行けると思っているので。

本書は２、３回目を通しておきたいところ。