アジャイルサムライ(要約) その7
1.概算見積りの問題
見積りの目的(スティーブ・マコメルの言)
ソフトウェア見積りの主目的は、プロジェクトの結果を予言する事ではない。見積りを行うのは、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断するためである。
見積りは間違えてしまうものであり、問題は見積りを未来の正確な予測だと思い込んでしまうことにある。 概算見積りは当てずっぽうという前提が大事。前もって見積もる時に必要な答えはこのプロジェクトをやり遂げられそうなのかということにある。 次の3つの条件が満たせるような見積り手法が必要。
ソフトウェア見積りの主目的は、プロジェクトの結果を予言する事ではない。見積りを行うのは、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断するためである。
見積りは間違えてしまうものであり、問題は見積りを未来の正確な予測だと思い込んでしまうことにある。 概算見積りは当てずっぽうという前提が大事。前もって見積もる時に必要な答えはこのプロジェクトをやり遂げられそうなのかということにある。 次の3つの条件が満たせるような見積り手法が必要。
- 今後の計画を立てられる
- 見積りは当てずっぽうだという前提を踏まえている
- ソフトウェア開発の複雑さを認めている
2.ピンチをチャンスに
プロジェクトをはじめるには予算、成果の見通しが必要になってしまう。見積りを信頼できるものにするためには、アジャイルだからといって特に変わったことはせず過去の実績の計測して、それを基に計画を立てる。
具体的には次の2つを踏まえて計画を立てていくとよい
具体的には次の2つを踏まえて計画を立てていくとよい
- ストーリーそれぞれを互いに相対的なサイズで見積もる
- ストーリーをそれぞれ、お互いがお互いに対してどれぐらいの大きさなのかを相対的に見積もる。ただ見積りでの1日は実際のカレンダーの1営業日と同じではない。チームの進む速度は見積りの数値より速くなることも遅くなることもある。この日付に対する捉え方の違いを明確にするため見積りの単位をポイントとして扱う。(単位はNUTSでもグミベアでもよく、拘りはない)
会員システム構築のストーリーを例に挙げると以下のようになる
- 会員のログイン機能 → 1pt
- 会員登録機能 → 3pt
- 会員削除機能 → 4pt
- ポイントをもとにして進捗を追跡する
- 例えば上記の会員のログイン機能の見積りが3日だったのに実際は4日かかってしまった。このとき他のストーリーの見積りをすべて33%増やす事もできなくはないが、1.33日とか1.66日とか分かりづらい数値となってしまう。こういった事態を避けるためポイント制を推奨している。
見積りの単位にポイントを採用する事には次のようなメリットがある。
- 見積りとは当てずっぽうである事を肝に銘じることができる
- 見積りとは純粋に大きさを測るものだと考える事ができる
- 手早く気軽にシンプルに見積もれる
3.見積り技法
実際に見積もるにあたって使えるシンプルな技法を2つ紹介
- 三角測量(Triangulation)
- 代表的なストーリーをいくつか基準として選出して、残りのストーリーを基準になるストーリーとの相対サイズで見積もる手法。
1回のイテレーションの期間に収まりそうなサイズのストーリーから大中小をいくつか選び出せるのが望ましい。比較する基準ができたら残りのストーリーを振り分ける。
もしも見積もりの途中で、これまでに経験がなくサイズの見当がつかないストーリーに出くわしたらスパイクを実施する。 スパイクとはタイムボックス化された実験のことであり、ストーリーを見積もれるようになる程度に調査を実施して見積もったら止める。長くても数日以内に留め手早く試す事を心がける。 お客さんにコストが伝えられる程度の情報が得られれば十分。 - プランニングポーカー
- 開発チームのメンバーで各ストーリーを自分自身で見積もる。各人が見積もったらその数値をメンバー同士で見せ合ってチームで統一した見積りを出す。
初回で全員の見積りが一致すればそれで決まりだが、差異があれば話し合って再び見積もる。チームで見積もり結果に合意できるまで、話し合いと再見積りを繰り返す。
プランニングポーカーの狙いは個々人が自らの見積りについて意見を伝え合う事で従来よりも適切に見積もれるようになること。 また数値は大きい数字(8,13,20,40)にするとあたかも精密な見積りであるかのように見えるのでシンプルに小さくする事を心がける(1,3とエピック(大きなストーリー)を表現するため5があれば十分)
0 件のコメント:
コメントを投稿