戳藍字「CSDN雲計算」關注我們哦！
譯|Lorraine Lo
文|Isaac Sacolick
來源|InfoWorld網站
如今企業強調敏捷開發不是一天兩天，但在此過程中敏捷團隊通常都會面臨的一大挑戰就是如何定義以及遵循開發中數據架構的模式和標準這一系列問題。
人們之所以認為推動數據和技術標準實踐的難度很大，主要是因為敏捷團隊通常需要2-4周的時間來完成不同sprints（spring被認為是輕量級敏捷框架，又被稱為scrum）的開發，畢竟標準需要時間，而遵循標準更需要團隊預留足夠的時間來規劃技術方面的實現；相反產品經理只需要優先考慮功能層面就可以了。
那麼問題來了！對於一個正在執行某個sprint且計劃下一個sprint的敏捷團隊來說，很難有時間依據標準來制定其開發計劃。換句話說，如果文檔形式的標準不易遵循或者參考，就會導致團隊工作效率降低，自然很難培訓新的開發人員來進行最佳架構和數據的實踐。這就像是一個沒有地圖或GPS的團隊在森林裡徘徊，很大程度上會成功摸索到下一個山頭，卻不能保證可以找到返回站點的最佳路徑。所以提前知曉可能出現的有關數據與架構的諸多問題，很必要！
例如可以將數據和架構標準分成以下兩類：
標準架構。例如數據模型、數據管道、支持微服務架構的技術、標準化的CI/CD（持續集成和持續交付）管道以及新技術相關概念的求證，這些都需要前期工程工作。
標準實踐。包括命名約定、測試要求、微服務接口標準和可用性模式等，這些對敏捷團隊在如何實現特性和解決技術債務問題方面具有指導作用。除此之外，標準實踐還可能包括定義如何擴展數據模型、驗證CI/CD管道改進或記錄新微服務端點的流程標準。此外當標準需要工程工作時，最好將此工作定義為敏捷積壓中的史詩（epics）、特性（features）和故事（stories），同時將它們分配給適當的團隊。
這些團隊要將其他應用程式的開發團隊視為自己的客戶，同時定義驗收標準，其中開發的產品負責人可以是數據、應用程式或是解決方案架構師，但都需要致力於提供一個易於敏捷團隊使用和交付業務價值的組件。
另一方面，當這些標準為開發團隊提供數據和架構指導時，它們也應該成為開發人員如何實現用戶故事的基礎。這就要求團隊對這些標準有深入理解，最好是可以創建一個易於使用的知識庫，以便供負責人和各成員查閱參考。
當團隊的優先級是對現有應用程式進行小改進時，以上這種方法確實奏效；但如果涉及正在開發的是一項新功能，並且功能要求與數據與架構標準保持一致，即時規劃肯定是來不及的。所以要想敏捷團隊朝著標準邁進就需要提前做好計劃。
理想情況下，團隊建立持續性的敏捷規劃流程並完成持續審查史詩、特性和用戶故事。針對複雜的項目儘可能在計劃實施前安排多個sprint，以便團隊全面協作完成開發任務，畢竟碎片化的工作相對容易完成。最重要的是，提前開會可以帶給團隊時間上的壓力，由此團隊就不得不去考慮引用標準，因為這樣才會有充足的時間來執行計劃。
此外開發根據參考架構和數據模型描述當前和近期未來狀態以及長期目標，是協調敏捷團隊的另一種有效方法。這些圖表可被視為開發團隊的路線圖，用以指導如何更好地實現其與架構、數據標準的一致性。
為了將這些不同元素同時呈現在單個頁面上，架構師不僅要定義相關組件的範圍，還應該精確描述一個或多個應用程式的端到端服務。其中參考數據模型可能包括多個圖表，具體取決於數據在組織中的使用方式。通常包括：
概念數據模型——用以描述業務實體、關係和基本事務。
數據集中在數據湖泊或數據倉庫中的分析模型——用於分析、人工智慧實驗和數據可視化。
數據集成模型——顯示數據源，對從其加載的數據執行關鍵轉換以及存儲的主資料庫。
服務模型——顯示微服務和其他API如何連接資料庫。
畢竟在這個過程中，團隊集中精力完成開發代碼和產品發布已經承受了莫大的壓力，所以對他們來說，審查標準不是最重要的；這時候就應該由架構師負責審查用戶故事、與團隊成員面對面分享學習、在故事中制定驗收標準等，來保證實施和標準的一致性。此外，軟體開發經理還應與其團隊就驗收標準進行討論，從而達到實施與未來架構和數據標準相一致的目的。
如今大型企業採用多種方法來保證敏捷團隊與數據及架構標準一致性，迫在眉睫。想要團隊能夠交付與架構一致的新功能，不妨試試定義標準、在sprint之前進行規劃、編寫架構驅動的驗收標準和定義權責這些實踐方法，看看是否有效？
福利
掃描添加小編微信，備註「姓名+公司職位」，加入【雲計算學習交流群】，和志同道合的朋友們共同打卡學習！