大规模敏捷案例︱车联网规模化敏捷开发历程

每年参加很多技术圈和敏捷圈的分享，其中科技、金融行业的案例居多，这个现象从2020年度的State of Agile™敏捷状态报告的被访者比例（前两名）就可以看出关联。

 本文分享的案例来自笔者所投身的车联网行业。在2020年的第14年的敏捷报告中，仅有5%的被访者来自工业/制造业（虽然已是历年最高比例了）。各种敏捷大会上，汽车行业的案例分享并不常见，近几年成为热门的车联网这一领域更是稀有。通过亲述这段历程，希望为团队的这段经历做一个总结与纪念；也借此机会感谢各路前辈的对我们团队成长的指点，将我们的实践经验回馈给行业。

第一阶段：敏捷开发项目集组建

我于2017年加入上汽大众移动互联（车联网）团队，当时部门成立不久，业务架构与应用开发团队也仅有个位数的员工。在半年多的时间里，我们每天热烈地讨论着未来向用户提供的服务，同时缜密地规划智慧车联平台的蓝图。

虽然是从零到一，出于未来服务治理与可扩展性等方面的考量，我们自然也不会为了单纯追求建设速度，而去走大多数分享者所讲述的Monolith->微服务化拆分的辛酸历程。当时在车联网行业使用微服务，还未出现成功案例，好在我们的几位同事都对其他行业的案例有颇深研究，决定一起吃这个螃蟹。我们将平台横向切分成了两层：将所有核心能力原子化的L1层，以及支持随时组合组装各种服务的L2层。也正因为是从头建设，我们相当看重架构设计的切分边界能正确落地，当时L1与L2层分别交由两支团队协作完成。这条路后来被证明是崎岖但是正确的道路。

开发项目开始之初，App、L1、L2三支团队（来自3家公司）基本都是全新招募，人力资源爬升速度还算比较快，随之对组内的协作方式，组间的协作方式带来了挑战。从塔克曼团队发展阶段模型来看，在Forming阶段。而我所在的开发项目集PMO所力求的，便是缩短跃迁到下一阶段所需要时间。三支团队都有来自甲乙双方的项目经理，在服务拆分与人员的职责之间的关系尚未完全固化的当时，我们没有选择纵向的Feature Team，而是让三支团队各自跑Scrum的3355。这样团队内部的磨合就会以公司为单位进行。

每周都会出现实际的层与层之间的协作问题，我们对于流程规范也是使用敏捷的思路来推进：初步定义->快速调整->逐步稳定。PMO日常要组织大家讨论不同团队间如何拉齐对需求的认识，如何统一对质量的定义，上下游工序的时间约束等工作流程方面的话题；也需要处理不同团队间的冲突，有时候是带情绪的那种。（所以说PMO除了专业能力，心中一定要充满爱。）工作流程的逐渐稳定以及团队间熟悉程度的提升都让整个项目集向着Norming发展。

这里值得一提的一次促进合作的契机，原先三个团队坐在同一幢办公楼的不同楼层，有一次因办公地点调整，有机会搬去坐在同一层。我们很敏锐地抓住了这个机会，在安排座位的过程中，有意识地将一整排座位进行了双拼。将负责同一功能的App与L2层的两家公司员工安排在了同一排。缩短了他们空间上的沟通路径，一转身就能与不同公司的相关同事讨论，这个操作与项目后期重组Feature Team的原理应该是异曲同工。这为开发和测试的同事提供了一种选择，不必事事都需要先通过项目经理的通信管道建立沟通，从而避免其带来“信息带宽”的瓶颈。当我们的功能负责人/BA在向团队说明需求或确认最新实现时，不必特地约一个会议室，就能找齐所有人，信息得以最直接地传达。

在团队领导、开发项目经理、功能负责人、架构、开发、测试、DevOps同事日夜兼程的全力推动下，项目集的第一个Milestone按时上线了。

不知不觉写到此处，最初打算在一篇内写完的，看了后面的提纲（Backlog），决定敏捷式的交付，有任何的想法欢迎留言交流。

第二阶段：规模化敏捷试点

2019年下半年，在我们的第一代智慧车联网平台尚未完全上线之际，纯电动平台的车联项目必须进入开发了。做车联的同行应该都了解，车型项目的时间线就是车企的生命线，是必须要保障的。我们原先三支团队并没有余力接手，如果引入一支新的团队，又会进入两难的境地。——像这样车型之间重叠的项目节奏，在传统汽车开发领域很常见。因为研发时间长，为了保证每年都有新车型投放市场，重叠周期是必须的选择。在车型项目初期可以对需要共享的新零件进行规划，如果无法共享，就会使用替代方案解决了。但是车联平台与单个零件有着本质的不同：作为替代方案的零件可以交给不同的团队来分头供货，零件装上车后就作为这个组合的一部分一直工作下去了；而做为一个平台其宗旨是复用，交给不同的团队做分支就会面临代码合并或重构（1难），如果采用主干提交方式，将会对原有的主干代码产生侵入，从而造成大量的回归工作（2难）。对于仍在襁褓之中的初代平台而言，主干的稳定是当时的场景下最看重的。因此我们艰难地决定：我们引入一支新团队，使用分支来处理新的纯电平台项目。这个最现实的选择，也为下一篇将要提到的第三阶段埋下了伏笔，按下不表。

