如何解決敏捷開發(fā)中的數(shù)據(jù)和體系結(jié)構(gòu)標準問題

Isaac Sacolick

從長遠來看，花時間為標準實踐制訂計劃是值得的

敏捷領(lǐng)導和敏捷團隊在敏捷開發(fā)中面臨的挑戰(zhàn)是怎樣定義并遵循數(shù)據(jù)、體系結(jié)構(gòu)模式和標準。有一種觀點認為，由于敏捷團隊敏捷迭代（sprints）的工作通常會長達2～4周的時間，而產(chǎn)品所有者一般會提出太多的按優(yōu)先順序排列的產(chǎn)品需求項，因此，很難推動數(shù)據(jù)和技術(shù)標準。標準的制定需要時間;遵循標準要求敏捷團隊有足夠的時間來計劃技術(shù)的實施。

在一個敏捷迭代中執(zhí)行，并且只計劃下一次敏捷迭代的敏捷團隊將很難使用標準來制訂他們的開發(fā)計劃。如果不容易遵循或者引用文檔化的標準，那么團隊的效率就會降低，并且很難針對最佳體系結(jié)構(gòu)和數(shù)據(jù)實踐對新開發(fā)人員進行培訓。這好比一支沒有地圖或者GPS的隊伍在森林里走散了;他們也許能到達下一個路口，但他們不知道自己是否正沿著一條最佳路徑返回鎮(zhèn)上。

需要注意哪些數(shù)據(jù)和體系結(jié)構(gòu)問題

把數(shù)據(jù)和體系結(jié)構(gòu)標準分為兩類是比較合適的：

·標準體系結(jié)構(gòu)，例如，數(shù)據(jù)模型、數(shù)據(jù)管道、實現(xiàn)微服務體系結(jié)構(gòu)的技術(shù)、標準化的CI/CD（持續(xù)集成和持續(xù)交付）管道，以及圍繞新技術(shù)的概念驗證等。這些都需要前期的工程工作。

·標準實踐，包括命名約定、測試需求、微服務接口標準和可用性模式。以上這些指導敏捷團隊怎樣實現(xiàn)功能并解決技術(shù)難題。還可能包括定義怎樣擴展數(shù)據(jù)模型、驗證CI/CD管道改進效果，以及記錄新微服務端點的流程標準。

當標準需要工程工作時，最好將此工作定義為敏捷產(chǎn)品需求項中的用戶長故事（epics）、特征和故事（stories），并將它們分配給適當?shù)膱F隊。這些團隊應將其他應用程序開發(fā)團隊視為其客戶，并應圍繞他們的工作定義驗收標準。這類開發(fā)的產(chǎn)品所有者可以是數(shù)據(jù)、應用程序或者解決方案架構(gòu)師，他們的工作就是交付易于敏捷團隊使用并能實現(xiàn)業(yè)務價值的組件。

另一方面，當標準向開發(fā)團隊提供數(shù)據(jù)和體系結(jié)構(gòu)指導時，這些標準應該成為開發(fā)人員怎樣實現(xiàn)用戶故事的基礎。這就要求團隊深入了解這些標準;也許還需要一個易于使用的知識庫，供團隊領(lǐng)導和成員審閱。

敏捷開發(fā)需要持續(xù)的計劃

很多敏捷團隊在敏捷迭代開始時會召開計劃會議。他們審查按優(yōu)先級排列的用戶故事，評估這些故事，并承諾在敏捷迭代期間處理它們。

當團隊按照優(yōu)先級對現(xiàn)有應用程序進行小的改進時，這種方法很有效。但是，如果他們正在開發(fā)新功能，并且希望與數(shù)據(jù)和體系結(jié)構(gòu)標準保持一致，那么即時計劃是不夠的。在敏捷迭代即將開始之前，團隊沒有足夠的時間在一次會議上審查用戶故事，檢查實施與標準是否保持一致。

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

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

開發(fā)參考體系結(jié)構(gòu)和數(shù)據(jù)模型

