如何实现Scrum敏捷转型？

随着敏捷项目管理模式在国内的流行，各流派敏捷实践培训风起云涌，Scrum框架的相关实践和案例最多，也最为国内推崇。然而在实际应用中，我们会遇到怎么样的阻碍？如何突破这些阻碍，让客户满意，提升客户交付价值？

我们通过敏捷圈内人士的问卷调查，获取了一手的最新各类企业关于敏捷转型中的成与败，选取几个案例进行剖析进而阐明不同组织中，要想实现敏捷转型，我们应该如何避坑。

敏捷转型实例

以下企业和人名出于隐私保护，具体信息都已隐去。

与以上专家沟通中，主要谈到以下几个问题：

1）为什么使用Scrum进行项目管理？

2）实施Scrum过程中采取什么的路线，选择的原因？

3）实施中最大障碍是什么，如何解决的？

4）实施Scrum带来了哪些收益？

5）Scrum实施是如何失败的？

1）为什么使用Scrum进行项目管理？

Robin：客户需求变化实在太快了，产品经理在控制客户需求上经常会产生矛盾，使得双方经常合作的不愉快，影响客户满意度，也严重损耗公司项目团队的自信心，为了更好响应客户，让项目团队有更开放的心态拥抱变化，引进了Scrum框架进行项目管理。

叶胜：我进公司的时候，公司已经有一套完整的传统项目管理流程在跑，由于效率比较低，交付周期过长，经常引发客户的不满，我进来后，劝说部门领导可以在小范围实施Scrum敏捷开发，并告知他我这边有很多成功经验，可以帮助现有团队做到快速交付，提高整体绩效，部门领导很审慎的态度接受了。

2）实施Scrum过程中采取什么的路线，选择的原因？

David：我们不是简单的照猫画虎，而是从Aglie中的很多理念贯彻到团队日常工作中，例如:XP的核心做法，再结合我们实际环境所具备的条件，采用Scrum的几个回顾会议来帮助团队做改进，团队逐渐磨合默契后，沉淀出一套适合我们自己的敏捷方法。每次在Sprint迭代的回顾会议上，我们对当前Sprint中做的不好的地方拎出来，作为下一次Sprint的重点改进内容，几个Sprint之后，整个团队的效率都提高了。同时我们采用自底向上的方式，从一个项目团队试点，获得成功后，逐渐推广到项目集的相关团队，最终实现了整个研发部Scrum框架的全面落地实施。

叶胜：公司太大，一个业务线的研发团队就有1000多人，是否采用敏捷或采用其它方式，都是老板说了算的，我充其量是个执行者，用自己已经具备经验和技能帮助团队做好Scrum转型。

3）实施中最大障碍是什么，如何解决的？

胡天天：先别说实施敏捷的障碍，就是我们传统PMP的做法，都会有很多问题，Scrum这种框架的引入本就是为了更高效交付客户价值的一套理念，以下障碍，大部分研发团队都会遇到：

1. “需求太模糊，造成后期开发沟通成本巨大，反复和产品经理沟通花了太多时间。”

2. “发布周期太长，一个 Sprint 要做 3、4 周才能上线，产品经理希望每周都能上两次线。”

3. “由于 Scrum 过程的特点，我们不能很系统地把握历史需求和整个产品的架构。”

4. “上线时间被业务拍死了，哪儿有时间做单元测试，连代码 Review 的时间都挤不出来。”

5. “目前的 Backlog，人和人之间的协调，任务之间的瓶颈什么的都看不大清楚。”

6. “需求上线，至少 1 周才能分析数据看结果，没法在这个 Sprint 一做完就提出新的改进方案。”

7. “开发节奏太快，产品开发测试都没有时间停下来仔细考虑，历史需求没有善加利用。”

