2009-12-12 117 views
7

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

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

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

回答

14

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

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

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

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

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

+0

除了上面的質量答案:使用戶可以看到它們的設計定義的要求。這有助於您設想領域模型,同時關注用戶和最終的用戶界面(這在任何軟件項目中都應該是最重要的)。 – 2009-12-12 07:23:40

1

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

這是一個文件,那麼誰去需要它,做什麼?

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

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

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

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

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