ソフトウェア開発の工数見積

あれこれ


-概算見積・確定見積
-工数見積り・期日見積り

-ソフトウェア開発見積りの基本的な考え方 ~見積り手法の課題・歴史とCoBRA法~
--https://www.ipa.go.jp/files/000005394.pdf

-【第1章】PMBOKを理解しよう:PMBOK とは
--https://products.sint.co.jp/obpm/blog/serial-umeda01

『アジャイルサムライ』


- 「もしも、1.33日と見積もったストーリーが、実際には1.66日近くかかってしまったらどうする? また再見積りするの?」
- 「アジャイル手法ではこうした状況、すなわち見積りの数値を再調整する作業がいつまでも終わらなくなる状況に陥るのを避けるために、見積り結果の数値の単位には意味を持たせず、ただポイントとして表現することを推奨している」

-アジャイルサムライ 達人開発者への道
--http://www.nilab.info/wiki/Book4274068560.html

『アジャイルコーチング』


- 「実装するのに数日もかかるような大きなストーリーは、タスクに分解してもらいましょう。タスクというのは、ユーザーストーリーのデリバリーにつながる(1日もかからない程度の)ちょっとした作業を指します。タスクに分解することで、ストーリーテストの不足がわかったり、ストーリーをさらに分割する方法が見つかったりします」
- 「小さなタスクに分解されていれば、作業を分担しやすくなるので、同じストーリーを複数人で担当できるようになります」
- 「データベースの変更は必要?」
- 「どうやってテストしようか?」
- 「エディトリアルコピーやGUIのデザインアセットみたいに、他のチームから何かもらう必要はある?」

『エッセンシャル スクラム』


-「見積もりはコミットメントではない」
-「見積もりは相対サイズで行うべき」
-「実際に作業をする人たちが集まり、みんなで見積もる」
-「見積もりは正確にしなければならないが、必要以上に精度を追い求めてはならない」

-nilog: プログラマが工数を多めに出してしまうのはこれが原因。スケジュールをざっくり引いただけでも、それを守るのが絶対になってしまう。だから多く見積もる。正確さを欠く精度が低くなる。見積もりはコミットメントではない。 エッセンシャル スクラム (2014-12-03)
--http://www.nilab.info/nilog/?type=twitter&id=539942039412957185
--

-[ヅ] エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (2014-11-30)
--http://www.nilab.info/z3/20141130_01_essential_scrum.html

『エラスティックリーダーシップ』


-「見積もりには品質を向上させる時間を確実に含めるようにしている。たとえば、「それは合計でX日かかり、テストも含めるとX+3日かかります」とは言わない。私のXは、常にテスティング、TDD、コーチング、ペア作業の時間を含んでいる。それは仕事の一部なのだから、特に言及するようなことはしない。デバッグに費やす時間も言及しない」
-「私たちは仕事をよく分かっていない人間が仕事を指示してくることを考慮しなければならない」
-「品質が低下するのは、マネージャーのせいではない。なぜなら、彼らは「テストを省くこと」を求めているときに、何をしているのか分かっていないからだ。その責任は、私たち開発者、コーダー、テスターにある」

-nilog: 見積もりには品質を向上させる時間を含める。テストなどを含めるが、それについて特に言及しない。 「彼らは「テストを省くこと」を求めているときに、何をしているのか分かっていない」 エラスティックリーダーシップ (2017-10-07)
--http://www.nilab.info/nilog/?type=twitter&id=916506031848439808
--

-エラスティックリーダーシップ ―自己組織化チームの育て方
--http://www.nilab.info/wiki/Elastic_Leadership.html

WEB+DB PRESS Vol.93 特集1『要求の変化に柔軟に対応する実践見積り』


-WEB+DB PRESS Vol.93|技術評論社
--https://gihyo.jp/magazine/wdpress/archive/2016/vol93
-->特集1 [要求の変化に柔軟に対応する]実践見積り スケジュール,スコープ,スキル
-->第1章:見積りとは何か
-->よくある誤解を招かないようにしっかり定義しよう……原田 騎郎,吉羽 龍太郎
-->第2章:見積り技術の背景
-->誤差や認知バイアスにどう向き合うか……原田 騎郎,吉羽 龍太郎
-->第3章:問題の変化が限定的な領域での見積り方法
-->計測データをいかに収集しどう活用するか……原田 騎郎,吉羽 龍太郎
-->第4章:問題が変化する領域での見積り方法
-->アジャイルと組み合わせて開発の改善を助ける……原田 騎郎,吉羽 龍太郎
-->第5章:これからの見積り方法
-->No EstimatesとMob Programming……原田 騎郎,吉羽 龍太郎

-「たとえば、1日あたり実際に作業に使える時間を8時間と見積もってしまい、実際は会議や事務作業や研修や休暇などでそれ以下の時間しか使えないことによっても誤差が生まれるでしょう」
-「一般的に就業時間のうちに実作業に使える時間は平均で50~60%程度になります。したがって、すべての時間を使える前提で見積りをして約束してしまうと、残業したり人を増やして対応するしかなくなってしまいます」
-「多くの場合納期の見積りは過小見積りであるという点が挙げられます。開発者自身が行う見積りにおいて特にその傾向が強いと言われています」

不確実性コーン


-nilog: 不確実性コーン。 「プロジェクトの初期には、見積もりは非常に高いバラツキを持っています。例えば「初期コンセプト」の段階では、最も大きい見積もりで4倍、最も少ない見積もりで0.25倍となっています」 プロジェクトの本質とはなにか | 日経クロステック(xTECH) (2022-12-24)
--http://www.nilab.info/nilog/?type=twitter&id=1606547101101752320
--

参考情報


-システム開発のための見積りのすべてがわかる本
--http://www.nilab.info/wiki/Book4798156493.html