Scrum plus项目制 —— 双轨并行的酷家乐特色产研实践
前言
坊间经常拿传统的项目管理和敏捷迭代做对比，似乎两者是完全对立不能共存的两派。作为软件行业常用的两种管理方法，其理念和操作方式有着很大的差异，但其目标都是为了更快速高质量的交付价值。那么项目和敏捷是否有可能强强联合，扬长避短的协作运行呢？
酷家乐产研背景——敏捷+项目
作为一家SaaS解决方案提供商，为保障产品功能的快速迭代和对市场反应的敏锐识别，我司产研团队采用了敏捷开发中的Scrum，在长期的敏捷循环迭代下，敏捷已经成为了酷家乐产研团队DNA的一部分。但是Scrum有其局限性，它期望产品模块相对独立避免耦合，对于一家SaaS解决方案提供商来说显然是不可能的。酷家乐从2011年创建至今已有十年的历史，产品架构的复杂性和多样性已经是软件开发环节避免不了的话题，业务之间的交互在所难免，单纯使用Scrum对于这类需求的支持就面临诸多困难，因此在敏捷环境下的酷家乐特色项目管理应用而生。公司将紧迫的产品需求或公司的战略规划以项目制方式来集中资源保障快速交付。项目不仅是新产品或业务从0-1的建设，也是已有产品或服务从1-N的过程，更多的是复杂的跨产品线的解决方案和战略落地。
酷家乐特色的产研运作方式
在酷家乐敏捷和项目是双轨并行的。换句话说，一位开发既是敏捷组成员也可能是项目成员，同时为迭代和项目创造价值。从项目管理的视角看，酷家乐的项目团队是平衡型矩阵，项目成员在项目中”兼职“而非”全职“。
项目将需求分发至敏捷组，敏捷组按照项目计划将项目需求拆解至迭代分批交付。项目相当于将工作包分发到各个敏捷组，搭上敏捷组迭代的班车，按照迭代周期到站下车，再根据项目计划验收和测试发布上线。
项目经理和项目负责人在项目过程中协调各环节推进，保障各参与敏捷组间的工作包内容和节奏符合预期。项目实际通过分批交付，小步快跑的方式快速交付上线。
双轨运作如何为大项目的落地提供助力
以2021年实际运作的大项目之一酷立方2.0为例，我们一起来了解双轨运作下产品功能交付的模式。
项目背景
————
项目涉及公司几乎所有的产品线，因为改动账号底层逻辑，可能对绝大部分产品功能有影响。需要摸排现有产品的权限情况并重新梳理改造点，可以说是对现有产品权益的颠覆性改造。项目6月初正式立项，目标是10月初完成新版功能和解决方案的上线，并支持售卖。项目所涉及的干系方除了19条产品线的产研外，还有商务、法务、财务等公司的各个部门。仅项目kick-off邀请人数已达到100+，项目的复杂度可见一斑。
附上一张项目战报的截图
这么大规模且复杂的项目，在双轨运作下是怎么保障平稳落地，并且保障上线后无 P0和P1 bug的呢？
双轨制为大项目的落地保驾护航
面面俱到 or 精准攻坚
这个项目产研侧的特点是“散”，涉及到19条产品线，5个平台方，7个上下游系统的改造，但相关方的改动并不都是庞大的功能开发，每个团队根据盘点结果改动不同工作量也不同。
从项目型和双轨制来看，让相关产研全职投入这个项目显然不行。如果组建一个All in 的项目团队，成员则来自各敏捷组，不仅会打断现有产研规划的交付，而且项目成员需要学习所涉及新产品领域的知识再投入开发，面面俱到，则学习和应用的成本必然不低，并且一旦项目结束释放资源，还增加了资源重新磨合团队的损耗。
每位开发都是自己所在产品领域的专家，如果项目按需使用，让资源精准攻击其负责领域的内容，则既不会对产品规划产生严重影响，也将人员的效能发挥到最大。
再考虑酷家乐各产品线之间的关联和耦合，对于跨产品线的项目，部分核心功能的上线需要根据盘点后的上线计划按照步骤上线。因此各产品线的改造只要满足项目计划的时间达到功能上线的标准即可。细节的功能点在产品线内部的开发计划具有一定的灵活性。
从化整为零，到聚零为整
跨产品线的项目更重要的是需求范围的盘点、信息的分发、计划和进度的对齐。双轨制下，细节的产品功能增加了各产品线的产品经理和SM把控，对项目管理来说天然的增加了助力，免去了各信息调度员的任命和培训。在项目范围的交付上，我们将项目的WBS分发到了不同的敏捷组，与项目制的差异仅在于团队使用了敏捷开发和“兼职”完成项目工作。
化整为零：
Kick-off对齐项目概况：在会前重点盘点了干系人，并对重点干系人点对点邀请。为了帮助相关方记忆项目的核心信息，将项目的核心目标、价值和计划提炼形成PPT，以图文结合的方式呈现给干系人。会议对齐重要性、目标、计划等，尤其是各干系方所负责模块参与项目的时间和项目内容。
产品专题会分解事项：产品侧盘点所有改造的内容和排查点，同各产品线经理一起对齐改造的范围、依赖关系和时间节奏，将项目WBS分发至各产品线。此时项目的需求就进入了产品线的backlog，待产品线梳理清晰后项目需求会被规划至敏捷组的迭代。敏捷团队只要保障迭代事项的正常完成即可。
业务改造大盘总览：为了方便彼此了解各产品线的进展和整体的计划，将所有的产品线改造汇总整理并通过系统管理。这样敏捷团队也不再是流水线上的工人，只了解自己的工作不了解项目的全貌。如图：
项目信息有效分发：整体的项目进展和计划调整通过大群广播，专项群同步，重点人员点对点沟通的方式确保信息的一致。
聚零为整：
进展和风险汇总：项目中各领域的负责人和各产品线的产品经理及SM就是项目信息的汇总收口。他们通过站会等及时了解项目事项的落地情况，项目经理和领域负责人又通过他们快速了解到各项目事项的进展，风险可以被及时捕获。酷立方2.0项目在推进中项目群达到160+人员的规模，信息的单点沟通显然是难以实现的。通过敏捷的运作，项目的信息汇总得到了很大助益。
联合测试整合：项目中有依赖关系的产品线在功能自测完成后，组织联合验收测试，参照整理的功能清单和测试用例，对齐成果差异，并修改。
全链路验收：各产品线的功能开发测试完毕后，由测试负责人根据梳理的测试计划，将上下游关系和业务依赖汇总并组织联合验收，由产品负责人和相关产品确保功能符合预期。除2条产品线发现小修改外，17条产品线beta 环境一次验收通过。
产品联合发布：大部分产品线的发布功能上不存在严格的先后顺序，但是项目涉及到解决方案的新版本上线，功能在外网可用的时间需要一致。因此涉及到灰发的团队需要提前发布，以确保功能在计划时间全部灰完。发布后，线上的验收由主产品协调，汇总各产品线的验证情况。保障了功能上线后的 0 P0 和P1 bug。
双轨并行，双重保障
在酷家乐的项目管理过程中，将项目的WBS分发至各组，化繁为简，化整为零地分解了项目事项，责任明确边界清晰。随着各组产品经理对backlog的管理和迭代计划，项目内容按照计划如期完成，项目仿佛搭着敏捷组的班车，按照两周一个迭代有计划也节奏紧凑的完成了项目的产研内容。我们又通过项目管理方法聚零为整，分批交付，保障了项目的总体目标达成和价值实现。对于敏捷组而言，既减少了资源的浪费，也完成了项目目标。项目管理不再只是项目经理和项目负责人的责任，项目团队中的各产品经理和SM也身兼要任，处处保障，环环相扣。
在软件及互联网行业要快速响应市场的情况下，项目和敏捷可以和谐并进。项目和敏捷开发就像两条火车轨道，有平行、有相交、更有重合。在这两条轨道的保障下，公司得以快速响应市场需求，得以更快、更稳、更准地交付市场价值。