当初初次尝试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的名义。