協(xié)調(diào)敏捷團隊的一種方法是開發(fā)描述當前狀態(tài)、近期未來狀態(tài)和長期目標的參考體系結(jié)構(gòu)和數(shù)據(jù)模型。這些圖表可以作為開發(fā)團隊的路線圖，以便他們知道怎樣更好地將其實施與體系結(jié)構(gòu)和數(shù)據(jù)標準保持一致。

文檔化的參考體系結(jié)構(gòu)是帶有顏色代碼和其他符號的單頁圖表，分清楚當前狀態(tài)和未來狀態(tài)。為了把它們放在一個頁面上，架構(gòu)師應該定義相關(guān)組件的范圍，并描述一個或者多個應用程序的端到端服務。

參考數(shù)據(jù)模型可能包括多個圖表，具體取決于數(shù)據(jù)在組織中的使用方式。它們通常包括以下內(nèi)容：

一種概念數(shù)據(jù)模型，用于描述業(yè)務實體、關(guān)系和基本會話。

一種分析模型，分析數(shù)據(jù)怎樣集中在數(shù)據(jù)湖或者數(shù)據(jù)倉庫中，用于分析、人工智能實驗和數(shù)據(jù)可視化。

一種數(shù)據(jù)集成模型，顯示數(shù)據(jù)源、對從數(shù)據(jù)源加載的數(shù)據(jù)執(zhí)行的關(guān)鍵轉(zhuǎn)換，以及存儲數(shù)據(jù)的主數(shù)據(jù)庫。

一種服務模型，顯示微服務和其他API怎樣連接到數(shù)據(jù)庫。

這些圖表可以作為敏捷團隊理解標準和未來方向的起點。架構(gòu)師應該為這些模型補充完善更多的細節(jié)，比如API文檔、數(shù)據(jù)字典，以及每個體系結(jié)構(gòu)和數(shù)據(jù)組件的領(lǐng)域?qū)＜伊斜怼?/p>

編寫參考標準的驗收標準

用戶故事應描述需求的內(nèi)容、原因和對象。理想情況下，產(chǎn)品所有者不應記錄故事是怎樣實施的，因為這是架構(gòu)師、軟件開發(fā)人員和測試人員的工作。團隊應該負責交付功能，并確保實施滿足體系結(jié)構(gòu)、數(shù)據(jù)、安全性、Devops和其他標準。

僅僅記錄標準和參考體系結(jié)構(gòu)還不足以讓團隊遵守它們。團隊在開發(fā)代碼和完成發(fā)行版方面承受著太大的壓力，因此審查標準并不總是首要任務。架構(gòu)師應該負責審查用戶故事，與團隊開會共同學習，并通過在故事中寫入驗收標準，使實施與適當?shù)臉藴时３忠恢隆?/p>

此外，軟件開發(fā)經(jīng)理應與其團隊討論驗收準則和標準，以確保他們遵循最佳實踐，保證實施與未來的體系結(jié)構(gòu)和數(shù)據(jù)標準相一致。

規(guī)模較大的部門應考慮通過多種方法來促使敏捷團隊遵循數(shù)據(jù)和體系結(jié)構(gòu)標準。定義標準、在敏捷迭代之前進行規(guī)劃、編寫體系結(jié)構(gòu)驅(qū)動的驗收標準，以及定義職責——只有采用這些實踐措施，團隊才能夠交付符合體系結(jié)構(gòu)要求的新功能。

Isaac Sacolick是《數(shù)字化驅(qū)動：通過技術(shù)進行業(yè)務轉(zhuǎn)型的領(lǐng)導者指南》一書的作者，該書涵蓋了很多實踐，例如敏捷、開發(fā)運維和數(shù)據(jù)科學等，這些都是成功實施數(shù)字化轉(zhuǎn)型計劃的關(guān)鍵。

原文網(wǎng)址

https：//www.infoworld.com/article/3433923/how-to-address-data-and-architecture-standards-in-agile-development.html