敏捷開發和架構

Question

正式體系結構規範如何適應敏捷開發 - 如果有的話？

我特別想的Scrum，這使得沒有提及其中包括官方的文物建築的。

在組裝第一批產品積壓之前，您是否只是讓架構「不小心」（可以這麼說）發展，是非正式的，還是有空間做類似於4 + 1規格的事情？

Answer 1

敏捷經常被描述爲「只做你現在需要做的事情，如果需要更多的事情，你可以重構」。

這很容易讓人誤解。它可以被理解爲「現在快速地避開某些東西，然後研究如何升級它以在將來做更多事情」。這將導致痛苦和技術債務的世界。

對於任何需要設計的系統。對於小型/簡單系統來說，這種設計可能在你的腦海中，但在開始系統將要做什麼之前，以及如何最好地做到這一點之前，你仍然需要思考。

所以恕我直言，包括設計成敏捷方法正確的方法是現在設計不夠，你知道什麼是系統最終應該做的，並廣招說明它是如何做到這一點。提出足夠靈活的設計，以免燒燬任何橋樑。但不要浪費時間爲每個螺母和螺栓編寫正式的詳細規範。設計到您知道子系統將在何處以及如何適應的級別，但可將其視爲「黑匣子」，本身只能在需要實施時設計。

敏捷開發不應該排除一個正式的體系結構 - 它只是意味着你應該只設計足夠的正式體系結構，當你完成後所有的部分都能很好地配合在一起，並且你充實了設計的較小細節只有當他們需要的時候。有時候這意味着您需要事先進行相當詳細的設計。

Answer 2

取決於您的範圍。可能是一個給定的，可能是綠地。只要足夠的架構，就在時間。你需要能夠寫出你的第一個測試，做持續集成。

這是一個文件，那麼誰去需要它，做什麼？

• 您的團隊需要描述放置功能的位置和測試位置;
• 當你需要發展你的團隊時，新人可能會喜歡介紹;
• 營銷可能需要美麗的圖片;
• 某人可能不得不購買並安裝硬件和軟件; ...

Answer 3

Scrum的主要是項目管理技術，這就是爲什麼它沒有提到架構的原因。

儘可能架構被遞增地定義。在這方面，端到端而不是逐層完成的實現有助於實現每層中的一部分。

架構決策可能很難恢復，所以他們必須要很好，雖然並在最後一刻負責拍攝，當你有系統和客戶需求的更多的知識。

沒有強烈的正式規範需求。

Answer 4

敏捷並沒有像應該那樣強調架構。這降低了軟件將來可用的可能性。權力的遊戲方法學從敏捷的優點和侷限中學習;它創建了一個更「不受未來影響」和可擴展的軟件。數字動物寫這篇文章來建立這種方法。 http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/