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访问不了，请从附件下载

恭喜你们取得的成功。不过如何保持下来和推广到所有的团队是非常有挑战性的工作。

与楼主有同感，细读《销烟中的scrum和xp》，给我带来很多的灵感。
希望楼主再分享你的实施感受
支持一下。。。。。

很多人都说scrum不适合组织级别。不知道接下来lz公司的情况会如何？个人恳求能否每周通报一下公司推广后的情况和问题？

感谢楼主，共享自己的东西。
一直看infoq介绍scrum但自己都没有怎么认真学，谢谢你的资料。呵呵！

楼主，太感谢你了啊！我正处于和你之前的环境下～

我们项目组一直是在实践scrum，但是现在觉得越来越像iterative了

感谢几位的回帖，再补充一点信息。

一. Scrum实施门槛不高，但也不是全无条件。我原来的team之所以能很快见效，个人认为具备了以下条件：
1.人的因素。工作成员都是以工作为重，没有政治，大家都直接面对着业务部门的压力，自发的寻找解决问题的方法；现有系统是团队成员开发的，大家对这个系统的内部结构很了解
2.团队因素。作为事业部的团队具备了完成backlog需要的所有能力，包括分析设计开发测试以及配置管理等，而且这些角色都可以归入统一的调度，并且大家认可敏捷开发
3.环境因素。团队成员可以按需很方便的集中到一起，大家彼此看到到，彼此听得到；有一面任务墙可以布置，不会被公司或者物业来骚扰
4.对SCRUM的理解。个人认为团队对Scrum的理解比较到位----Scrum就是一个提供了简单基础的框架，在这个框架基础上可以因地制宜引入任何可以解决我们问题的实践，所有实践都面向软件开发的基本目标----更快的开发速度，更高的产品质量。

二. 关于Scrum在公司范围的实践，还没有正式开始，所以可以介绍的信息不多，现在能够分享的就下面几点。
1.这并非是一项组织级的实践，原来的团队也是划分为几个小团队的，Scrum的实施是以这些小团队为单位实施
2.目前仅仅是把原文中提到的PPT跟所有人分享了一下。我是有担心的，因为原来的团队是自发地采用Scrum来解决问题的，如果从外部把这样的实践推给一个团队，推动力是个问题，毕竟，与问题相处可能比改变现状更容易。
3.现在的团队中，QA和SCM是独立的部门，现在的流程中他们会成为瓶颈。按照Scrum的要求，团队要能够完成软件开发需要的所有工作，这很可能会需要团队的重新组织----这显然不是一项简单的工作。
由于各种原因，我可能没有办法做到“黑暗浪子”提到的按周通报，不过有较大的进展之后，我会来更新一下。坦白讲，由于上面的到问题和对领导层的担忧，我个人也不怎么看好Scrum在公司范围的实践。

很高兴看到有同样对Scrum感兴趣的朋友，个人感觉只要条件具备，实施成本很低，学习曲线不高，对人员的要求也不高，见效比较快，更多的信息或者问题，原因跟大家继续分享，探讨

听过Scrum作者的演讲，还不错，听吸引人的

切中问题的改进，2-3个月足见效果。
谁要说1-2年后会有效果，那就是永远不会有效果。