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

回到开头所提的纯电动平台，为了与德国的开发节奏对齐，我们决定也采用相近的工作方式。本想到了请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人+的规模。这也作为车联网开发团队全体的工作方式，有节奏地延续至今。