Scrum 实施情况调查之案例分析

作者李剑，在 InfoQ 中文站上发表了一篇" Scrum 在中国——企业实施情况调查实录"。这份调查实录，分别调查了五个实施 SCRUM 的公司，其中三家公司实施成功，二家公司失败。我建议所有准备或者正在实施 SCRUM 的人们都能来读一下。

在此，我们会对这篇文章中的案例分类进行分析、诊断。并探讨什么是敏捷开发方法、什么是 SCRUM、使用敏捷方法需要什么条件、它可以解决什么问题以及如何在团队中合理的使用敏捷方法。

什么是敏捷开发方法？什么是 SCRUM？

有人在这个字面上下功夫，说敏捷就是反应要灵敏，动作要快捷；有人还在字面上进行延伸，说敏捷就是又好又快，或者就是多快好省；有人说敏捷就是光写代码不写文档；有人觉得敏捷就是没有制度，管理松散的工作方式；有人觉得只要敏捷了，就代表高软件交付水平。 那么，敏捷这个词到底由何而来呢？在九十世纪中期，涌现了一批软件行业的激进人士，他们反对那些以过程为本的重型软件开发方法（例如：传统的瀑布开发方 法）。在 2001 年，17 位软件业界的专家们齐聚一堂，讨论正在兴起的轻量级开发方法（Lightweight methods）。专家们给这类轻量级的方法学起了一个新的名字叫做敏捷，并发布了敏捷开发者宣言。

敏捷方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善。 敏捷开发方法是这些轻量级方法的总称，它旗下有很多具体的开发过程和方法。主要的有：极限编程（XP）、特征驱动软件开发（FDD）、SCRUM 开发方法 等等。SCRUM 开发方法是由 Jeff Sutherland 在 1993 年创立，Jeff 也是制定敏捷宣言的 17 位专家之一。SCRUM 借用了橄榄球运动中的术语——一个团队拿球向前冲。

严格的说，SCRUM 是遵循敏捷方法的一个软件开发框架。在 SCRUM 框架中，融入敏捷开发的精神和思想，就被称作 SCRUM 开发方法。SCRUM 是一个 什么样的开发框架呢？简单说，它由三个角色（Role），三种会议（Ceremonie），三项工件（Artifact）组成。

• 角色（Role）：产品主管（Procuct Owner），他负责项目的商业价值；SCRUM 师傅（ScrumMaster），他负责团队的运转和生产；以及自组织的团队。
• 会议（Ceremonie）：迭代计划会议，每日晨会（daily scrum meetings），迭代回顾会议。
• 工件（Artifact）：用来排列任务的优先级和跟踪任务。待开发任务列表（product backlog），迭代任务列表（the sprint backlog），进度图（burndown chart）

在敏捷刚出现的时候，极限编程（XP）一直是主流。但是，在敏捷方法开始在全世界流行的今天，为什么最红火的却是 SCRUM？这是因为 SCRUM 更容易普 及和推广。其实极限编程包容了 SCRUM 方法。我们从工程学的角度，可以把软件开发分成两部分：过程（分解任务，排列优先级和迭代计划）和代码实现（高质 量的代码和自动化的代码保障体系）。其中最难的就是代码，最有直接商业价值的是过程。SCRUM 则回避了最难的部分，加强和创新了最能直接体现商业价值的 过程部分。 这就是 SCRUM！

现在，我们就开始对案例进行分析和诊断。

失败案例分析

我们这里借用 SCRUM 实施调查中的两个词“成功”和“失败”。其实，我们很难定义成功和失败。在实施调查中，失败可以理解为使用 SCRUM 不当，没有到 达预先的期望，直至最后团队放弃了 SCRUM。成功是意味着大家还在继续使用 SCRUM，从某种程度上说，就是 SCRUM 达到了团队的预先期望，至少是可 以接受的期望。 我们先看第一失败案例：某知名大型互联网公司，被采访者是一个叫 David 的工程师。

他是这样总结失败的原因：

“有些高层错误理解了 Scrum 和 Agile，导致歪曲了某些东西，使得 Agile 变得形式化” 他们在项目中尝试使用了 SCRUM 中的一个实践：每日 SCRUM 会议。下面是 David 描述不了解 SCRUM 的项目经理，如何使用这个实践的：

“项目经理发现这个东西挺好，就单独把 Daily Scrum 拿来进行推广；结果，这个经理并不理解什么是 Scrum，他把 Daily Scrum 变成了 Daily Report：每个员工都要在早上固定时间开 Daily Scrum，然后把当天的任务告诉给他，让他来决定工作是不是饱满。而其他 Scrum 的精华部分都没有推广。” 有的网友分析，得出结论说失败是因为“这家大型互联网公司的制度和文化的问题”。当然，失败肯定是跟这有关系，但我觉得还没有直接上升到整个公司的制度和文化。

了解 SCRUM 的人，都会很清楚。他们对 SCRUM 的应用很初级，也只用了一个 SCRUM 中提到的晨会（其实，在其它很多的软件开发方法中都有这个实 践）。我们可以看出，他们的问题就是：项目经理根本不知道什么是 SCRUM。也许连自己在开发中遇到了主要问题是什么都还不清楚？就四处寻药，甚至就给自 己下了一个处方。