陈凯陆：我觉得最大障碍还是团队成员对这个概念的理解不够，没有接触过相关实践，在前期的实施过程中，只有其形，没有其实，对于为什么这么做，都无法有清楚的认识。那我作为团队的高级工程师，其实是负担了部分架构责任的，为了更好交付功能，会利用业余实践去学习下相关知识，理解后，在与团队成员配合中，通过实际例子讲解，逐渐消除大家的疑虑，经过几次Sprint之后，大家都能对Scrum有一定认识了，然后会觉得自己确实从中受益了，会更好的朝着自组织团队的方向发展。

David：我这边最大的障碍主要还是来自于高层的支持以及团队对于Scrum流程的认识。我们的领导幸好还算开放，对于先进管理模式的引入虽然比较谨慎，但是还是给了不少支持，放手让我在实际项目中去尝试，成功后再去推广；团队成员大多偏向于传统的开发模式，对Scrum并没有多少认识，所以为了解决认知问题，我在前期组织过Scrum的相关培训，通过一些场景小视频，以及提炼的重点内容，让团队成员在进行Scrum敏捷开发之前就已经知道自己的角色，以及自己要做什么了，所以推广起来也还算顺利。

在与胡天天的深入沟通中，他解释道，为了解决需求模糊问题，帮助产品经理整理需求模板，在进入计划会议前，增加内部评审环境，参与角色有产品、测试和研发；针对第二和第三个问题，我们对需求进行排序后，讲产品经理关心的可见部分需求，安排特定迭代优先级，在每周的固定时间进行开发转测和演示；

4）实施Scrum带来了哪些收益？

David：收益应该是几部分，一方面对公司来说，不太容易衡量，只能感性认知，通过对客户的回访收集客户满意度，迭代周期的缩短肯定是可以为公司交付能力的提升塑造口碑的，但是需求的及时响应，可能也增加了公司的研发成本，研发模式的引入，并无法解决成本问题，只能通过效率提升抵消这部分损耗。一方面对于团队来说，确实是提高了整体研发交付能力，但也带来不好的一面就是受到公司企业文化影响，sprint之间的间隙很短，长期都处以一种上战场状态，容易产生疲怠感；

Robin：我们老板比价开放，第一个项目Sprin看到成果后，就要求全公司采用Scrum敏捷式管理，甚至销售、HR都要遵守Scrum规则。所以整个公司在很短的时间内适应了Scrum规则。新人入司第一件事就是Scrum培训，然后在项目中进行锻炼，逐渐习惯Scrum规则。目前公司通过Scrum方式已经交付了两个客户项目，收到不错的反馈，所以我们正在研究大规模敏捷的做法，讲研发团队关联的项目纳入体系，提升整体战斗力。虽然遇到很多障碍，但因为是初创公司，团队规模不大不小，调整适应的能力还是不错的。

5）Scrum实施是如何失败的？

叶胜：我们的问题在于，有些高层错误理解了 Scrum 和 Agile，导致歪曲了某些东西，使得 Agile 变得形式化。举个简单的例子，当时的 Scrum Master 负责一个大项目的开发，走的比较顺利，然后有个项目经理发现这个东西挺好，就单独把 Daily Scrum 拿来进行推广；结果，这个经理并不理解什么是 Scrum，他把 Daily Scrum 变成了 Daily Report，而其他 Scrum 的精华部分都没有推广。

每个员工都要在早上固定时间开 Daily Scrum，然后把当天的任务告诉给他，让他来决定工作是不是饱满。这个把弹性工作制直接给破坏了，引起很多人反感；另一点就是很多人认为这样的 Daily Report 太频繁太低效，而且还有压榨员工的嫌疑。所以逐渐大家谈起 Daily Scrum 来都是恶心的不得了，于是经理也知趣地取消了 Daily Scrum，再到后来在公司内部就没有人谈什么 Agile 了。

