豊富な変異

私の著作の読者であれば、私が進化的な設計の強力な支持者であることをご存知でしょう。このアプローチに対する私の熱意にもかかわらず、完璧なテクニックは存在せず、私は成功例と同様に問題点についても報告したいと思っています。

これまで、わずかに異なる形で、この問題に2つのプロジェクトで遭遇しました。

進化的な設計では、プロジェクトの進行に応じて、チームが設計を変更することを期待します。それは、要件の変更に対処するため、そして学習を活用するためです。これを、これらの変更に反応する設計への変異の追加と考えることができます。この変異は良いことであり必要なことですが、多くの良いことと同様に、やりすぎる可能性があります。

最初のプロジェクトは、約100人の開発者がいる大規模なプロジェクトでした。この場合、過剰な変異は、異なるサブチームが共通の問題に異なる方法で取り組むために発生しました。これは、異なるフレームワークを構築したり、異なる外部フレームワークを組み込んだりすることによって行われました。

2番目のプロジェクトは、12人の開発者からなる中規模のプロジェクトでしたが、ローテーションが頻繁にありました。新しく参加したメンバーは、以前の問題への取り組み方を見て、それを理解できなかったり、欠陥を見つけたりすると、新しい方向に向かいました。問題は、新しい人々がやってくる前に物事が完了せず、この中途半端な解決策に欠陥があると感じたことです...お分かりいただけたでしょうか。

どちらの場合も、最終的な結果は、同じ問題を解決しようとする複数の方法でした。努力の重複が無駄であっただけでなく、ソフトウェアが不必要に複雑になりました。

同じ組織の他のシステムと比較して、全体の設計の健全性は非常に良好であったことを強調しておきます。特に、自動テストへの注意は、進化が通常よりもはるかに安全になることを可能にし、両方のプロジェクトは非常に低い欠陥率でした。

メタファーによる質問を乱用する危険を冒して言えば、これは環境が弱い変異を排除できなかった場合と考えることができます。理想的には、競合する設計が現れたとき、それはすぐに消滅するか、既存の設計を打ち負かします。ここで問題なのは、どちらも発生しなかったことです。そこで、劣った設計をシステムから強制的に排除するにはどうすればよいのかという疑問が生じます。

どちらの場合も、私が話を聞いた人々は、全体的な設計リーダーシップが不足していると感じていました。大規模なプロジェクトでは、アーキテクチャチームを通じて、これらの問題に対する基本アプローチを確立し、実行中のことについて密接に連絡を取り合うことで、これが追加されました。2番目のチームはまだこの問題に取り組んでいませんが、より安定した設計リーダーシップが必要であると認識されています。したがって、進化的なメタファーではなく、優れた特性を奨励し、劣った特性を阻止するブリーダーのようなものだと考えることができます。（これはダーウィンのインスピレーションの源でした。）

メタファーはさておき、私は基本的に、原則「技術的な卓越性と優れた設計への継続的な注意は、アジリティを高める」に従うことに帰着すると考えています。進化的な設計には、注意、スキル、リーダーシップが必要です。それは、多くの人が一般的に考えるリーダーシップの種類とは異なるだけです。