当初初次尝试Scrum，便即取得成效之后，感觉很兴奋，到处跟人讲Scrum的好处，“用了以后，腰不酸了，腿不疼了，上楼也有劲儿了”，恨不得呼吁门口卖包子的阿姨也来尝试一下，可以卖更多的包子。而眼看当下，Scrum有在公司生根发芽的趋势，好几个组在尝试实施或者已经实施，我反倒觉得有点不安，就像推荐朋友去看一场自己觉得好看的电影，等朋友去了以后反倒担心不合对方的口味，空耗钱财。与其这样，在更多新的team尝试Scrum前，我觉得是时候该泼点冷水，让包括我自己在内的、听到敏捷这个词就开心的TX们冷静一下。

某次介绍Scrum的讨论会上，有个TX问了个很有意义的问题：你们team的人没变，团队能力没变，怎么可能用了Scrum就能把团队效率提升那么多？！这是一个很客观的问题，因为当有人说“Scrum，成了！”的时候，这很容易给人形成一个印象，是Scrum这个东西在起作用，即使再普通的团队，用上就起效果，就像神龙教众喊一嗓子“洪教主仙福永享，寿与天齐”之后就变身一样；或者说，只要团队用了Scrum，然后大家就可以静静地等着，等着团队的功力慢慢提升。这里我想强调的是：Scrum绝不是终南山活死人墓小龙女的千年寒玉床，躺上去睡觉就可以提升功力。如果一个团队使用了Scrum之后取得成功，我认为这个成功九分属于实施Scrum的人，只有一分属于Scrum。

为了解释为什么我下这个结论，先来看看Scrum是怎么回事儿。据Scrum教育专家考证，Scrum这种团队合作的方式最早起源于二战后的日本，因为国家经济遭受了巨大的打击，很多公司都面临着生死存亡的时刻，这个时候，好几个公司都采用了这样一种尝试：把公司内各个部门最杰出的人召集在一起，把他们关在一起，目标只有一个，在指定的时间里设计出一个用作公司未来战略的方案或者产品。而做这种尝试的公司，大都生存了下来并且高速发展了。这种尝试，被后来的方法论学者借鉴来，逐渐发展出后来的Scrum。显然，最初那一群群被组织在一起的来在各个部门的员工，他们不知道自己在Scrum，他们面临的是公司的生死存亡及与其相关的个人的利益得失，他们的目标就是在特定时间里设计出可以让公司和自己活下来的产品、方案，可以想象这种在压力和求生存的欲望下迸发出来的工作激情，与个人在领域内的经验相结合，再加上团队间的合作、互补，最终产生出高质量的输出不是一件很困难的事情。

不管这些“考证”是否属实，我觉得这种说法里蕴含着Scrum的精髓，就是上面用黑体标出的部分----团队人员来自各个部门（对应到我们团队的需求，开发，QA，SCM），团队要在指定的时间盒内（固定周期的sprint）做事，团队要有一个目标（为每个Sprint设置目标很容易被忽视，但很重要）。当然，这些还只是外在的施设，不要忽略参与到其中的那些人，他们在面临着存亡的压力时，所焕发出的高效的能量。

回到我们现在实施Scrum的团队，如果只是按照教科书，把不同角色的人召集在一起，使用周期性的sprint来管理迭代，设定每个sprint的目标，如果只做这些，那十有八九团队还会在不断出现的问题中渐渐磨去热情。对Scrum潜意识上的依赖会让人觉得，嗨，我们现在正躺在Scrum的千年寒玉床上，几个sprint以后，我们就功力大增了。但是真的走了一两个sprint后，就会发现，问题还在那里，并且可能不断出现新问题，怎么回事？用了Scrum，怎么不见效？

-------------------------------------------冷水分割线-----------------------------

