文/苗得雨

敏捷开发最早是应用在开发团队中，目前在国内已经有许多公司都在积极的想敏捷转型，敏捷开发也成为了互联网公司一种组织转型的首选方式。相对于那些传统的开发团队，通过敏捷开发实施转型的团队更容易开发出高质量的产品，可以用更低的成本来满足用户的需求。这一点在业内已经取得了公认的共识。

时雨本来是公司研发团队的敏捷教练，公司在从敏捷组织转型中尝到了开发的甜头之后，公司的VP副总裁突然想让非研发团队尝试一下敏捷项目管理。看能否通过敏捷转型，将问题积累很久并解散的市场部重新整合起来。

恰巧，公司想在今年中旬举办一次规模非常大的行业会议，由于刚重组的市场缺乏一个既了解互联网产品，有了解项目管理和市场的人选，所以在面对这次大会的时候颇显费力。以至于在划分会议分论坛的时候，都设计的一团混乱。

在这种情况下，公司决定调时雨去市场部门，重整市场部门的组织结构，并对市场部门实施敏捷管理。不得不说这是非常大胆的一个决定，因为在此之前时雨作为敏捷教练只是在研发部门实施过Scrum敏捷开发，对于非市场部门来说虽然不是第一次，但是之前在另外一家公司的非研发团队实施时，都遇到了前所未有的障碍。

 

发现问题：沟通！

时雨在非研发团队实施敏捷组织转型并不是第一次，上一次是在一个同等大规模的公司，但是那次敏捷转型最终是以完美的失败收官的。总结上次的教训，时雨认为，在上一次敏捷转型中，没有得到高层的任何，团队内部老将的强烈反对，以及团队成员将许多精力花在处理突发事件上，最终导致那次敏捷转型以失败告终。

所以这次在B公司决定调时雨进入市场之前，时雨先对市场部进行了一番了解。公司的市场部是一直刚刚重组的团队，市场部的新领导是一个服务了公司六年的老员工，是市场部的创立者，但是后来由于岗位变动被调任其他部门。此次公司决定重新着重打造品牌，特地将其从其他部门调回，重组市场部。

时雨作为公司唯一的敏捷教练，被空降到市场部推动尝试推动敏捷方法。由于研发团队很好使用敏捷开发，并进行的颇为顺利，因此时雨在和市场部负责人沟通使用敏捷管理该项目之后，市场部门恰好想通过实施敏捷项目管理和研发部门保持项目同步和情感上的认同。

通过和市场部负责人平成沟通，时雨了解到，由于平成刚刚重组市场部，市场部除了原有的老将之外，还有大量的新人。此次市场部想推动敏捷方法除了想向研发团队展示一下服务研发部门的决心之外，更主要的目的是改善目前市场部门混乱无序的管理，由于此次公司对这次行业大会的筹备非常重视，因此如何通过有效的项目管理推进此次会议成功举办成为了公司最终的任务之一。

由于早先在非研发部门实施敏捷的失败经验，让此次时雨非常小心谨慎，他决定先进驻到该市场团队观察一段时间之后，在决定如何推广实施敏捷。进驻团队2周之后，时雨发现了这个团队众多的问题。最常见的问题是推诿。

在团队中你常常能够听到这样的对话：“啊？这个事情我不知道呀，你没有跟我说呀。”

“我不清楚这个事情，这个事情是XX负责，他不在，你等他回来跟你说吧。”

”我不知道这个事情XX也要配合。“

……

时雨决定和平成进行一次沟通。

“你感觉现在团队在推动互联网大会这个项目时存在什么问题？”平成非常直截了当，他不想再等待了，他希望能够尽快的扭转团队无序的局面。

“我在团队这几周发现，困扰团队的问题主要是沟通问题。团队成员缺乏线下沟通，很多项目虽然在线上的企业微博中公布了，但是项目进度仍然很慢，而且很多人做的很多项目并没有加入到线上的项目中。导致目前很多子项目丢失。”时雨告诉平成，团队内成员虽然很活跃，但是大家在沟通工作方面并不是非常的积极。

