-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinsapporo20111220
irasally edited this page Dec 20, 2011
·
8 revisions
- 2011年12月20日 19:00-21:00
- エスプランニング開発室
- 参加者 6人
- 7.2 ～ 8.2
- 見積もりのコンテキストをはっきりさせてから話を始めたほうがいいね
- ここでの見積もりは「規模」の見積もりだよね
- この話のゴールは「規模」の見積もり、計画を立てるための見積もり
- 予算を立てるための「お金の見積もり」ではない
- これを共通認識としておかないと話がおかしくなることがあるから気をつけた方がよいね
- 規模を測るときの話を「見積もり」っていうと誤解を招きやすいよね
- 相手によっては別の言葉を使ったほうがいいかもしれないね
- 「で、いくら？」とは違う次元の話をしているという意識は必要だよね
- 「ピンチをチャンスに」のタイトルの意味
- 何がピンチで何がチャンスか
- 前章からの続きじゃないかな「初期段階での概算見積もりは信用できない」：ピンチ → 具体的に相対サイズで見積もる：チャンス
- 相対サイズで見積もるのって難しい
- 「何日でできます」→ 「ポイント」で見積もるの発想の転換
- 「日」という単位を勘違いすると間違った方向に流れがちだから気をつけよう
- 意味をしっかり理解しておけば「日」という単位を使っていても大きな混乱にはならないと思うよ
- PivotalTrackerの難しさ
- いきなり「ポイント」という単位が出てきて面食らったことがあるよ
- 普段の見積りとは違うところがたくさんあるから、なれるのに時間はかかるかもしれないね
- でも、難しい原因は「ポイント」という単位の違いだけではないと思うよ
- ポイントで見積もるということはどういうことなんだろう
- プログラムを外側からみて「他と比べて大きいか小さいか」を考える
- 単位は日数でもポイントでも同じ
- 「相対的」が肝なんだね
- ポイントか理想日か
- 理想日が全部悪いというわけではない
- それぞれの環境で合う（合意できた）単位を使うのがいいよね
- 理想日で見積りしたときに、理想日の積み重ねがプロジェクトの（終了予測しての）期間見積りにならないように気をつけないといけないね
- 日数を使ってはいけない理由で書かれていないこと
- 「日」になるとどうしても相対的ではなくリアルの作業の手順から時間を見積もってしまう危険性がある
- それは相対的な見積りじゃないよね
- そういう誤解は本を読んでも受けなかったな
- 「アジャイルな見積りと計画作り」の本ではそこがとても詳しく書かれていてよいよ
- 中身を全く考えずに見積もりできるものですかね？
- ある程度ブレイクダウンしないと相対的というところの想像も湧かないよね
- 2つじゃ相対見積りできないからいくつか複数のものを比べてみるといいよ
- 134ページ：「見積りが相対サイズになっていれば、ストーリーのひとつひとつには過大見積り過小見積があったとしても全体としての辻褄は合うはず」
- どうして辻褄が合う、といえるのだろう
- 1イテレーション毎の辻褄ではなくて、イテレーションを繰り返すことによって全体の辻褄があっていくようになるよ
- なるほど、文脈を理解できた
- タイポ「あっと」-> 「あったと」
- クッキーの例
- 相対サイズの見積りができる例となっているけれど、そうはうまく行かなさそうな例だよね ＊ 7枚食べたらお腹いっぱいになってしまいそう・・・
- 本として出したい事例としてのコンテキストは理解できた
- 三角測量
- 3つのストーリーを上手く選べるのは経験？
- 具体的な方法より「みんなと話をして合意する」ことが大事
- プランニングポーカー
- 「投票システムじゃない」ことが大事、多数決ではないよ
- 完全に一致をするまで続けるのが大事じゃない（本では合意に至るまでと書いているけれど、それは完全な一致と読み取らなくても大丈夫）
- 話し合いをすることが大事
- 意見を交換してメンバーが納得できること、共有することが大事だよ
- 新米経験者の見積もりはなかなか難しいよね
- プランニングポーカーには知見を共有するだけじゃなく、知見がある人がそれを広める仕組みでもあるよね
- プランニングポーカーで合意の上で見積りをする = コミットメントの側面があるよ
- 少なくても、これくらいの規模ですと認識しているというコミットメント
- xx日で完了させますというのとは違うコミットメント
-
http://www.square-enix.com/jp/info/library/dldata/PM/PM.pdf
- 2点見積りの話が載っていたよ
- 精度が上がる、モチベーションが保たれることが2点見積りの良いところだね
- プランニングポーカーで、8,13,20,40,100 のカードは使わない理由
- 数字の大きさが問題なのではなくて種類の多さが問題
- 相対的な良い数値の選び方 1,2,3,5,8 はそれぞれの数値を相対的に考えるのによいバランスの数だよ
- 数字が選べなかったらどうしているの？
- チームの方針で決める：大きな方に合わせるとか、近い方に合わせるとか
- 大きな方に合わせるとバッファを取りすぎてしまうんじゃないかな
- イテレーションごとのバッファだからそこまで大きな問題ではない
- 大きな方に合わせるとバッファを取りすぎてしまうんじゃないかな
- ○ポイントを超えたらストーリーを分割しましょうというルールを決めていたりもするよ
- チームの方針で決める：大きな方に合わせるとか、近い方に合わせるとか
- 「アジャイルな見積と計画づくり」との比較
- 前鼻さんがもってきてくれていました
- 「アジャイルな見積り〜」では「理想日」と「ポイント」の違いについて1章割いてあるんだよ
- この本は「入門」だからさすがにそこまでは書いていないね
- 上記の本は2章だけでも読んでみるとすごく現場で生かせることが書いてあるよ
- 今すぐアジャイル的な開発ができる現場じゃなくても計画作りを健康的に行えるようになると思うよ
- この失敗例：アジャイル的な開発をしたらすべて解決する話・・・じゃないよね・・・
- プロジェクトマネジメントの中のリスク管理の話
- そもそもこういうふうになる前にリスクマネジメントしているはずだよね
- 失敗例のような状況になってしまうってプロジェクトマネジメントへの理解が足りないんじゃないかな
- 「これらのことは（リスク管理をしなくても）アジャイル開発にすればうまくいく！」と思っているのであれば、正しくアジャイルも学習してないんじゃないかな
- アジャイル開発の話はリスクマネジメントの話も重なってくるから、同じ事を違う視点からみるとプロジェクトマネジメントの話になるよね
- コラム
- トム・デマルコの言葉「プレッシャーを与えて手を動かす速度を速めても考える速度は2倍にはならない」
- 手は動いていても考える速度が上がるわけじゃない
- 「信頼関係を損ねてしまった」とあるけれど、この例の場合そもそも信頼関係なんてなかったんじゃないかな・・・
- 最初の時点でおかしい（規模と予算が合ってない）
- 政治的事情とかいろいろあるのかな
- トム・デマルコの言葉「プレッシャーを与えて手を動かす速度を速めても考える速度は2倍にはならない」
- 実際に想定よりも進みが早くて前倒しになることってあるの？
- わりと最後の方に余裕が生まれてきたことが多かったよ（2,3ヶ月の小さなプロジェクト）
- イテレーションの中でちょっと遅れが出たら残業をしてでも取り戻そうとしてしまうな
- そういうこともある
- 初めての技術を導入するときなんかはやはり大変だったよ
- 実質的な成果がなかなかでなくて残業をたくさんして軌道に載せたりもしたよ
- 今日から自分の作業の相対見積もりをやってみた
- どういうものなのかな、まだ感触がつかめないでいる
- ストーリーの粒度だと相対的な見積りが大事だけど、もっと細かくなってくると現実的に「だいたいx日」というめどを立てることも必要になるよね
- チームでこのイテレーションでやることをコミットするという考え方はすごく良いと思う
- 個人の力量はあるけれど「チームで」全体量をやるという形（できる人が自ら仕事を引き受ける形）は双方のモチベーションが保たれると思う
- 上から仕事を与えられるだけだと、たくさん仕事の量をこなせる人が、ただただ疲弊していって、チームに貢献している気持ちが薄くなってしまうことがあるとおもうよ
来年もよろしくお願いします！！
次回は 1月17日 議事録のおさらいをしながら 見積もりと計画の話を勉強していきたいとおもいます。