# アジャイルサムライ　第Ⅲ部　アジャイルな計画づくり
## 第6章　ユーザーストーリーを集める
### 6.1 文書化の難しさ
文書化は、多くのプロジェクトで役に立たない。なぜなら
* 変化に対処できないため。
* 顧客の欲しいものではなく仕様に合わせて作ることになるため。
* 下手な推測や誤った前提を招くため。
* 多くの時間を無駄にするため。
**→文書に頼りすぎてはならない。**

### 6.2 ユーザーストーリー
ユーザーストーリーは、インデックスカード（小さなカード）を用いて、想定するユーザの振る舞いを書き出す。書き出したものは、顧客へのインタビューの材料となる。
顧客の要求を収集する最大の目的は、**本質を捉えるキーワード**を聞き出し、書き留めておくことである。
思いついた時点では、本当に必要になるかどうかまだ分からないからである。
ストーリーは必ずしも顧客（プロダクトオーナー）が書く必要はない。

### 6.3 良く書けているユーザーストーリーとは
* INVEST(ビル・ウェイクの考案)
* Independent(独立している)　ストーリーは互いに独立している。
* Negotiable(交渉の余地がある)　期限や数値は交渉の余地がある。
* Valuable(価値がある)　顧客が「価値」を感じられるような、具体性のある文面にする。
* Estimatable(見積もれる)　実施期間が見積もれる。
* Small(小さい)　1~5日で完了できるよう粒度を小さくする。
* Testable(テストできる)　テストできるストーリーは完了の基準が明確になる。

#### デイブのユーザーストーリー
＜ユーザーの要求＞
* イベント予定表
* 割引グッズ一覧
* ビーチの状況をリアルタイムで配信する。
* 更新がすぐに反映される。
＜制約条件＞
* ウェブサイトはサクサク表示して。→2秒以内
* デザインはカッコよく。
#### ユーザーストーリーのテンプレート
[ユーザーの種類]として、[達成したいゴール]をしたい。なぜなら[理由]だからだ。

### 6.4　ストーリー収集ワークショップを開催する
* なるべく多くのフィーチャーを捉えるため、顧客と開発チームが一緒にユーザーストーリーを書いていく。
* 大人数が入れる大きい部屋で行い、図をたくさん用いてブレインストーミングが効率よく進められるようにする。
* ユーザーストーリーを抽出する際は、INVESTの原則を心掛ける。
* 大きめのストーリーはエピックと呼び、ざっくりとした計画や、必要である確信が持てない時に役立つ。
* その他必要なもの（書類作成、資材準備期間等）も洗い出し、ストーリーをリスト化する。

## 第7章　見積もり　当てずっぽうの奥義
### 7.1 概算見積もりの問題
プロジェクトで最初に出す見積もりは、そもそも当てずっぽうにすぎない。
問題となるのは、見積もりへの期待の大きさが異なる点である。
顧客は、見積もりは正確な予測であると思っているが、実際には当てずっぽうなので不確実性が大きい。（不確実性コーンのグラフ）
この期待の差が大きいまま合意してしまうと、後から顧客と開発チームで深い亀裂が生じることになる。

#### 正しい見積もりを行う
あくまで見積もりは、プロジェクトをやり遂げられるかを知る目的で行う。
正しい見積もりを行うためには、以下の3点が必要である。
* 今後の計画を立てられる。
* 見積もりは当てずっぽうである前提条件を踏まえている。
* ソフトウェア開発の複雑さを認めている。

### 7.2 ピンチをチャンスに
正しい見積もりのために行うのが、相対見積もりと、ポイント化である。
#### 相対見積もり
あるユーザーストーリーを完了させるまでの期間を基準（1）として、基準値の何倍であるかを見積もる。絶対的な見積もりを取り去ることで、より概算的になる。一方で、1日＝1営業日としてしまいがちである。
#### ポイント化
基準値を日数で示すのではなく、ポイントで表す。大きいポイントほど大変な作業である。相対見積もりと比べて感覚的なのが特徴で、具体的な日数に左右されないメリットがある。

### 7.3 見積もり技法
#### 三角測量
代表的なストーリを基準として選出し、残りのストーリーを相対的に見積もる。
実際のストーリーと明らかに違う場合は再見積もりを行うが、それなりに正しければよい。
検討がつかないストーリーは、タイムボックス化された実験「スパイク」を行って見積もる。
#### プランニングポーカー
開発メンバー全員が集まって、ユーザーストーリーに対する見積もりを合わせるためのアクティビティである。
ポイントが書かれたカードを用いて、メンバーそれぞれの見積もりをポイントで表す。意見が異なれば、話し合いを行った上で全員が一致するまで繰り返す。
投票システムではなく、話し合いで見積もりを調整する場である。また、プランニングポーカーの数字はなるべく小さいもののみを用いる。

