百度技术沙龙第 7 期回顾：敏捷开发实战分享（含资料下载）

InfoQ 和百度共同举办的第七期百度技术沙龙中，特邀嘉宾百度项目管理部高级工程师宋金永和淘宝搜索广告引擎团队的 Scrun Master 邹磊与参会者分享了各自的敏捷开发实践经验。本文将简要总结了他们的演讲内容，并提供相关音视频、演讲资料下载。

首先是百度项目管理部高级工程师宋金永给我们分享他们引进敏捷后，结合自身实际做出一系列准备和推进过程中的体验（音视频、演讲资料下载见百度敏捷之旅）。

百度技术团队在开始引进敏捷的时候，大家也在疑惑敏捷会水土不服吗？但其实敏捷是一种思想，主要包括沟通、简单、反馈、勇气等四个要素。敏捷思想的核心精髓是小胜 + 反思，这和百度的价值观有些类似，即简单，可依赖。另外百度技术开发还有另外一个原则：迅速迭代，越变越美，允许试错等也与之相吻合。所以，整体上来说，百度一贯坚持的文化核心和技术开发原则与敏捷思想的精髓是一致的，水土不服的问题是不存在。

那么在开始正式实施之前，百度技术团队做了哪些准备呢？

简单来说，先是对照敏捷的思想，找出自己的优势，比如项目基本都是迭代开发，也执行了分级；测试实现部分自动化；具备项目管理和开发平台；拥有简单可依赖的文化等。然后再找出自己的不足，比如迭代规划方法不太合理；项目沟通与协作机制有待加强；存在一些低效的流程环节；单元和自动化测试在工具方法上欠缺；强化的组织结构影响团队目标的一致性等。最后，在发现自己的优势和不足后，确定目标，找到最佳突破点。通过以上分析，他们最终找准了自己引进敏捷的目标——提升效率。同时也找到了两个关键切入点，一是充分发挥人的主动性和能动性；第二就是建立自适应方法集和项目管理体系。就这样，最终的结果就是，通过一系列的调研他们把握住了真正需要提升的核心，取得了上级领导的支持，开始了试点并逐步扩大。

那他们又是如何推进敏捷实施的呢？

他们针对业务需求型和技术型项目分别采取了不同的措施：针对业务需求型项目统一团队目标，优化需求管理，提高流程效率的方式；而对技术型的项目则在单元测试、自动化回归等方面做功夫。

当然在执行的时候也碰到了不少问题，但因为事先准备的充分，也都一一被有效的解决掉。最后他对百度引进敏捷后带来的变化进行了总结，第一，引进敏捷之后，原有的 SQA 团队转型成项目管理结构，形成一个坚强的组织来实现敏捷开发；第二，在产品的研发效率和改进思想上找到一些具体的点，让他们变得更有体系。

在演讲报告的问答环节上，听众对如何建立目标团队一致上和项目部如何才能落实提出了疑问。宋金永做了这样的回答：

百度在建立目标团队一致上有很多做法，其中把相关强职能部门结合成一个事业部的做法最有效果，当然不是所有强职能部门都适合这样，对仍然需要强职能部门分布式团队的产品线，没有具体的一个人负责的时候，就引入一个有效的活动或者方法来完成。另外就是项目部的必须有一个相当的地位，不然太末端的话，项目管理部不可能充分的发挥其职能。

之后是在淘宝广告搜索引擎团队的邹磊和我们分享了 Scrum 在他们团队中的实施情况，以及作为一名 Scrum Master 在整个 Scrum 实施过程中的困惑和思考。（音视频、演讲资料下载见 SCRUM 在淘宝搜索广告引擎团队的实施）

淘宝广告搜索引擎团队的业务特点非常适合 Scrum 的开发模式，在演讲的一开始邹磊就向我们介绍了他们团队业务的特点：

支持的业务多；需求变化频繁；产品发布频繁；对产品的稳定性和性能要求高等。

针对他们业务的特点结合 Scrum 模式，他们团队分成四个部分：产品经理、开发团队、测试团队和 PE 团队。开发流程分为四个阶段：需求、设计、开发和上线。

在需求阶段，产品经理提出具体需求，根据优先级进入需求池；开发团队确认项目经理统筹安排，结合产品经理、开发和测试团队进行需求和功能的罗列，三方通力合作，进行功能列表的 review，做出设计计划，并邮件通知全体。进入设计阶段，项目经理建立项目 twiki，设计人员开始进行迭代 review，达成一致后，项目经理组织全体人员进行 review，随时把出现的情况通知到相关负责人。一切妥当之后，设计人员开始开发阶段，对项目进行人日估算，包括开发、code review、开发测试、开发人员内部集成测试等，调动资源，确认项目时间。上线前一周，项目经理通知 PE 团队，做好上线前的准备，进行风险评估、冒烟测试等工作，确保产品完成上线。

整个实施的过程可以说是痛并快乐着，刚刚开始的时候，各个环节都不同的存在着这样或那样的问题，晨会、项目计划会、code review、设计、项目总结会都不同程度的存在着不和谐。不断的发现问题不断的解决问题，痛苦与快乐交织并存。

最后，邹磊提出了他作为 Scrum Master 在工作中的困惑：

目前他 70% 的时间在做开发，不知业内是不是其他 Scrum Master 也这样做；还有 SCRUM 讲究主动性，由团队成员领取任务，但是将最合适的任务分配给最合适的人，是不是就是最佳的方式？另外就是无法估出复杂项目的准确人日，给团队带来负面的影响的困扰等。

在最后的互动环节里，有人问道 Scrum Master 的技术操作和背景以及项目如果是两地合作的话应该怎样处理的问题，邹磊一一做出了详细的回答：

在我们的部门里 ScrumMaster 的开发任务是偏重的，了解很多 Scrum Master 都存在这样的问题。Scrum Master 不一定是部门里技术背景最强的，但是必须要对产品线有充分的了解，以及对团队人员的熟悉，否则会影响对整个开发时间的统筹。 至于两地合作项目问题，他们自己就是在杭州和北京并行，许多项目就是两个地方的技术力量合作完成的。这就牵扯的项目经理责任制，解决办法就是会议和邮件。他个人偏向邮件，通过邮件把进度点公布给相关人员，尤其是领导们知道，更有利于自己开发的进展，也有利于大家对进度的把握。

此次会后，有些参会者在博客上发表的自己的感受，比如来自“绿城社区”的一篇博客：作者感觉这样的活动丰富了自己的周末生活，文中写道：“而最吸引我的，是沙龙中的 Open Space 环节，极富互动性！”。可以看出作者对 OpenSpace 的互动环节由衷的喜爱。