dX: 最小のRUPプロセス

(preliminary chapter of Object Oriented Design with Applications, 2nd ed., G. Booch, R. C. Martin K. Newkirk, 1998, Addison Wesley Longman)

dX Inception (dX開始フェーズ)

主要なユースケースを索引カードに書く。記述はシンプルに。これは顧客の代表者が書き、開発者がフィードバックを与える。顧客の代表者は常にチームの一員でなければならない。
これらのユースケースの簡単なプロトタイプを作る。これらは捨てられる可能性がある。
プロトタイプを使って、a) チームの開発速度を測定する。b) ユースケースが適切な大きさと詳しさを持っているかどうかを確認する。我々はこの情報を使ってプロジェクトのスケジュールを開始し、ユースケースのプロセスを洗練させていく。
同様に、プロトタイプを使って幾つかの可能なシステム・アーキテクチャを探っていく。

Lifecycle Objectives Milestone(LOM)は主要なユースケース、プロジェクトのスケジュール、初期のシステム・アーキテクチャについてよく分かったかどうかを目安とする。

dX Elaboration (dX推敲フェーズ)

前のフェーズで作ったコードの殆どは捨てる。チームの合意があった場合のみ残しておく。設計とプログラミングに手をつけはじめるフェーズである。

引き続き、チームの一員となった顧客がユースケース・カードを書いていく。
開発者はユースケース・カードごとに仕事量を見積もり、カードに記入していく。
顧客はユースケース・カードごとに優先順位をつけ、カードに記入していく。リスクの高いユースケースはこのフェーズで優先度を上げておく。
イテレーションの期間を決めて(通常は1週間以下くらい)、イテレーションを計画する。顧客がこのイテレーションで開発するユースケース・カード(複数でも可)を選ぶ。カードの見積もりの合計が、このイテレーションの期間を超えてはいけない。
一つのイテレーションが終わった時点で、見積もった数値と実装したユースケースの数値が異なる場合がある。この比率(実際値/予想値)を負荷係数と呼ぶ。この係数を次のイテレーションの見積もりに適用する。
開始フェーズで識別したシステム・アーキテクチャに合うように、各イテレーションを分析・設計する。分析と設計は開発者が「設計セッション」で行なう。開発者はUMLのダイアグラムでもCRCカードでもその他のどんな方法でも構わないので、チームに合うような方法を使って分析モデルと設計モデルを構築する。
設計モデルはコードに引き継がれる。dXでのルールは、作ったコードは一行残らず二組の眼で調べ尽くすこと。開発者はたいていの場合、二人が組みになり、二人で一台のワークステーションに向うことによってこれを遂行する。いったんコードにまで落ちたら、分析モデルと設計モデルはdXの手を離れる。捨てるなり、後々のためにとっておくなりする。
テストはdXでもっとも価値の高いものである。つまり、テスト対象のコードを書く前に単体テストのためのコードを書く。ユースケースはテスト可能な単体まで分解する。開発者は交互に、テスト・ケースを書き、コードを書く。テストとコードは同時に一緒に成長していく。
単純さもdXで価値が高い。設計とコードは可能な限り単純なところから始める。ユースケースから指定された場合以外は複雑なことは付け加えない。
dXでは、コードの品質とそれがシステム・アーキテクチャとうまくマッチすることが最高の報酬となる。開発者は無慈悲にも、この基準に合わないコードをどんどん変えていく。dXでは、コードは幾らでも鍛えがいのあるものであるとみなされているので、開発者もコードを変えることに何の躊躇もない。変更のお陰でなんらかの問題が紛れ込んだとしても、テストで見つけることができる。
コードはすべてのチームメンバの共同所有物である。誰が書いたコードであれ、誰でも変更してよい。
統合は少なくとも一日に1回行なう。

dX Construction (dX構築フェーズ)

Lifecycle Architecture Milestone(LAM)は、dXではほとんど問題としない。ほとんどのdXプロジェクトでは、アーキテクチャとプロジェクト計画は一緒に進化し、その品質も一緒に改善されていくからである。したがって、dXでは構築フェーズと推敲フェーズはほとんど区別がつけられない。両者の差は単にアーキテクチャとプロジェクト計画それぞれの安定度だけである。プロジェクトが構築フェーズに移っていくと、チームはリリースのスケジュールを立て始める。スケジュールは負荷係数を使い、リリースごとに必要になるユースケース・カードを足し合わせて作る。

dX Transition (dX移行フェーズ)

殆どのdXプロジェクトでは、移行フェーズは一番最初のリリース後から始まる。通常これはプロジェクトのかなり初期に起きる。この時点からシステムは生き始めるのである。同時に機能は非常に不足していることが多い。従って、可能な限り古いシステムも動作するようにしておく。

チームは引き続き、イテレーションとリリースの計画を続ける。イテレーションは新しいリリースが誕生するまで積み重なる。リリース・サイクルが短いほど、チームは動いているシステムからフィードバックを早期に得ることになる。

dX Extras (dX追加分)

dXにはその他にも幾つかの要因と規則がある。このプロセスはチームメンバのコミュニケーション能力に非常に大きく依存することになる。従って、オープンな作業場所が必要である。これによって、チームメンバやチームに加わった顧客が互いに近しくコンタクトを取ることができる。

dXでは残業(? overtime)はプロセスの失敗とみなされる。さらに2週間以上続いての残業は許されない。その代わりにプロジェクト計画を変更する。

dXはUMLに限らず、なんらかの記法を明示的には利用していない。dXが利用する媒体的な作成物はユースケース・カードだけである。このことは、dXを使うエンジニアはモデルを作ったり、なんらかの仮定をテストしてみるのにUMLを使ってはいけないということではない。単にdXではエンジニアにいつこのようなモデルを作ればいいのかを示していないということに過ぎない。

UMLなしで分析や設計を行なうというところから、dXでは分析も設計も行なわれないという結論を引き出す人もいる。しかしそれは間違っている。dXでは分析と設計は繰り返される設計セッションで行なわれている。こういったセッションから得られた決定は、通常索引カードに書き留めるが、これらのカードはいったんコードに引き継がれた後は捨ててしまうのである。

もちろん、一部のプロジェクトにとってはこういった事柄はあまりにも形式から外れているように見えるだろう。しかし、これらは実際に十分効果があることが証明されている。プロセスが複雑でなければ効果もない、などということはないのだ。実際、我々はプロセスをできる限り単純なものにしようと思っている。