SCRUM实践误区（一）

往往在团队接触SCRUM一两个月后，在自认为对SCRUM的方法和流程已经足够了解后，容易犯下几个小错误。但如果不能够及时加以纠正，将可能导致更大的错误。以致阻止SCRUM或者其他敏捷的正常实施和组织的顺利转型。

误区一： 越频繁变更越彰显“敏捷”

进入这个误区的人不在少数，大多数认为“快”就是敏捷，SCRUM中的Sprint周期如能缩短，团队将会更加灵敏；有些业务分析员，一边“享受敏捷的礼遇”，一边工作“开着小差”，觉得自己隔三差五给团队个交代就可以了。于是，想到哪里设计哪里，也不和客户保持经常的接洽，更不会去管理客户需求，所以是客户说的，无论是成熟与不成熟都扔给开发团队；这导致了产品三天一小改、一星期一大改；这样的“SCRUM”开发模式把团队完全被弄蒙了，还没等团队没明白过来怎么回事，就被教育“进入下一个迭代了”，一边重复工作着，一边被教育越“快”就是越“敏捷”。这种做法显然可笑，因为敏捷的增量型递增模型完全就不存在，团队变成了“无头苍蝇”。

不得不指出，这种现象尤其发生在互联网行业；这个行业的客户其实就是普通大众，而一半大众到底稀罕什么、另一半不稀罕些什么是经常发生的事情；例如说针对网页中的“动画Flash”，如果询问用户，差不多喜欢和痛恨Flash的一半一半。如果你不仔细分析和观察这类普通大众的需求，很有可能今天加一个，明天再去掉一个动画，并且开始争辩哪种方式最好。这样，既浪费时间又耗费团队的精力。

实际上，我们仔细分析，这类痛恨Flash的用户，是不喜欢使用不当的Flash，那些大而复杂的动画，下载时间长，还没有兴趣完整的看完的动画；设计不可避免变更，但绝不要用“缩小迭代周期”“短频快”的作法来遮掩设计的缺陷。

所谓“武功唯快不破”的那只是小说。