「アジャイルな見積もり」を語ってみませんか?参加してきた

「アジャイルな見積もり」を語ってみませんか? - 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か月半前にリリースできるように計画する(早く終わったら追加しますという姿勢)
  • リリース後に技術的負債の返済用枠を数時間取っておく
  • 全力でがんばっていると信頼してもらうことが、計画づくりには大切
  • 現状を受け入れて計画する