一部のソフトウェアエンジニアリング手法とソフトウェアエンジニアリングサクセスストーリーの間に相関関係はありますか？

私はLeonard Mlodinow の本「The Drunkard's Walk：How Randomness Rules Our Lives」を読んでいて、本当に啓蒙的な本です。本は確率と人間の推論を扱います。そして、記録のために、いくつかのことは時々うまくいきますが、あなたがそれをうまく動かしたと思ったものが、実際にそれを動かしたものとは無関係である可能性があるとだけ言いましょう。

確率は直感的ではありません。

しかし、それは私にアイデアを与えました。ソフトウェアエンジニアリングの取り組みの結果を数値化しようと試みた、これに関する研究はすでにあるはずです（もちろん、それ自体が難しい問題です）。そしてこれらの研究は、定量化可能な成功という点で、どのようなソフトウェアエンジニアリング手法が本当に重要であるかを指摘する必要があります。

すなわち

• TDDを採用するチームthisは、thisある種の問題を抱えている可能性がはるかに低くなります。
• SOLID原則を採用しているチームthisは、thisある種の問題を抱えている可能性がはるかに低くなります。
• などなど

ここで私が探しているのは、実装と成功の間の強い相関を示すソフトウェアエンジニアリングの実践です。私はこれらのものが存在すると確信していますが、それらを手に入れるのは難しいので、私はこの質問をします。

実装と成功との間に強い相関関係があることを知っている研究や実践はありますか（成功は多少恣意的ですが、あなたはその考えを理解していると思います）？

ソフトウェアエンジニアリングがカウボーイコーディングよりも優れているという考えを売り込むなら、証拠が必要だと思います。

この種の定量化の問題は、意味のある結論を出すためにソフトウェアエンジニアリング手法の有効性に関する十分なデータを取得することがほとんど不可能であることです。

最も重要なのは、相関関係が因果関係を意味するものではないことです。たとえば、優れたプログラマはすぐに新しいアイデアに飛びついて実装できるため、プロジェクトの成功と新しいソフトウェアエンジニアリング技術の採用との間に一般的な相関関係が見られます。しかし、全体の効果はそれらを採用するプログラマーのより高い才能レベルによって説明されるかもしれないので、それはテクニック自体の有効性について何も証明しません。

そして、独立変数を制御することは困難です。以下のすべてを制御できなければ、どのようにして公正な調査を保証しますか？

• チームの経験/スキル/やる気レベル
• 主張された方法論の採用の実際の範囲（彼らは本当にTDDを適切に行っていますか？）
• ソフトウェアエンジニアリング方法論とは無関係の主要な設計ミスの存在/不在（例：プロジェクト中に主要な再構築が必要なミス）
• 比較されるプロジェクトの難易度
• 外部から課せられた問題の影響（たとえば、主要な要件の変更）
• 選択バイアス（たとえば、人々は成功したプロジェクトについてより頻繁にデータを共有する傾向があったか？）
• 確認バイアス（たとえば、人々は自分の好きな方法論を使用するプロジェクトの成功を誇張しましたか？）

注意深く制御された同じ条件下で複数の慎重に選択されたチームに同じ問題を与えることによって上記に取り組むことを決定したとしても、統計的に有意な十分なデータを作成したい場合、実験は法外に高くつく可能性があります。

そして最後に、成功を測定することはほとんど不可能です：

• コードのソース行（SLOC）のような数量メトリックは、ひどく悪いです。開発者へのインセンティブは、より「生産的」に見えるようにするために、コピー/貼り付けコーディングで百万行の怪物を作成することです。
• 予定どおり/予算内の指標は、主に計画/予算の作成に使用される見積もりの​​野心のレベルに依存します
• ROIタイプのメトリックは、エンジニアリング出力の品質に依存するのと同じくらい、市場の状況と製品の商業管理に依存します（Microsoft Windowsの履歴を見てください！）
• ストーリーポイントは、アジャイルチームの速度感を得るのに役立ちますが、実際にはチーム間で比較することはできません。
• 機能ポイントやユースケースポイントなどの機能ベースのメトリックは、おそらく最高の束ですが、収集するのは官僚的であり、機能の各ユニットを作成するために必要なエンジニアリング作業の違いを反映していません。
• 本番環境/アプリの可用性のバグなどの品質指標は、同等の基準で計算して比較することは非常に難しいことで有名です。選択したプラットフォーム、ユーザーベースのサイズ、さまざまな運用/展開要素などに大きく依存します。

結論として、ソフトウェア開発タスクの影響を定量化することは非常に困難なタスクであり、トピックを何年も続けてきたにもかかわらず、誰もまだ真に効果的なアプローチを考え出していません。その結果、ソフトウェア開発の方法論の評価は、科学というよりは芸術にとどまり、おそらく今後何年も続くでしょう。

興味深いことに、私が約束しているアプローチの1つは、リーン原則の適用です。これは万能薬ではなく、ソフトウェア開発方法論を評価する問題を直接解決しませんが、重要な洞察が1つあります。廃棄物の特定の要素を含むプロセスは、廃棄物の要素を含まない同じプロセスよりも明らかに効率が低く、他のすべてが等しいこと。したがって、ソフトウェア開発プロセスの無駄をなくすことに集中すれば、少なくとも正しい方向に進んでいることを確信できます。さらに、廃棄物は定量化できることが多いため、少なくともおおよそのパーセンテージで、どれだけ効率が向上しているかについても理解する必要があります。