受困于敏捷开发的数据与架构？肿么办？

戳蓝字“CSDN云计算”关注我们哦！

640?wx_fmt=jpeg

译|Lorraine Lo

文|Isaac Sacolick

来源|InfoWorld网站

如今企业强调敏捷开发不是一天两天，但在此过程中敏捷团队通常都会面临的一大挑战就是如何定义以及遵循开发中数据架构的模式和标准这一系列问题。

人们之所以认为推动数据和技术标准实践的难度很大，主要是因为敏捷团队通常需要2-4周的时间来完成不同sprints（spring被认为是轻量级敏捷框架，又被称为scrum）的开发，毕竟标准需要时间，而遵循标准更需要团队预留足够的时间来规划技术方面的实现；相反产品经理只需要优先考虑功能层面就可以了。

那么问题来了！对于一个正在执行某个sprint且计划下一个sprint的敏捷团队来说，很难有时间依据标准来制定其开发计划。换句话说，如果文档形式的标准不易遵循或者参考，就会导致团队工作效率降低，自然很难培训新的开发人员来进行最佳架构和数据的实践。这就像是一个没有地图或GPS的团队在森林里徘徊，很大程度上会成功摸索到下一个山头，却不能保证可以找到返回站点的最佳路径。所以提前知晓可能出现的有关数据与架构的诸多问题，很必要！

例如可以将数据和架构标准分成以下两类：

标准架构。例如数据模型、数据管道、支持微服务架构的技术、标准化的CI/CD（持续集成和持续交付）管道以及新技术相关概念的求证，这些都需要前期工程工作。
标准实践。包括命名约定、测试要求、微服务接口标准和可用性模式等，这些对敏捷团队在如何实现特性和解决技术债务问题方面具有指导作用。除此之外，标准实践还可能包括定义如何扩展数据模型、验证CI/CD管道改进或记录新微服务端点的流程标准。此外当标准需要工程工作时，最好将此工作定义为敏捷积压中的史诗（epics）、特性（features）和故事（stories），同时将它们分配给适当的团队。

这些团队要将其他应用程序的开发团队视为自己的客户，同时定义验收标准，其中开发的产品负责人可以是数据、应用程序或是解决方案架构师，但都需要致力于提供一个易于敏捷团队使用和交付业务价值的组件。

另一方面，当这些标准为开发团队提供数据和架构指导时，它们也应该成为开发人员如何实现用户故事的基础。这就要求团队对这些标准有深入理解，最好是可以创建一个易于使用的知识库，以便供负责人和各成员查阅参考。

当团队的优先级是对现有应用程序进行小改进时，以上这种方法确实奏效；但如果涉及正在开发的是一项新功能，并且功能要求与数据与架构标准保持一致，即时规划肯定是来不及的。所以要想敏捷团队朝着标准迈进就需要提前做好计划。

理想情况下，团队建立持续性的敏捷规划流程并完成持续审查史诗、特性和用户故事。针对复杂的项目尽可能在计划实施前安排多个sprint，以便团队全面协作完成开发任务，毕竟碎片化的工作相对容易完成。最重要的是，提前开会可以带给团队时间上的压力，由此团队就不得不去考虑引用标准，因为这样才会有充足的时间来执行计划。

此外开发根据参考架构和数据模型描述当前和近期未来状态以及长期目标，是协调敏捷团队的另一种有效方法。这些图表可被视为开发团队的路线图，用以指导如何更好地实现其与架构、数据标准的一致性。

为了将这些不同元素同时呈现在单个页面上，架构师不仅要定义相关组件的范围，还应该精确描述一个或多个应用程序的端到端服务。其中参考数据模型可能包括多个图表，具体取决于数据在组织中的使用方式。通常包括：

概念数据模型——用以描述业务实体、关系和基本事务。

数据集中在数据湖泊或数据仓库中的分析模型——用于分析、人工智能实验和数据可视化。

数据集成模型——显示数据源，对从其加载的数据执行关键转换以及存储的主数据库。

服务模型——显示微服务和其他API如何连接数据库。

毕竟在这个过程中，团队集中精力完成开发代码和产品发布已经承受了莫大的压力，所以对他们来说，审查标准不是最重要的；这时候就应该由架构师负责审查用户故事、与团队成员面对面分享学习、在故事中制定验收标准等，来保证实施和标准的一致性。此外，软件开发经理还应与其团队就验收标准进行讨论，从而达到实施与未来架构和数据标准相一致的目的。

如今大型企业采用多种方法来保证敏捷团队与数据及架构标准一致性，迫在眉睫。想要团队能够交付与架构一致的新功能，不妨试试定义标准、在sprint之前进行规划、编写架构驱动的验收标准和定义权责这些实践方法，看看是否有效？