豐富的突變

任何讀過我文章的讀者都知道，我是演化設計的忠實支持者。儘管我對這種方法充滿熱情，但沒有任何技術是完美的，我樂於報告它的問題，就像我樂於報告它的成功一樣。

到目前為止，我在兩個專案中遇到過這個問題，儘管表現形式有些不同。

演化設計希望團隊在專案進行時修改設計；既要應對需求變更，又要利用學習成果。你可以將此視為對設計新增突變，以應對這些變更。這種突變是一件好事，也是必要的，但就像許多好事一樣，你可能會過度使用它。

第一個專案是一個大型專案，大約有一百名開發人員。在這種情況下，過度突變發生是因為不同的子團隊會以不同的方式解決一個常見的問題。這可能是透過建構不同的架構或整合不同的外部架構來實現的。

第二個專案是一個中型的專案，有十幾位開發人員，但輪換率很高。當新人進來時，他們會查看以前解決問題的方法，不理解它或發現它有缺陷，然後朝著新的方向前進。問題是，事情在新人進來之前不會完成，他們發現這個半完成的解決方案有缺陷... 你懂的。

在兩種情況下，最終結果都是有多種方法嘗試解決同一個問題。不僅重複工作浪費，還使軟體比必要的更複雜。

我應該強調的是，與同一組織中的其他系統相比，整體設計的健康狀況仍然相當不錯。特別是，對自動化測試的關注使演化比常態安全得多，而且兩個專案的缺陷率都顯著降低。

冒著濫用MetaphoricQuestioning的風險，你可以將這視為環境沒有消滅較弱突變的情況。理想情況下，當出現競爭設計時，它會快速死亡或消滅現有設計。這裡的問題是兩者都沒有發生。因此，問題變成了：你如何才能將劣質設計從系統中移除？

在兩種情況下，我交談過的人們都認為缺乏整體設計領導。在大型專案中，這是透過一個架構團隊新增的，該團隊為這些問題制定了基礎方法，然後密切溝通正在執行的內容。第二個團隊到目前為止還沒有解決這個問題，但它被視為需要更穩定的設計領導。因此，與其說是演化的隱喻，你可能更像是一個鼓勵優良特質並阻止不良特質的育種者。（這是達爾文的靈感來源。）

撇開隱喻不談，我認為這從根本上歸結為遵循原則「持續關注技術卓越和良好設計，增強敏捷性。」演化設計需要關注、技能和領導力。這只不過是一種不同類型的領導，與許多人普遍認為的不同。