怎樣在敏捷開發中做到“事半功倍”

敏捷領導和敏捷團隊在敏捷開發中面臨的挑戰是怎樣定義並遵循資料、體系結構模式和標準。 有一種觀點認為，由於敏捷團隊敏捷迭代（sprints）的工作通常會長達2~4周的時間，而產品所有者一般會提出太多的按優先順序排列的產品需求項，因此，很難推動資料和技術標準。  標準的制定需要時間；遵循標準要求敏捷團隊有足夠的時間來計劃技術的實施。

在一個敏捷迭代中執行，並且只計劃下一次敏捷迭代的敏捷團隊將很難使用標準來制訂他們的開發計劃。  如果不容易遵循或者引用文件化的標準，那麼團隊的效率就會降低，並且很難針對最 佳體系結構和資料實踐對新開發人員進行培訓。 這好比一支沒有地圖或者GPS的隊伍在森林裡走散了；他們也許能到達下一個路口，但他們不知道自己是否正沿著一條最 佳路徑返回鎮上。

一、需要注意哪些資料   和體系結構問題

把資料和體系結構標準分為兩類是比較合適的：

• 標準體系結構，例如，資料模型、資料管道、實現微服務體系結構的技術、標準化的CI/CD（持續整合和持續交付）管道，以及圍繞新技術的概念驗證等。這些都需要前期的工程工作。

• 標準實踐，包括命名約定、測試需求、微服務介面標準和可用性模式。以上這些指導敏捷團隊怎樣實現功能並解決技術難題。還可能包括定義怎樣擴充套件資料模型、驗證CI/CD管道改進效果，以及記錄新微服務端點的流程標準。

當標準需要工程工作時，最好將此工作定義為敏捷產品需求項中的使用者長故事（epics）、特徵和故事（stories），並將它們分配給適當的團隊。 這些團隊應將其他應用程式開發團隊視為其客戶，並應圍繞他們的工作定義驗收標準。這類開發的產品所有者可以是資料、應用程式或者解決方案架構師，他們的工作就是交付易於敏捷團隊使用並能實現業務價值的元件。

另一方面，  當標準向開發團隊提供資料和體系結構指導時，這些標準應該成為開發人員怎樣實現使用者故事的基礎。 這就要求團隊深入瞭解這些標準；也許還需要一個易於使用的知識庫，供團隊領導和成員審閱。

二、敏捷開發需要持續的計劃
很多敏捷團隊在敏捷迭代開始時會召開計劃會議。他們審查按優先順序排列的使用者故事，評估這些故事，並承諾在敏捷迭代期間處理它們。當團隊按照優先順序對現有應用程式進行小的改進時，這種方法很有效。但是，  如果他們正在開發新功能，並且希望與資料和體系結構標準保持一致，那麼即時計劃是不夠的。 在敏捷迭代即將開始之前，團隊沒有足夠的時間在一次會議上審查使用者故事，檢查實施與標準是否保持一致。

按照標準向前推進的團隊應提前做好計劃。我  更傾向於在敏捷迭代開始時召開名為“承諾會議”的會議，讓團隊確定他們要處理什麼樣的故事。將計劃實施這些故事的重要工作安排在一個或者多個“計劃會議”中。

理想情況下，團隊建立一個持續的敏捷計劃過程，在這個過程中，他們會不斷地審查長故事、特徵和使用者故事。 對於需要更多計劃時間的更復雜的工作項，在計劃實施之前安排了不止一次敏捷迭代，這樣團隊就能夠全面完成開發計劃；工作項越小，過程完成的就越快。最重要的是，儘早開會可以減輕團隊的時間壓力；這樣，他們有足夠的時間來計劃實施，因此更有可能去考慮標準。

三、開發參考體系結構和資料模型
協調敏捷團隊的一種方法是開發描述當前狀態、近期未來狀態和長期目標的參考體系結構和資料模型。  這些圖表可以作為開發團隊的路線圖，以便他們知道怎樣更好地將其實施與體系結構和資料標準保持一致。

文件化的參考體系結構是帶有顏色程式碼和其他符號的單頁圖表，分清楚當前狀態和未來狀態。為了把它們放在一個頁面上，架構師應該定義相關元件的範圍，並描述一個或者多個應用程式的端到端服務。  參考資料模型可能包括多個圖表，具體取決於資料在組織中的使用方式。它們通常包括以下內容：

• 一種概念資料模型，用於描述業務實體、關係和基本會話。

• 一種分析模型，分析資料怎樣集中在資料湖或者資料倉儲中，用於分析、人工智慧實驗和資料視覺化。

•  一種資料整合模型，顯示資料來源、對從資料來源載入的資料執行的關鍵轉換，以及儲存資料的主資料庫。

•  一種服務模型，顯示微服務和其他API怎樣連線到資料庫。

這些圖表可以作為敏捷團隊理解標準和未來方向的起點。 架構師應該為這些模型補充完善更多的細節，比如API文件、資料字典，以及每個體系結構和資料元件的領域專家列表。

四、編寫參考標準的驗收標準
使用者故事應描述需求的內容、原因和物件。理想情況下，產品所有者不應記錄故事是怎樣實施的，因為這是架構師、軟體開發人員和測試人員的工作。團隊應該負責交付功能，並確保實施滿足體系結構、資料、安全性、Devops和其他標準。

僅僅記錄標準和參考體系結構還不足以讓團隊遵守它們。團隊在開發程式碼和完成發行版方面承受著太大的壓力，因此審查標準並不總是首要任務。架構師應該負責審查使用者故事，與團隊開會共同學習，並透過在故事中寫入驗收標準，使實施與適當的標準保持一致。此外，  軟體開發經理應與其團隊討論驗收準則和標準，以確保他們遵循最 佳實踐，保證實施與未來的體系結構和資料標準相一致。

規模較大的部門應考慮透過多種方法來促使敏捷團隊遵循資料和體系結構標準。  定義標準、在敏捷迭代之前進行規劃、編寫體系結構驅動的驗收標準，以及定義職責——只有採用這些實踐措施，團隊才能夠交付符合體系結構要求的新功能。