工数見積もりで陥りやすい罠 - プログラマの思索

「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い

[haruten]

「ざっくりで良いから工数だしてよ」と言われて、おそらく規模感（予算）をはっきりさせるために出した工数で、そのままスケジュール表の日数のマスを埋められたときは殺意を感じた

[mikage014]

「計画プロセスそのものもAgile化することによって、計画の精度を上げていくことが可能になる」

[warriorking]

工数見積もりで陥りやすい罠: プログラマの思索

[murasuke]

Focus Factor = 実績Velocity/予測Velocity

[fumokmm]

あとでチェック。

[chuhey]

今ってまさにこれにハマってるんじゃないだろうか

[suginoy]

スクラムの見積もりは正直理解が追いついてない。

[prometheus3000]

意外にも。

[luccafort]

あとで読む

[rytich]

むずかしい

[stomach55]

あとでよむ

[atty]

工数見積もりで陥りやすい罠: プログラマの思索

[tsuyok]

工数見積って数字が出るから真っ当ぽいけど、実はかなーりいい加減よね

[norip44]

ちょうどさっきまで見積りをやってたので。そういうときはよく頭に入ってくる。

[inulab]

胃がキリキリするお話

[invent]

『私の見積り工数とあなたの見積り工数は等価でない』

[wkoichi]

理想日による見積もりだと生産性が上がった場合に、1理想日×5機能になるので、Velocityが相変わらず5になるということであって、Velocityの計算を25/5としているのは誤りではないかな？

[indication]

考え方はアジャイルでの作業工数と規模の違い。

[ndanna]

あとで見る