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

每年参加很多技术圈和敏捷圈的分享，其中科技、金融行业的案例居多，这个现象从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公司的同学。