## 第8章　アジャイルな計画づくり：現実と向き合う
### 8.1　固定された計画の問題
変化に対応できない計画は順風満帆なスタートでも、突如として崩壊していく可能性がある。（主力メンバーの引き抜き、開発速度が思った以上に低い、顧客の要求が変わるetc...）
プロジェクトが成功するための計画には、次の4つの観点が必要である。
* 顧客にとって価値ある成果を届けられる計画。
* わかりやすくありのままを伝える、誠実な計画。
* 約束を守り続けられる計画。
* 必要に応じて変更できる計画。
### 8.2 アジャイルな計画づくり
まずは、チームの開発速度を計測する必要がある。
* Todoをまとめた「マスターストーリーリスト」
* ユーザーストーリーから動くプログラムへの変換速度である「ベロシティ」
* スクラムのスプリントに代表される、開発期間単位の「イテレーション」
この３つで表す。
まず、「イテレーション数=全作業量÷予想ベロシティ」でイテレーション数を見積もる。ここからイテレーションをこなして、予想と比較して進みが早いか遅いかを見る。実際のベロシティが予想より大きいと速く、小さければ遅くなる。
### 8.3 スコープで柔軟に
作業量が多すぎる場合、マスターストーリーリストを見直す。ここで要求される範囲＝スコープを見直すことで、作業量を減らす。
なお、スコープを柔軟に変更できるよう、顧客側に外すユーザーストーリーを予め決めてもらうことが大切である。
### 8.4 初回の計画づくり
1. マスターストーリーリストを作る（スクラムのプロダクトバックログ）
ユーザーストーリーを実現するためのフィーチャーの一覧である。
顧客が優先順位をつけて、開発チームが見積もる。
およそ1~6か月程度でこなせる仕事の範囲に収まるようにする。
この中から、1~3か月分程度で分け、ストーリーのサブセット「リリース」としておく。
リリースは、そのまとまりで実装してデプロイできる価値がある編成にする。
MMF（Minimal Marketabke Feature set）　最小限度の市場価値のある機能をまとめておく。=>MVPの要素となる。
2. プロジェクト規模を見極める
プロジェクトの規模と、その旅の長さの見通しを見極める。
3. 優先順位をつける
最も重要なストーリーから順番に実装する。そのためには、顧客にビジネスの観点から優先順位をつけてもらう。また、開発チームは技術的なリスクが高いものは先に片づけるよう伝える。
4. チームのベロシティを見積もる
8.2, 8.3の通りに、ベロシティを見積もる。
この時、個人の生産性を計測しないこと。チームの信頼関係が崩れてしまう。
プロジェクトを始めたばかりだとベロシティは安定しないが、3～4回イテレーションをこなせば安定する。
完了の定義をあらかじめ確認しておき、漏れが無いかをチェックできるようにする。
過度な期待を抱かせず、控えめな目標で良い。計画は当てずっぽうであることが前提なのだから。
5. 期日を仮決めする
開発期日は、期日固定型だと変化への対応が難しい（重要なストーリーが見つかった場合、スコープ内でトレードオフを行う）一方で、メンバーの緊張感を保つことができる。
フィーチャーセット固定の場合、期限を柔軟にする代わりに確実な機能提供が求められる。基本的にフィーチャーをすべてこなすまで終われないが、中核部分が完成すれば、残りは調整可能である。
### 8.5 バーンダウンチャート
縦軸を作業量、横軸を時間とし、イテレーションごとにベロシティ分グラフの高さを下げていき、どの程度の速度で開発できるかを表にまとめたものである。
* 残りの作業量
* 完了させた作業量
* チームのベロシティ
* いつ頃に終えられるか
以上の4つが分かる。
また、新たなストーリーの追加や要求の変更などの背景の動きも、グラフの動向になって見える化する。
プロジェクトのありのままを伝えてくれるチャートである。
#### バーンアップチャート
逆に、終了したベロシティ分が徐々に積みあがっていくバーンアップチャートもある。ストーリー量の変化のグラフが書き加えられ、分かりやすい。
### 8.6 プロジェクトを途中からアジャイルにする
行き詰まり、早く成果を上げたいならば、現状の計画を捨て、インセプションデッキの構築から進めていくしかない。新しく、信じることのできる計画を立て直していく。
そこからは、可能な限りはやくMVPを届け、小さくてもいいので価値のある成果を届けていく。「完了」を繰り返すことで、やがて顧客の信頼は回復に向かうであろう。

### 8.7 現場で実践する
これまでの理論をもとに、現場で実践していく。
#### シナリオその1:　顧客が新しい要求を発見したら
顧客にその要求をどうしたいかを尋ねる。期限を延ばして作ってもらうか、ユーザーストーリーから優先度を低いものを除外するか。
決めかねている場合は、オプションとして「あるといいな」リストに加える。
#### シナリオその2:　進捗がおもったよりも遅い
ベロシティが思うように上がらない場合。序盤であれば想定内。計画は当てにならない前提と柔軟なスコープがあれば対処できる。
ここで重要なのは、開発速度が上がらないという事実について話し合ったり、顧客に選択肢を持たせたりすることである。
悪い知らせも素早く伝えて対処するのがアジャイルの流儀である。
この問題が終盤であれば難しいため、隠さず率直に顧客と話し合った方が良い。
##### スパルタ戦士の流儀
スパルタ式では、余分な部分を省いた最小バージョンでさえも間に合わないなら、計画が間違っているとみなす。
中核のフィーチャーをいくつか選び、その実装にどれくらいかかるかを計測する。この計測結果を基準として、相対見積もりを行う。
そして、残りの時間とリソースで達成できるかを確認する。
達成不可能な場合、顧客との交渉に臨む。事実をはっきりと伝え、計画を修正するための良い議論に繋げる。
#### シナリオその3:　チームメンバーが抜けた場合
顧客にその旨を報告し、進捗の遅れが生じることを伝える。
そして、メンバーが抜けた後のベロシティの減少幅によって、具体的にどの程度の影響が出るかを見積もり、顧客に報告する。

#### シナリオその4: 時間が足りなくなったら
一番はスコープを調整する事であるが、顧客と問題に向き合い、解決策を真剣に模索することになる。
顧客が困ったときに救いの手を差し伸べることは、長続きする信頼関係の構築につながる。お客様に選択肢を示せることが大事である。
また、この時の話し合いは双方向でなくてはならず、一方的な押し付けはしないことが望ましい。

###### tags: `読書`