本文做者：HelloDeveloper分布式
InfoQ 和百度共同举办的第七期百度技术沙龙中，特邀嘉宾百度项目管理部高级工程师宋金永和淘宝搜索广告引擎团队的 Scrun Master 邹磊与参会者分享了各自的敏捷开发实践经验。本文将简要总结了他们的演讲内容，并提供相关音视频、演讲资料下载。工具
首先是百度项目管理部高级工程师宋金永给咱们分享他们引进敏捷后，结合自身实际作出一系列准备和推动过程当中的体验。性能
百度技术团队在开始引进敏捷的时候，你们也在疑惑敏捷会水土不服吗？但其实敏捷是一种思想，主要包括沟通、简单、反馈、勇气等四个要素。敏捷思想的核心精髓是小胜 + 反思，这和百度的价值观有些相似，即简单，可依赖。另外百度技术开发还有另一个原则：迅速迭代，越变越美，容许试错等也与之相吻合。因此，总体上来讲，百度一向坚持的文化核心和技术开发原则与敏捷思想的精髓是一致的，水土不服的问题是不存在。单元测试
那么在开始正式实施以前，百度技术团队作了哪些准备呢？测试
简单来讲，先是对照敏捷的思想，找出本身的优点，好比项目基本都是迭代开发，也执行了分级；测试实现部分自动化；具有项目管理和开发平台；拥有简单可依赖的文化等。而后再找出本身的不足，好比迭代规划方法不太合理；项目沟通与协做机制有待增强；存在一些低效的流程环节；单元和自动化测试在工具方法上欠缺；强化的组织结构影响团队目标的一致性等。最后，在发现本身的优点和不足后，肯定目标，找到最佳突破点。经过以上分析，他们最终找准了本身引进敏捷的目标——提高效率。同时也找到了两个关键切入点，一是充分发挥人的主动性和能动性；第二就是创建自适应方法集和项目管理体系。就这样，最终的结果就是，经过一系列的调研他们把握住了真正须要提高的核心，取得了上级领导的支持，开始了试点并逐步扩大。优化
那他们又是如何推动敏捷实施的呢？搜索引擎
他们针对业务需求型和技术型项目分别采起了不一样的措施：针对业务需求型项目统一团队目标，优化需求管理，提升流程效率的方式；而对技术型的项目则在单元测试、自动化回归等方面作功夫。spa
固然在执行的时候也碰到了很多问题，但由于事先准备的充分，也都一一被有效的解决掉。最后他对百度引进敏捷后带来的变化进行了总结，第一，引进敏捷以后，原有的 SQA 团队转型成项目管理结构，造成一个坚强的组织来实现敏捷开发；第二，在产品的研发效率和改进思想上找到一些具体的点，让他们变得更有体系。设计
在演讲报告的问答环节上，听众对如何创建目标团队一致上和项目部如何才能落实提出了疑问。宋金永作了这样的回答：code
百度在创建目标团队一致上有不少作法，其中把相关强职能部门结合成一个事业部的作法最有效果，固然不是全部强职能部门都适合这样，对仍然须要强职能部门分布式团队的产品线，没有具体的一我的负责的时候，就引入一个有效的活动或者方法来完成。另外就是项目部的必须有一个至关的地位，否则太末端的话，项目管理部不可能充分的发挥其职能。
以后是在淘宝广告搜索引擎团队的邹磊和咱们分享了 Scrum 在他们团队中的实施状况，以及做为一名 Scrum Master 在整个 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 的互动环节由衷的喜好。