XDDPとAgile、TiDDは相性がいい

「派生開発カンファレンス2010」の講演資料が公開されたのでメモ。
ラフなメモ書き。

【元ネタ】
「派生開発カンファレンス2010」開催案内

XDDPとUSDMでプロジェクトの課題解決

ソフトウェアの改造で悩んでいませんか？　～派生開発の品質と効率の向上を目指して～

派生開発は、既に運用されているソフトウェア製品に対し、保守したり、機能追加したり、それを移植して別製品を作ったりするアプローチ。
日本の携帯電話が、カメラ、着うた、オサイフケータイ、Edyなど次々に機能追加していく様は、まさに保守ではなく派生開発だ。
派生開発は組込製品やパッケージ製品でよく発生し、その難しさは以前から知られていた。

特に大規模プロジェクトほど、再利用可能な部品を作る設計にしておかないと、似たような部品を作っているのに、別チームで開発してしまって、工数やコストをかけすぎてしまいがち。
更に、似たような機能やソースがあちこちに散らばってしまうので、保守するのが難しくなり、品質はどんどん劣化する。

講演資料で目を引いたのは二つ。
一つは、XDDPとUSDMでプロジェクトの課題解決。

PSPをまなぶとPFD、つまりXDDPのプロセスの理解が深まる。
XDDPは規律がある。だからPSPとも相性が良い。

XDDPを経験した開発者は、Agileを正しく理解する。
XDDPの本質は並行開発だ。だから自然にアジャイルになる。
何故なら、今稼働している製品(メインライン)を触らず、派生した製品用のライン(ブランチ)で設計書やソースを修正してテストするからだ。
元々の製品(メインライン)を不用意にいじってコミットせず、その差分を重視する開発スタイル。
まさに、パッチベースの作業を重視しているのだ。

一口サイズ見積りとチケット駆動開発。
全体計画を2週間単位の計画に分解する。
XDDPを経験した開発者は、小さな機能単位で見積もるから、見積もりの精度が上がるので、チケット駆動開発やアジャイル開発にすぐに馴染む。
アジャイルの利点であるイテレーション単位の開発スタイルを導入すれば、朝会がプロセス設計の場になる。

もう一つは、ソフトウェアの改造で悩んでいませんか？　～派生開発の品質と効率の向上を目指して～。

XDDPは最終的にはSPL(ソフトウェアプロダクトライン)へ落ち着く。
XDDPは製品ファミリー開発につながる。
何故なら、成功した製品を元に移植して、特定のマーケットや顧客向けに派生した製品をどんどん作って売り出す開発が可能になるからだ。

すると、再利用可能な部品というコア資産が重要になってくる。
いかに以前作った部品を使い回し出来るか？
以前作った部品はあちこちの製品で運用されていれば、品質は担保されている。

コア資産を流用するには、ロジックは変えずに、I/Fを調整する方が多くなる。
Adapter、Facade、移譲のようなパターンを流用する時が多いだろう。

SPLで重要な品質は移植性や保守性。
移植しやすいプログラムでなければ、派生製品の開発速度が落ちるし、移植作業でバグを入れ込んでしまう。
保守性が高くなければ、独自ロジックを組み込んでしまって、再利用できなくなり、バグが発生したら修正範囲が広がって工数が多くなる。

XDDP、Agile、TiDD、SPLの関係性が面白い。