时雨给平成讲了一个发生在美国太空总署的故事：2003年9月6日，美国太空总署的一支科学家团队正在移动一个价值2亿美元的”NOAA-N-Pime“气象卫星，然而就在几分钟之后，这颗卫星轰然倒地，重重的摔在了地板上，完全报废。事后调查发现，原来技术队伍在一侧转动承载着卫星的支架时，却不知道另外一组技术人员经将底部的螺丝送掉了，他们忽视了沟通，并忽视了检查所有的螺丝是否固定的步骤，于是这款造价2亿美元的卫星瞬间就被摧毁了。

平成听了这个故事若有所思，他承认现在沟通的确已经成为了团队一个重要的死结。市场团队之前采用的正式交流方式是每周一次的周会，通过周会沟通一周的工作任务和计划。这种沟通方式不仅时间长，而且效率非常低，团队内的成员汇报工作内容容易出现跟丢的现象，每次周会结束之后，人人都被平成骂的狗血喷头，会议的项目进度却没有任何进展。

平成在跟时雨沟通之后，想通过敏捷方法，让市场部找到一种更契合的项目管理方法，以便最大程度上激活市场部的活力，通过制度避免掉任务丢失的情况。敏捷就这样被决定在市场部生根发芽了。时雨认为，Scrum敏捷方法中，最重要的一个环节是每天的站会，15分钟的站会能够很有效的促进团队成员积极沟通，并让团队成员之间相互了解彼此的工作状态，解决沟通中存在的问题。

于是在平成和时雨的推动下，一场敏捷组织转型在市场部门开始实施了。在正式实施敏捷之前，时雨先了解了市场部的组织结构和日常工作。同时他详细的向市场部的负责人介绍了Scrum在开发团队的实施方法。在开发团队实施Scrum时，实施的关键要素是Sprint的周期。Sprint包含了规划会议、每日站会、故事时间、Sprint评审和回顾，这几个关键流程。

听完时雨的介绍之后，平成说：“我们先将这次大会作为敏捷项目实施一下。这是一个较为完整的会议项目，所以可以先进行尝试。不过，市场部的许多活动每天都熟悉万变，特别是传播工作，每天都会有零零碎碎的突发事件发生，所以很多计划跟不上变化。”

时雨听出来，平成其实对敏捷过程中的许多环节还是有疑虑的，不过这次尝试对于所有人都是全新。不具体实施就无法发现敏捷在非研发部门运用时会出现什么样的问题，于是在非研发团队的敏捷实施开始了。

 

推动敏捷：敏捷的推动力

按照研发团队的惯例，推动Scrum或者任何一个敏捷过程转型，长期以来最通常的建议是以一个试点项目作为开始，从中吸取经验教训，然后在企业范围内在进行推广。这个方法就是我们经常使用的小团队试点（Start-small）模式。使用这个模式时，企业往往选择一到三个有代表性的团队，每个团队人数控制在5~9个人，让这些团队取得成功，然后再以此为基础推广Scrum。

市场部目前人员数量在12个人，是一个比较好的试水团队。在向非研发团队实施敏捷之前，时雨召开了非研发团队的会议，向所有的项目相关人员介绍了敏捷项目管理的要素和规则。时雨根据自己在研发团队实施敏捷管理的经验，决定保留规划会议、每日站会和回顾会议。

时雨先进行了对此次传播项目做了传统的项目拆解，详细的规划了每个人应该负责的任务。这样做主要是出于“保险”的目的，防止后期出现扯皮现象。不过时雨感觉这次会议开得非常沉闷，市场部的老将们似乎并不喜欢这种来自研发部门的全新管理方法，会议中没有任何人提问和质疑，这更让时雨感觉这次在非研发团队实施敏捷很可能潜藏着巨大的风险。开完了规划会之后，时雨将自己的感觉和平成进行了简单的沟通，平成也察觉到了这种氛围。

时雨列出了此次组织转型的目标：

（1）    解决团队沟通不畅问题；

（2）    解决团队任务丢失问题；

（3）    解决团队积极性调动问题；

对于时雨和平成而言，完成了这三个目标，这次敏捷转型就算是一次成功的组织转型。

有平成支持算是一个好的开始，在《Succeeding with Agile:Software Development Using Scrum》这本书中有提及到，敏捷开发很难达成的六个原因，时雨仔细的回顾了一下：

成功的变革并非全然由上而下或者由下而上所引发的；

