Scrum，幸福来得挺突然

    某天，正在驾校学车，突然收到Boss的短信“请将敏捷开发方法总结一下，我们全公司推广”，当时有个师弟刚开始练倒车，正被师傅揪着耳朵教训，想想自己走过来的路，偶一阵得意。
    偶现在的公司做的是金融服务，软件开发团队分为四个事业部，大约一百多号人，偶在三个季度左右的时间里担任其中一个事业部的开发团队负责人。现在回忆起最初的那段日子依然心有余悸，相信好多在软件行当里混的兄弟们都经历过某些类似场景：
创业型公司，来自产品和业务部门的需求积压着一大堆，而且一个比一个紧急；
包括QA和SCM在内也就十个人左右的团队像一台小挖掘机，一点点消耗着需求大山；
包括负责人在内的所有人都参与开发，解决关键问题紧急问题，松散的任务跟踪导致了一边是做不完的事情，一边是大量开发人员灰色时间的浪费；
生搬硬套的所谓RUP流程划分了一堆角色，定义了各个角色在流程中要做的事情，于是每个角色很“负责”地履行自己的职责，你会看到产品负责人费了好长时间整理的的需求文档被开发和QA团队不断地否决重做，开发团队发布的产品因为达不到测试标准不断被QA踢回，整个项目的周期没有办法有效控制；
业务人员急到骂娘，项目还是会卡在某个环节上，因为环节上下方对某个问题的不同看法而停滞不前；
团队士气低落，开发人员有任务就做，得空就做布朗运动，看博客，玩网页游戏；
嘈杂的开发环境，不断被业务人员和用户投诉打扰，开发人员日有效工作时间在50%左右；
做出来的产品经过开发和QA的测试都没问题了，一上线就出事，然后被业务的同事一顿臭骂，开发团队在公司里的地位越来越低，被鄙视程度越来越高；
大家偶尔也会一起坐下来讨论如何改进，却往往找不到有效的方法，最后随波逐流；
每天都在忙，下班以后脑袋里却空空如也，一无所获；
一切看起来都没有拯救的希望，你似乎要永远地跟问题生活在一起......
    嗯，我承认我有些渲染气氛，不过上面描述的情况都在我所在的部门发生了，作为负责人的我必须找到一个出路才能活下来。这个时候，我读到一本名叫《硝烟中的Scrum和XP》的小册子。
    至今我还记得读这份文档的心情，仿佛久病的人找到了可以疗救顽疾的灵药，150页的pdf文档，一天的工作时间，细细地读完，生怕漏掉一个字。如果可能，我真想当晚就召集team里的同学，把文档中提到的敏捷方法共享给大家，然后马上开始实践。
    实际开始跟team探讨和实施Scrum的时间是在接下来的两天里，把分散的team成员集中到一起，腾出一面墙做任务墙，赶着定制Backlog模板......（此处略去实施过程）
    实施Scrum是在六月初，七月份我加入到另外一个部门，原部门继续实施Scrum。前两天收到了一份来在公司QA team的项目统计报告，我待过的那个部门7-8月份完成的任务量超过了上个季度的总工作量，而且产品质量还有所提升--这是在我这个原负责人离开的情况下做到的（原来在的时候还可以帮团队分担相当一部分工作）；考虑到Scrum是从6月份开始实施的，这样算起来Scrum实施前后的团队战斗力提升了50%左右。
    于是，就有了开头我收到的Boss发来的那条短信。收到短信后，仔细考虑了一下Scrum到底如何给团队带来改变，结合实际的实践过程，整理了一份演示文稿，思虑再三，始终是原著《硝烟中的Scrum和XP》讲解的透彻，于是把自己的文档命名为导读，跟原著一起附在下面，共享给在开发困境中挣扎的xdjm们。
原著：《硝烟中的Scrum和XP》-- http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches
我整理的导读： -- http://www.slideshare.net/ohmygodlzl/scrum-1993831
如果slideshare访问不了，请从附件下载