我们就以每日晨会为例，在 SCRUM 中，明显的提到，在会议中每个人只可以说三件事情：

1. 我昨天做了什么

2. 我今天准备做什么

3. 我在工作中遇到了什么障碍。 每日晨会，目的有二点：

4. 加强团队交流和信息共享。互相了解彼此都在做什么工作，完成了什么任务。这样，每日的信息传递，可以让每个人可以更多的了解整个项目的业务和技术状况。并 且如果在工作中遇到障碍或问题，也可以在这时候提出来，请求大家的帮助（其实，一般在敏捷团队中，遇到问题，都会当场就提出来，或直接去找相关的同事，问 他们有没有处理过类似的问题，或者有没有一些建议）。

5. 促使每个人在早上做好一天的工作计划。这样，每个人一天的工作就会有明确具体的目标。这会直接提高一天的工作效率。 所以，上面的这个失败项目根本谈不上是在使用 SCRUM。连基本的 SCRUM 框架还没有弄明白，就更谈不上敏捷的精神和思想了。

第二个失败案例是一个离岸开发的某创业型公司。虽然团队比较特殊（离岸开发团队），但这个失败案例却非常典型和普遍。

“某一天，国外的 PM 突然发来几个链接，一看讲的是一个闻所未闻的词，就是 Scrum 了。好像就给了一两天的时间去看 Scrum 的介绍文档，然后就开 Stand-up Meeting（站立会议）。” 和第一个案例相比，这个案例的团队是真真的在推行 SCRUM。从表明看，大家也是在按照 SCRUM 框架的方式工作：有相应划分的角色，有具体的分解任务，有会议，也有迭代（Sprint）。那又怎么会失败呢？

显然，他们是在照搬照套了 SCRUM 的框架。他们是两个离岸的开发团队，因为地点、时区和语言的差异，很容易就会导致沟通和交流不畅，这时候再生硬的引入 SCRUM，无异是火上浇油。

下面我们来看看他们是如何使用 SCRUM。

1. 每日晨会

“其 实大家都知道沟通进度的重要性，但我们双方 7、8 个小时时差，那边一上班这边就快收拾东西走人了，就这样还要讲自己今天要做些啥，遇到啥困难，一点意思都 没有。很快 Stand-up Meeting 就成了形式。后来，我们又间歇性地在自己团队内部做 Standup，但最后还是因为不能带给我们太大价值，流于形式，就放弃了。”其实，在敏捷的实践中，每日晨会是最容易做，也是最有效果的实践之一。那为什么最后会流于形式，而放弃了呢？一、 会议的时间不好。中国团队快下班了，准备收拾回家。通过我们的实践，发现站立会议最佳的时间是早上。比如：9 点上班，会议时间可以定在 9：30。早上到公 司之后，大家收个邮件，处理一下个人的事务。到点了，按时的举行晨会，然后全身心的投入到一天的工作中。这样，很自然，开发节奏很畅快。

二、从上面的描述，明显可以看出来。大家对它是有抵触心理。或许是在抵触会议，或许是在抵触 SCRUM，或许本来就已经上火，只是借此宣泄。

三、 这是最重要最重要的一点：团队的文化氛围。说具体一点，晨会不是每天的工作报告，更不是项目经理进行工作检查，甚至考核。项目经理有责任营造一个安全 （Safe）的会议氛围，让每个人都乐意说出真正发生的事情，就算是昨天遇到技术问题，没有任何的工作成果，也能得到谅解，而不是胆颤心惊。比如：我们在 每天早上做站立会议的时候，可以端杯饮料，很轻松的围成一圈，说说笑笑，然后会议结束，就开始一天的工作。

2. 迭代任务

“在 第一次使用 ScrumWorks 的时候，好歹 Product Owner 还能来设置优先级，我们估算时间，最后决定哪些故事放到下一个 Sprint 里面。到后来就只要是人，就能往 Scrumworks 上扔任务，也不 知道哪些重要哪些不重要，我们自己开发人员看着办，最后剩下几百个小时完不成再扔到下一个 Sprint 里面去”显 然，大家的迭代过程很随意，松松散散，没有任何的约束。有的网友说这是公司制度的问题。那无疑是在“头痛医头，脚痛医脚”。如果，这时还拿制度说事，明显 是在和敏捷精神相悖。敏捷方法，表明看上去管理松散，没有规章制度。其实不然，它有很多的准则，要求每个人能够自觉遵守，养成工作习惯，成为一种职业素 质，最终目标是要形成一个自组织的团队。例如，谁可以往 Scrumworks 上扔任务？这明显是产品主管的职责。就算是开发人员想往上扔任务，也应该和产 品主管以及整个团队讨论，明确任务的价值和优先级之后，再决定是否可以把任务放到当前的 Scrumworks 上。这是最的基本要求，这是每个团队成员默认 遵守的原则，甚至可以认为这是一个开发者最起码的职业素质要求。我们从上面的描述可以再次看出，大家是在对 SCRUM 有抵触的。如果，到现在，推广者到还不能让大家理解、认可和接受 SCRUM 方法。那么，引入 SCRUM，也绝不可能获得成功，甚至会直接拖垮整个项目。

