作者简介
黎娟，去哪儿过程改进总监。15年软件项目管理及过程改进经验，曾先后就职于雅虎中国/阿里巴巴、腾讯、去哪儿网，擅长问题分析以及基于问题驱动的过程改进。本文来自黎娟在“携程技术沙龙——敏捷总动员”上的分享。“敏捷”这个词近几年非常火，经常会有人问：“我们应该怎样开始做敏捷？”或者：“能不能来帮我们推一下敏捷？”这种问题我通常都不敢轻易回答——敏捷有很多实践，管理的、工程的都有，但敏捷绝非我们看到的站会、持续集成、TDD等那么简单，真正的敏捷体系是从理念到文化的一次变革。
所以具体到一个团队，究竟为什么要做敏捷，能够多大程度地承受改变所带来的痛苦和风险，本质上还是需要自己先想清楚，我们要解决的问题或者期望的价值究竟是什么，再来判断应该做什么以及怎么做。
这里分享几个敏捷相关的过程改进案例，希望能够给到大家一些可以借鉴的东西。
案例一：灵活地响应变化
两年前我在酒店事业部做支持的时候，有一次同一位产品总监聊天，他向我抱怨，说：“技术团队怎么有那么多的项目延期？他们能不能靠谱一点，至少给我的周计划里，承诺要完成的事情应该做到吧！”
我反问了一个问题：“那作为一个产品总监，你能不能保持你的团队一周内的需求不改变呢？”
他想了想说：“我做不到。”
我们相视一笑，很容易就达成了共识——我们不能指望不变或者少变，而是要提升整个团队的应变能力，去响应甚至拥抱变化。
那么怎样才能提升团队响应变化的能力呢？
首先，要建立良好的可视性——能够清楚地知道每个人每天都在做什么，进展如何，何时能完成——这样在发生变化时，我们才知道应该安排谁、什么时候去做是最合适的。
所以我们做story/task的拆分，并搭建看板，展示每个人的工作；再通过站会沟通进展以及问题，保证信息每天都能得到更新。
图一：一个典型技术团队的看板
其次，要提升变更决策的效率——我们要让有价值的变更能够快速地得到实施，首先要有个快速且有效的决策机制。那么应该由谁来做这个决策呢？决策人级别太高，决策效率会低；决策人级别太低，又担心水平不够，不能服众。我的观点是“让具备这个能力的、级别最低的人来做”——资深人员能做就不要让leader做，leader能做就不要让总监做，总监能做就不要让VP做。有做的不对或者不好的时候可以升级问题，但不要一开始就把职责都定在管理者身上。
所以我们引入了PO（ProductOwner）的概念。为每个团队指定一个PO，他/她负责接收所有的需求、判断价值和优先级；如果有需要的话，还要帮助其他产品经理做系统的需求分析。大部分团队的PO都是资深的产品经理；但也有小部分技术团队，由于对应多个需求方，最后技术leader自己做了PO。在实践中我们发现资深的产品经理和技术leader都能把PO这个角色做的很好，需要升级到管理决策的情况非常少。
最后，要降低变更管理的成本——变更过程中最令人感到痛苦的事情，就是re-plan。一般来说，如果只是调整当前项目的计划，还相对比较容易。但由于项目延期或者对人员的时间占用增加，通常会导致其它项目的等待或延期，这种情况沟通起来就比较费时费劲了。更糟糕的是，技术团队已经对计划做出了承诺，“客户”就会很愤怒：“你们这帮人怎么这么不靠谱，承诺的事情为什么老是变！”所以很多技术leader会倾向于拒绝变更，他们会说：“你们先去走个流程！”“你们先去找VP审批一下！”
所以我们转变做计划的思路，从承诺everything转向只承诺当前优先级最高的事情；从“事推动人”转向“人拉动事”——也就是说我们尽量让每个人都工作在优先级最高的事情上；做完一件事情，再去需求队列里取当前优先级最高的；再完成之后，再去取下一件……如此循环。这样我们就把对变更的决策与制定工作计划这两件事情“解耦”了，让整个团队都能够聚焦在变更所带来的价值，而不是痛苦和折腾的过程。
关于如何制定工作计划（就是我们通常说的“排期”），这里推荐一个实践——每天上午站会结束之后，会有一个小型的计划会议（planning meeting）。如果前一天有人交付了手头的工作，就留下来参加计划会议，leader会综合待排期的需求优先级、当前人员的能力等因素安排他们的工作。原则上已经开始开发的工作尽量不要中断，除非有特别紧急的事情，leader会暂停部分相对低优先级的工作，抽调人手响应紧急情况。一个10人以内的团队，平均每天花费的时间不会超过15分钟。
这个案例是最轻量的敏捷实践，在不改变组织结构和工程流程的前提下，能够以最低的成本实现灵活的应变能力。这也是目前在金融事业部和大住宿事业部绝大多数团队所采用的实践。
案例二：高效地沟通与协同
有一天，专车事业部的一位总监找到我，说：“我们也很想做敏捷，你们能不能来帮个忙？”于是，我安排了一位同事去支持这个团队。
她去到这个团队，开始尝试用我们一贯的方法，帮助团队搭建看板、开站会，却发现几乎所有的leader一致认为站会是没有意义的——他们曾经尝试过，最后发现每日沟通花费了时间，但却并不会给他们的工作带来多大的帮助，于是都放弃了。
为什么在那么多团队行之有效的实践，到了某些地方就失效了呢？
经过调研，我们找到了问题的答案——要找对需要在一起沟通的人，这比沟通的形式更重要。
专车的这个团队是个典型的app开发团队，分为ios、android和服务端开发三个组；维护着两个主要的产品，分别是给用户下单用的“用户端”和供司机抢单用的“司机端”。
当我们按照组织结构召集一个团队开会的时候，团队成员之间由于工作的相关度不高，所以并不太关心其他人干了什么，虽然站会时间不长，可大家觉得没有价值，是在浪费时间。
而当我们将团队重新组合之后，按照产品线划分成司机端、用户端和纯服务端三个团队，每个团队都包括PM、各种DEV以及QA。调整完之后，大家沟通的积极性马上就高了起来，因为大家是共同在做一件事情，是上下游的关系，相互能够给对方提供信息并解决问题。
最终我们其实只做了一件事情，就是建立了一个完整的交付团队（也就是通常人们说的“敏捷团队”），所有的实践就顺理成章地实施起来了。从这里我们可以看到，敏捷的团队，是比敏捷的流程或者实践更重要的东西。
那么，什么样的团队，才能算是一个敏捷的团队呢？Mike Cohn给出过9个问题，用来判断一个团队是否“结构优良”，有兴趣的同学可以去看相关的资料。这里给出几点我认为最重要的特点：
第一，要有交付能力——能够独立交付完整的业务功能，这是一个敏捷团队的最基本的特性。这就意味着团队必须包含交付所需要的全部角色（一般至少要有前后端开发、测试），或者具备全部角色的能力。
第二，要“高内聚，低耦合”——团队所承接的需求，大部分都应该能在团队内部完成，对其他团队的依赖应该是少量的或者简单的；同时，应该尽量避免两个以上的团队共享一个成员的情况。这样才能进一步地减少等待以及各种管理的浪费，保证快速交付的能力。
第三，要保持小团队——团队太大会降低沟通效率，增加管理的浪费；而小团队则更容易保持对目标的专注并形成凝聚力。一般认为7加减2是比较合适的范围。
第四，要足够长期——团队需要一定的时间去形成统一的规则和文化。一个新团队度过磨合期通常至少需要2-3个月的时间，而要想在这个基础上形成自组织、自管理的团队文化，则需要更长的时间。只有成熟度非常高的组织（团队文化和基础设施都高度成熟），才能频繁地变更团队的组成而不破坏团队文化。
这个案例是中等程度的敏捷实践，从过程改进的角度来看，仍然是属于渐进式优化的做法：在保持组织结构不变的基础上，按照业务和产品的结构划分出“虚拟的”交付团队。在这个团队里，各种角色能够频繁地、一致地、充分地交流，及时发现和解决的问题，从而快速交付产品功能，实现业务价值。对这个实践目前执行到位的团队并不多，主要的原因是很多FE和QA团队作为“公共资源”没有与DEV进行对应的分拆，无法形成完整的交付团队。
案例三：目标一致的团队
去年下半年，我们在一个部门做支持的同学跟我反馈，说她觉得团队的流程在退化：原本分拆了的FE和QA团队又合回去了，团队从原本的每日排期变回了周排期。跨团队的项目越来越多，沟通、协调的过程也越来越复杂。整体的可视性在下降，管理的浪费在增加，当前虽然还没有明显的问题，但长期发展下去团队的整体交付能力会下降。
当时我们的CTO正好坐在我旁边，问了一个问题：“如果一个流程是好的，它就不应该会退化。如果它退化了，是不是说明有些什么地方是不够好的？退化的原因究竟是什么？”
为什么有些团队的流程，在过程支持的同学退出之后，就会慢慢退化呢？究竟是因为人的惰性，还是流程的设计本身就有不合理或者不到位的地方呢？
经过对已经实施的团队流程的反复检视，我认为流程会退化的主要原因有两个：
一是这种虚拟团队的组建机制不够强壮——这种虚拟团队之所以能够形成，本质上是基于所有的资源经理的承诺，这是一个不太稳固的基础。尤其是当资源团队的leader发生变动的时候，新的leader没有经历过改进的过程，不理解为什么要这样做，或者不知道这种情况下该怎么做，通常都会选择自己最熟悉的管理方式。这个时候，如果团队中没有一个真正懂得这套体系的价值，并且能够强势坚持的人，流程就会发生退化。
二是团队的职责范围定的太窄——我们的交付团队最初建设的时候，基本上是基于一个系统的，比如酒店交易的“用户系统”、“订单系统”。这在产品/系统建设的初期是没有问题的，因为每个系统本身都还不完善，需要做的事情很多，大部分需求都可以由一个团队独立完成。但是随着产品/系统的建设成熟，单个系统上可以做的东西越来越少，更多的需求会需要跨多个系统修改，这时候团队的“高内聚，低耦合”特性就不存在了。
那么怎样解决这样的问题呢？
今年3月中旬，我去上海与携程的技术与管理同学们做交流，有幸与大家公认的“敏捷做的最好的团队”——酒店无线的技术团队做了一次关于敏捷实施的交流。在这里把他们的经验分享给大家。
酒店无线的技术团队有70多人，组织架构按照技能划分为iOS团队、Android团队、Service团队和测试团队（见下图），存在的主要问题包括：
开发周期过长，从拿到PRD到交付要跨越一个月或者两个月。
需求变更频繁，2个月内会有很多变化，导致已经开发的代码被浪费。
团队成员技能单一，不能根据需要互相援助。
开发团队只是被当作执行者，没有目标感和参与感。
最终这个团队选择了scrum的模型，将原有的组织结构整合重编，调整成了如图所示的一系列的scrumteam。每个scrum team都是完整的交付团队，包含iOS、Android、Service开发和测试。并且鼓励一专多能，iOS开发也会参与Service开发工作。每个团队分别对应不同的目标（OKR），比如：用户/订单增长、基础体验优化、系统架构优化等等。
经过这样的调整，大大缩减了沟通和管理的成本，提升了工作效率；团队聚焦于目标的实现，会更加积极地参与目标的制定，团队的士气也得到了提高。
这种做法不仅解决了案例二中组织结构不稳固和职责范围过窄的问题，更好地方在于，它把每个团队的目标和特定的业务目标明确地关联在一起，使得每个团队成员都有可能最大程度地发挥主动性，帮助业务更好地取得成功——我们每年举办诸如hackathon之类的活动，希望工程师们能够发挥创意，解决更多的业务问题。而事实上，如果能够提供更加有效的组织结构和管理流程，工程师们每天都可以hackathon。
这个案例是局部的比较彻底的敏捷实践，采用了组织变革的方式，将组织结构调整为基于交付团队（敏捷团队）而非职能团队。并且在这个基础上，逐步形成“无边界”的工程师文化。这个实践目前携程的酒店无线技术团队正在尝试，我们期待这个团队能够成为一个标杆，带动大家走向更加开放、更加敏捷的文化。
案例四：强健的工程体系和文化
采用scrum的这种模式，显然在速度和灵活性方面有很大的优势。但是，天下没有白吃的午餐，想要获得好处，就必然要付出代价。那么，敏捷要付出的代价是什么呢？
显而易见的，首先是资源问题。敏捷团队建设过程中最常见的情形之一，就是资源经理说“我的人手不够，需要在不同的开发组之间协调资源，不然不够用”，“如果要拆下去的话，我们需要多招N个人，还是现在这样效率高”。
所以这里就涉及到人的能力问题，一方面我们需要有招聘人的能力，以达到各种资源的合理配比；另一方面，我们要有培养人的能力，鼓励团队成员成为“多面手”，每个人都能承担至少2种角色，这样在有需要的时候可以在团队内部相互弥补。事实上，资源问题是个比较容易解决的问题，只要大家有意愿、去努力，几乎所有的团队都能做到。
而真正严重的，其实是质量问题。很多强硬地推行了敏捷最后又退化的团队，绝大部分都是因为hold不住质量。网上有很多这样的案例，大家可以自己搜着看。
去哪儿酒店以前的交易系统HMS，当时就是有4个独立的开发团队在上面工作，分别对应不同的业务，就是因为没有控制住质量，最后不得不用上100多个人、几个月的时间，把系统重新做了一遍，就是现在的QTA。以至于团队的老成员们都有点心理阴影，一听说要让几个团队修改同一个系统就紧张。
而我们之所以一直只在小范围做试点，没敢大规模地“推敏捷”，最担心的也是这个问题——如果没有足够的把握，能在这种组织模式下保证系统的质量，即使我们“推”成功了，总有一天还会要退回去的。
那么怎样保证质量呢？
这个时候就可以翻开敏捷的书籍们了，里面有各种各样的实践：单元测试、持续集成、codereview……遵循这些实践，我们最终的目标是打造一个质量风险高度可控的工程体系，并且在这个过程中提升人员的能力，形成团队的文化。
这里分享一下Google在工程体系方面的实践。
Google的所有代码全部放在一个代码库中，除了搜索引擎的核心算法等少数模块，绝大部分代码是没有权限控制的，所有人都可以修改。代码全部是主干开发以及源码依赖，自动化的测试（包括单元测试）、持续集成和code review是必须的——每次提交代码时，系统会基于最新的源码进行编译，并执行自动化测试。自动化测试不仅会“向下”执行，而且会根据依赖关系“向上”执行所有可能被影响到的系统/模块的test case。持续集成通过之后，还要经过code review，没有问题了代码才能真正入库。
这种做法保证了代码库的基础质量，建立了可以让“任何人随时修改任何代码”的体系能力。
这样的工程体系很好很强大，显然要投入相当多的资源和时间去建设，而且需要每一个工程师时时刻刻都用心去维护，这就必须要形成工程质量的文化。
那么，什么是工程质量的文化呢？当我们提到敏捷的团队是面向目标而非系统时，很多leader的第一反应是：“系统没有owner，质量怎么办？” 其实潜在的意思就是“是owner的人才会好好干，不是owner的人就会随便造。”这样的文化是不可能把敏捷做好的——系统没有owner，就需要每个人都有owner的意识，这才是敏捷的文化！只有建立了这样的文化，敏捷的体系才能够长期有效地运作。
最后分享一个关于文化的案例。
我在前一家公司（腾讯）工作的时候，团队也在实施全主干开发、全源码依赖以及持续集成等实践。当时新版的搜索引擎和云计算平台都在开发中，搜索引擎依赖云计算平台。搜索引擎团队有几个开发leader经常投诉云计算平台，因为他们发现很多次持续集成不通过的原因，是云计算平台有bug、不稳定。他们觉得太影响效率，要求云计算平台发布稳定分支，开发团队基于稳定分支做集成。只有2个前Google的开发leader说：“没关系，我们就依赖最新的源码，这样才能第一时间帮助他们发现问题，尽快解决，系统就会做的更好。”
大家可以看到，开放的企业文化会造就同样开放和有大局观的员工——不own一个系统，工程师们会own所有。
这个案例是公司级的极致的敏捷实践。打造这样的工程体系和文化，成本是巨大的。我们要不要投入这样的成本去换取极致的速度与灵活性？或者说什么时候才是“合适”去做这件事的时候？我们仍然在探寻中。
(转自CSDN，原文地址：http://blog.csdn.net/wemedia/details.html?id=33184)
