アジャイルメトリクス、どうなの？（ソフトウェア分析）
アジャイルソフトウェア開発とその宣言
アジャイルソフトウェア開発の精神はアジャイルソフトウェア開発宣言にあります。「プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を」という宣言です。
この宣言の中ではメトリクスやそれによる定量分析については直接的な言及はありませんが、推理するとどうも左側に入りそうです。「メトリクスよりもテスト結果を、定量分析よりも価値結果を」という宣言が入りそうです。
確かにアジャイル開発は動的な開発方法論です。このダイナミックさが臨機応変に対応でき、変化への対応が俊敏にできる源泉です。アジャイルの命です。
アジャイルメトリクスは必要
アジャイルソフトウェア開発とメトリクスの関係はどうなのでしょうか。確かにアジャイル開発は動的な開発方法論です。そしてメトリクスはどうしても静的な評価になります。一方、ウォーターフォール型開発は静的な方法論なのでメトリクスと相性が良かったのですが、アジャイルはそうはいきません。
しかし相性が悪いと言っても、アジャイル原理主義者でない限り、アジャイルでもメトリクスによる分析は必要です。必要です。大事なことだから2回言いました。
アジャイル開発では信頼性が悪いという都市伝説があります。その冤罪であるという証明、犯罪を犯していないという根拠のためにも、アジャイルメトリクスは必要です。もしかしたら犯罪が立証されてしまうかもしれませんが。
アジャイルメトリクスの勇気
アジャイルメトリクスは必要です（3回目）。特に大規模プロジェクトでは必要です。（ぼそっ）逆に言えば小規模の場合は不要かもしれません。大規模プロジェクトでメトリクスなしに開発を進めるのは勇気が必要です。灯りなしの夜道を歩くくらいの勇気が必要です。そして怪我をしても自力でなんとかする勇気も必要です。
しかしアジャイルメトリクスは難しいものです。ウォーターフォールと同じメトリクスのみをそのまま使うのは駄目でしょう。ここで大事なのは従来のウォーターフォールのメトリクスそのものが駄目ということではなく、それだけでは駄目ということです。つまり従来のメトリクスも使えるものは使うのです。全部、捨てる必要はありません。もったいないです。
アジャイルメトリクスの決め方
それではアジャイルならではのメトリクスにはどんなものがあるでしょうか。アジャイル開発は動的な開発です。これに対応するメトリクスは難しいですが、アジャイル開発の中でも静的なものはあります。例えば、1回ごとの繰り返し開発の中はウォーターフォールのように静的に運営している場合が多々あります。
1回ごとの繰り返し、スクラムではスプリントに相当しますが、この中では従来のウォーターフォールで使っていたメトリクスが使えます。例えば、スプリントでのバグ密度です。しかしここで注意する必要があるのは、スプリントで注目している箇所（ストーリー）のバグと、そうでない箇所でのバグは明確に区別することです。
アジャイルメトリクスの方針は上記になりますが、アジャイル開発という名称は総称的な名前なので、スクラムやXPなどのように固有のアジャイル開発の派閥単位にアジャイルメトリクスを決める必要があります。
例えば、XPは固有の方法論が定義されているものではないので、該当のプロジェクトでメトリクスを決める必要があります。スクラムでも多くは「なんちゃって」スクラムぽいのをしている場合がありますので、このときもプロジェクトで決める必要があります。それでキメる必要があります。
なお、「なんちゃって」アジャイルが悪いとは（ここでは）言っていません。これは別問題ですので、別の機会で書くことにします。
ということで今日の結論。「アジャイルメトリクスは個々でキメる」 以上です。
以下のグループで今回のメトリクスに関する情報を紹介しています。
ソフトウェア研究会「とある技術のソフトウェアエンジニアリング」 | Facebook
マンガFAQの引用元：ソフトウェア開発分析データ集2022 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
いいなと思ったら応援しよう！
