下载掌阅APP，畅读海量书库
立即打开
搜索引擎后台团队，负责淘宝绝大部分搜索引擎海量数据的离线数据运算处理和产出。其数据使用方包括主搜索引擎、一淘搜索引擎、商城搜索引擎、无线商城搜索引擎、图像搜索引擎、促销搜索引擎、店铺内搜索引擎、同店购搜素引擎等。
下图是Dump中心与OA团队的上下游团队关系介绍。
“Dump中心与OA”团队是其中的一个虚拟小组，小组成员如下表所示。
这个团队的负责人以前有过敏捷实践背景，在2011年3月的时候，就开始考虑借鉴Scrum的一些方法，解决当时团队面临的一些问题和挑战。
由于Dump中心与OA团队负责主搜索引擎及其下游相关搜索引擎的离线数据运算、处理和产出（简单说就是为引擎提供搜索数据），因此我们会面对搜索上游的很多需求方（包括产品、运营和技术）提出的业务需求，那么快速响应业务需求的变化、高效开发上线、保证线上生产系统稳定运行的责任，就是我们团队的整体目标和努力方向。
在采用敏捷模式之前，团队平均一个月正式上线一次，每次上线都会包括很多业务和技术驱动的需求，打包一起开发、测试、上线。这样的开发迭代模式表面看上去貌似没什么问题，在运行了一段时间之后，过程改进组对团队上游的需求方（外部客户）和团队内部分别进行了项目满意度方面的调查和反馈。
外部客户：
●不能及时响应业务需求的变化。
作为一个互联网公司的技术研发团队，这样的研发效率和周期显得笨拙和低效，需求方提出需求后，可能要等一个月才能看到效果，对产品的运营和推广也是不利的。时间久了，会降低外部客户对团队的信任度，团队士气也会受到影响。
●把业务驱动和技术驱动的需求打包到一个大的迭代中，一旦其中有一个需求延期无法按时发布，那么整个迭代都有延期的风险。
由于搜索中很多的应用开发都是跨多个团队协同配合来完成的，而且很多业务需求开发都可能修改同一个系统模块，如果一个迭代安排的需求过多，如果一个需求由于各种各样的问题延期，那么整个迭代都会有延期的风险，这种情况和案例屡见不鲜。
说到这里有人会问：“你们每个迭代为什么不少安排一些需求呢？你们为什么不能给需求归类，安排好优先级，对上下游依赖的需求特别关注或者特别对待呢？”，以及其他诸如此类的问题。我要说问得好，这些问题也是后来引发我们认真思考的，而且最终合理地解决掉了。
内部成员：
●一个大的迭代，一次上线需求很多，大大增加了测试的复杂度，系统风险加大，隐藏的Bug不容易发现，而且上线时可能需要更新多个系统模块，生产系统的稳定性受到影响。这种情况下，要想保证上线的质量和生产系统的稳定性，可以说难度是很大的，更多的是依赖开发人员的个人素质和修养，以及测试人员的白盒测试能力。
●有的开发人员抱怨在接到业务方的需求后，有时跟业务方开几次需求沟通会还是不能确认问题，很多时候为了确认一个需求问题，要找很多人，找不到人就要等，拖慢了整体的开发进度，而且很浪费开发人员的时间和资源。希望能有一个人统一来收集需求，细化需求，确认好技术方案和详细设计后，直接交给开发人员开发即可。
●有的开发人员抱怨在遇到上下游团队协同开发的需求时，有时由于依赖的上下游团队无法按期提供开发联调测试接口，导致无法联调测试，以至于无法按期提交测试。
●有的测试同事抱怨，一个迭代包括的需求过多，设计测试用例就会很复杂，而且测试过程中的难度加大，如果一个模块有Bug，开发人员修复重新提测以后，就需要全部重新回归，延长了测试周期，测试风险加大。
●有的测试同事抱怨，由于没有完整的联调测试环境，新的需求提交测试后，无法和上下游系统模块进行联调测试，功能测试是无法覆盖所有测试用例的，模块间接口调用的测试风险加大。
●线上开发运维同事抱怨，每次上线需要更新多个系统模块，上线步骤非常复杂，为了避免对线上系统稳定性的影响，迫不得已需要晚上深夜发布，发布风险加大。而且开发、测试、运维同事都需要深夜加班，影响团队成员的家庭生活质量。
在收到以上这些反馈之后，针对大家提出的问题，研发团队进行了认真的总结和思考，怎样才能更好地解决这些问题，既能让外部客户满意，也能让团队成员满意，在提升研发效率和系统稳定性的同时，还能有效地提升团队成员的生活质量，于是我们制订了一系列的行动和改进计划。
思考中我们发现，要彻底改善现状，不能一蹴而就，需要一个渐进的过程，要先从改善外部环境入手，然后完善团队内部的研发流程，要打通外部循环和内部循环的通道。
改善外部环境，需要考虑以下几个方面：
●梳理清楚搜索上下游的业务流程、团队及其相关接口人，建立一个高效快速的沟通渠道，在遇到上下游联动的问题时，及时找到相关负责人，快速响应并解决。
●建立一个上下游联动的开发和测试平台环境，方便开发和测试同事在这个平台上进行开发联调和集成测试，而不是等到真正预发上线了再联调，把系统联调Bug消灭在预发上线之前。
●外部需求由一个专人来收集整理、分析细化、提供技术方案，详细系统设计之后交给研发团队开发。
●借助流程化管理工具或者相关平台，打通外部环境和研发团队的内外部通道，达到研发流程和进度信息透明、公开开放，具有自动化通知、延期告警和信息报表等功能。
建立和完善团队内部研发流程，需要考虑以下几个方面：
●缩短每个迭代的研发周期，提升研发效率。
●快速响应需求的变化，并承诺需求发布时间，“谨慎承诺，承诺必达”，提升团队的外部影响力和团队士气。
●研发流程的细化和完善，加强流程管理，在保证研发质量的前提之下，提升研发效率。
●提升研发团队成员的生活质量。
综上，Scrum团队适用的流程框架已经形成。
此时敏捷模式的具体实践策略已经初步有了思路，而我们也思考着引入的时机，以及怎么应用才能更容易被团队成员所接受。并且，我们希望能够利用研发项目管理平台，让各个角色的协作更顺畅。同时，和上一级主管进行沟通，以获取认同和支持。
在方案被认可和确认之后，我们并没有马上和团队成员及外部客户宣布改进计划，考虑到团队成员并不熟悉敏捷概念，一下子灌输到每个成员，恐怕效果反而不好，于是我们打算先做起来，再慢慢引入理论概念，在运作顺利并做出成绩之后，再逐步介绍和宣传。
团队整个敏捷方案的实施过程，从空间维度分析，可以分为两个大的步骤。
第一步：改善外部环境，建立上下游一体化平台
① 梳理清楚搜索上下游的业务流程、团队及其相关接口人，建立一个高效快速的沟通渠道，在遇到上下游联动的问题时，及时找到相关负责人，快速响应并解决。
实施过程：
a）首先建立了一个旺旺群、Wiki和邮件组，在梳理搜索上下游的业务流程和团队时，我们会跟每个团队的负责人确认其团队的开发和测试接口人，并把他们加入旺旺群和邮件组中，并要求其注明来自的团队和负责的业务线，这样一来随着上下游联动机制的完善细化，这个虚拟的一体化平台和沟通机制慢慢地建立起来了。
b）把上下游各个业务团队负责的系统接口全部整理出来，整理到Wiki中，描述清楚接口参数细节及相关负责人，各业务团队负责的接口信息由自己负责维护和信息的更新。Wiki信息开放给上下游各个业务团队，方便各个团队的开发测试接口确认和联调。
带来的好处：
a）在这个一体化平台上的任何一个团队有业务问题需要确认或者请求协助的时候，只需要通过旺旺群及时沟通，即可有人快速响应解答，并配合解决。
b）在一个团队负责的系统模块升级更新，需要确认影响范围或者需要上下游联动配合联调开发测试的时候，只需要通过邮件组或者旺旺群快速地定位到各个业务团队的接口人，大大提升了上下游联动的沟通和研发效率，并且降低沟通成本和集成联调测试的风险。
② 建立一个上下游联动的开发和测试平台环境，方便开发和测试同事在这个平台上进行开发联调和集成测试，而不是等到真正预发上线了再联调，把系统联调Bug消灭在预发上线之前。
实施过程：
a）在开发环境单独申请一组服务器，搭建一个搜索共享的开发测试平台，并和上下游业务开发团队自己的开发测试平台打通，形成一个巨大的跨团队开发测试联调平台（Daily日常联调平台）。
b）这个平台要求24小时提供稳定服务，重要级别仅次于生产系统，要求平台上的每个系统都由专人负责开发和维护，保持更新到系统最新版本，分别建立系统层面和软件层面的报警监控，在发生问题时，通过邮件和旺旺消息等方式及时通知相关负责人尽快处理解决。
c）测试同事在这个平台部署和完善系统自动化测试脚本，可以提升系统联调测试和功能回归的效率，并且在测试过程中出现问题，及时地报警通知相关负责人处理解决。带来的好处：
a）在一个团队负责的系统模块开发完成，完成功能测试后，部署到联调测试平台，就可以很方便地和上下游业务系统一起进行联调测试和功能回归，大大降低了系统联调测试的风险，提升研发效率和质量。
③ 外部需求由一个专人来收集整理、分析细化、提供技术方案，详细系统设计之后交给研发团队开发。
实施过程：
a）团队负责人身兼两个角色，ScrumMaster、ProductOwner，负责收集客户（ 来自部门外部、部门内部和团队内部，其中有运营、产品和技术 ）的需求（ 业务驱动和技术驱动 ），整理、沟通讨论、分析细化，结合对技术架构的理解，为客户提供合理可行的技术方案，并把详细的设计文档和需求一起交给研发团队评审和实施。
b）作为ProductOwner，一项重要责任是要分析客户需求的合理性和复杂度，以及对技术框架的冲击，对于不合理的需求，需要跟客户解释原因，和客户一起商量找到对大家都有益的解决方案。
c）需求根据规则（主要规则有：1.业务驱动需求优先；2.客户设定的需求优先级；3.客户期望需求完成时间；4.同类需求合并）放到IFree（研发项目管理平台）上的ProductBackLog（需求列表）中，编排将要进入下一期Sprint的需求。
④ 借助流程化管理工具，打通外部环境和研发团队的内外部通道，达到研发流程和进度信息透明、公开开放，具有自动化通知、延期告警和信息报表等功能。
实施过程：
a）借助过程改进团队提供的研发项目管理平台（iFree），开放需求提交快速通道给客户方用户使用，用户提交新需求时，可以设置需求执行的团队、需求的重要级别（A、B、C三级）、需求的优先级（P1～P4）、业务需求负责人、客户期望需求完成的时间等信息。需求提交后会有专属邮件发送给需求执行团队的负责人。
b）在需求被研发团队确认后，进入研发状态，会有邮件通知需求方。
c）需求在研发完成、提交发布申请时，会通过邮件和消息的方式通知相关负责人进行会签，会签通过自动生成上线申请单和上线预约通知邮件，周知上下游团队的负责人或者接口人。
d）在需求按期发布完毕或者延期时，需求方也会收到相关通知，要求其进行需求的验收或者确认。
第二步：建立和完善团队内部研发流程
① 研发流程的细化和完善，加强流程管理，在保证研发质量和生产系统稳定的前提之下，提升研发效率。
实施过程：
a）ScrumMaster根据需求规则和团队可用的开发、测试资源数量，编排Sprint需求，召开ScrumMeeting进行需求的评审和资源分配，设定开发计划，确保每一轮Sprint迭代保质保量地稳定上线发布。同时向客户方承诺上线时间，客户方可以同时准备产品需求的推广和后续运营工作。
b）核心原则：等边三角形（资源、时间、产出）原则，在资源和时间确定的情况下，努力带领团队一起做到最大的产出。
② 缩短每个迭代的研发周期，快速响应业务需求的变化，及时开发上线，提升研发效率，最大程度上支持业务的发展。
实施过程：
a）每个Sprint迭代从原来的三周调整为两周，正常情况下，一个Sprint迭代周期为两周。
b）随需而变，在需求紧急的情况下，灵活将Sprint迭代调整为三周两个迭代或者一周一个迭代。
c）每个Sprint迭代可以支持紧急需求的插入，并快速上线。
d）Scrum团队的开发成员可以和基础平台团队的开发成员轮转，在完成需求开发之后，或者没有被安排到需求开发，可以转到基础平台团队支持底层框架的开发；在需求多而开发资源又紧急的情况下，基础平台团队的成员也可以进入Scrum团队进行业务需求的开发。
③ 快速响应需求的变化，并承诺需求发布时间，“谨慎承诺，承诺必达！”
实施过程：
a）每轮ScrumMeeting之后，进入Sprint迭代的需求列表被确定下来，ScrumMaster会发出本轮Sprint迭代的KickOff邮件，在邮件中会承诺列出进入本轮迭代的需求列表、需求负责人、需求概要描述，以及Scrum团队的研发计划和具体的预发布、正式上线的时间点。
b）KickOff邮件会周知本轮进入迭代的需求方和整个研发团队，以及相关的接口人。
c）KickOff时承诺Sprint的上线时间，意味着我们整个团队对外部客户做出了承诺，一定会按计划保质保量地发布上线，让客户可以同时开始准备产品的推广和运营准备工作。
④ 提升研发团队成员的生活质量。这个需求不仅带表了Scrum团队成员的心声，而且关系到团队的稳定，老板们也非常重视。
实施过程：
a）每轮Sprint迭代都有2～4个发布窗口，将涉及同一模块更新的需求一起发布，利用多个发布窗口，分开交错发布，可以有效地降低单次发布的系统更新量和系统升级的风险。比如业务驱动的需求和技术驱动的需求分开发布等。
b）根据对系统架构的掌控，以及升级对线上系统造成的影响范围不同，可以将不影响数据实时性、正确性和系统正常运行的需求白天发布，反之则考虑在晚上发布，可以降低系统升级对线上用户体验的影响。比如，全量Dump每天凌晨运行一次，可以考虑白天发布，第二天凌晨自动生效；增量Dump如果升级的内容不涉及系统数据结构的改动，只是数据内容或逻辑的更新，也可以考虑在白天上线，反之则需要在晚上发布。
团队整个敏捷方案的实施过程，从时间维度分析，又可以分为三个大的阶段。
第一阶段：基础构建阶段
a）解决上下游各个业务团队高效沟通的问题梳理清楚搜索上下游的业务流程、团队及其相关接口人，建立一个高效快速的沟通渠道（旺旺群、邮件组、wiki等等），提升沟通效率，快速响应并解决遇到的问题。
b）解决上下游各个业务团队集成、联调、功能回归等开发测试方面的问题。
建立一个上下游联动的开发和测试平台环境，方便开发和测试同事在这个平台上进行开发联调和集成测试。
c）解决上下游各个业务团队对本团队负责业务和问题咨询，快速响应和解决，提供一个统一开放的问题响应解决渠道。
团队建立统一的旺旺账号，公开给上下游各个业务团队，团队成员轮流onCall，为外部客户提供业务和问题的咨询、反馈和解决。
d）团队研发流程的梳理，挖掘可以优化的点，分批逐步优化。
第二阶段：初期运行阶段
尤其是在团队从来没接触过敏捷开发模式或者对理论概念不了解的情况下，可以由一位资深的项目管理专家（ 这个人要求有丰富的项目管理经验，还要对业务知识和系统架构非常了解，对个人能力要求比较高 ）担任团队的ScrumMaster和ProductOwner，来带领团队慢慢进入敏捷的开发状态。初期建议不要给团队成员灌输大量的敏捷理论知识，可以考虑先做起来，然后慢慢影响团队的成员并逐步介绍敏捷的概念和技巧。
a）团队研发流程的梳理、优化和规范化。
b）团队的磨合及人员的培养，可以选择具有一定沟通和协调能力，有责任心、积极性高的同事进行培养，作为未来团队ScrumMaster的继任者。
c）团队外部影响力的逐步建立。
第三阶段：稳定运行阶段
a）团队内部已经逐步熟悉、掌握敏捷方面的知识和技巧，可以适应每个迭代循环的研发周期，能够清楚地知道每个迭代自己要承担的责任，简单来说就是什么时间需要完成什么事。
b）团队内部的磨合已经完成，人员已经培养起来了，ScrumMaster可以交给继任者担当。开始的时候，我们可以给新的ScrumMaster一段时间的支持和帮助，让他明确一个合格的ScrumMaster的职责范围，然后慢慢放手，逐步退出Scrum团队内部研发流程的管理。
c）我们将精力重点放在ProductOwner的角色上，对于外部需求的把控对于一个成熟的Scrum团队来说非常重要。如果接到的需求没有很好地精细设计，有可能对系统技术框架带来巨大的冲击和影响，系统框架后续的扩展可能将会非常被动；对需求进行有效的规划安排，可以帮助每轮Sprint迭代稳定有序地正常运转，可以降低延期风险。
d）打造团队外部的影响力，提升团队士气和信心。
主搜索生产应用开发敏捷、高效、稳定，大大提升了主搜索应用开发的效率，提升了客户满意度和团队信任度。更重要的是，这个团队在敏捷实践上的成功，改变了大家对敏捷的认识，成为一个被同部门其他团队学习的标杆，团队内部的凝聚力也显著提高了。
在2011年下半年，抓取小组的同学找到我们，希望能给他们做一次关于Scrum的培训。于是我们先和他们的主管进行沟通，了解他们的现状及尝试Scrum的出发点。
在沟通中，我们了解到，这个团队主要做数据抓取部分的功能开发，他们的挑战是：
●需求方众多，有多个产品经理会直接给他们提需求，同时也要接别的技术团队（上游）转过来的需求，而彼此间无人能统一给出需求的优先级。
●开发团队新人多，5个开发，2个测试，其中3个人是新入职的，带人的成本高。
●需求方变更多，且对上线时间要求“快”，随时加进来的需求总是打断开发的进度，欲速则不达。
●上线频繁，新手多，容易发生线上故障。
他们看到别的团队在实践Scrum后，需求开始逐步有序，并且能降低被需求提出者“随时”打断开发的干扰，且其中一人对Scrum有过了解（没有实践），于是大家决定尝试迈出这一步。
结合上述背景情况，我们考虑到当时团队的接受能力，建议先解决需求优先级及开发节奏的首要问题，请团队主管先确定下述几项：
●谁来做PO——解决需求优先级的问题。
●谁来做ScrumMaster——负责引导团队一起实践。
●如何管理这些需求，如何反馈进展。
●Sprint的周期是多长最为合适。
●Stand Meeting的时间和地点。
●每个Sprint结束，都应该开Review Meeting。
由于需求方众多，在无法让需求方互相PK优先级的情况下，技术主管主动承担了这个任务，即任何需求提交，需要通知他，由他做优先级的判断，由他和需求方沟通，推动需求方对优先级的认同。
关于需求提交的形式，以及如何跟踪，之前的做法因为从没有要求过，因此，大多数需求通过邮件提交给研发团队，小一点的需求就是通过旺旺或者口头告知。研发团队通过团队周报、会议、口头的形式，反馈每周需求的状况和问题。
对此，建议团队尝试利用我们今年自研的iFree工具管理需求，好处就是让需求方有个统一的地方提需求，开发有统一的地方管理这些需求和优先级，分配开发资源和制订计划、维护需求的状态。这一点，无论是需求方，还是研发，都是支持的。
我们对Sprint周期做了一些说明，可能对敏捷中“时间盒子”的概念没有重点要求，但是会建议研发团队能固定周期，有利于控制需求和开发的节奏。大家很容易地否定了以一个月为一个Sprint周期的念头，开始纠结于一周一次，还是两周一次。为什么如此呢？原来研发团队认为，需求方总是希望提出需求能立即响应，快速上线，如果一周一次，那么每周都会上线，让业务看到效果；如果两周一次，则最快也是隔周上线能看到效果。我们举了几个其他团队关于迭代周期的实际例子，用于帮助团队侧面去分析不同迭代周期可能产生的管理成本和产出效果，最终，大家一致认可两周一次迭代，并且，也取得了需求方的支持。
第一个Sprint结束后，过程改进人员和抓取小组一起做了第一次Review Meeting，过程改进人员担任主持者，主导这次总结。
我们采取的形式是：提前准备白板和便笺纸、笔，让每个参与者在便笺纸上写下他/她认为本次Sprint中做得好的、做得不好的，每个纸上只写一点。随后，过程改进人员收集大家写好的便笺纸，贴在白板上，同类问题放在一起。我们发现，关于“好”的方面，大家有着相同的评价，诸如目标明确、需求有序之类；关于“不好”的方面，便笺纸也有很多，却不尽相同。摘取这个总结的记录分享一下：
“今天大家对Sprint1进行了总结，大部分成员都是第一次进行Scrum开发，体会比较深刻，以下是大家的个人体会和建议。
体验出Scrum开发模式的好处：
●开发目标更为明确和具体，从而提高了开发效率。
●上线任务更加明确，没有那么混乱。
●测试工作更明确，更容易计划。
建议需要完善的步骤：
●计划会上对User Story 进行任务拆分，由开发人员来认领。
●计划会上给出明确的提测时间，方便测试人员准备。
●测试人员也参与Plan Meeting和Stand Meeting。
●测试人员需要接触PD，直接了解需求，方便测试Case设计。
●开发提前准备设计文档，测试人员可以参考。
●开发人员参与对测试Case设计进行Review。
●开发人员自身加强单元测试做自测。
下一次Sprint需要落实的改进点：
●计划会上对User story 进行任务拆分，由开发人员来认领。
●测试人员也参与Plan Meeting和Stand Meeting。
●计划会上给出明确的提测时间，方便测试人员提前准备。
●开发人员参与对测试Case设计进行Review。
上面这个总结里面会提到关于任务拆分、测试的介入方式等，产生这些改进是因为第一次Sprint中，对于这些细节还没有完全让团队掌握这些方法，我们一直采用的是逐步渗透、逐步改进、自我改进，帮助团队自我意识到这些环节的重要性，从而主动实施改进，在这个过程中效率和意愿都比被动改进更高。