Index: [Article Count Order] [Thread]

Date:  Fri, 20 Sep 2002 12:54:25 +0900 (LMT)
From:  Mika Ohtsuki <mika@....com>
Subject:  [XP-jp:03752] Re: XP&アジャイル開発プロセスセミナーに参加しました。
To:  extremeprogramming-jp@....jp
Message-Id:  <20020920125425Y.mika@....com>
In-Reply-To:  <iss.5c28.3d89c219.84bd.1@....com>
References:  <20020912113214J.mika@....jp>	<iss.5c28.3d89c219.84bd.1@....com>
X-Mail-Count: 03752

みかまま、こと大月@佐賀大学です。

From: HAMAI Kyoichi <k-hamai@....com>
Subject: [XP-jp:03747] Re: XP&アジャイル開発プロセスセミナーに参加しました。
Date: Thu, 19 Sep 2002 21:22:34 +0900

> >> XPの場合、短いイテレーションにより、「チェーン」が実質的にできない
> >> ようにして、スケジュールの狂いの影響を最小化しようとしている。
> >> と私は認識しています。

> >ああ、私はちょっと考え方が違って、イテレーションの終わりがチェーンの合
> >流ポイントになってるのかなぁ、と思いました。
> 
> 「クリティカル・チェーン」は、ウォーターフォールの一種になりますから、
> あえて言うなら、一つのイテレーションがチェーン全体に相当すると思います。

クリティカル・チェーンも、その基本となっているPERTも別にウォーターフー
ルの一種ではないと思います。作業の依存関係をネットワークとして表現する
こと、作業単位で時間見積りをして、どのパスがクリティカル(あるいは制約
になっているか)を考えることができるようにする、という考え方にすぎませ
ん。

ですので、依存関係がない場合には、入れ替えたりずらしたりすることで、日
程を短縮できたりします。必ずウォーターフォールという形態でなければなら
ないというような制約はPERTにもクリティカル・チェーンにも存在しません。

思うに、ソフトウェア開発が構造化プログラミングであった場合には、モジュー
ル間の依存関係が非常に密であり、切り離すことが難しい。このため、作業の
大部分が並列化できないがために、ウォーターフォールのような形態にならざ
るを得なかったという面もあるのでは。

オブジェクト指向プログラミングやXPになったからといって、依存関係が完全
に無くなったわけではないので、実際にはパスは残っていると思います。ある
いはXPでは、切り分けたパスの一部を最適化しようとしている、と考えるわけ
です。

> ソフトウェア開発の場合、ベータ分布と断言できるほど見積りの精度に関する
> 充分なデータが集まっているのでしょうか?
> そういう点で、ソフトウェア開発の見積り精度は、さらに数ランク低いと
> 思っています。

何か誤解があるようですが、私が言いたかったのは、クリティカル・チェーン
での時間見積りの精度は「非常に低い」、つまりソフトウェア開発の見積もり
精度と大して変わらないということです。ベータ分布というのは、「いつまで
経っても出来上がらないこともある」ような分布です。「やったことのないよ
うな作業」を見積もるときに使われるようです。この分布がどのようなプロジェ
クトにも使用できるわけではなく、「すでに実績のあるような場合には」経験
的な見積もりを使用するのが良いとされているようです。

#読み違えているかも知れませんが、以下より。
#「計画の科学」VII章 ISBN 4-06-117635

TOCのクリティカル・パスでは安全を見越した時間見積り(ベータ分布のおし
り)をひっぺがしてプロジェクトの最後にくっつけるんですが、これがXPの理
想日という考え方と、イテレーションの最後に調整をかけるやり方と似ている
な、と思っています。

並列作業を行っている場合のフィーダー・パスと合流バッファは、ストーリー
がそろわないと完成しない場合にはやはり必要でしょうし、リソースの競合が
ある場合のクリティカル・パスとその合流バッファの考え方は、開発者のかけ
もちや特定の資源が必要なときにはやはり考えないといけないことなんだろう
と思います。

とりとめがなくなってすみません。
---
みかまま
http//www.mikamama.com/
mika@....com