[#TiDD] アジャイル風開発ラフシミュレーション

以前まとめたアジャイル風開発のリスク対応力についてラフシミュレーション、いわゆるドンブリ勘定をしてみました。突っ込みどころは多々あると思いますが、ざっくりと考えるきっかけになると思い、公開します。

前提

状況：いつでも実装を始められる。
仕様書作成：完成には１ヶ月かかる。期間は考慮するが工数は考慮外とする。
製造工数：12人月（アジャイル：3人×4ヶ月、その他： 4人×3ヶ月）
問題の発生パターン１：2・2・2人月、あるいは2・１・2・１人月の問題が開発後期に発生
問題の発生パターン２：2・1・ 0 ・ 0 人月の問題が開発後期に発生
残業：問題発生の翌月から25％の残業ができる
仕様削減：アジャイル開発、五月雨ウォーターフォールは2人月の仕様を削減可能

ウォーターフォール

ウォーターフォールでは仕様が固定されていますので、パターン１しかありません。

あふれた作業は残業でも吸収できません。４人月分残ります。リリースを１ヶ月のばすか、混乱を招いても人を足して少しでも早めるかですね。できれば残業と類似プロジェクトの経験者で何とかしたいところですね。

五月雨ウォーターフォール

図中ではまとめて書いていますが、文書化と開発を段階的に進めます。見積もりや発注が煩雑になりますが、文書による仕様の確認後に請負契約を段階的にします。

パターン１では、優先度の低い仕様を削減しても２人月あふれます。ウォーターフォールよりは少ないですが、残業での吸収は厳しいですね。

パターン２では25％の残業で何とか吸収できます。リスクベースの計画で問題による工数が削減された事、優先度の低い仕様を削減できた事の効果が大きい様です。

スクラムウォーターフォール

全体のプロセスをウォーターフォールで構成し、実装と単体テストをスクラムで開発する方法です。仕様はあらかじめ固定されていますが、段階的に開発する事で環境やUIなど実装中のリスクをある程度低減できます。

パターン１では４人月あふれますのでウォータフォールと変わりません。繰り返し開発によるプロセス改善で、少しは削減できると思われますが、ふりかえりの時間を削りたくなってしまうかもしれません。

パターン２ではリスクベースの効果があるものの、徹底したプロセス改善であふれた２人月を削減するのは厳しいでしょう。

アジャイル開発

最初の開発に必要なユースケース等が明らかになっていると言う前提ですので、文書化の期間も実装でき、少ない人数で開発できます。アジャイルでの残業と言う行為に目をつむると、残業の可能な期間も長くなります。

パターン１では最も少ない1.75人月の工数があふれます。ふりかえりの改善効果のほか、アジャイル開発では実装以降の作業も実装と同時に行うので、その工数を実装中に割り振ると考えると何とかなるかもしれません。

パターン２では25％の残業をするとなんと工数が余ります。残業を減らす事もできますし、削減可能な仕様を復活できるかもしれません。

まとめ

アジャイル風の開発と言ってもその効果は様々です。アジャイル開発で実装を優先する効果は大きく、リスクをうまく低減できる可能性があります。

一方、ウォータースクラムフォールは、チームのコミュニケーションやプロセス改善の効果は期待できると思われますが、リスクに対してはあまり効果がありません。今回は考慮しませんでしたが、ウォーターフォール開発でプロトタイピングや共通化によってリスクの低減を図る方が、場合によっては効果があるかもしれません。

今回の結果で意外と良かったのは五月雨ウォーターフォールです。安定した発注が可能かどうかと言う問題はありますが、うまくいくとウォータースクラムフォールよりも効果がありそうです。

最後にアジャイル開発のパターン２の問題の発見が遅れたパターンを考えてみました。リスクの考慮をしないで優先度のみで実装を進めると、リスクが顕在化が遅れてしまう可能性があります。この場合だと0.5人月ですが、あふれてしまいました。リスクの考慮は大切ということですね。

論文ネタを探している方へ

ご自由にこのネタを使ってください。ご協力も可能ですので、必要でしたらご連絡ください。