牛尾でございます。
>期間やコストを最初に固定するよりも機能重視。‥‥とは言え、期間やコスト
>が曖昧なままだと顧客が困るんですよね。XPで顧客に発生するリスクって、期
>間の曖昧さが一番大きいような気がします。
>
>うーん、想像で書いてても埒があきません。この辺は経験者に語ってもらうの
>が良いのかも。
そうですね〜。うちのＰＪではプロジェクトの初期に大まかな機能
と、期間を決めています。１〜３イテレーションでカタログ機能実装
みたいな感じです。最初から分かっている機能と、期間で縛っている感じです。
ですので、途中では、「あと２イテレーションしかないので、カタログを
さっさとやらないとやばいですよ」という感じでお客様と一緒に要件を
決めながら作りました。最初から分かっている機能はお客様には「やる」と
約束しています。
あとは、変化ヲ抱擁の範囲を決めています。例えば大きすぎる例ですが、
販売物流のシステムを作っているときにストーリカードで「生産管理を作る」
といわれてもそれは範囲外ですよね。
でも、画面の変化やロジック、機能追加がその枠の範囲内だったらこてこて
に受け入れて、まだやっていない機能だったら同程度の工数のものと
入れ替え可能・・・
ちなみに範囲を超えるもの、イテレーション予定に収まらない機能追加要望
がきたら２次開発に回したりしました。
という感じでやってました。ちょっと説明が難しいですが。。まとめますと
・初期範囲（最初から見えてる機能）
・期間（見積もりは当然４０時間計算）
・変化ヲ抱擁範囲
を決めて、初期範囲から想定される機能から見積もり、危険係数を掛けて（つまり
これが変化ヲ抱擁枠）という感じでしょうか？そして、合意した枠に対してお客様
と協調して作業をすすめてイテレーション内に収まるようにする。という感じです。
以上です。