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

导读：
　　社区Agile主题敏捷实施,企业级敏捷标签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. 我在工作中遇到了什么障碍。
　　每日晨会，目的有二点：
　　1. 加强团队交流和信息共享。互相了解彼此都在做什么工作，完成了什么任务。这样，每日的信息传递，可以让每个人可以更多的了解整个项目的业务和技术状况。并 且如果在工作中遇到障碍或问题，也可以在这时候提出来，请求大家的帮助（其实，一般在敏捷团队中，遇到问题，都会当场就提出来，或直接去找相关的同事，问 他们有没有处理过类似的问题，或者有没有一些建议）。
　　2. 促使每个人在早上做好一天的工作计划。这样，每个人一天的工作就会有明确具体的目标。这会直接提高一天的工作效率。
　　所以，上面的这个失败项目根本谈不上是在使用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个最有价值的东西 好吗？
　　二、如何知道团队在一个迭代可以完成多少任务呢？显然，迭代只有两周的时间，相对的计划会很准确，而且前面一个迭代的工作量，是这个迭代最好的参照。如果是第一个迭代&#x