我们知道软件开发是一件非常复杂的工作，如何保证在预期的资源下产出高质量的软件，这个课题从软件行业产生起就一直被激烈探讨。现在来看，我个人认为大体有两个方向，传统软件工程领域内的如瀑布、CMMI、RUP（不算太传统，但是同样强调流程）等强调的是软件开发流程的作用，通过建立一套坚实的流程机器，提高流程质量来提高产品质量；而相对应地，包括Scrum在内的敏捷软件开发方法，则强调的人的作用，敏捷宣言的第一句就是“个体与交互胜过过程与工具”，所以保证敏捷团队成功的，不是敏捷方法自身，是参与到这个过程中的人。

Scrum没有让问题走开，相反，它会让问题变得更明显（咦，一个sprint过去了，我们好像没什么产出吗？）。这种情况下，团队必须具备识别问题和解决问题的能力，找出当前团队面临的最大问题，是什么在阻碍效率提升，是什么让我们觉得不happy，是什么让我们在尝试敏捷的时候反倒笨手笨脚......然后，团队来分析问题，找出解决方案，小步快走地投入实践，然后反馈，再修正，进入PDCA的良性流程。这里我可以拿XP的哲学来说明一下它是如何解决软件开发环节中的问题的：

既然对需求的理解很重要，那么就让客户跟我们坐在一起，随时沟通

既然代码Review很重要，那么就让程序员结对编程，每时每秒做review

既然测试很重要，那就先写测试再写代码，做测试驱动开发

既然集成测试很重要，那么就从一开始就集成，每天，每时，随时集成，持续集成

...

XP在应对软件开发环节中的问题时，把好多方面都做到了极限，所以它叫极限编程。我们在软件开发中碰到的问题，也需要这种见解和魄力来解决，团队成员通过有效沟通确诊问题，然后确定解决方案，激进一点的也没问题，然后，咬牙坚持下来。这个说起来容易，实际操作的时候，需要团队成员间的信任、包容，以及共同的想把事情做好的愿望，甚至在某些方面要改变一下自己的做事方式。首先团队成员应该具备如自律，严谨，包容，有责任心这类品质，然后在彼此的合作中，将这些品质逐渐凝聚为团队的品质，那我们说这个团队才是高效的团队，成功的团队。

说到这里，感觉所有的事情都要人来解决的话，那么Scrum起什么作用？我觉得，Scrum打开了一个机会，在传统的以项目经理为主导的command and control的工作模式之外，提供了另一种工作风格，即：在自组织的、自律的团队中，团队成员平等地参与决策，参与工作，共同对最终结果负责，团队自己迈过问题向前走，共同提高共同进步，这个过程中，分享、合作、共同决策以及由此带来的新鲜的体验、成长、快乐和成就感，是Scrum这个机会能够提供给我们的。当你作为一个新员工，觉得不熟悉这个环境而羞于提出问题的时候，你可以想到-嗨，我们在Scrum，我们在努力让这个团队更好，我的问题可以让我进步，进而让这个团队进步；当你作为一个老员工，产生了在团队中应该得到更多尊重的想法时，你可以想到-嗨，我们在Scrum，我们大家是平等的，我没有更多可以让其他人服从的权利，虽然我可以提出自己的看法，但我不能强制别人接受，团队应该在合作的氛围中提升；当你意识到自己长久以来的不好的工作习惯在影响团队的时候，当团队成员间有矛盾发生的时候，当任何负面问题发生的时候，你可以想到，嗨，我们在Scrum，我们是一个团队，只有持续地改善才能让团队变得更好，跟团队目标相比，其他的事情或许不那么重要...

今天，我们踏上Scrum这条路，路的终点有两个，一个通向成功，一个通向失败，我们每个团队成员任何一个让团队变得更好的尝试（一个建议，一次为了提高代码质量的代码review，一次增强成员间了解的私人或者团队沟通）都会让我们更靠近成功的方向，而相反的，任何一种对尝试的放弃或者对工作和敏捷实践的漠然，都会让我们滑向失败的方向。

那么，为了团队变得更好，让我们做的更多一点吧，以Scrum的名义。