这一点比较容易了解，任何组织的变革，不太可能光靠老板一个人的意志力就可以达成。有看过清宫剧的朋友都知道，大清帝国如此庞大的江山，不然一样也要依靠皇帝下面的官员们来进行治理，光靠皇帝自己一个人肯定是不行的。所谓上有政策，下有对策；如果低下做事情的人不配合领导的意图，变革就无法落实。顶多就是大家根据大老板的要求做做样子，行礼如仪一番。“看起来”好像变好了，实际上在根本上没有发生任何变化，甚至变得比以前更加糟糕。

相同的道理，如果光是基层管理人员或者敏捷教练一个人的满腔热血想要在公司内部推动什么惊天动地的改革更是不可能的任务。想想自己是什么角色，在大公司中只是一个小小的螺丝钉而已。

很多人面对这种感受的时候会想“算了吧，公司烂就让他烂吧，小的还是继续数日子，等着每个月的5号发工资吧。”

此时经常会有人问时雨，如果公司不支持，我可以继续使用Scrum之类的敏捷开发吗？答案是当然可以。只要团队成员获得共识，改变当然也是可以由下而上所进行的。敏捷教练或者产品经理在面对研发团队的时候，的确可以要求团队成员达成共识，一起迈向敏捷开发和组织转型的大道之上，然而由于敏捷的组织转型在缺乏管理层支持，引入Scrum的过程将会变得非常痛苦，团队成员必须要有“吃苦”的心理准备。

举一个非常简单的例子，绝大多数的敏捷方法都要求团队成员必须坐在一起，以方便面对面的沟通。但是许多公司原本安排员工坐在办公室隔间之内，而且团队成员的座位如同天女散花般的分散在公司不同的楼层。由于没有获得公司管理层的支持，团队便无法因为要引入Scrum而提出调整座位的要求。在这种情况下要引入Scrum，成效就很可能会大打折扣。原本Scrum所要求的面对面互动，马上就被办公室隔间与现有的作为安排给打败了。

一个比较好的情况是由基层员工发起敏捷方法运动，而且同时获得管理层的支持。

此外改善的最终结果是无法预估的；

为什么许多团队想引入敏捷方法？可能是听到江湖中传言，说Scrum可以改善产品品质并提升团队生产力。既然现在Scrum很流行，国内同时也有很多成功的案例，那么就实施也无妨呀。如果抱着“照抄别人的经验到自己的团队中”这种引入敏捷方法的步骤很容易造成最终的失败。因为每个组织文化与成员组成各不相同，别人实施敏捷方法的方式在别人的团队中有效，并不表示相同的模式可以直接套用在自己的团队中。

例如，别人的团队成员可能都是刚刚毕业的硕士研究生，他们对新鲜事物的接受程度与配合度非常高。因此，别人在引入敏捷方法时，例如持续集成、看板等，并不会遭遇很大的反对力量而进行的很顺利。但是如果你带领一个工作时间都超过十年以上的“老将团”，以前从来也没有做过任何和项目管理或敏捷相关的工作，跟别说开评审会议和回顾会议了，这简直是要了这帮市场人员的老命。结果，在敏捷实施过程中，过多了参考了研发团队的经验，但是却没有根据市场部门的组织文化与成员组成的特点加以“改良”，最后的结果就是敏捷方法和组织转型的失败，并从此认为敏捷开发这种方法不是好方法。

 

实施敏捷：组织转型成功

任务白板

任务白板 

第一天的站会顺利召开了，时雨同样准备了白板，不过这次敏捷没有采用Scrum贴纸条的方式，而是采用了项目管理计划表。之所以没有采用贴纸条的敏捷方式，主要是考虑到市场部门的人员本身就已经有较为明确的分工和领域，即便将其打散让其任务自由领取，也不会产生本应该有的效果，最终结果可能还是原有负责的人各自负责各自的工作。

除了将任务改成了项目管理表之外，时雨保留了每天的站会，站会要求组内人员每天沟通一下昨天完成了什么。但是时雨很快发现了这种方式存在的问题，就如同之前所见的一样，市场部的工作千变万化，很多工作当天就会出现更动，要么被删除，要么需要新增任务。而这种项目管理计划表在应对变化的时候，远远不如白板+便签纸来的灵活。

