プロジェクトで最初に出す初期見積もりは実に--そう、実にひどい当てずっぽうに過ぎないってことなんだ。
開発なんてやってみなければどれくらいのスピードでできるかわからない。
前もって正確に見積もるなんて無理。…前もって見積もるときに、私たちが欲しい答えはただひとつだ。つまり、
このプロジェクトをやり遂げられそうなのか？！
だから私たちには、次の３つの条件をみたすような見積もり手法が必要だ。
- 今後の計画をたてられる
- 見積もりは当てずっぽうだという前提を踏まえている
- ソフトウェア開発の複雑さを認めている
このプロジェクトをやり遂げられそうなのか？！は非常に重要なところだと思う。
できないものをできるとかいうと後々痛い目を見そうだし。
7.2 ピンチをチャンスに
見積もりを信用できるものにしようと思ったら誰でもやっていることをやるだけの話だ。…
- ストーリーそれぞれを互いに相対的なサイズで見積もる
- ポイントをもとにして進捗を追跡する
相対的な見積もりについて
ストーリーをそれぞれ、お互いたお互いに対してどれくらいの大きさなのかを相対的に見積もる。それから、自分たち開発チームがどれくらいの速度で仕事を進められるか(ベロシティ)を計測する。アジャイルな計画づくりにはこの２つがあれば十分だ。
ポイントについて
相対サイズ見積りでの１日は、実際のカレンダー上の１営業日とは必ずしも同じじゃないってことだ。
…
たとえば、あるストーリーで、最初の見積りが３日だったのに、実際には４日近くかかったとしよう。
このとき、他のストーリーの見積もりをすべて33%増やすこともできなくはない。
だが、そうできるからといって、誰がこんな単位で仕事をしたいだろうか。1.33日とか1.66日とか……。…もしも、1.33日と見積もったストーリーが、実際には1.66日近くかかってしまったらどうする？また再見積りするの？
アジャイルしゅほうではこうした状況、すなわち見積もりの数値を再調整する作業がいつまでも終わらなくなる状況に陥るのを避けるために、見積り結果の数値の単位には意味を持たせず、ただポイントとして表現することを推奨している。その狙いは、見積の数値と営業日の日数とを対応させないようにすることだ。
見積もりは確実なものでないとわかっているので、日数でなく、これくらいみたいな感じで見積もっておいたほうがよいってことかな。
SIer「このプログラム何日かかる？」
プログラマー「わかりませんが、この前の仕事の5割増ですね。」
SIer「つまり3日だね？」
プログラマー「どうですかね？この前の仕事は確かに2営業日でできていますけどね。まあ、たぶんこの前の仕事より5割増くらいだということですね。」
SIer「つまり３日だね？」
プログラマー「いや、分かりません。」
SIer「この前のは２日でできたのだから、それの５割増だから、３日だろう。」
プログラマー「どうですかね？この前の仕事は確かに2営業日でできていますけどね。まあ、たぶんこの前の仕事より5割増くらいだということですね。」
SIer「つまり３日だね？」
…以下続く
見積り技法
三角測量
ストーリーの一覧から１回のイテレーションの期間に収まりそうなサイズのストーリーを大中小選び出す。
選び出す際の視点。
- 論理的なグループ分けができる
- エンド・トゥ・エンドになっている
- プロジェクトを象徴するストーリー
スパイク
今まで経験したことのないようなストーリーに対する見積もり方法。
タイムボックス化して数日以内でストーリーを見積もれる程度に様々な調査を行う。
プランニングポーカー
開発メンバーが一つ一つのストーリーを自分自身で見積もる。
その結果をメンバー同士で共有する。
一致していたら、その見積もりにする。
異なっていたら相違について話し合って見積りを出す。
重要なポイントは話し合いがあること。
プランニングポーカーは投票システムではないこと。
ストーリーのサイズは小さくする。(1、3、エピックを表すのに5を使う。)
0 件のコメント:
コメントを投稿