要求と見積り
Scrum Guide、Ron Jeffries の Card/Conversation/Confirmation、Bill Wake の INVEST、 Agile Alliance のユーザーストーリー、Martin Fowler の The Purpose of Estimation を 取得して読み、理解した内容を自分の言葉で書いたもの。本文の引用はしていない。
このリポジトリは**「作ると決まった後」から始まっている**。ここがその手前。
範囲を先に断っておく。 公開されている一次情報で書ける範囲に絞っている。 要求工学の網羅的な体系(BABOK、Cohn や McConnell の見積り手法)は 有料または書籍なので、規約(一次情報源を実際に取得してから書く)を満たせず含めていない。 扱うのは、要求を文書ではなく会話として扱う流儀と、見積りを何に使うのかの判断。
要求を「文書」ではなく「会話」として扱う
ユーザーストーリーは3つの C でできている。
| 何か | |
|---|---|
| Card(カード) | 要求を識別し、思い出すためのしるし |
| Conversation(会話) | 要求の中身が実際に決まる場 |
| Confirmation(確認) | どうなれば「できた」と言えるかの合意。受け入れテスト |
カードは要求のすべてを含まない。 ここが最初の要点。
カードは会話のための約束手形であって、仕様書の圧縮版ではない。 優先度と費用を書き込み、完了したら顧客の手元へ戻る、という運用上の道具でもある。
会話は主に口頭で、文書で補える。ただし 最良の補足は例であり、最良の例は実行可能なもの。
確認の順序が独特で、顧客は「何が欲しいか」を、 「どうやって出来たことを確認するか」を伝えることで示す。
つまり受け入れテストが要求の実体になる。 この形にすると、顧客は納品を検証でき、開発者は着手前に理解を確かめられる。
テストと、 原則の 「推測ではなく実際にどうなるか」が、要求の段階から効いている。
ストーリーの書き方と、外し方
よく使われる形は 役割・機能・価値。
[利用者の役割] として、[できること] が欲しい。なぜなら [価値] だから
落とし穴の方が有用なので、そちらを挙げる。
既存の要求仕様書の構造からストーリーを起こす(顧客に聞かずに作る)
会話の媒体ではなく、静的な文書として扱う
計画の射程を考えずに、全部を同じ詳細度で書く
ユースケースと混同する
画面やダイアログのような技術的な部品をストーリーと呼ぶ
詳細度は実装の時期で変わる。 近いものほど深く、遠いものは粗くてよい。 全部を同じ粒度に揃えようとするのが、この領域で最も無駄が出るところ。
INVEST
ストーリーの品質基準。満たさないものは分割する。
| 意味 | |
|---|---|
| Independent | 概念が重ならず、どの順でも実装できる。常に達成できるわけではない |
| Negotiable | 機能の明示的な契約ではない。 詳細は顧客と開発者が一緒に作る |
| Valuable | 顧客にとっての価値がある |
| Estimable | 順序づけと日程化ができる程度に理解されている |
| Small | せいぜい数人週。数人日に制限するチームもある |
| Testable | 「テストを書ける程度には、何が欲しいか分かっている」 |
V が実装に直結する。 分割するときは ネットワーク・永続化・ロジック・表示を貫いて縦に切る。層で横に切らない。
横に切ると、出来上がるのは顧客に届かない途中の基盤になる。 「今スプリントは DB 層をやりました」に価値がないのはこのため。
E が満たせないときは、**時間を区切った調査(spike)**を先に置く。 見積れないものを見積らせない。
T の言い換えが効く。カードは 「テストを書けるくらいには分かっている」という暗黙の約束を運んでいる。 書けないなら、それはまだ要求になっていない。
積み残しの管理
Product Backlog は「製品を良くするために必要なもの」の、順序づいた、常に変化する一覧。 やる仕事はここからしか出てこない。
Refinement(手入れ)は継続的な活動で、項目を小さく正確にし、 説明・順序・大きさを足していく。
Product Owner Backlog の管理に責任を持つ
Product Goal を決める。項目を作り、順序を決める
Backlog が透明で、見えていて、理解されている状態にする
1スプリントで完成させられる大きさになって初めて、選択できる状態になる。 その透明性は、手入れを重ねた結果として得られる。
Product Goal は製品の将来の状態の記述で、計画の的になる長期の目標。 Backlog の中にあり、残りの項目はそれを満たすために現れる。
見積りは誰がするか
作業をする開発者が、大きさの見積りに責任を持つ。
Product Owner はトレードオフの議論に影響を与えられるが、見積りを割り当てない。
スプリント計画の3つの論点も、責任の所在が分かれている。
なぜ このスプリントが関係者にとってなぜ価値があるか(Sprint Goal)
何を 開発者が Backlog から項目を選ぶ。PO と相談しながら
どうやって 開発者が分解と進め方を決める。他の誰も、やり方を指示しない
見積りの目的
見積りそのものは良くも悪くもない。問題は、それが何かの判断に使われるかどうか。
見積りを求める前に問うべきことが1つある。
この見積りは、どんな判断に使われるのか。
重要な判断が出てこないなら、その見積りは無駄。
価値がある場面。
資源の配分(競合する案件のどれに投資するか)
チーム間の調整(相手の完成時期が分からないと着手が早すぎる)
会話のきっかけ(数字より、見積り会議で起きる技術的な議論の方が価値がある)
計画を基準線として使い、新しい要求が既存の制約にどう収まるかを見る
有害になる場面。
判断と切り離された、手続きとしての見積り
非現実的な期待を作り、チームを消耗させる
機能を仕上げること自体が目的になる
低い見積りに合わせるために品質を落とす圧力になる
見積りは低めに出る。 そのうえ損失回避の心理が働くので、 外したときの失望が不釣り合いに大きくなる。 緩和するのは精度ではなく、見通しの変化を顧客と定期的に話し続けることの方。
賞味期限の比喩が的確で、見積りはレタスに似ている。 数日はよく、1週間でしなび、数ヶ月経つと原型をとどめない。
見積りをやめる選択もありうる。 小さく、事業側と密に動いているチームで、 見積りが重要な判断に使われないと双方が理解している場合は成り立つ。 ただしやめるなら、見積り会議で起きていた価値ある会話を、どこか別で起こす必要がある。
完成の定義
Definition of Done は、増分が製品に必要な品質基準を満たした状態の、形式的な記述。
満たしていない仕事は、そもそも増分の一部ではない。
テストや コードレビューの基準は、 この定義の中身にあたる。定義が曖昧なまま速度を測ると、 生産性の計測の落とし穴に入る。
このリポジトリの他の場所との関係
| ここでの話 | 対応する場所 |
|---|---|
| 受け入れテストが要求の実体 | テスト |
| 実行可能な例が最良の補足 | 原則 |
| 縦に切る(層で横に切らない) | モジュール境界 |
| 見積りは何の判断に使うのか | 生産性の計測 — 測る前に測る価値を問う、と同じ構造 |
| 変化のリードタイムを測る | リリースとデプロイ |
| 作ったものをいつ畳むか | 廃止 |
書けていない範囲
一次情報が公開されていないため、以下は扱っていない。
要求工学の体系的な手法(BABOK は有料)
見積り技法の各論(プランニングポーカー、ファンクションポイント、
ベロシティの統計的な扱い。Cohn / McConnell は書籍)
非機能要求の洗い出し手法
見積りの「精度を上げる技法」がここにないのは、意図的でもある。 上記のとおり、効くのは精度よりその見積りが何の判断に使われるかの方。