几个Scrum误用模式

Scrum被腐蚀或歪曲之后有这样一些典型症状。请注意，不要把它们与新（但是真实的）团队所面临的“成长的烦恼”混为一谈。比如，总做不到准时开始站会虽然并不理想，但如果有合适的动机，这个过程就可以改进，而且并不意味着团队无法到达成功的彼岸。

测试Sprint

质量保证应该作为开发流程不可分割的一部分。一个需求如果不完全满足“完成标准”（参见捷径11）所规定的质量要求，就不能认为它做完。但在有些时候，做法会有点儿走样。具体表现是把前面几个Sprint称为“功能”Sprint，先一股脑儿批量做完新代码（让人觉得有进展），然后在随后几个“追赶补齐”Sprint中专注于发现和解决问题。

对于这种行为，最典型的辩解是团队想通过这样的方式验证他们的工作：至少得向用户展示一些最基本的功能。在碰到这种情况时，我会向团队指出，即使他们以Sprint方式工作，但并不意味着他们没有偷梁换住，实际是在搞瀑布式开发。记住，功能没有经过全面测试，是不完整的，不可发布的（因而也毫无用处）、存在高风险的。

这种误用模式的另一种表现形式是程序员和测试员不在同一个Sprint中工作。比如，测试员可能比程序员晚一个Sprint。出现这种情况的基本原因是测试自动化还不成熟，只好严重依赖于手工测试。这种交错的Sprint注定会造成前面所说的“追赶补齐”Sprint。

没完没了的Sprint0

Sprint0不是真正的Sprint，而是一个人为的概念，通常用于描述团队在开始真正的Sprint之前所做的准备工作。

这些准备工作不一定有时间表，也不需要具备实际Sprint的一些要素，比如Sprint列表和准备好的需求。

尽管我不太喜欢容易误导人的Sprint 0标签，但我对准备阶段这个概念并没有意见。我对Sprint 0最大的看法是，有很多不恰当的工作被塞入Sprint 0，使真正的Sprint被推迟开始。如图1.4所示，让我们看看哪些应该放入Sprint 0，哪些不应该。

我们不能仅仅因为图1.4中“不包括”部分里的东西看似比具体的功能需求更含糊，就说它们不能被估算、计划和分拆成更小的任务，从而不能放入Sprint。恰恰相反，我想说明的正是因为这些任务含糊的特性，才使我们更有必要用Sprint机制来提供更好的可见度和更严格的控制。

长短不一的Sprint

规则的Sprint持续期很重要，具体原因可以参见捷径8的详细描述。

对于Sprint长度的波动，我所听到的最常见的理由是挤点儿时间出来完成一些快要完成的需求，好让Sprint回顾会有更吸引人的成果。

我认为，只有下面这两种改变Sprint长度的理由是合理的：

·　新建团队在成立初期做尝试；

·　在最后一个Sprint的最后一天之前，所有工作都做完了，如图1.5所示。

单独估算

在我工作过的非Scrum环境中，这种情形很普遍。要求资深开发人员单独分析估算每一个任务需要花多少时间。你也许会问，既然资深开发人员最有资格做估计，为什么还有问题呢？对，这恰恰是问题之一。虽然资深开发人员是团队里最有经验的人，但在大多数情况下，他/她都不会做具体的开发工作。毫无疑问，专家和团队里做具体任务的人是有能力差异的，正因为此，他/她的估算和最终实际需要时间就会有差异。

此外，工作不是某个人的，而是整个团队的；所以团队应以集体身份进行工作估算（参见捷径14）。如果只有一个人在做估算，就不会有人检查和制衡。如果这个人当天不在状态或听错重要细节而做出错误的假设，怎么办？如果各有所长的团队成员一起做估算，那么信息在经过层层处理和过滤之后，就不太容易出现前面提到的类似过失。

依赖于规范

“如果这个没有被写入规范，就不该做。”或者“我的实现和规范里写的一模一样。”如果出现诸如此类的评论，则可以断定团队已经呈现瀑布式开发的雏形了。这也表明团队成员已经变成彼此间不交流的官僚主义者了。所谓的规范，只是一个信息存放点或提醒而已。实际需求是通过团队同声唱响的美妙音符以及开发出真正能工作的软件来表现的。

找错ScrumMaster

如果ScrumMaster不具备捷径4提到的特性，更没有起到捷径26应该有的效果，那么十有八九你是被冒牌货骗了。怎么识别冒牌货呢？嗯，如果这个ScrumMaster总是自说自话独断专行，做产品和技术相关决定，或直接分配任务，或逼着团队经常加班……简而言之，就像暴君，就说明有问题。