Extreme Hour
原文はhttp://c2.com/cgi/wiki?ExtremeHour
超訳: masaki@metabolics.co.jp
2001/03/05
課題
- 企業セクタを制覇するようなネズミ捕りの新製品を作ること
- 計画、スケジューリング、開発、品質保証
- 時間は1時間
スケジュール
- 10分間 ユーザ・ストーリー、アーキテクチャ・スパイキング
- 10分間 優先度とスコープの見積もり
- 10分間 最初のスケジュール
- 10分間 イテレーション1
- 10分間 スケジュールの修正
- 10分間 イテレーション2
- リリース!
ルール
- 成果物はホワイト・ボードに書く
- ユーザ・ストーリーと機能テストはナプキンに書く
- プレゼンタがコーチをやる
- 聴衆からメンバ9人を集める
- ストップウォッチとSCMノートを持ったトラッカ - 1名
- 開発者 - 4名
- QA - 2名
- 利害関係者 - 2名
- QAは各10分の最後まで、開発者の書いたものを見ることができない
- SCMノートは、開発者が書いて消したものを記録する。開発者はSCMノートから戻すことができる
- 開発者はQAや利害関係者が書いたものを10分の最後まで見ることができない
- トラッカは、5分と最後1分を通告する
ユーザ・ストーリー、アーキテクチャ・スパイキング
- 二人の利害関係者がユーザ・ストーリーを書く
- 二人の開発者がアーキテクチャ・スパイクを描く
- この間、他の人はあちこちに行って、いろいろ提案する
優先度とスコープの見積もり
- 利害関係者はストーリーを三つの山に分ける
- 利害関係者はそれぞれの山の中をさらに優先度に従ってソートする
- 4人の開発者は、スパイキングにもとづいて理想分をストーリーに割り当てる
- 最大10理想分、それ以上に場合には利害関係者に分割してもらう
- 楽観的に行こう。リスクは忘れずに
最初のスケジュール
- ストーリーを二つのイテレーションにスケジュールする
- 優先度とリスクの順にスケジュールする
- 最初の負荷係数は3とする
- つまり、4人x10分/3で、イテレーション当たり13分使える
イテレーション1
- QAは、ストーリーごとに機能テストを書く
- QAは、イテレーションが終わるまで開発者の描いているものを見ることはできない
- QAは、テストを実行してバグを見つける
- バグのあるストーリーは不完全なので、以降の負荷係数に影響する
- 開発者はエンジニアリング・タスクを定義する
- つまり、ユーザのストーリーを満たすものをどうやって描くかについて話し合う。一般的には描く前10秒間で計画を立てるようだ
- 開発者は解決策を描く
- 他の開発者がそれを理解できなければ、単体テスト失敗
- 開発者はできればリファクタリングする
- トラッカは、消されたものを記録する
- 利害関係者は、内緒で新しいストーリーについて考える
スケジュールの修正
- トラッカかコーチが、実際の負荷係数を計測し、次のイテレーションでの負荷係数と理想分を再計算する
- 前のイテレーションで、QAを通ったストーリーの理想分が9分だったとすると負荷係数は40/9で4.4。次のイテレーションでも同じと見なす
- バグを新しいストーリーに直す
- 利害関係者は新しいストーリーを提示する
- すべてのストーリーの優先度とスコープを見直す
- ストーリーをスケジュールにおさめる
- もっと開発者が必要か? あるいは負荷係数をあげる必要があるか?
- エルゴノミックスは負荷係数に影響するか?
イテレーション2
イテレーション1と同じことをやる
リリース!
- 利害関係者はこれが市場に出せるものかどうか検討する
- まだ力が残っていたら、スケジューリングとイテレーションを繰り返す