敏捷方法導致零散設計

Question

如何防止每月衝刺/迭代導致分散設計的敏捷方法。例如。以曼哈頓街道vs波士頓街道的設計爲例。曼哈頓街道的藍圖被設計爲一個整體，從而帶來輕鬆的操控性和駕駛樂趣。波士頓街道的設計採用了一種餐食方式，它的噩夢四處走動。

Answer 1

敏捷開發並不是放棄過度設計的使命。例如，計劃「全局圖」很重要 - 主要組件的責任是什麼，以及它們將如何相互作用。在我自己的團隊中，我發現一個合理的妥協方法是事先同意一個廣泛的公共API，但在可能的情況下推遲詳細的實施決策。這使得個體開發人員可以隨着實現的發展自由地修改設計，同時還可以在設計級別獲得不同方法的好處，而且變化更便宜。模塊化也是關鍵 - 保持組件在功能上特定並儘可能彼此分離。當您發現需要對實現進行更改時，這可以最大限度地減少開銷，並且可以增加您編寫的單個組件仍然有用的機會。

Answer 2

街道是用於軟件的糟糕比喻。如果沒有顯着的努力，街道不能輕易移動，重新路由或更改。編寫良好的軟件是正交組件，可根據需要輕鬆進行重組和修改。

敏捷開發工作的原因是開發人員和軟件本身都很敏捷。開發人員對變化做出迅速反應，他們編寫的軟件的編寫方式也會對變更做出響應。

Answer 3

重構，重構，重構。

Answer 4

您可以在街道上設計一個設計階段。每個階段都確定建造什麼建築物。

我認爲在scrum項目中有一種傾向，即設計/架構太少。你可以做不斷的重構，但是如果沒有設計出來的話，那可能是很多工作。如果設計中存在錯誤，則可能會遇到同樣的問題。

Answer 5

使用SOLID principles將導致代碼鬆散耦合&高度內聚。

還記得設計是國王。

恕我直言，與建築物，街道軟件組件類比是不合邏輯的。這些都不是軟件開發或軟件設計的遠程類似。

Answer 6

敏捷用戶總會提出將敏捷原則調整到適合當前情況的風險，然而，如果這種情況隨後失敗，那麼支持向敏捷提出支持的人可能會受到批評，因爲敏捷尚未得到充分採用。

碎片化設計是敏捷的持續風險，因爲在架構上沒有價值。我們需要的是一種使用敏捷（如持續交付）的優勢方面的方法，但可以解決諸如敏捷的不可伸縮性等問題。一種可能的方法是The Game of Thrones Methodology就是這樣做的。

Answer 7

「敏捷方法論」（我假設你的意思是SCRUM，這裏）與你設計的架構無關;該體系結構是您創建的軟件或系統的屬性（在UML世界中，您可能會將其稱爲「artefacts」）。

「敏捷」不會告訴您任何有關您編寫的軟件的事情，它可以用於任何和所有類型的軟件，甚至可以輕鬆用於與軟件完全無關的項目。

所以如果你覺得你的敏捷項目存在一個糟糕的軟件架構，那麼你應該看看實際的原因是什麼。僅僅因爲你敏捷並不意味着每個人都沒有計劃就做他想做的事，或者你根本就不需要文檔。儘管在開始工作之前，您不會將每個類都指定到位級別，但即使在第一次衝刺之前，仍然需要記錄高級體系結構。根據你的團隊規模和選區，你可以想象使用你的第一個衝刺甚至創建你的架構。