百度移动端项目敏捷开发实践

Posted 2021-04-25 前端下午茶

    在夯实移动基础、决战AI时代的百度战略下，百度APP承担着夯实移动基础的重任。2018年起，工程效能部以交付加改进小分队的形式进入百度APP，联合PM、UE、RD、QA承担百度APP版本、重点Topic交付加改进的工作。

一、百度APP介绍

    百度APP是一款历史悠久，深受用户欢迎的搜索和资讯客户端，自2011年由“掌上百度”发展到2014年“手机百度”，于2018年正式更名为”百度APP“。

    现在百度APP作为以内容为主的容器，帮助用户完成内容消费和服务体验的全流程，建立起在移动时代连接人与内容及服务的入口；未来，百度APP将从连接信息到连接万物，蜕变为人与世界沟通的入口！

    面对承担如此重要的历史使命，百度APP团队将面对怎样巨大的挑战？背后涉及到的多体系、多部门、多角色，项目管理又是如何在其中扮演何种角色？和小型项目相比，大规模的项目管理是如何运作的？下面我们将以项目管理的视角切入如此大的项目中。

二、 准备期-理解特点与挑战

    为了更好的理解百度APP，进入前期，就进行了从业务、架构、组织、流程各个方面的梳理，从而从整体认识了百度APP的特点，以及面临的挑战。

1、梳理组织架构

    团队涉及百度内多个体系，生态内外多个部门，六个角色累积人员规模千人+。

    注：Topic：百度APP独立具体业务，比如小程序就是一个单独的Topic，类似的Topic还有Feed、小游戏、社区等等；

2、了解业务架构

    整体划分为：以基础建设的底层容器、百家号与小程序的承载形式、信息流和搜索与社区的分发模式、图文视频为内容的垂类细分业务。

3、理解特点与挑战

    从组织架构上来看， 近千人规模的跨体系、跨部门、人员角色复杂，沟通成本和协同作战压力山大。从业务上来看，Topic较多且有耦合，更有跨Topic需求，全流程涉及多系统含10+个环节。

三、规划期-建立整体管理方案

1、确定目标

    结合百度APP特点&挑战，建立规模化敏捷管理框架，实现整体闭环管理；提升研发效率，降低各个角色之间Handover成本，加速业务价值交付。

2、解决方案

1）整体思路

    由于整体规模较大，且有区分Topic，所以整体进行了分层管理；为了持续迭代产品，优化流程，在分层管理的同时实施闭环管理；

分层管理

确定项目组合层、Topic层、团队层，明确各层角色、流程，落实到 iCafe，实现工具固化
•项目组合层：解决跨Topic的需求优先级问题，以及确定版本重点需求的问题
•Topic项目群层：拉通Topic各个角色、各团队，实现跨组织、跨团队的面向Topic业务价值的管理
•团队层：实现组件团队的管理

闭环管理

•需求收益闭环：需求上线有收益回顾
•版本闭环：版本上线有回顾总结

2）建立规模化敏捷管理框架

    每层分别对应不同流程，最后形成三类发布火车：

• 例行随版版本需求，每三周发版

• 对于需要配合运营活动、重大事件，增加三周中间小版本

• 针对非随版需求实施流式发布

3）管理方案

    建立整体管理策略，实现整合管理，我们从如下几个方面介绍整体的管理策略：

• 整合管理：明确各级角色，建立各级流程、DOD(Definition of Done) 标准与度量；实现需求闭环与版本闭环；建立面向Topic的需求管理解决方案；

• 时间管理：建立三周发版节奏，建立整体发版心跳，使得各项工作有预期；

• 范围管理：根据需求插入时间，明确不同原则，使得需求变更有序进行，降低整体风险；

• 质量管理：升级质量标准，明确各项工作准入和准出，内建质量；

• 干系人管理：建立整体沟通地图，降低跨部门沟通成本；

• 沟通管理：建立整体沟通机制，实现团队内、Topic内、跨Topic整体协同；

• 风险管理：分级风险管理；

• 人力资源管理：建设交付团队，落地管理机制；

四、落地期-具体管理策略与落地

下面对整合管理、时间管理、范围管理、干系人管理、沟通管理，几个具体管理策略进行一下介绍；

1、整合管理

1）版本闭环：实现版本整体业务、技术需求闭环管理

    定义项目组合层-版本层的：

• 主要角色与职责，解决跨Topic需求优先级问题，实现整体版本的闭环管理

• 版本级别各个流程与准入准出的要求，内建质量

• 主要度量，实现量化管理，驱动持续改进

2）Topic闭环：明确Topic项目群层的主要角色、职责、流程与度量，实现各Topic 业务、技术需求闭环管理

3）团队闭环：明确团队层流程与度量，实现团队需求闭环管理

4）面向Topic的需求管理：落地与固化整体流程方案，解决Topic依赖管理与Topic内多端管理

主要思路：

• 空间设置：统一百度APP各个Topic整体空间，每个Topic一个子空间，每个子空间建立随版与非随版不同计划，再建版本计划

• 固化流程：通过Feature卡片固化Topic流程；通过Story卡片固化团队流程

• 卡片层级：Epic为业务规划，Feature为端到端需求，按照团队拆分Story，RD拆分task细化工作

• 团队视角：通过不同层级查询，支持团队视角

2、时间管理：建立三周发版节奏，实现整体可预期

• 3周固定发版

• 需求前置，实现上个版本灰度期间下个版本视觉发布结束

3、范围管理：不同阶段不同插入需求策略，使得需求变更有序、高效进行

•插入节点1（开发启动前）：需求正常走LR流程后，按优先级Topic开发排期。
•插入节点2（需求开发测试阶段）：
             Follow Topic内部需求插入流程。原则是排定优先级，研发、测试角色评估，如果超出容量，置换低优需求；
•插入节点3（上车截止，封版之后）：
             需要发送插入邮件申请，并之前与涉及研发、测试角色评估此需求对版本影响，给出初步结论；

4、干系人管理 ：建立整体沟通地图，实现凡事 有接口人可联系

• 梳理Topic，梳理主要角色

• 各角色/各Topic分别反馈对应的负责人

• 定期例行更新

5、 沟通管理-重要事件：建立整体闭环，实现整体管理可视化，加速问题解决与风险暴漏

• 确定各个层次主要事件，实现整体闭环管理

五、整体效果

    通过建立整体的项目管理框架，实现了千人团队的协同，实现了版本初期优先级决策时间的有效降低，实现了整体的闭环管理。对发版周期、频率及时间成本进行了有效提升。

至此关于百度APP这样一个大规模的研发项目管理方案便整体展现出来。

---

❤️ 看完三件事

如果你觉得这篇内容对你挺有启发，我想邀请你帮我三个小忙：

1. 点个「在看」，让更多的人也能看到这篇内容（喜欢不点在看，都是耍流氓 -_-）

2. 关注我的博客 https://github.com/SHERlocked93/blog，让我们成为长期关系