-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinchiba20120630
参加者は、自由に編集してください。
- 2名
- 第3部
- 見積もりや計画作りのワークショップ
- 文書だけでは誤解を招く恐れがある（意味の取り違えとか）
- 文書の量だけでは何事も計れない、良し悪しも決まらない
結局のところ、フェイス・トゥ・フェイスでコミュニケーションをとることが大切
- 要件は常に変わりゆくもので、文書にする場合は必要最低限（本質的なキーワード）を書き残しておく
- 文書におこすだけでも時間がかかるし、修正にも時間がかかる
文書をおこすことばかりに固執していると、顧客が一番期待している動く製品をいつまでも提供できなくなる
というわけで・・・
最低限、プロジェクトを進める上で必要な文書を、常にチーム内で取り決めておこう
ユーザーストーリーを使ってみる。
ユーザーストーリとは、顧客の要望を簡潔に書き出したもの。したがって、なんでもかんでも書いていいわけではない。
なおかつ、顧客が対価を支払っても「イイ！」と思ってくれる内容じゃないとダメ
- アーキテクチャの話とか書く必要はない（顧客的には裏側の技術などどーでもいいはず）
- Hadoop使ってます！とかきっと興味をひかない
これが必要最低限な文書になる。あとはプロジェクトで必要だと思うものを文書にしておけばいい。
第6章の内容を参考に、ユーザーストーリーを作成。
テーマは「喫煙場所を探せる」サービス。
- Google Mapに喫煙場所をマーキングする
- マーキングした地点に任意でコメントを書く
- 「無料/有料」スペースを選択してマーキングする
- 任意の地点または、GPSで取得した現在地にマーキングする
- 特定の地点（指定した場所または、現在地）から半径50m以内にマーキングされている喫煙場所を表示する
- 半径はユーザーが好きな値で初期設定しておくことができる
- タバコを販売している場所を登録する
- 利用者が任意で登録する
- 運営側が一括で登録する
- タバコを販売している場所を表示する
- 任意で利用者登録をする
- サービスで収益を得たい
- 最終的なサービスのビジョン
- 歩きたばこを減らしたい
上で考えたユーザーストーリーの一部を、テストできる内容にする。
題材は「Google Mapに喫煙場所をマーキングする」を使用。
- Google Mapが表示できる
- GPSで現在地を取得できる
- 任意または現在地にマーキングできる
- （マーキングするとき）無料/有料スペースを選択できる
- 任意でマーキング時またはマーキング後に、その地点にコメントを書くことができる
- 一般的に侵入不可エリア（思いつく範囲では海）、学校や禁煙エリアはマーキングできない
- マーキングに失敗したらエラーを表示する
上記の内容が1つのイテレーション（たとえば2週間）で収まるかは検討する必要あり。
収まらない場合は、ユーザーストーリーの粒度を変える必要がある。
プロジェクトの初期段階で正確な見積もりなど出せない（最終局面に向かうにつれて精度が高まる）
ここは本を参考に・・・
- 1枚のクッキーを10秒で食べ切れるとしたら
- 10枚のクッキーであれば、100秒で食べ切れる（はずだ）
- 途中でむせて、タイムロスするかもしれない
- たとえば、ユーザーストーリー全体が10ポイントだとして、1ポイント/1日で消化できるとする
- 10日ですべてのユーザーストーリーを終えることができると予測できる（多少のブレはあるかも）
これで相対見積りの概念はわかったけど、実践に置き換えるとよくわからなくなる・・・。
じゃあ、とある架空の機能について、日数を使った相対見積りを考えてみよう。
まずはポイントの定義を行う。今回は、下記の定義とした。
- 大
- 中
- 小
大だと○日、小なら△日とか、この時点では考えない。思いついた感覚的な単位（各人で個人差がでてもしょうがない）。 そして、下記の架空機能にポイントを付けて、おおよその規模感を推測する。ここは参加者全員で話し合いながらポイント付け。
- データを表示する（単に、取得したデータを画面に出すだけ。レイアウトなんてない）
- 小
- データを表組みにして表示する
- 中
- データをグラフ化して表示する
- 大
- データを何かしら解析して表示する
- 大
仮に、「小」をつけた機能から手を付け、実装が0.5日で終わったとする。そうすると、まずは下記の予想ができるかもしれない。
- データを表示する（単に、取得したデータを画面に出すだけ。レイアウトなんてない）
- 0.5日で実装完了
- データを表組みにして表示する
- 1日でおわるかも？
- データをグラフ化して表示する
- 5日ぐらいかかるかも？
- データを何かしら解析して表示する
- 大にしたけど、5日よりもっと多くかかるかも？
このようにして、予想しやすい機能を作ってみて（作らずに予想できるならそれでヨシ）基準値をだし、それをもとにしてほかの機能と実装難度を比較することが、相対見積りなのだろうと結論付けた。
なお、各機能にポイントを付けて見積もるときは、プランニングポーカーを使うとよい。使い方は、以下のサイトがわかりやすかった。
http://d.hatena.ne.jp/wayaguchi/20120218/1329524230
- 誰かが病気で倒れたり、事故にあったりして、プロジェクトから外れるかもしれない
- スーパースター軍団にしたのに、開発速度が全然あがらない！
あるある・・・
- 常に開発速度を計測して、完了時期を見積もること
- 開発速度 = リリース可能な成果を開発することができる速度
- この「開発速度」をベロシティと呼ぶそうだ
計画作りを行うにあたり、マスターストーリーリスト（ユーザーストーリーの中から、1～6ヶ月でこなせる範囲を抽出したもの）を用意する。そして、イテレーションは1～2週間とする。
ここでもまた具体例をもとに、実践的な計画作りをしてみる。たとえば、下記のマスターストーリーリストがあるとする。
マスターストーリーリスト
- 大 x 2 → 2イテレーション必要
- 中 x 5 → 3イテレーション必要
- 小 x 20 → 4イテレーション必要
それぞれのポイントは、大=5日/中=2日/小=1日とする。単純計算でおおよそ9イテレーション（18週、5か月弱ぐらい？）となる。
上記のマスターストーリーリストをもとに、ベロシティを決める（ベロシティはプロジェクトが進むにつれて変動する）。イテレーションは2週間とする。
2週間 = 大x1/中x2/小x5
これがチームのベロシティとなる。このベロシティで、マスターストーリーリストに掲げられている機能をどのぐらいの速度でこなせるか算出してみる。
- 最初のイテレーション実行
- 残ストーリー 大x1/中x3/小x5
- 次のイテレーション実行
- 残ストーリー 大x0/中x1/小x15
- 次のイテレーション実行（中が1しかなかったので、その分、小を10こなした）
- 残ストーリー 大x0/中x0/小x5
- 最後のイテレーション実行
- 残ストーリー 大x0/中x0/小x0
4イテレーション（8週）で完了させることができると見積もることができる。
こんな感じで、プロジェクトが進行するにつれてベロシティを変更しながら、完了時期の予測をたてる。
ところで・・・
期限が遅れそうになったときに、顧客と相談して開発スコープを期限に収まる範囲に変えるというアレ。
たとえば・・・
メンバーの離脱によってスケジュールが遅れます！
って許されるの？？？（これをそのまま言わないとは思うけど）
- 遅れを報告せずに、そのまま頑張り続けるか
- 報告して、できるところまで実装して、契約打ち切りとなるのか
- それとも・・・
いずれにせよ、開発側の都合で遅れることを、顧客は受け入れるだろうか？
- 自分が顧客の立場だったら受け入れないだろう
そこで・・・
スコープを変える行為について、実は前提があるのでは？
前提というのはマスターストーリーリスト。たとえば、以下のような、顧客と優先度や重要度を決めたマスターストーリーリストがあるとする。
- 必須機能
- 全体の50% ・・・ ビジネス的に必須であり、開発側は期間内に完了させられるとしたもの
- 顧客は欲しがるが必須ではない機能
- 全体の20%
- あればいいね程度の機能
- 全体の30%
これらのマスターストーリーリストは、顧客と合意がとれている。
この前提を元に、顧客と話をしてスコープを変えればいいのではなかろうか。
最後はまとまりがありませんでしたが、要はただ漫然と遅れます、できませんといってスコープを変えるわけではない。
あらかじめ顧客とマスターストーリーリストで合意をとっておき、最低限顧客に提供できる機能を決めておくことが大切。
以上。