アジャイルはウォーターフォールと仲良くできるのか（ソフトウェア分析）
アジャイル開発とウォーターフォール開発の狭間
アジャイル開発ではベンダとユーザが価値を見出すため、漸次的に仕様を固めて、繰り返して開発し、価値を大きくしていきます。一方、ウォーターフォール開発は価値を最大化するために、そのための要求をベンダがユーザとともに詰めていき、見出した要求に基づいてベンダが開発を行い、ユーザが価値を確認することになります。
これらの開発プロセスの特徴に合わせて、適材適所で両者を使い分け、両者のそれぞれの利点を活かして、ハイブリッドで開発していきます。
というのが教科書やセミナー講師が言うことです。
実際はアジャイルは価値を外に置きっぱにして、本当の要求を見い出せずに、仕様をあいまいにしたまま、うだうだと繰り返して開発をします。一方、ウォーターフォールでは適当に要求を出し、適当に仕様を決め、そのまま一気に開発し、最終のテスト段階でこっそりとやり直しをする開発です。
これらの開発プロセスの特徴に合わせて、お互いの欠点を無理やり、別の開発プロセスで穴埋めしようともがいて、ハイブリッドで開発していきます。
アジャイルとウォーターフォールは仲良く
どちらにせよ、アジャイルとウォーターフォールは仲良くハイブリッド開発するのが吉です。これはセミナーをハイブリッドでするのと同じで・・・はないかも。なんにせよ、アジャイルとウォーターフォールは仲良くハイブリッド開発します。
ハイブリッド開発で問題になるのが、プロジェクト管理とその一部で使用するソフトウェア開発のメトリクスです。ここではメトリクスに話を絞ります。ハイブリッド開発のプロジェクト管理は後日に回します。後回しにするのは難しいからということではないです、たぶん。
両者のメトリクスの共通化は難しい
アジャイルとウォーターフォールとのハイブリッド開発のメトリクスは、どのようにすればいいでしょうか。アジャイルメトリクスとウォーターフォールメトリクスの足し算、OR結合、和集合でいいのでしょうか。
足し算では大変です。アジャイルとウォーターフォールは水と油の関係です。決して交じり合うことはありません。それでもハイブリッド開発は勝手に自由気ままに進んでいきます。メトリクスも両者で独立に勝手に自由気ままに作り、それぞれでデータを収集します。多くなり面倒です。
そこで両者のメトリクスの共通化が必要になります。共通化すればするほど、足し算は楽になります。つまりメトリクスによるデータの計測数が少なくなります。まさに共通化は神です。
しかし運用後のバグ件数くらいは共通化できますが、それ以外の共通化は難しいのが現状です。例えば、プログラム規模をSLOC(ソースコード行数）やFP(ファンクションポイント）で計測しようと思ったときでも、ウォーターフォールは単純な計測でたぶん問題ありませんが、アジャイルでは繰り返し開発の中での作り直し部分をどのように扱うかが問題になります。このためウォーターフォールと共通化できません。アジャイルがかわいそうです。
アジャイルとウォーターフォールのメトリクスは
それでもアジャイルとウォーターフォールのメトリクスは工夫して、やや無理やりでもいいので、共通化する必要があります。
メトリクスの共通化をする一番簡単な方法は、係数で調整することになります。例えば、SLOCが a 行のとき、アジャイルではソースコードをウォーターフォールの b 倍変更し、価値を c 倍にすると仮定したとき、価値をベースにした規模はウォーターフォールが a となる（SLOCと価値が単純に比例すると仮定）のに対し、 アジャイルは a ÷ b × c となります。
b と c を固定の係数とすれば、SLOC の a を計測するだけで、アジャイルとウォーターフォールのハイブリッド開発でも、簡単にデータを収集でき、生産性を評価することもできます。
ということで今日の結論。「アジャイルとウォーターフォールのメトリクスは共通に」以上です。
以下のグループで今回のメトリクスに関する情報を紹介しています。
ソフトウェア研究会「とある技術のソフトウェアエンジニアリング」 | Facebook
マンガFAQの引用元：ソフトウェア開発分析データ集2022 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
いいなと思ったら応援しよう！
