读《Scrum敏捷软件开发》有感

本书是敏捷联盟及Scrum联盟创始人之一、敏捷估算及计划的鼻祖Mike Cohn三大经典著作中影响最为深厚的扛鼎制作,也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考。

敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:

工作和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说,尽管右项有其价值,我们更重视左项的价值

什么是Scrum?

Scrum是一个用于开发和维护复杂产品的框架,是一个增量的、迭代的开发过程。整个开发过程由若干个短迭代周期构成,一个短迭代周期称为Sprint,每个Sprint的建议长度为2到4周。使用Backlog来管理产品需求,Backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。

简而言之这是一套流程规范,我们参照这套规范进行软件研发就能应对不断变化的需求。

软件研发中最痛苦的就是需求变更,尤其是对于研发工程师来说,每一次的变更都意味着『对上一次的否定』,是非常打击士气的。尤其是以半年为周期发布一个版本的大项目,在传统瀑布研发模式下,首先产品经理需要规划大量的需求,是非常可怕的事情。尤其是当产品复杂度增大的时候,人的思维严谨度是有限的,就很难保证需求文档的质量。在开发过程中发现需求和设计层面缺陷的可能性就会大大增加,导致项目越到后期,变动越频繁,进而影响团队氛围。

Scrum则将大迭代调整为小迭代,在一定程度降低了需求设计的工作难度。同时也能尽快的将可用的产品交付给用户,得到反馈,以便在下个迭代进行调整。这样通过多次迭代反馈,最终交付给用户满意的产品。

那么我们如何理解『拥抱变化』呢,是否意味着我们采用敏捷开发之后,就可以肆无忌惮的改需求了呢?我们先来看看中国特色的敏捷:

极限编程
每天只工作8小时,工作量不饱和,没到『极限』。

拥抱变化
『我的需求很简单,这里改一下,那里的审批流程不要了……』产品经理上午说好的需求,下午就变。

迭代式开发
做完了发版,有BUG下个版本修。

Sprint冲刺
版本要上线,今晚大家通宵努力一把。

不少公司的管理层其实并不真正关注敏捷,他们并不想改变自己。他们被广告打动了,『用敏捷吧,交付更快,质量更高。』于是敏捷成为了他们的新玩具。敏捷好啊,简单易懂,成本低廉,记得更快交付哟。

迭代期内无变更

首先我们要理解一下什么是变更
我们通常意义上说的变更,就是频繁改需求。以前常听测试说的一句话是『都要发版了,还在改需求』,这种临近发版,功能细节的调整,风险是很大的。但这种情况在软件研发的过程中却经常发生。对于一个大功能模块来说,一个影响业务流程的改变对于产品经理来说可能是一句话,对于研发和测试来说可能就是前面几天的努力都白费了,还得再来一次,但时间可没那么多了,于是项目延期,出现质量问题的风险大增。

上面说到的是功能细节的频繁变更,还有一种是迭代开发已经开始,还没明确要开发什么功能。我觉得这种问题至少我是没有遇到过的,如果一个团队出现这个问题,那我认为是项目经理的重大失职。每个产品的版本迭代都是企业的一步棋:在某个时间,推出某些功能,满足某些需求,获取某些客户,打败某些对手,取代某些产品。若认同了这一点,则早在产品版本规划的时候,就应该确认此版本中应该大致包含哪些功能,而非到迭代计划会议或迭代中才会确认,更不会在迭代中间发生变化。

通过一番思考,我的理解是在迭代周期内不要进行影响业务流程的需求变更。倘若不得不这么做(该变更不能放到下次迭代调整),我们需要反思为何产生这种变更,是在做需求分析出现了偏差,还是客户的需求发生了本质上的变化。2-4周的短迭代本身就是对用户需求的渐进明细的过程,但渐进明细是要保证对用户需求的理解在大方向上是没有问题的,这样通过多次迭代,使产品越来越接近更满足用户需求的样子。而不能是每次迭代对用户需求的理解都是南辕北辙的。举例,用户想要一个能让他从A地快速移动到B地的工具。按照渐进明细的敏捷研发方式,我们第一个迭代做了一个滑板,第二个迭代做了一辆自行车,第三个迭代做了一辆汽车。在这三次迭代中,我们对客户需求的理解,在大方向上是没有问题的,并在每一次迭代都交付给了客户比上一次更接近需求标准的产品。假如我们第一次迭代做了一个扳手,第二次迭代做了一把螺丝刀,第三次迭代计划是做电钻,但在研发一周后产品经理突然领悟到做一个滑板更接近需求,于是要求改做滑板。那么以上三次迭代就是刚才说的南辕北辙式敏捷研发。

avatar

Code4Cocoa

A ThoughWorker