于是时雨迅速将原有的项目计划表更改为了白板+便签纸的敏捷方式。将站会也修改为早晚2次。早晨的站会，所有的团队成员可以将自己的任务写在便签上，然后贴到白板上。下班前的站会，除了可以更新今天的任务之外，还可以将明天的任务写好贴在未开始项目中。

通过这种改善，这次会议项目的节奏开始加快，通过早晚两次站会，团队中的所有成员都能够进行顺畅的沟通。团队之中在也没有出现过”我不知道这件事情跟我也有关。“这种话。每周对白板上的所有任务进行一次总结，算是一个小的Sprint回顾。

Scrum敏捷的组织转型有一个关键点在于”持续改善“，而且这种持续改善的过程是渐进式与演化式的过程，而非计划性的过程。在开发团队实施敏捷的过程中，每个Sprint结束的时候都会召开一次Retrospective meeting，也叫回顾会。听过这次会，团队成员可以根据团队与项目的现状提出改善建议。由于项目现状可能因为需求变更或团队目标的改变而改变，因此”改善“的重点绝不会是一个静态的目标。所以Scrum敏捷团队的改善策略便是要采用渐进式的模式，从每一天的站会到最后的回顾会，依据现状和反馈进行随时随刻的调整。

Retrospective Meeting是Scrum设计用来改善开发流程的一道关卡，每一个Sprint结束之前都要经过这一关，在和平成讨论之后，他们一直认为这种改善也适用于非研发团队。在回顾会议当中，开发团队会讨论在这个Sprint当中，有哪些事情做得很好，要继续持续；哪些做得不好，应该改善，并挑出几个比较重要的改善项目，列出改善的行动方针。

例如：

好的部分：

引入Scrum开发框架

有一个公开的Product backlog

有制定产品的release plan

有持续整合的环境

有自动化功能测试案例与测试环境

 

有待改善：

工作任务分配不均

电脑效能不佳（都是微软的阴谋！）

没有写单元测试

没有pair programming

Task完成条件定义不清

JIRA打开速度太慢（以前的团队真的有人提出过这个改善事项……5555……）

 

改善行动方针：

长期目标：增进工作环境效率

    行动计划：增加内存条到8GB

    行动计划：都统一使用XX软件优化（或者我们穷的只能够用XX软件优化了）。

长期目标：所有method至少都有三个对应的单元测试案例。

    行动计划：安排一个小时的讲座教导JIRA使用方法；

    行动计划：下个Sprint，每个人至少写三个测试案例；

长期目标：50%的开发工作都以Pair programming 方式进行

    行动计划：因为目前工作环境并不适合Pair programming，因此先改善工作环境。首先向公司申请22寸屏幕、无线键盘及鼠标。

 

由于改善开发流程是一条很漫长的道路，有多长？这么长…… 长到你看不到底。所以，很多改善项目需要长时间的关注。时雨在非研发团队推行敏捷研发过程时，也借鉴了这一点。他和平成进行沟通，将每周的周会改成回顾会，回顾上一周的项目推进情况，回顾项目的好与坏，并让大家提出改进意见。

在2次回顾会之后，团队提出现在的敏捷看板的方式虽然能够让任务不再发生丢失，但是缺乏了对会议项目的整体掌控，由于非研发团队的许多项目仍然会在整个的大项目计划之中，不会发生太多因为用户需求改变而需要改变研发任务的问题。相反，对项目整体的全局观往往会更加重要，因此在看板之外添加一个全局的项目进度表也非常重要。

在这次回顾会之后，我们制作了一个全局项目进度表，将整个会议所有需要推进的细节一一列到这个项目表中，然后落到相关负责人，相关负责人根据这张表拆解自己的任务，然后写在便签纸贴在白板上，保证了项目的整体流畅性。

 

******

一个月后，这只非研发团队已经能够熟练的运用敏捷的方式辅助以传统的项目管理控制，快速的推进项目了。行业会议也在当初认为完全不可能成功召开的情况下成功推进召开。团队成员再也没有出现沟通的问题，大家相互激励，沟通频繁，彼此了解对方的工作，团队氛围非常融洽。

而公司也撤回了时雨，让其再去改善下一个非研发团队。