SCRUM 敏捷开发 基础及失败成功案例分析
 

2010-02-21 作者:小寒 来源:小寒的blog

 

什么是敏捷开发方法?什么是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个最有价值的东西 好吗?

二、如何知道团队在一个迭代可以完成多少任务呢?显然,迭代只有两周的时间,相对的计划会很准确,而且前面一个迭代的工作量,是这个迭代最好的参照。如果是第一个迭代,根据团队的经验做好一个合理的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的公司,无疑是璎珞天色的团队最能深入敏捷的精髓。

小结

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


火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织