[#TiDD]ウォータースクラムフォールよりも五月雨WFの方が変化に強い！(かも)

ウォータースクラムフォールは「アジャイル風」

第15回アジャイルラジオによると、ウォータースクラムフォールと言うものがあり、ソフトウェア開発のプロセス全体はウォーターフォール（以下WF）で、製造工程だけスクラムで実施するプロセスがあるそうです。

この方法は上流で仕様を固定する、あるいは、一定の予備工数を取っておいて、仕様変更に対応するようです。製造工程は繰り返し開発なので、フレームワークやOSに想定していなかった問題が生じれば対応できると思われます。

しかし、それは製造時（コーディング＆単体テスト）のリスクであり、スコープは変更されないと思われます。予備工数がある場合は、その範囲で仕様変更に対応できますが、それは追加するだけで（交渉の余地があるものの）当初の仕様は全て実装されるのでしょう。

これを「アジャイル風」と言うらしいです。確かに私がUAS2で私が書いた「アジャイル風」と同じ様にアジャイルプラクティスの一部を実施したものですが、アジャイル開発の価値観を求めるものかどうか大いに疑問があります。

アジャイル風の開発で集中を実現する from Makoto SAKAI

アジャイル風ウォーターフォール開発の比較

そこでアジャイル風と思われるWFを比較してみました。ここでいうWFとは（工程を進めるかを判定する会議があるなど）厳密な意味ではなく、仕様をドキュメントで定義して開発開始後の仕様変更は管理されるという意味で使っています。

典型的なウォーターフォール
仕様決定は１回、リリースも１回です。プロジェクトの終盤になって、開発や実行の環境や仕様、ユーサーインタフェース(UI)の問題が発覚します。優れたユーザ体験(UX)の実現は実現が困難だと思います。プロトタイピングのほか、リスクが問題化した際の手戻り作業を予め見込んでおく必要があります。

複数リリース
仕様は予め決められているものの複数回のリリースによって、ある程度リスクを低減できます。基本的な動作や多システムとの連携、ベースとなるUIを早期に確認することで、ある程度リスクを低減する事が可能です。この場合も典型的な場合に比べて工数が減りますが、手戻り作業を見込んでおかなければいけません。チケット駆動ならアダプタブルWFを実現可能。

五月雨（さみだれ）発注
複数リリースと同じくなるべく早く動作を確認したい部分を早期に発注し、仕様が固まらない部分や決定を遅らせたい部分を後から発注します。手戻りは次回の発注分に含める事も可能ですので、多くのリスクに対応する事ができます。リリース時期に合わせて、後期に発注する仕様のスコープを変更できますが、タイムボックス管理はされません。チケット駆動ならアダプタブルWFを実現可能。

ウォータースクラムフォール
厳密な定義は不明です。いわゆるV字あるいはW字モデルの製造部分をスクラムで開発します。リリースが複数であれば複数リリースとほぼ同じリスクへの対応が可能です。製造工程ではスクラムなので、継続的な改善や良好なコミュニケーションが基本的に導入されると考えられます。

アジャイル開発
アジャイル開発ではタイムボックスに合わせてスコープ（仕様の範囲）を変更しますので、様々なリスクに対応可能です。リスクを考慮してプロジェクトのロードマップを決めれば、より効果的でしょう。UXの向上は文書化が困難なので早期に実装を始めるアジャイル開発に向いていますし、開発と運用が連続しているので、予算の範囲内で発生した問題に対応できます。

コミュニケーションの考慮

アジャイル開発では、XP祭り2009の土屋さんの講演にある「同じ人の所に仕事が来るというモデル」が基本なので、コミュニケーションの問題が生じにくいという特徴があります。

しかしアジャイル開発でも 、配員が増減するとコミュニケーションを取る事が難しくなるようです（commの事例）。どのような開発をする場合でも、作業をなるべく前倒しにするなど配員を平準化して、早めにチームを立ち上げる工夫が必要です。

配員の増減によるコミュニケーションロスは生産性に大きく影響しますので、発注側が作業量を調整するなどの考慮をすることで、より良い関係が築けると思います。

どこがどのようにおいしいのか？

アジャイル風開発はナポリタンとかトルコライスのような、名前だけそれらしくしたものでしょうか？それとも同じ方向を目指したバリエーションの一つなのでしょうか？かつて日本のカレーライスをインドの大統領が食べた際に「おいしいですね。なんと言う料理ですか？」と言われたそうです。本人が本物のつもりでも、全くの本物以外はすべて偽物なのかもしれません。

とはいえ「おいしいから良いでしょう」という意見もあるでしょう。でもそれが、どのようにおいしいのか？本物とどう違うのか？ということをきちんと理解しておけば、本物を選ぶ事もできますし、本物でない事を理解した上でよりおいしくいただけると思います。

これらの開発法が問題発生時にどのように対応できるかをラフシミュレーションしてみた記事を書きました。ぜひ、ご覧ください。