2017/06/13 09:36:58
isdh
面白い。
2017/06/13 14:49:21
pribetch
『黄金長方形の軌跡』でPDCAを回せッ!
2017/06/13 20:46:05
a-know
相対見積り
2017/06/13 21:17:00
mkn-fj-cd
何これ面白い
2017/06/13 21:39:41
braitom
フィボナッチ数列でポイントを付けるのかなるほど面白い。
2017/06/13 22:08:24
muuran16
今まさに取り組もうとしてる。ベロシティを 測るには全スプリント期間でストーリーポイントを相対的につける必要があると思うんだけど、見積もり会議のたびに過去の2とか5ポイントのタスクを参考にして見積もるのかな
2017/06/13 22:44:48
paradisemaker
しばらく運用すると分かるけど、プランニングポーカーは結局エンジニア間やプロダクトマネージャーとの取引の材料にしかならなくなるよ。
2017/06/13 23:42:55
auient
アジャイルな見積もりの本で見たやつ。これくらい簡易な手順に落とし込まれているといい
2017/06/14 00:54:31
zZwIwl
しゅごい・・・
2017/06/14 05:15:27
yuichi0613
へー “全員でそれぞれのチケットに対しての必要工数をフィボナッチ数列 2、3、5、8、13、21の数列を使って、最も工数のかかりそうなチケットに21ポイントを、最も少ない工数のチケットに2ポイント”
2017/06/14 06:07:13
amori
評価に結び付けないというのは重要だな
2017/06/14 06:14:26
fumisan
なんだ、プランニングポーカーじゃないか。フィボナッチ、つまりチームの仮想単位で規模見積もりしてるだけで、そのあと時間に換算しないとスケジュールにはならないんだよ
2017/06/14 07:02:03
kojette
すごい
2017/06/14 07:13:21
tofu-kun
プランニングポーカーと何が違うんだろ
2017/06/14 07:16:22
indication
興味深いが、評価へ組み込む奴が絶対出る
2017/06/14 07:18:40
n_231
なるほど、雑念入らない見積もりは確かに話し合いやすい。
2017/06/14 07:45:33
kitaj
プランニングポーカーの話
2017/06/14 07:45:52
hogetahogeko
「2、3、5、8、13、21の数列を使って、最も工数のかかりそうなチケットに21ポイントを、最も少ない工数のチケットに2ポイントをつける」「実務においてタスクの重さは指数関数的に伸びる」
2017/06/14 07:45:57
sky-y
“5とか13という単位の無い数字にすることで余計な邪念を挟む余地が無くなる” 人月みたいな具体的な単位ではなく、「ほげポイント」みたいなチームだけで通用するオリジナル工数でラフに見積もる。
2017/06/14 07:49:39
yamak
"そのスプリントにおける”最小が2 最大が21だと1の単位がスプリント毎に変わりそうだが、ベロシティの安定性に影響は出ないのかな
2017/06/14 08:03:52
grandao
肌感に合ってる。しかし「個人が処理したポイント数を人事評価に結び付けない」までは分かるが、人事評価をどうするのが適切かが分からない。
2017/06/14 08:08:02
nabe1121sir
面白い手段だけど、大抵の会社は1番のタスク分けすらまともにできない地獄。
2017/06/14 08:08:31
uturi
“個人が処理したポイント数を人事評価に結び付けない。” 一番難しい部分。チームでの処理能力を個人の評価に結び付けないのは難しそう。
2017/06/14 08:09:22
snjx
ポイントの多い少ないで批判しない、人事に反映させない、たぶんこれが一番難しい。
2017/06/14 08:13:23
psfactory
プロジェクトマネージメント手法:フィボナッチ工数見積は「完成させます!(徹夜で)」という無理ゲーによる弊害を最小化する - ジャバ・ザ・ハットリの日記
2017/06/14 08:22:16
wheson
フィボナッチ数列を使ってることが目から鱗だった。なるほどと。
2017/06/14 08:32:07
taka222
ストーリーポイントのお話
2017/06/14 08:35:08
exsoul
コレやってみたいのよね
2017/06/14 08:45:22
garage-kid
287: エクセレントだ。何より“個人が処理したポイント数を人事評価に結び付けない”がポイントですな。
2017/06/14 08:46:17
info55
プランニングポーカーとストーリー分割の話では。逆にそれまではどういうアジャイルだったのか気になる。
2017/06/14 08:50:16
nokogiring
これは真似したい。
2017/06/14 08:54:53
puffy_nipples
これアジャイル説明してる本に大体書いてあるじゃん。この人が言うアジャイルとは何かその定義を聞きたいわ。
2017/06/14 09:05:06
kwms
昔何かで見た記憶があるなこれ
2017/06/14 09:05:40
mswar
当たり前だけど、BugFix対応も割り込みチケットとしてちゃんと見積もるのって、重要っすよなぁ。。。 "【7】バグフィックスが出るたびにチケットを発行し、そこにフィボナッチ数のポイントを見積もって付ける。"
2017/06/14 09:05:51
khtno73
プランニングポーカーの実践例として。
2017/06/14 09:13:01
pzp
見積もりが正確なのとビジネスが成り立つこととのギャップがあるから徹夜してる
2017/06/14 09:13:06
ryun_ryun
面白い試みだけど、そもそもマネジメントの素養がないやつが管理したりするのが日本のITの闇なんだよな。仕様を全く把握してないPMがわんさかいる。
2017/06/14 09:13:57
n314
ブコメ見て、アジャイルが広まらないのってプランニングポーカーとかベロシティとか新用語を次々畳み掛けるからなんじゃないかと思った。
2017/06/14 09:16:04
halix
フィボナッチ数を使うのが面白かった。普通に仕事のタスク付けでも使えそう。
2017/06/14 09:17:51
fukuchiharuki
フィボナッチ数列でポイントをつける
2017/06/14 09:18:23
Bosssuke
外圧がかからない前提なら素敵な手法。考えてみよ
2017/06/14 09:18:45
slash_01
まあ、ですよね。
2017/06/14 09:28:01
koroharo
ポイントでつけても、結局客には人月に変換して出さざるを得ないという。
2017/06/14 09:29:51
napsucks
余裕のある見積もりこそが正義。カネのない顧客とは縁が切れるし、どうしてもやらなければいけない重点顧客をカツカツで受注しても余裕ができる。
2017/06/14 09:35:07
youichirou
あの本はこういうことが書いてあるのか。また読んでみよう。
2017/06/14 09:43:21
sheeplogh
ストーリーポイントの見積りにはまだ踏み出せずにいる。型化すれば始められるのかな。はてぶ界隈の人がこれ読んでどう思うのか気になって珍しくブコメみたのだが溜め息が出た…。
2017/06/14 09:46:34
bell_chime_ring238
覚えとこ。
2017/06/14 09:53:40
ysksy
面白い。そのまま活用は難しそうだが。/"ここをフィボナッチにすることで13と21の差はとても大きく、「あれが21だったらこれは13にすべきだろ」と、より明確に区別することが可能になる。"
2017/06/14 09:58:41
inose660
合理的だけど、どうせPMがこれを参考に人日に落とすし人事評価にも使うだろうから、経験値が貯まればやがてPM一人でやることになる予感。
2017/06/14 10:05:23
Falky
相対見積もりを時間に換算しないとスケジュールにならないとか超おもろい。アジャイルだっつってんのに、時間に換算しないといけないタイプのスケジュールを組むのか。
2017/06/14 10:07:55
tpircs
ブコメに既存のスケジュール管理から抜け出せてない人がいるな。ポイントのまま管理するんだよ。ポイントの増減が把握できれば状況把握できる。日数に落とす必要は無い。
2017/06/14 10:11:23
NOV1975
面白いけど、これ暗黙に時間換算しているよね。
2017/06/14 10:19:20
megamouth
なるほど冴えたやり方
2017/06/14 10:27:11
otihateten3510
ちょっと儀式的なので、フィボナッチ要素を除きたいところ / "工数見積正確にできる人に出会ったことが無い" しかし工数見積の不正確性を理解してる人、理解してない人は割りと幅がある。今日も一人でデスマである
2017/06/14 10:28:55
dco0901
ここまで洗練されてはいないけど、自分のいるチームでも作業にかかった時間を集計してチームの処理能力を数値化するようになったら残業が劇的に減ったよ。
2017/06/14 10:47:35
yoiIT
本の勧め方が上手い
2017/06/14 10:50:41
MasaoBlue
言われてみると当たり前、しかしやろうとすると難しい。
2017/06/14 10:59:04
minimalista
自分の身を守るためにも自分やチームの進捗を管理・把握する術を身につけておいた方がよいので、エンジニアでもそういう本とか読んで学んでおくのはいいと思うな
2017/06/14 11:00:52
natu3kan
>まず実務においてタスクの重さは指数関数的に伸びていくこと。軽量なタスクはそれほど差はないが重量なタスクにはモノによって大きな差が出ることはエンジニアなら経験則でご理解いただけるはず。
2017/06/14 11:03:05
tbpg
ペアの見積りはセクシー素数にしよう(適当) https://ja.wikipedia.org/wiki/%E3%82%BB%E3%82%AF%E3%82%B7%E3%83%BC%E7%B4%A0%E6%95%B0
2017/06/14 11:11:34
mori1027
【1】実装したい機能を細かくできない【3】どれがどのくらい工数かかるか出せない【4】優先順位の付け方が間違っている【5】2週間以上かかる分量を取り出してしまう/これがうちのディレクターです
2017/06/14 11:16:44
hisaju
そうなんだけど、ビジネス側まで含めて納得させるのは難しい。そして徹夜する。
2017/06/14 11:37:20
yellowpad
「実務においてタスクの重さは指数関数的に伸びていく」これは他にも汎用的に使える概念。1,2,3,,,では、各要素間の差異は1だが、フィボナッチ数では2,3,5,8,,,と各要素間の増大していく差異を利用しより重み付けが可能。
2017/06/14 11:41:02
airj12
「わがチームが見積もるわがチームの開発スピードポイントです」これ気持ちよさそう / チーム内の開発マネージメント と 個人と組織の評価や予算 は切り分けた方が健全よね
2017/06/14 11:41:09
gomayumax
“要はチームの開発スピードを全員が(論理的に!)把握しておくことの効果が絶大なのだ。” わかる。理由のない「いけるっしょ!」はガン無視しよう
2017/06/14 11:52:43
yoshikidz
フィボナッチ数列ってすごいな。時間という言葉で圧迫感感じるのをポイントとして処理するのも結構マネジメント手法としては有効な気がする。心理的な圧迫感は取り除きたいね。ポイントかーおもしろいな。
2017/06/14 12:00:00
masayoshinym
全員がまともにやれれば良いやり方だけど、変なのが一人でも混ざると破綻しそう。
2017/06/14 12:12:18
userhiro
Sier(はBPさんで成り立っているので、契約の見積もり時に提示できない難点はあるが、契約でこんなんやりますと盛り込んで、徐々に平均を把握していければ素晴らしいな(フェージング契約が適しているかな?)
2017/06/14 12:18:13
PerolineLuv
そうは言っても納期が決まってる受託開発系だと、納期近くになるとポイント→人日換算工数になり漆黒の修羅場となる。疲弊したくないエンジニアなら、やはり受託開発業界にはそもそも関わってはいけないと思う。
2017/06/14 12:18:46
imash
この辺はよく知らないから調査や検討にどれだけかかるか予想できないようってなるわ
2017/06/14 12:19:49
shozzy
これは覚えておいて損はなさそう。
2017/06/14 12:22:54
kastro-iyan
でも他に人事評価ってどうやって決めるの?数こなせるのは一つの評価指針であってそこを評価しないのはどうなんだ
2017/06/14 12:50:40
field_combat
内部の数値として運用するのに良さそう
2017/06/14 12:54:23
tak-mizu
参考に
2017/06/14 12:54:36
sin20xx
スケジュールが破綻する原因は、自分の作業の定量化、他人の作業の定量化、対象の作業の定量化、そして周囲の作業の定量化、これができているかできていないかに左右される。これはそれをまるっと丸める話なので注意
2017/06/14 12:55:12
yohskeey
プランニングポーカーとはまた違うのかしら
2017/06/14 12:58:57
ryownet
SPとかベロシティとか言わないからわかりやすいのか
2017/06/14 13:30:35
wiz7
フィボナッチでなく1,2,4,8…でもいいけどねw/このように教科書通り美しく回るプロジェクトと、カオス化して頓挫するプロジェクトってスコープ管理方法の握りとバックログ管理が全てな気がする。要は顧客との関係次第
2017/06/14 13:45:20
lazytruth
便利で面白いかも
2017/06/14 13:47:07
eerga
常識(普通のScrum)だった。やってるやってないに関わらず知らない人はヤバイ。【3】だけは違和感。
2017/06/14 13:49:19
keitone
弊社ではミナボッチ工数というひとつの案件は全てそいつ一人でやるという画期的なマネジメント手法を導入しています。
2017/06/14 13:56:55
yfujisawa
細部は違えどアジャイル界隈では有名な手法だと思う。。。両方経験したおいらからすると、徹夜がどうこうってのは、極論すれば締め切りや要件を調整できるか次第かと。
2017/06/14 14:22:20
Nyoho
フィボナッチ大好き
2017/06/14 14:28:57
stealthinu
チケットに切ってフィボナッチ数でそのチケット毎の重さを付ける。んで2週間の実績から2週間でできる平均ポイント=仕事量が導出でせる。
2017/06/14 15:01:11
midori44
「プランニングポーカー」と呼ばれる手法らしい
2017/06/14 15:12:10
TokyoIncidents
“全ては同僚のスペイン人プロジェクトマネージャーRの言ってることの受け売り” 紹介されている本にかかれている手法ですからね… ブコメにもあるけどプランニングポーカーですよね…
2017/06/14 16:14:06
matsubobo
5年前ぐらいに流行ったアジャイルのプラクティスの1つであるプランニングポーカーの話。なぜ今更。。。。謎
2017/06/14 17:03:33
xact7
“フィボナッチ工数”
2017/06/14 17:48:47
cachico
プロジェクトマネージメント手法:フィボナッチ工数見積は「完成させます!(徹夜で)」という無理ゲーによる弊害を最小化する
2017/06/14 19:07:03
noonworks
時間という単位のままだと、作業速度の個人差から感覚のズレがあるし、納期等の外圧もあってチームの認識をあわせるのは難しい。
2017/06/14 22:11:30
zaskar99
[management]
2017/06/14 22:14:12
kasei_san
意外に知らない人多いのね。まずは SCRUM BOOT CAMP THE BOOKかアジャイルサムライあたりを読むとよいよ!
2017/06/14 22:14:32
bricklife
「プランニングポーカー」より「フィボナッチ工数見積」のほうがいい名前だと思った
2017/06/15 00:13:10
yumainaura
ポイントベースの素晴らしさって、これだよな。 “誰かがアレもコレも2週間以内にやれー!とやったとしても「いやいやこのポイント数を見て。平均速度の3倍だぜ。それ無理だから」と論理的に諭すことができる。”
2017/06/15 00:43:47
d_log8
フィボナッチ工数見積は「完成させます!(徹夜で)」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法 Star added 2017-06-13 フィボナッチ工数見積は「完成させます!(徹夜で)」という無理ゲーによ
2017/06/15 00:50:23
takkpapa
単位の無い数字にするってのが面白い発想だわ。
2017/06/15 01:11:04
cheapcode
うちのチームでもこれやってて結構うまくいってる。「プランニングポーカー」とか「フィボナッチ〜」とかの意識高い呼び方は流石にアホみたいで恥ずかしいから「ざっくり見積もり」って呼んでる。
2017/06/15 02:01:12
takkuru98
メンバーへの精神的負担が少なくて良さそう。プロジェクトマネジメント手法もまずは概要からでも勉強しなきゃなぁ。。
2017/06/15 03:19:12
oukayuka
Pivotal Trackerとか使ってたら普通にこのやり方しかできないはずだけど、そうじゃないチームはどうやってタスク管理してんの。
2017/06/15 06:50:19
pmint
これは一体何を見積もっているんだろう。下手を打つよりは適当にしたほうがまし、それでもプロジェクト間の比較はできるといったところか。/ 日数にしないのは正しい。そこはPMの仕事。見積り手法は比較しかできない
2017/06/15 07:36:45
paravola
ポイント数にする場合に連続した数字ではなくフィボナッチ数列にしているのには理由がある
2017/06/15 08:56:02
k1take
良い。「5とか13という単位の無い数字にすることで余計な邪念を挟む余地が無くなる。この時点で誰が担当するかは割り振られてないので「オレだったら1日でできるぜ」などと無駄なアピールをさせなくて住む」
2017/06/15 09:25:17
akitsukada
「これじゃ予定たてられないよ」「1SP=1日目安にしてよ」「たくさんこなせた人が評価高いんでしょ?」と言い出す人いるよね
2017/06/15 09:28:49
kmatz90
実際に今これでやってる
2017/06/15 10:09:36
arajin
「工数を日数で表現しない」「なに?4日?こんなの1日で十分だろ(オレならできるぜアピール)」「「重いタスクを9かな?それとも10かな?」とじっくり考えても9と10の差は1でしかでなく」
2017/06/15 14:03:49
to_tu
見逃されがちだけど、工数の見積力ってエンジニアとして重要すぎるスキル。いつまでも課題だ。。。これ試してみたい
2017/06/15 14:47:17
tmf16
久々にプランニング・ポーカーを思い出した
2017/06/15 16:44:10
hiroshiweb
プログラマ時代にやったなー。 管理ツールはTrelloで。 ただ、プログラマの人数が私入れて二人で、もう片割れが超優秀で、力の差がルールを壊してしまい、あんまり意味がなかったな、、、
2017/06/15 17:43:07
vanbraam
"PMチーム"と"開発チーム"が分かれてる"アジャイル開発"とは?それ一番タチの悪い「偽アジャイル開発」だったのでは
2017/06/15 22:20:31
rin51
スクラムの文脈で「13より大きいタスクは粒度が大きすぎるので分割すべし」みたいなことを読んだけどどこだったか
2017/06/16 09:11:18
gesukawa
ぴぼたるとらっかーで見た
2017/06/16 16:20:46
iww
なんだかんだいってポイントは人日に置き換えざるをえない気がするけど、リニアにしないというのは良いアイデアかも