Isaac Sacolick

從長遠來看,花時間為標準實踐制訂計劃是值得的
敏捷領導和敏捷團隊在敏捷開發中面臨的挑戰是怎樣定義并遵循數據、體系結構模式和標準。有一種觀點認為,由于敏捷團隊敏捷迭代(sprints)的工作通常會長達2~4周的時間,而產品所有者一般會提出太多的按優先順序排列的產品需求項,因此,很難推動數據和技術標準。標準的制定需要時間;遵循標準要求敏捷團隊有足夠的時間來計劃技術的實施。
在一個敏捷迭代中執行,并且只計劃下一次敏捷迭代的敏捷團隊將很難使用標準來制訂他們的開發計劃。如果不容易遵循或者引用文檔化的標準,那么團隊的效率就會降低,并且很難針對最佳體系結構和數據實踐對新開發人員進行培訓。這好比一支沒有地圖或者GPS的隊伍在森林里走散了;他們也許能到達下一個路口,但他們不知道自己是否正沿著一條最佳路徑返回鎮上。
需要注意哪些數據和體系結構問題
把數據和體系結構標準分為兩類是比較合適的:
·標準體系結構,例如,數據模型、數據管道、實現微服務體系結構的技術、標準化的CI/CD(持續集成和持續交付)管道,以及圍繞新技術的概念驗證等。這些都需要前期的工程工作。
·標準實踐,包括命名約定、測試需求、微服務接口標準和可用性模式。以上這些指導敏捷團隊怎樣實現功能并解決技術難題。還可能包括定義怎樣擴展數據模型、驗證CI/CD管道改進效果,以及記錄新微服務端點的流程標準。
當標準需要工程工作時,最好將此工作定義為敏捷產品需求項中的用戶長故事(epics)、特征和故事(stories),并將它們分配給適當的團隊。這些團隊應將其他應用程序開發團隊視為其客戶,并應圍繞他們的工作定義驗收標準。這類開發的產品所有者可以是數據、應用程序或者解決方案架構師,他們的工作就是交付易于敏捷團隊使用并能實現業務價值的組件。
另一方面,當標準向開發團隊提供數據和體系結構指導時,這些標準應該成為開發人員怎樣實現用戶故事的基礎。這就要求團隊深入了解這些標準;也許還需要一個易于使用的知識庫,供團隊領導和成員審閱。
敏捷開發需要持續的計劃
很多敏捷團隊在敏捷迭代開始時會召開計劃會議。他們審查按優先級排列的用戶故事,評估這些故事,并承諾在敏捷迭代期間處理它們。
當團隊按照優先級對現有應用程序進行小的改進時,這種方法很有效。但是,如果他們正在開發新功能,并且希望與數據和體系結構標準保持一致,那么即時計劃是不夠的。在敏捷迭代即將開始之前,團隊沒有足夠的時間在一次會議上審查用戶故事,檢查實施與標準是否保持一致。
按照標準向前推進的團隊應提前做好計劃。我更傾向于在敏捷迭代開始時召開名為“承諾會議”的會議,讓團隊確定他們要處理什么樣的故事。將計劃實施這些故事的重要工作安排在一個或者多個“計劃會議”中。
理想情況下,團隊建立一個持續的敏捷計劃過程,在這個過程中,他們會不斷地審查長故事、特征和用戶故事。對于需要更多計劃時間的更復雜的工作項,在計劃實施之前安排了不止一次敏捷迭代,這樣團隊就能夠全面完成開發計劃;工作項越小,過程完成的就越快。最重要的是,盡早開會可以減輕團隊的時間壓力;這樣,他們有足夠的時間來計劃實施,因此更有可能去考慮標準。
開發參考體系結構和數據模型
協調敏捷團隊的一種方法是開發描述當前狀態、近期未來狀態和長期目標的參考體系結構和數據模型。這些圖表可以作為開發團隊的路線圖,以便他們知道怎樣更好地將其實施與體系結構和數據標準保持一致。
文檔化的參考體系結構是帶有顏色代碼和其他符號的單頁圖表,分清楚當前狀態和未來狀態。為了把它們放在一個頁面上,架構師應該定義相關組件的范圍,并描述一個或者多個應用程序的端到端服務。
參考數據模型可能包括多個圖表,具體取決于數據在組織中的使用方式。它們通常包括以下內容:
一種概念數據模型,用于描述業務實體、關系和基本會話。
一種分析模型,分析數據怎樣集中在數據湖或者數據倉庫中,用于分析、人工智能實驗和數據可視化。
一種數據集成模型,顯示數據源、對從數據源加載的數據執行的關鍵轉換,以及存儲數據的主數據庫。
一種服務模型,顯示微服務和其他API怎樣連接到數據庫。
這些圖表可以作為敏捷團隊理解標準和未來方向的起點。架構師應該為這些模型補充完善更多的細節,比如API文檔、數據字典,以及每個體系結構和數據組件的領域專家列表。
編寫參考標準的驗收標準
用戶故事應描述需求的內容、原因和對象。理想情況下,產品所有者不應記錄故事是怎樣實施的,因為這是架構師、軟件開發人員和測試人員的工作。團隊應該負責交付功能,并確保實施滿足體系結構、數據、安全性、Devops和其他標準。
僅僅記錄標準和參考體系結構還不足以讓團隊遵守它們。團隊在開發代碼和完成發行版方面承受著太大的壓力,因此審查標準并不總是首要任務。架構師應該負責審查用戶故事,與團隊開會共同學習,并通過在故事中寫入驗收標準,使實施與適當的標準保持一致。
此外,軟件開發經理應與其團隊討論驗收準則和標準,以確保他們遵循最佳實踐,保證實施與未來的體系結構和數據標準相一致。
規模較大的部門應考慮通過多種方法來促使敏捷團隊遵循數據和體系結構標準。定義標準、在敏捷迭代之前進行規劃、編寫體系結構驅動的驗收標準,以及定義職責——只有采用這些實踐措施,團隊才能夠交付符合體系結構要求的新功能。
Isaac Sacolick是《數字化驅動:通過技術進行業務轉型的領導者指南》一書的作者,該書涵蓋了很多實踐,例如敏捷、開發運維和數據科學等,這些都是成功實施數字化轉型計劃的關鍵。
原文網址
https://www.infoworld.com/article/3433923/how-to-address-data-and-architecture-standards-in-agile-development.html