敏捷方法，需要有一个英明的领导（也许就是 Scrum Master），以身作则，带领着团队向前冲锋，大家齐心协力，以项目的成功作为最高奋斗目标。只有这样，才能发挥敏捷方法的威力，只有这样项目才可能获得成功。

再回到迭代开发，它能给我们带来什么样的好处呢？

一、 明确的短期目标。如果让一个团队做半年的详细工作计划，一定非常困难，但如果是 2 周，那就完全不一样。假设，客户有 100 个东西要做，但团队在一个迭代 （一般是 2 周左右）中，只能完成 20 个东西。那么就明确的告诉客户，一个迭代的时间，我们只可以完成 20 个东西，那么我们先开发其中 20 个最有价值的东西 好吗？

二、如何知道团队在一个迭代可以完成多少任务呢？显然，迭代只有两周的时间，相对的计划会很准确，而且前面一个迭代的工作量，是这个迭代最好的参照。如果是第一个迭代，根据团队的经验做好一个合理的 2 周计划应该不难。

三、迭代结束之后，给客户演示工作成果，及早获得用户反馈。同时团队在一个迭代结束之后，也会对整个开发的状况进行思考和反省，举行一个回顾会议，客观的讨论前一段时间的工作，哪些地方做的好，哪些地方做得不够好，对不好的地方，要能讨论出具体可行的解决办法。

敏捷的团队就是用这种迭代的方式，增量的进行工作。小步前进，不停的思考、反省和总结，不停的进行自我调整和完善。让自己一步一步的变得优秀，走向卓越。

总而言之，如果只是学了 SCRUM 的形，却没有敏捷的意，没有掌握敏捷的思想和精神，那么再怎么使用 SCRUM，仍然只是在东施效颦。

成功案例分析

到此，也许你会吸取上面两个失败案例的教训，也认同文中的分析，觉得敏捷很实用、很有价值；也许此时，你却在紧缩双眉，因为敏捷的思想和精神，让你觉得有点理想化，不切实际。是的，思想和精神只可意会不可言传。这些只可以在每天的工作和问题中去领悟、体会和沉淀。在学习敏捷方法的时候，我们 应该尽可能多和深入的学习，并融会贯通。在具体工作的时候，我们先要忘掉学到的条条框框。首先分析自己的上下文环境，找出最主要的矛盾，然后根据团队状 况，通过学到的经验和方法将这些问题进行平衡和解决。

下面我们看一下璎珞天色是如何在项目引入 SCRUM 的。他们路线是这样：

“我们不是采用纯粹的 Scrum，而是将 Agile 中的很多理念，包括 XP 的部分做法，然后结合现有的开发环境与要求，用 Scrum 的回顾不断地做改进， 从而趟出自己的一条路。如果这个 Sprint 我们回顾时觉得自己代码 Review（审查）做的不好，下个 Sprint 就会引入新的代码 Review 机制。 这个 Sprint 觉得重复性的 bug 较多，下个 Sprint 就会引入缺陷预防机制。我们是自底向上，先做小范围试点，再全面推广，中间对过程进行不断改进” 他们的具体做法如下：

“其实我们一开始并没有把 Scrum 这个说法拿出来。就是首先和业务一起商量什么时候上线，商量出来的结果是每个月定期上线。于是就有了一月一个项目的进 度（我们是线上服务，没有版本的概念，有一堆需求过来，对技术来说就是在这一个月以内完成这些需求，把这一个月以内的工作叫一个项目）。然后为了管理，我 们开始开晨会。然后为了改进，我们开始开项目总结会，把 Product review 和 Team retrospective 放在一起，既有产品经理介绍现状，也有大家讨论成绩，不足和挑战。后来总结会上觉得质量不好，我们加入了单元测试和代码 Review 机制。至于计划会议，一开始我们就采用的 Scrum 的方法。项目小，MS Project 太难调。我们就更换了 Scrum 的 Excel 计划表，后来又换了 Xplanner。” 无独有偶，这些成功案例的团队，就是通过这样的方式进行一步一步推进，把 SCRUM 成功的引入到了各自的项目中。其中三个成功实施 SCRUM 的公司，无疑是璎珞天色的团队最能深入敏捷的精髓。

小结

敏捷就是一个团队持续不断的自我改进过程，直到那些优秀的品质成为大家的一种职业习惯——一个自组织的团队。敏捷没有终点，我们一直在路上。

参考资料

* 《敏捷开发者修炼之道》
* “Scrum 在中国——企业实施情况调查实录”
* http://www.scrumalliance.org

作者介绍 钱安川，ThoughtWorks 公司－软件咨询师、敏捷过程教练、开发者。敏捷项目管理工具 Mingle 的团队成员之一。关注中国传统文化知识。