由上述讨论可见，车型项目时间作为约束条件的车联网平台项目规划和管理，是目前最复杂的项目管理之一，尤其是在车型较多的企业。

时间稍稍回拨到2017年的12月，我参加了在上海举办的Agile Tour敏捷之旅活动。在英孚总部的会场里，第一次听到了来自Wilson分享的规模化敏捷框架，当时他已经在金融行业率先尝试使用SAFe，案例中它既能支持多个Feature Team，也能兼顾自研+供应商的混合的场景，给我留下了深刻印象。对于项目管理者而言，了解到实用框架带来的喜悦，可以类比开发工程师学习到了好用的开发框架。

2018年下半年，车联网开发高级经理陈总在一次出差后，跟我们分享了这样的信息：德国大众的纯电动平台车联网，已经开始采用规模化敏捷的方法进行工作。总人数上千的数十个开发团队，同时在一个体育馆内，进行为期两天的PI Planning，拉着毛线识别依赖和风险、采用丰富的Demo方式、与任一团队面对面互动等场景……我们听得心驰神往。因此在19年初，我得知国内将会举办一场（唯二的）RTE培训时，在培训部的大力支持下，我们一行三人踏上了规模化敏捷的求学路。整整三天印式英语的课程与练习，信息密度非常之高，效果拔群。当时课上结识了李建昊老师，以及来自Honeywell, Intel等国内比较早期采用SAFe公司的同学。

 回到开头所提的纯电动平台，为了与德国的开发节奏对齐，我们决定也采用相近的工作方式。本想到了请Wilson来协助我们做导入的工作，最后因为档期等种种原因，请来了圈内同样资深的两位老师。我们在下半年花了不少精力，内部架构、开发、测试专家亲自把关层层面试，招募了一支新的团队进入项目集，并且在搭建时，天然地按业务领域建立了团队。这样安排没有历史包袱，也是按照各位Team Leader理想中的样子组建了Feature Team。

整个团队对新模式的认知程度需要在最短时间内对齐。时任移动互联高级总监李总对规模化敏捷的热情非常高，在他的带领下，部门管理层开展了规模化敏捷导入的研讨会。随后我们面向团队的不同角色，展开了近十场规模化敏捷培训。同时联合了团队内各专业领域的专家，编写并建立了符合项目集情况的DoR与DoD。与PO的协作也随之变得更为密切起来。关于这段经历，在移动互联的敏捷先行者一文中有所描述，感兴趣可以点击阅读。

独立的新团队，在独立的分支上试点使用规模化敏捷的方式，业务需求和架构需求都开展的如火如荼。而随着分支独立得越久，大家也不禁担心起来……

第三阶段：全体集结再启航

在2019年末第一代智慧车联平台正式上线之后，代码合并的工作被提上了日程。在3个月的时间内，我们规划了2次合并，10周主线锁定的时长，充分的回归测试。在第一次尝试合并以后，因为天然地存在两组人在维护代码，很难避免为了修复线上问题后，而需要产生新的合并。这是一个工程实践和工程效能问题。

回溯到2017年，第一次登录中国的DevOps Day的上海站期间，有幸参加过乔梁老师的亲授的公开课。他所解构的持续交付理念与全球最领先的案例，刷新了我对软件工程实践的理解。现在DevOps培训的教材之一，就是他所译的《持续交付》。2018年他所著的《持续交付2.0》，更是在此基础上的更新和升级。从2019年下半年开始，我们每年都组织研发、DevOps同事参加DevOps Master等各种技术、管理培训，这提升了团队整体的工程效能理念。

 在2020年的工程难题，经过架构师与几位Team Leader的多次讨论，我们定义和优化了适用于当前团队现状的工作方法，推及到每一位开发。伴随着的是对组织形式变更的需求，两个项目团队需要在物理上——至少在逻辑上的融合。我们组织将第一篇中的L1, L2的两个团队同事根据职责划分到了各Feature Team中，每天在一起开每日站会，让大家充分互相了解到正在进行的工作和变更。这种变动过程并非一蹴而就，宣导工作能起到效果，也是得益于这是一支理性的、有素养的团队。

在开发资源规划方面，MEB车联平台项目中，除了提供给业务需求的容量，也给架构优化留出了跑道：划出了近三分之一的容量给到架构需求，这是为了将来在合并回主干时，让我们的架构有能力支持中远期的百万、千万车联网用户的场景。因此新技术组件和变更配置项数量之巨，可以想象。DevOps同学深得持续交付的精髓，拥有配置即代码的思想，经过数周与各团队的梳理和编写，90%的配置都已代码化，并能在30分钟内将数百个微服务自动配置并启动完毕。

后台顺利完成合并之后，我们终于拥有了梦寐以求的一个产品主线，开发团队组织结构也完成了调整。尽管如此，我们的需求输入来源并没有减少，在上汽大众、斯柯达两个品牌的基础上，还增加了上汽奥迪品牌。规模化敏捷试点，这个管理方式的“分支”，也终于可以合并回“主干”了。在2020年7月底，具有里程碑意义的全项目集PI Planning正式召开，未来三个月内所有的项目目标，都在2天的Workshop内被充分讨论，排优先级、排期、对齐。团队中有相当数量的同事参加过规模化敏捷的试点，在充分地准备了1个月以后 ，我们成功地将这些实践扩展到150人+的规模。这也作为车联网开发团队全体的工作方式，有节奏地延续至今。