什么是敏捷开发方法?什么是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，无异是火上浇油。

原文转自：http://www.ltesting.net