「アジャイルな見積もり」を語ってみませんか?参加してきた
「アジャイルな見積もり」を語ってみませんか? - DevLOVE関西 | Doorkeeper
2013/11/1
楽天大阪支社
超簡単な解説
書籍紹介:
見積りが合うのは、対象とほぼ同じことをやったことがある場合のみ
大前提
- 見積りは合わないもの
- 現時点での情報での確率でしかなく4~1/4倍の精度になる
計画
- 専門家の意見(色々な人の話を総合する)
- 対比(何かと比較して見積る)
- 分割(できる大きさに分割する)
実際にやってみる
- やってみると色々わかる(2週間程度の期間で)
- チームのスキルセットとか計画に沿うか
- 作業量と期間は別物である。1日の作業は4~6時間程度でしかない。計測すると見えてくる
- 顧客のフィードバック(返答の遅い、返答がチンプンカンプンな人なのか)
計画見直し
- なかなか言い出しにくくて、交渉するよりパワーでやっちゃってデスマになる
- 信頼貯金が大事で、計画見直しや見積りを信じて聞いてもらうために
ワークショップ
プランニングポーカー
- 相対的な見積りをするためにツール
- 基準(2ポイント)となるタスクを一つ決める
- テンポよくやることが大切
- おでこに裏返してセット。せーので、見せ合う
- ポイントが一番離れている(ポイントの大きい人と小さい人)がそれぞれの見積り理由を述べる
- 見積りの前提条件を聞くことも大事
- ポイントが近づいたら、多数決or大きい方をとる
- 同じポイントでも前提を話し合うと結構違うこともある
http://www.slideshare.net/Ryuzee/ss-11644359
http://www.slideshare.net/Ryuzee/ss-11644359
計画づくりの現場
20131101 Planning From The Trenches
計画づくり
- タスク分割と時間見積り
計画
- 期限を守るため。でも期限ばかり気にすると、期限にだけ目を向けてしまい良いものが作れない
- マネージャにとって計画とは、約束をさせるためのもの
- 計画という名の期限を決めさせ約束させたがるマネージャは技術力が低い人に多い
ポイント
- 要件
- リリース時期
- 開発メンバ
計画表
- ガントチャートはいまいち
- 2週間区切りでつくる
- 終わりが分かる機能分割(終わったけど、TODOあるよ!とか作業者に言われないように)
- リリース後のスケジュールに機能改善タスクをはじめから入れておく(仕様追加、追加機能はリリース後ですよ。と話がしやすくなる)
- 要件が不透明なら、1か月半前にリリースできるように計画する(早く終わったら追加しますという姿勢)
- リリース後に技術的負債の返済用枠を数時間取っておく
- 全力でがんばっていると信頼してもらうことが、計画づくりには大切
- 現状を受け入れて計画する