如何在敏捷中交付可靠的架構？

如何在敏捷世界中交付可靠的架構？這是一種建立適應不斷變化的架構的方法。

有很多關於敏捷架構的文章，但我認為我們還沒有一個公認的實踐。

好的架構必須考慮許多不同的觀點（技術和人的），並不斷地權衡一個與另一個。

MVP 論點

有一種觀點認為不需要架構，開發人員可以構建最小可行產品（MVP）。

對於簡單的解決方案，這可能是一個有價值的練習。如果做得正確，MVP 可以提供許多幫助定義客戶需求的經驗。從這個意義上說，它是原型設計的一種形式。

但是，MVP 的任何增長都需要某種形式的架構。

備註：如果您有客戶為解決方案付費，並且您建議向客戶提供最低可行產品，這聽起來像是“我們將根據的資金提供最低限度的產品”。但是，如果您說您將首先構建一個 MVP 以加速需求收集過程，然後最終會交給他們的一個強大解決方案，那是一個非常不同的提議。

作為交付 MVP 的專案的架構師，您需要幫助正確確定其範圍。確保 MVP 是一次性的，或者更常見的是，當 MVP 回答問題時有一個明確的點，並且有一個結構化的演變成一個完整的產品。

未來交付的架構意圖願景

當今世界沒有大前端設計 (BUFD) 的空間，這是一件好事。BUFD 在沒有明確價值的情況下花費了數百萬美元，而且通常，當（或如果）完成時，設計就已經過時了。

解決方案是開發架構意圖Architecture Intent。

架構意圖是全域性的東西。

鑑於您的專案、客戶、解決方案或企業的需求，處理所有“功能”的最終架構是什麼？哪些可能的產品可以幫助實現目標？

從表面上看，這可能聽起來像 BUFD，但你所做的是制定長期的架構願景。並非所有細節都已充實。確定可能需要更多充實的架構上重要方面將取決於您的具體解決方案。

它只是為將來大的架構來設定方向。

除了少數（現在很少見的）政府 IT 專案外，沒有人能夠從一開始就實施完整的架構。

架構意圖為整個架構設定了方向。然而，架構意圖可以並且將會改變。

與所有敏捷或增量交付一樣，需求也會發生變化。需求變化可以改變架構意圖設定的方向。

此外，轉型計劃可能需要數年時間。當您交付架構意圖的某些方面時，可能會使用與您開始時不同的技術。

即時當下的架構

已經確定了架構意圖，那如何首先滿足當下即時需求？

此外，鑑於開發團隊目前的技術能力，需要縮減多少意圖以避免交付風險？

再一次，架構就是權衡。這些是具有業務意義的權衡，而不是架構師孤立地做出的事情。

與架構意圖不同，即時架構是具體的。針對需要發生的事情制定了精確的規範或政策。

即時架構到架構意圖

毫不奇怪，從即時架構到架構意圖的步驟構成了您的路線圖並定義了產品或釋出增量。

根據專案的敏捷程度，只有路線圖中的後續步驟可能會得到很好的定義。目標是不要做太多的BUFD；當需求改變時浪費精力。

是不是在一開始時就沒有基本架構的解決方案嗎？

不是。作為架構師，您仍然需要確保所有必需的“功能”都在即時架構中。但是，可能會與客戶就初始增量進行一些協商。

您可能還會發現最初的資料量和使用者數量很少，因此可以採用分階段的方法來支援可擴充套件性和併發性。