胡天天：我们是分布式开发，当时中方的团队对于敏捷开发只是一知半解的水平（当然，我们都确定外方团队也好不到哪里去）。某一天，国外的 PM 突然发来几个链接，一看讲的是一个闻所未闻的词，就是 Scrum 了。好像就给了一两天的时间去看 Scrum 的介绍文档，然后就开 Stand-up Meeting（站立会议）。其实大家都知道沟通进度的重要性，但我们双方 7、8 个小时时差，那边一上班这边就快收拾东西走人了，就这样还要讲自己今天要做些啥，遇到啥困难，一点意思都没有。而且最关键的问题在于双方文化差异，语言差异，还有项目的整体规划协调。很快 Stand-up Meeting 就成了形式。后来，我们又间歇性地在自己团队内部做 Standup，但最后还是因为不能带给我们太大价值，流于形式，就放弃了。

再说其他方面，我们没有计划会议，有名义上的 Product Owner，但是他不跟我们解释每一个 Story 具体的细节，也不说如何定义这个 Story 的完成状态。我们自己搞过 Retrospective（回顾），但总结出来的看法反馈到那边就没动静，后来也不做了。在第一次使用 ScrumWorks 的时候，好歹 Product Owner 还能来设置优先级，我们估算时间，最后决定哪些故事放到下一个 Sprint 里面。到后来就只要是人，就能往 Scrumworks 上扔任务，也不 知道哪些重要哪些不重要，我们自己开发人员看着办，最后剩下几百个小时完不成再扔到下一个 Sprint 里面去。后来公司里又搞 CMMI 认证，把我们项目作为 Pilot（试验），名义上是改善流程，但实际做法就是为了应付拿证，那就是一强制推行啊，把人搞得想辞职的心都有了。这个项目中间发生的事情太多了，反正磕磕碰碰的还在往前走，但现在我听见公司里有人提到敏捷就犯恶心。

Scrum有三大精髓内容：

1.解决客户问题

Scrum是通过交付产品的方式，解决客户的问题，这一条主要是站在Scrum Master的角度来说的。如果Scrum转型组织一味追求度量的数字，那么敏捷这条路走错了，因为Scrum最终的目标就是一定要让客户满意，要让客户的最终用户满意，帮助客户解决他的问题。

2.重在关系

这个关系包含团队成员之间的关系，团队与客户之间的关系，处理好关系，是正确做事的前提，对于Scrum来说，精髓的内容就是帮助客户真正的提高交付速度。只有提高了交付速度，才能不断尝试探索，如果交付速度不行，谈何快速应对变化呢？

3.重视反思

每天作为Scrum Master应该反问自己、反问团队，我们现在是否帮助客户解决问题了，我们和客户的关系怎么样？通过每天不断的反思，不断的问这些问题来促进团队成长。

以上三点如果做不到，最好不要硬上Scrum，上了也解决不了啥问题。因为采用Scrum以后，不断暴露的团队问题或是问题被隐藏，没人愿意接受，也没人愿意改进，那么我们上Scrum的意义在哪里？

Scrum有三大反模式：

1）以流程为中心

搞质量体系的和做开发的同学都不适合制定流程，流程要以提高工作效率为前提，因公司企业文化团队文化不同而有所不同，更重要的是团队一起反思如何更快的进行产品交付。而不是如何制定一个更完美的流程。

2）以考核绩效为中心

以绩效来考核团队的时候，团队会受到激励也可能受到打击，因为绩效本身就是双刃剑，不同企业文化有不同的绩效考核方式。没有正确的绩效也没有不变的绩效。所以还是回到Scrum精髓的本质，把团队的注意力拉回到正确的路上。

3）组织“推动”敏捷转型

很多的组织都是“推”敏捷，员工是被推着走，管理层也是被老板推着走。没有人愿意主动寻求改变。既然如此，你还折腾啥呢？大家都累，结局只能是：失败。Scrum转型，需要是团队、管理层、老板都一致认为，我们需要改，我们能改好。

总结下，本文主要通过对敏捷圈子的几位大佬的“访谈”，对为什么转型，怎么转，成功和失败的比较，以及对Scrum 框架的三个精髓和三打反模式进行了对比分析，希望对想要做敏捷转型，以及正在做敏捷实施的小伙伴有些实质性的帮助。

作者简介