matobaの備忘録

育児しながら働くあるエンジニアの記録

アジャイルな理想日の見積もりの話

アジャイルな見積もりと計画づくりを読んでる。

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

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

今回は、5章を読んでいて思ったことを書く。

5章は、「理想日による見積もり」について書いていた。

理想日について考える前に、理想時間と現実時間について説明されていた。

理想時間とは、何かをするのにかかる時間のうち、周辺の作業を差し引いたものらしい。 それに対して、現実時間は、実際にかかる時間らしい。 誰かに見積もりを聞かれた時は、現実時間を答えるのが、良さそうという話も書いていた。

一般的に、理想時間の方が簡単で正確に見積もれるということも書いていた。 なぜ、現実時間の見積もりが難しいかというと、怪我とかアクシデントとか、偶発的な出来事で変化したり、チームの流儀や環境の影響を受けて、変化するからだという話。

スポーツ、例えば、サッカーとか野球の試合時間も同じように現実時間の見積もりが難しい。ロスタイムがどれくらいあるかとか、アクシデントがどうとかが説明されていた。ただ、テレビはスポーツを放送するときに放送時間を決めてそこに収めてくるという話が書いてあった。

そして、テレビがどうやっているのか、という話も説明されていたけど、インタビューとかコマーシャルを使って、時間を埋めたり、延長したりしていると書いてあった。

ただ、それに視聴者は驚かないという話もしていた。なぜ驚かないかというと、変化することを知っているから。しかし、ソフトウェアの開発では、締め切りが伸びると驚く。なぜ驚くかというと、ソフトウェアの開発でスケジュールが変化することを知らないからという話を書いていた。

なるほどなあ。

スケジュールはあくまで雰囲気だという話なのかなあ。よくわからん。難しい。

どっちにしても、スケジュールを守るように努力はした方がいいと思う。ただ、必ずスケジュール通りにならないということは理解しておいた方がいいんだろうなあ。と思ったりした。

それから本の中にソフトウェアの開発が伸びる理由は、まず見積もりの段階で、準備、割り込み、知らなかったことが出てきた場合の時間、などを見積もっていないからだと書いてあった。

あと、作業を担当ごとに細かく見積もるのはやめようという話も書いてあった。 なぜ細かく見積もるのをやめた方がいいかというと、細かく見積もりをしたら、それのメンテナンスや管理コストが膨らむし、それに見合うだけの成果が得られない、かららしい。

なるほど。

で、理想日で見積もる場合は、担当を分けずに、ストーリーで見積もった方がいいという話を書いていた。

ストーリーかー、

ふむー。難しい。

で、ここからは僕の感想がメイン。

難しいなあと思う理由について考えてみると、例えば、ストーリーを見積もって、それが1ヶ月かかります。という話になったとして、それって、いつ遅れているとか、進んでるということがわかるのかなあと思った。

スケジュールを計画してる一つの理由が、どれくらいで終わりそうかの目処を立てることだと思ってる。早く終わったら別のことをやりたいし、時間がかかりそうなら、別のことはできないなとか考える。

作業を分けずにストーリーで考えた方がいい、という話が書いてあったけど、ストーリーの単位で進める場合、ストーリーが終わりそうか終わらなさそうかというのは、何を指標にして考えたらいいんだろう。

んー、これまで、作業の数がどれくらい終わったか。というのを使って測っていたりしたけど、そうじゃなくて、全体の雰囲気で測ればいいのかな。

いや、ストーリーをどれくらい実現できているか、なのかな。

いやいや、ストーリーは実現できているかどうか、のTrue/Falseだから、一つのイテレーションで一つのストーリーが消化できるとして、達成できたかできなかったかになるのかな。

だとすると、ちょっと困ることがありそうだなあとか思う。

だって、一つのイテレーションが終わらないと、そのイテレーションでストーリーが実現できたかどうかわからないと、計画の立てようがないんじゃないかなあ。

と思ったけど、よく考えたら、イテレーションの中で、ストーリーが終わってもいいのか。

んー、毎日、計画をアップデートする必要なんかなくて、イテレーションの単位がスケジュールというか、全体の計画を見直しする機会ということになるのかなあ。

どうなんだろう。

よくわかんないなー、とぼんやり考えていた。

追記

もしかして、チケット駆動開発のチケット、という単位と、ストーリーという単位は、似てるのかもしれないなあ