アジャイルでリスク対応（ソフトウェア分析）
アジャイルで定量分析は必要？
アジャイルソフトウェア開発で、定量データによる分析は必要なのでしょうか。可能でしょうか。どのようなメトリクスで分析すればいいのでしょうか。
これについては以下の記事で紹介していますので、読んでみてください。
上記の記事にあるように、アジャイルメトリクスは必要です。しかし生産性や信頼性の一部の分析は可能ですが、ウォーターフォールのように多くに適用できません。このようにアジャイルメトリクスは難しいものです。
定量分析の目的は？
このように生産性や信頼性などの一部は定量分析できますが、アジャイル開発の定量分析は難しいものです。それではアジャイルメトリクスによる定量分析は何を目的にすればいいのでしょうか。
ずばり答えを言うと、リスク対応です。
このリスク対応はアジャイル開発だけに限ったことではなく、さらに言えば、ソフトウェア開発に限ったことではなく、あらゆる定量分析の目的となるものです。
特にアジャイル開発では、定量分析の目的として、生産性や信頼性の分析が難しいこともあり、このリスク対応がぴったりと来ます。
アジャイルメトリクスでリスク検知
それではどのようなメトリクスで計測すれば、このリスク対応ができるのでしょうか。
リスク対応の最初であるリスク検知は、いつもと違う傾向を見つけることから始まります。このためには、なんらかのリスクがあると、いつものと違う傾向を示しやすいデータの種類を見つけることです。
アジャイル開発はユーザとベンダが共創して作ります。はっきり言って、両者のコラボこそがアジャイルの命です。そこでリスクに反応しやすいのも、このコラボに関するデータです。
両者の打ち合わせ回数とその時間、相互にやりとりする作業項目（ユーザストーリー）の件数などが考えられます。逆に言えば、バグ密度やソースコード行数はベンダに特化したもので、参考程度になるかもしれませんが、期待しないでください。
このようにユーザとベンダのコラボ関係のデータで、いつもと違う傾向性を見つけたら、それがリスクの発見になるかもしれません。ここ重要！
アジャイルでリスク対応
アジャイルメトリクスでリスクを検知したら、その対応をします。対応にはウォーターフォール開発での伝統的技法「新たに人を入れて、人月の力で解決する」があります。これはアジャイルでは失敗するでしょう。
ウォーターフォールでも成功してはいないですが。
ということで今日の結論。「いつもと違う、リスク検知」 以上です。
以下のグループで今回のメトリクスに関する情報を紹介しています。
ソフトウェア研究会「とある技術のソフトウェアエンジニアリング」 | Facebook
マンガFAQの引用元：ソフトウェア開発分析データ集2022 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
いいなと思ったら応援しよう！
