2007-02-04 :-)
_ [見積り][GUI][WBS][コスト][プロセス][ターゲット][ストーリー][プロジェクト][プレッシャー][プラクティス][ファジー理論][デルファイ法][スケジュール][ソフトウェア]ソフトウェア見積もり
読み終わり。
見積もりの教科書と言っても過言ではありません。
見積りは学校では習いませんでしたからね[ 2007-02-03 ]。
見積もりとは何か
見積もりとはプロジェクトにかかる期間やコストを予測すること。( p.4 )
見積もりと計画は異なる。( p. 4 )
- 見積もり
- 先入観に縛られない分析的なプロセス
- ゴールは正確性
- 計画
- 先入観を排除せずにゴールを指向するプロセス
- ゴールは特定の結果の追求
- 特定の到達点に達するための手段を特定する作業
見積もりを行うのは、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断するためである。( p.14 )
良い見積もりとは、プロジェクトの責任者がプロジェクトのターゲットを達成するために行ううえで、適正な意思決定ができる明確な視点を提供する見積もりである。( p.15 )
トムデマルコの定義:もしかたしらた終わらせることができる最も早い日( p.30 ) ←これは 熊とワルツを かな
見積もり能力のチェック
ということで第 2 章に見積もりスキルをチェックするクイズがあります。ルールはこう( p.17 )。
- 正解は 90 % の程度でこの範囲内にあると自分が考える範囲の上限と下限を記入する
- 答えを調べてはいけない
- 空欄は誤答
- 回答時間は 10 分
問題は 10 個( p.18 )。正解はこのエントリの最後です。
- 太陽の表面温度
- 上海の緯度
- アジア大陸の面積
- アレクサンダー大王の生まれた年
- 2004 年時点の米ドルの通貨流通量
- 五大湖の総水量
- 映画「タイタニック」の全世界での興行収入
- 太平洋に面した海岸線の総延長
- 米国で 1776 年以降に出版された書籍タイトルの総数
- シロナガスクジラの重さの世界記録
私は 2 点でした。
著者がこれを 600 名の見積もり作成者に試したところ平均正解数は 2.8 問だったそうです。
常人が直感的なセンスで考える「 90 % 確か」は、実際には「 30 % 確か」にほぼ近いと言わざるを得ない。( p.19 )
- 見積もり幅を広くすれば正解率は上がる( e.g. 太陽の表面温度は 0 〜 10 万度 と回答すれば正解ではある )
- しかし幅を狭くしてしまう
- 幅を狭くしてしまうのはこれはプレッシャーを感じるからである
- このプレッシャーは個人の思い込みから来る
過大見積りと過小見積もりはどちらがよいか?
過大見積りのほうがマシ。
- 過大見積りの不利益は直線的で有限である( p.27 )
- 過小見積りの不利益は直線的でなく限界がない
- 過大見積りへの反対意見( p.24 )
- 「パーキンソンの法則」( 作業は、使用可能な時間を使い尽くすまで拡大する )
- 過小見積りへの反対意見( p.25 )
- プロジェクト計画の有効性が減少する
- 予定どおりに完了する機会が統計的に減少する
- 土台をしっかり固めておかないともっと悪くなる
- 遅延がプロジェクトをさらに破壊する
不確定性のコーン
見積もりはプロジェクトが進行するにつれて正確になっていく( p.39 )
p.41 の図 4-2 参照。
- ばらつきを取り除くために意思決定した場合にコーンは収束する( p.42 )
- 製品ビジョンを定義する
- 要求を定義する
- ユーザーインターフェースを定義する
- アクティビティの見落とし( pp. 48 - 51 )
- 要求の見落とし
- ソフトウェア開発アクティビティの見落とし
- ソフトウェア開発アクティビティ以外の見落とし
見積もり技法
第 7 章〜第 20 章まで技法を説明しています。詳細は割愛。見づらいので一覧にしました。ラピッドデベロップメント も同じような紹介の仕方なので一覧を作ろうかしら。
技法 | 見積もりの対象 | プロジェクトの規模 | 開発ステージ | 反復型/シーケンシャル | 正確性 |
数えること | 規模、機能 | SML | 初期〜後期 | 両方 | 高 |
計算すること | 規模、工数、スケジュール、機能 | SML | 初期〜中期 | 両方 | 高 |
業界平均データによる補正 | 規模、工数、スケジュール、機能 | SML | 初期〜中期 | 両方 | 低〜高 |
組織のデータによる補正 | 規模、工数、スケジュール、機能 | SML | 初期〜中期 | 両方 | 中〜高 |
プロジェクト固有のデータによる補正 | 規模、工数、スケジュール、機能 | SML | 中期〜後期 | 両方 | 高 |
体系的プロセスの活用 | 工数、スケジュール、機能 | SML | 初期〜後期 | 両方 | 高 |
見積りチェックの活用 | 工数、スケジュール、機能 | SML | 初期〜後期 | 両方 | 高 |
範囲のある見積り | 規模、工数、スケジュール、機能 | SML | 初期〜後期 | 両方 | 高 |
見積りと実績の対比 | 規模、工数、スケジュール、機能 | SML | 中期〜後期 | 両方 | 適用なし |
機能やタスクによる分解 | 規模、工数、機能 | SML | 初期〜後期(S) 中期〜後期(ML) | 両方 | 中〜高 |
WBSによる分解 | 工数、スケジュール、機能 | ML | 初期〜中期 | 両方 | 中 |
標準偏差を使用した最良ケースと最悪ケースの計算 | 工数、スケジュール | SML | 初期〜後期(S) 中期〜後期(ML) | 両方 | 中 |
類推による見積り | 規模、工数、スケジュール、機能 | SML | 初期〜後期 | 両方 | 中 |
ファジー理論 | 規模、機能 | ML | 初期 | シーケンシャル | 中 |
標準コンポーネント | 規模、工数 | SML | 初期〜中期 | 両方 | 中 |
ストーリーポイント | 規模、工数、スケジュール、機能 | SML | 初期〜中期 | 両方 | 中〜高 |
Tシャツのサイズ分け | 規模、コスト、スケジュール、機能 | ML | 初期 | シーケンシャル | N/A |
グループレビュー | 規模、工数、スケジュール、機能 | ML | 初期〜中期 | 両方 | 中 |
広域デルファイ法 | 規模、工数、スケジュール、機能 | ML | 初期 | シーケンシャル | 中 |
ソフトウェア見積りツールの使用 | 規模、工数、スケジュール、機能 | ML | 初期〜中期 | 両方 | 高 |
複数のアプローチの使用 | 規模、工数、スケジュール、機能 | SML | 初期〜後期 | 両方 | 高 |
プロジェクト後期に正確な見積り技法への変更 | 規模、工数、スケジュール、機能 | ML | 初期〜後期 | シーケンシャル | 高 |
プロジェクト固有のデータに基づく見積りの詳細化 | 規模、工数、スケジュール、機能 | SML | 初期〜後期 | 両方 | 高 |
標準化された見積り手順 | 規模、工数、スケジュール、機能 | SML | 初期〜後期 | 両方 | 高 |
見積り手順の有効性の評価 | 規模、工数、スケジュール、機能 | SML | 後期 | 両方 | 高 |
ファンクションポイント | 規模、機能 | SML | 初期〜中期 | シーケンシャル | 高 |
オランダ方式 | 規模、機能 | SML | 初期 | シーケンシャル | 低 |
GUI要素 | 規模、機能 | SML | 初期 | シーケンシャル | 低 |
過去のプロジェクトとの非公式な比較 | 工数 | SM | 初期〜中期 | 両方 | 中 |
見積りツール | 工数 | SML | 初期〜中期 | 両方 | 高 |
業界平均の工数グラフ | 工数 | SM | 初期 | 両方 | 低〜中 |
ISBSG方式 | 工数 | SM | 初期 | 両方 | 低〜中 |
スケジュールの基本公式 | スケジュール | ML | 初期 | シーケンシャル | 中 |
過去のプロジェクトと非公式な比較 | スケジュール | SML | 初期 | 両方 | 中 |
Jonesの一次見積りプラクティス | スケジュール | ML | 初期 | シーケンシャル | 低 |
見積りツール | スケジュール | ML | 初期 | 両方 | 高 |
見積もり能力チェックの正解( p.295 )
問題 | 正解 |
太陽の表面温度 | 6000 ℃ |
上海の緯度 | 北緯 31 度 |
アジア大陸の面積 | 4439万平方キロメートル |
アレクサンダー大王の生まれた年 | 紀元前 356 年 |
2004 年時点の米ドルの通貨流通量 | 7199 億ドル |
五大湖の総水量 | 6.8 x 10^23 リットル |
映画「タイタニック」の全世界での興行収入 | 18 億 3500 万ドル |
太平洋に面した海岸線の総延長 | 13 万 5663 キロメートル |
米国で 1776 年以降に出版された書籍タイトルの総数 | 2200 万件 |
シロナガスクジラの重さの世界記録 | 17 万キログラム |
489100522X
_ [下村陽子][岩垂徳行]ツレヅレ:茶太さんVocalアルバム
記事を見たらさらに 岩垂さん 作曲のアルバムもあるですか。
両方とも amazon で予約開始していたのでさっそく予約しました。
ref.
B000N4RB5U
B000M7XT1S
うーん、書かれてる事良く判らん。<br>実施する作業を項目分割して各項目の作業時間を過去の経験から出すだけじゃないの?<br>他人の作業見積もりの場合はその人が自分よりどれぐらいの比率で作業できるかの係数掛けるとか。<br>太陽の温度の問題6kの物を0〜100kって回答じゃ過大見積りでどんな仕事も見積もりの時点で蹴られて終わっちゃうし。
>見積もり能力のチェック<br>太陽の表面温度約4000K(黒点)〜約6000K平均約5800Kに対して6000℃(=6273.15K)を正解としているけどこれはどうかなぁと思ったり。<br><br>余談<br>モノの本では6000℃と書いてあることがあるけど、一般書としてKという単位を出すのを避けてたり300度程度は誤差のうちとしてあえて無視していたりすることがあったり。<br># 確信的にKという単位を避けてる人は6000度と書いてたりしますが。(そういう本からの孫引きで6000度をなにも考えずに勝手に6000℃と写してるものもあったり)<br>閑話休題<br><br>また、ルールで『空欄は誤答』としているのに『常人が直感的なセンスで考える「 90 % 確か」は、実際には「 30 % 確か」にほぼ近いと言わざるを得ない。』という結論は悪意を持った操作に違いない。<br>見積もり不能と間違った見積もりを出すということの間には大きな隔たりがあると思う。<br><br>0~10万度で正解といってもそのような回答をするのは考えられる温度の上限として10万度の人がその数字をいった場合である。<br>同様に考える人であっても温度なんて1000度ぐらいまでしか無いだろうと考えてる人は0~1000度と答えてしまい不正解になるだろう。<br># さて、絶対零度などの知識がなかったとして冥王星の表面温度はどのように回答するだろうか。<br><br>そもそも、見積もりをするにはその対象についてある程度の知識を持っていることが前提条件として必要だし、知識の無いものが作った見積もりになんら価値はないであろう。