アジャイルな見積もりと計画づくり
https://images-na.ssl-images-amazon.com/images/I/51A8BTrHYxL._SX363_BO1,204,203,200_.jpg
一応全部読んだけど、チームに対してシェアすべきなのはまえがき〜8章、22章あたりだと感じたのでそれを中心にまとめ。
用語の整理
リリース
ソフトウェアを実際の顧客に提供し、実用に使ってもらうという広い意味で使っている。計画の最終目標はリリースである。実際の作業ではソフトウェアの実装だけでなく、ドキュメントや本番運用環境の準備、ユーザーテストなどを含むことがあるが、それらの然るべき手順さえ踏めばすぐにリリースできる状態を「リリース可能なソフトウェア」とよんでいる。
フィーチャ
ソフトウェアの機能、特性や特徴、性能目標、見た目や使い勝手など、いわゆる売り文句になるものの総称。フィーチャはあくまでも「ユーザーにとっての価値」を示すので、性能目標やセキュリティなどの非機能要件も含まれる。
イテレーション
プロジェクトを進行する際の区切りとなる期間の単位。通常1週間〜4週間程度とされる。本書のおすすめは2週間。各イテレーションごとにリリースを行う。
ユーザーストーリー
ユーザーの視点からプロダクトのフィーチャの概要を示したもの(以下は表現方法の違いの例)
例)通常のタスク:検索機能を実装する
例)ユーザーストーリー:本の購入者としてISBNで書籍を検索したい、それは探している本を素早く見つけるためだ
ストーリーポイント
ユーザーストーリーやフィーチャ、その他の作業の大きさを表す単位。
あくまで作業の相対的な大きさを示すものとして使い、各ユーザーストーリーのストーリーポイントは10倍以内に設定するのが良い。
例)犬の体高の相対的な指標をつけてみる(ダックスフント、テリア、シェパード、ゴールデンレトリーバー、プードル)
一番小さいものを基準とする方法、真ん中のものを基準とする方法が紹介されている
たとえばテリアやプードルなど、詳細に種類がわからない(要件が曖昧)なものは平均的と思われるサイズでつける、など
ベロシティ
チームの作業速度を表す指標。速度はイテレーション中に消化したストーリーポイントの総和で得られる。
ストーリーポイント自体が相対的な指標であり、作業の大きさを見積もっているので、そこから得られる速度(=ベロシティ)も相対的な指標である。ただこれらの相対的な指標を用いることで計画を立てるのに必要な「期間」を算出できるという点が優れている。
不確実性コーン
見積もりや計画づくりは重要だが、難しくて誤りやすい
見積もりや計画づくりはプロジェクトが進むにつれて正確さを増していく(=不確実性が減少していく)これを図示したものが不確実性コーンと呼ばれるものである
理想時間(理想日)
何かをするときにかかる時間のうち、周辺の作業の時間を差し引いた時間
現実時間(現実日)
何かをするときにかかる時間で時計やカレンダー上で現実に経過した時間
例)アメフトの試合は試合時間だけでいうと60分(=理想時間)だが実際のテレビ放送は3時間(現実時間)かかる
アジャイルソフトウェア開発とは(まえがき・3章)
迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称
通常、アジャイルを導入する目的は、ビジネスの変化に柔軟に対応すること
ユーザーが求めているものはそもそも不確実性があり、はっきりしないものであるということを認める
他のプロセスに対して、より不確実性と向き合い、より変化に柔軟に対応し、価値を顧客に届けることに主眼を置く
本書を読む上で大切なことや前提となること
この本を読んでも100%正確に見積もりができるようになる、というようなものではない
そもそも正確な見積もりは不可能であるということを念頭に置く
なぜ見積もりや計画が必要か(1章)
なにをつくるべきか?を決めるために計画や見積もりが必要
この回答に説得力を持たせる計画づくり
計画づくりそのものが、リスクと不確実性を低減させ、信頼の置ける意思決定を導き、信頼関係を確立し、情報を伝達するものになっている
よい計画とは以下のようなものである
リスクを軽減する
不確実性を減らす
意思決定を支援する
信頼を確立する
情報を伝達する
‥でも見積もりや計画は難しい
なぜ見積もりや計画が失敗するのか?(2章)
フィーチャではなく作業を見積もっている
マルチタスク
優先順位付けが誤っている
不確実性を無視している
見積もりはあくまで確率であることを無視している
…これらをアジャイルな計画づくりで克服していく。
なぜアジャイルな計画づくりがうまくいくのか(22章)
計画を頻繁に見直す
規模の見積もりと期間の見積もりを分離している
複数レベルの計画を立てている
リリース > イテレーション > 今日
計画の基準がタスクではなくフィーチャである
ユーザーに届く価値をもとに優先度がつけられる
小さなストーリーが流れをつくる
イテレーションごとにリリースする
イテレーションから仕掛作業を持ち越さない
リリースまで完了したものだけをカウントするようにする
これによってイテレーション内で完結する分量に作業が切り出せるようになる
不確実性を受け入れて、計画に取り組んでいる
アジャイルな計画づくりで大事なのはできあがった計画よりも、計画を立てるという活動そのものだ。アジャイルな計画づくりは変化を促進する。アジャイルな計画づくりは、立てた計画を用意に変更できる。アジャイルな計画づくりはプロジェクトのはじめから終わりまで何度も繰り返される。
計画づくりは最初に決めて終わりではない
計画づくりはプロジェクトの期間全体に均等に分散させて行う
計画づくりが繰り返されることで不確実性を減らす
計画の立て方は大きく分けて2種類
ストーリーポイントによる見積もり(著者のおすすめ)
理想日による見積もり(導入時はこちらから)
ストーリーポイントによる見積もり(4章)
期間ではなく、規模を見積もるやり方
ストーリーポイントによる見積もりは、規模を見積もる
比較的時間をかけずに見積もれる、人に依存しないなどの利点がある
理想日による見積もり(5章)
理想日で見積もると具体的でなじみがありとっつきやすい
チームが規模の見積もりに慣れていない時期などにも導入しやすい
ただし各人によって見積もる理想日が違うことがある(スキルの差など)ので注意が必要
自分の理想日は現実日で何日か、あるいは自分の理想時間は現実時間で何時間に相当するか、を把握する
大体4~5h程度とされる
見積もりの技法(6章)
完全な見積もりは存在しない
収益逓減の法則(時間をかけても精度はさがる)
アジャイルなチームは見積もりから不確定な要素を取り除くのが不可能であると認識しているので、必要以上に時間と労力をかけて見積もりに正確さを求めることをしない
できるだけ少ない労力で、どのあたりの正確性を求めて見積もりを立てるのかを意識するとよい
見積もりを何度も見直しながらすすめるのがアジャイルの手法(不確実性を減らす)
再見積もりのタイミングは、ストーリーにつけた相対サイズ(ポイント)について考え方がかわったとき
もっと具体的なテクニック
プランニングポーカーは見積もりの主要な技法を詰め込んだ効率のよい方法
チームで見積もる、専門家の意見を聞く、分割する(見積もりやすいように小さく分ける)、対比する(相対的な大きさを見積もる)
決まった数のポイントのカードを皆で持った状態で、あるユーザーストーリーに対してどのポイントをつけるかを出し合う
テーマの優先順位付けは下記の指標をもとにする
金銭価値
フィーチャの開発コスト
フィーチャの開発によって学べる知識の量とその意義
フィーチャの開発によって低減できるリスク
「望ましさ」による優先順位付け
必須・当たり前のフィーチャ
あればあるほどよいフィーチャ(線形・一次元的フィーチャ)
魅力的な・ワクワクするフィーチャ(潜在的なニーズ)
導入可能な部分に絞ったまとめ
アジャイルな計画づくりは「何を作るべきか決める」ため
言い換えると「ユーザーにどのような価値を届けるかを決める」ためのもの
なので、計画の基準はタスクではなくフィーチャ
ユーザーに届ける価値をもとに計画を立てるということ
計画が失敗する理由を排除する
作業を見積もるのではなく、フィーチャを見積もる
マルチタスクをしない
不確実性を無視しない
見積もりをコミットメントにしない
見積もりについて
見積もりから不確定な要素を取り除くのは不可能だと認識する
規模と期間の見積もりは分けて考える(別の単位をつかう)
見積もりはチームで行う(プランニングポーカー)
見積もり・計画づくりはプロジェクト内で何度も繰り返す
イテレーションについて
イテレーションの期間はチームで決めてよい(だいたい1~4週間)
イテレーションごとにリリースする(実際にリリースしなかったとしてもいつでもリリース可能な状態にする)
その期間でリリースできないものはストーリーの分割が必要であると判断される
仕掛りは持ち越さない(次のイテレーションに持ち越す場合も優先度であらためて判断)
見積もりと実行はチーム全体で取り組む
チームの速度をベロシティで確認する
本書では個人についてトラッキングしないことをおすすめしている
個人のこなしたポイント数をトラッキングするとチーム内で助け合いが生まれにくくなる
イテレーションの管理にタスクボードを用いる
例)ストーリー/やること/受け入れテスト可能/作業中/確認待ち/時間
一人が同時にサインアップ(担当)できるタスクは一つだけ
どれだけやったかを知るより、あとどれだけ残っているかを知るようにする