您如何控制敏捷項目中的架構？

Question

您如何確保項目能夠通過「良好」的設計決策來實現靈活的軟件架構？

你是如何在完全將體系結構留給團隊的一方之間取得平衡的，並讓所有的體系結構都能夠控制另一方的少數人？

你有「建築羣」，「建築標籤」或類似的東西嗎？

Answer 1

敏捷方法的先決條件是您已經知道如何使用的架構。

如果架構沒有很好的定義和完全理解，那麼您不能真正採用敏捷方法。

您需要有一些技術尖峯來展示架構如何工作，以及各個部分如何配合在一起。你可以做這些初步衝刺，但它們不會直接導致用戶發佈。它們是一個特殊情況，需要到達可以使用的架構。

一旦你通過這個「理解架構」的努力，你就可以開始執行衝刺，直接導致用戶發佈。

Answer 2

我可以解釋我該怎麼做，但this說比我好。

Answer 3

我通過預先做一些規劃來處理這個問題 - 通常，我有一些類似的應用程序的經驗以幫助解決這個問題。如果沒有，我會在這個空間做一些探索以獲得一個想法。一旦佈置了基本架構，我會根據我優先考慮的故事開始着手開發。然後，我會在重構時解決架構中的缺陷或錯誤。

Answer 4

根據我的經驗，您做這件事的最佳方式是經驗豐富的開發人員/架構師從事日常駕駛架構願景的項目。

我會建議它由項目的開發負責人來控制體系結構並確保所有新工作都適合它。

Answer 5

沒有做大的設計，通常有一個基本的設計適用於每個項目。通常，這會在應用程序的設計中定義基本層以尊重。大多數其他設計決策都由每個開發人員做出。

我們的開發流程基於短期開發並經常進行同行評審。每位開發人員的體系結構決策的質量在同行評審時進行驗證。這還包括驗證代碼是否遵循產品架構。

根據項目類型和可用工具的不同，我們還使用諸如macker之類的工具來自動驗證分層結構的完整性。

Answer 6

我還建議閱讀福勒文檔Is Design Dead，據我瞭解他的論點，如果你考慮所有的敏捷實踐作爲一個整體，那麼你可以自由地做出巨大的改變，所以可以演變的架構。

重構工作最有效地持續互動，測試通過TDD和持續集成得到增強...我可以繼續。如果你無法做出大的改變來糾正「錯誤」，那麼不斷髮展的'體系結構'是有限的。

另外，我認爲你有一個架構師作爲項目中的利益相關者，他們貢獻用戶故事，然後將這些用戶故事傳遞給架構師。

這也是一個很好的方式來與建築師一起使用配對編程作爲配對的一部分。在這種背景下，架構師並不是一個專注的人，而是一個開發團隊成員在配對編程時戴的帽子。

我認爲XP並沒有削弱建築師（和架構）的作用，它只是將所有團隊成員的可接受性放在項目的整個生命週期內提供和傳播成本。

[編輯]

每其他意見不要害怕一些前期規劃，itteration零是嘗試和圖表有點計劃的好時機，只是沒有得到嚴格的關於它的交付到特定的時間規模。