アジャイルな見積りと計画づくり2

アジャイルな見積りと 計画づくり2 2014年5月23日 ＧＭＯインターネット株式会社 次世代システム研究室 藤村 新 1

目次 1) 前回の復習 2) 見積もり方法 3) 優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ 2

目次 1) 前回の復習 2) 見積もり方法 3) 優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ 3

前回  計画の目的  なぜ従来の計画づくりは失敗するの か  なぜアジャイルな計画づくりはうまくい くのか 5

今回  具体的な方法  見積り方法  優先順位の付け方  リリース計画の作り方  イテレーション計画の作り方 6

目次 1) 前回の復習 2) 見積もり方法 3) 優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ 7

期間の見積もりは以下のようなプロセスになる 要求されるフィーチャ 規模の見積もり 期間への変換 スケジュール

1.ストーリー ポイント 2.理想日

http://www.slideshare.net/YohNakamura/yohhatu-yohhatu

http://www.slideshare.net/YohNakamura/yohhatu-yohhatu

http://www.slideshare.net/YohNakamura/yohhatu-yohhatu

作業量の見積り と 期間の見積り が分離

ストーリーポイントの長所  職能横断的な作業の進め方 を促進する  長持ちする  純粋に大きさだけをあらわす  早い  僕の理想日と君の理想日は 違う

プランニングポーカー 活発な対話を引き出す

1.ストーリー ポイント 2.理想日

サッカーの試合の長さ？ • 理想時間： • 45分＋45分＝90分 • 現実時間： • 45分＋3分＋15分＋ 45分＋5分≒113分

•リリース済みプロダ クトのサポート •体調不良 •会議 •デモンストレーション •私用 •電話応対 •緊急の割込み作業 •トレーニング •メール •レビューやウォークス ルー •候補者の面接 •タスクの切り替え時 間 •リリース済みプロダ クトのバグ修正 •マネージャとの面談 18

各ストーリーで 担当ごとの理想日を 見積もるという 手間をかけても、 報われる事は滅多にない

理想日の長所 • プロジェクト関係 者に説明しやすい • 導入しやすい

理想日 ≠ 現実日

目次 1) 前回の復習 2) 見積もり方法 3) 優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ 22

優先順位づけの判断要素 1. 金銭価値 2. 開発にかかるコスト 3. 開発を通じて学べる知 識の量とその意義 4. 低減できるリスク

優先順位づけの判断要素 1. 金銭価値 2. 開発にかかるコスト 3. 開発を通じて学べる知 識の量とその意義 4. 低減できるリスク

オススメは 「望ましさ」 による優先順位 づけ

顧客満足度の狩野モデル 1. 2. 3. 当たり前、または必須の フィーチャ 線形、一元的なフィーチャ 魅力的な、わくわくする フィーチャ

例)ホテルの特徴  必須  ベッド、バスルーム、机、清潔であること  あればあるほど良い  ベッドの寝心地、部屋が広い、ジムにあ るマシンの種類と台数  魅力的  ウォーキングマシンのテレビ、毎日無料 でミネラルウォーターがもらえる

http://www.nttdata.com/jp/ja/insights/trend_keyword/2013071101.html

例)ホテルの特徴  充足質問  毎日無料でミネラルウォーターがもらえ たらどう思いますか？  気に入る  不充足質問  毎日無料でミネラルウォーターがもらえ なかったらどう思いますか？  しかたない

http://sugiim.hatenablog.com/entry/2013/04/15/110321

1. 2. 3. 当たり前のフィーチャは不可 欠。リリースまでに必ず開発。 線形のフィーチャをできるだ け多く完成させる。 魅力的なフィーチャはこれら の機能を実装した後に、時 間の許す範囲で対応する。

目次 1) 前回の復習 2) 見積もり方法 3) 優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ 32

1.   2. 3. 4. 5. 満足条件を決める 日付主導 フィーチャ主導 ユーザーストーリーを見積もる イテレーションの長さを決める ベロシティを見積もる ユーザーストーリーに優先順位 を付ける

6.  ストーリーを選択し、リリース日 を決める 日付主導  イテレーション数にベロシティを掛け れば、リリースに含められるストーリー ポイントの合計を求められる。  フィーチャ主導  リリースに必要なすべてのフィーチャ の見積りを合計し、その値をベロシ ティで割る。

ストーリーポイント合計 ÷ ベロシティ

重要なのはリリース計 画を更新する事。 イテレーション終了時 点でリリース計画を見 直す。

目次 1) 前回の復習 2) 見積もり方法 3) 優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ 39

計画の 「水平線」 構成要素 リリース計画 イテレーション計画 3～6ヶ月先 1～4週間先 ユーザーストーリー タスク 見積り単位 ストーリーポイント または理想日 理想時間

イテレーション計画 の成果物

イテレーション 計画で やらない事

タスクの 担当者を 決めない

プロジェクトが最もうまくいくのは、 チームに「全員が一丸となって取り 組む」という態度が備わっていると きだ。 自分の空いた時間はチームのため に使うし、他のメンバーもきっとそう してくれると思える状態である。

イテレーションが始まる前に、すべて のタスクにサインアップして担当者 を決めてしまうと、イテレーションの ゴールに向かってチーム全員が一丸 となって取り組むという参加意欲に 水を差すことになるのだ。

1. 2. 3. 4. 5. 6. 優先順位を調整する 目標ベロシティを決める イテレーションのゴールを決める ユーザーストーリーを選ぶ ユーザーストーリーをタスクに分 解する タスクを見積もる

 多少の設計はOK  ある程度の設計に関する議 論は必要  クラス図などのモデルまでい くと危険  タスクの適切なサイズ  1営業日に1つ完了できるぐ らいの大きさが適切

目次 1) 前回の復習 2) 見積もり方法 3) 優先順位の付け方 4) リリース計画の作り方 5) イテレーション計画の作り方 6) まとめ 49

    ストーリーポイントを用いるべき 優先順位も感覚ではなく手法 (狩野モデル等)を用いて決め てみる イテレーション終了時にリリー ス計画を見直す 「タスクの担当者を決めない」 はやってみる価値がある

おわり 51