Date:  Tue, 21 May 2002 00:47:46 +0900
From:  Hidehiko AKASAKA <akasaka@....jp>
Subject:  [XP-jp:03476] Re: FYI: [NOS] 仕様変更に打ち勝つ
To:  extremeprogramming-jp@....jp
Message-Id:  <20020521004059.2F70.AKASAKA@....jp>
In-Reply-To:  <iss.4ad3.3ce890a4.f22a3.1@....com>
References:  <20020517094702.6EB6.AKASAKA@....jp> <iss.4ad3.3ce890a4.f22a3.1@....com>
X-Mail-Count: 03476

こんにちは、赤坂です。

[XP-jp:03473] Re: FYI: [NOS] 仕様変更に打ち勝つ
> >ウォーターフォールであっても
> >きちんと要求仕様がまとめられていれば、開発中であっても顧客の変更の要求は
> >受け付けられると思います。
> >もちろん、その時点で変更のリスク(開発工数、スケジュール等へのインパクト)
> >をきちんと検討することで、変更を"認める"または"認めない"判断が出来るはず
> >です。
> 
> 検討するだけでも工数がかかります。変更要求が続出すると変更しなくても
> それだけで作業が大きく遅れることになりかねません。

変更要求が続出してしまうと、その通りだと思います。
XPでは2週間程度といった短いイテレーションサイクルなので、途中で変更要求
が続出してしまうことはなさそうですね。というか、このくらい短いサイクルな
ら、イテレーションごとに変更要求の確認を行っても十分なのでしょうね。

[XP-jp:03472] Re: FYI: [NOS] 仕様変更に打ち勝つ
> >もちろん、繰り返し型開発でもXPに代表されるように、イテレーション注でも
> >必要があれば"勇気"をもって対応する(変更する)ものもたくさんあります。
> 
> XPでは、イテレーション中の変更については、変更するとも変更しないとも
> 特に言及されていなかったような……。

そうでしたっけ(^^;;。
必要あればいつでも変更する勇気を持ち合わせているのかと思っていました。
というか、きちんと読んだことがありませんでした。
短いサイクルでイテレーションを繰り返すのは、変更のタイミングを
コントロールしているのですね。
# すみません、きちんと本を読んでおきますm(_._)m

--
赤坂 英彦 (Hidehiko AKASAKA)
akasaka@....jp