于 Agile Journal 九月刊登的文章中，Joe Kreb，AOL 策划总监, 认为“Sprint”一词对向敏捷开发过渡有负面影响。他认为软件项目像马拉松多于全速冲刺（“Sprint”一词字典上的意思）：
我们假定软件项目需要多于四星期的时间。所以他们不能看作如运动那样一系列的“冲刺”，但应该看成长跑的“时间盒”（time-boxes）或者里程碑。
所以，当团队尝试以全速进行开发，每个迭代都“冲刺”，马虎、筋疲力竭、失误就会渐渐产生：
就有如运动员不断冲刺也会有容易出错一样，敏捷团队可能为了维持高速度而出错。最后执行时表现很有限，而 团队也不能以可维持的速度下开发。到了那时，团队亦已经筋疲力竭，技术债台高筑（technical debt，意思指维持不良代码所需要更多的时间精神，而且因为没有改善而累积）以及士气低落。即使团队开始时很好，几个迭代之后就有落后。虽然我们希望团 队自我管理而且可以满足期望，团队教练会保护团队免受外面骚扰。
所以 Joe 认为我们应该留意团队工作的质量和士气，留意有没有这种消耗过早发生：
所以当我们观察组织敏捷程度时，我们留意的不仅仅是团队在早期的开发速度（velocity），更必需留意之后的迭代去肯定团队燃尽的是未完成的系统功能，而不是开发团队的精神。要留意团队是否找到自己的稳定状态，管理人员需要留意开发速度以外的度量（metrics）。质量和士气跟速度同样重要。质量可 以简单理解为跟踪未解决的缺陷，士气就是在回顾（Retrospective）时收集回来的团队平均满意程度。较长的项目特别会受到早期迭代中稳定速度的 好处。虽然这“冲刺”是很有鼓励性的双关语，但其好处只能持久一段很短的时间，可能半路中途就出问题，像很多马拉松选手一样。
Joe 最后提出这个建议：
一 方面，冲刺可能给团队和其他行政人员带来错误讯息，这需要很少的解释，因为人人都知道冲刺是很短的，可以理解成为“快”，但也会理解成“加班”或者“过份进取的安排”。解释增量迭代可能不会给人像冲刺那样的理解，但如果期望长远的敏捷，可能马拉松的比喻会较易找到团队稳定的状态。如果有很好的理由去“冲 刺”，或者考虑多花些时间在迭代中回气。
这是个有趣的论点；我们知道“全速冲刺”和“可维持速度”（eXtreme programming 提倡的 sustainable pace）互相矛盾。而且也是原文作者经验中新团队使用 Scrum（以及敏捷）时尝试开发的太快所遇到的问题，这是其中一个原因嘛？
查看英文原文： Is a “Sprint” Detrimental to an Agile Transition?
译者附注：
在译者印象中，这方面的误会很少发生，这很可能是在中文社区当中从来没有过份强调“冲刺”字面上的意思，即使英文社区也没有同样问题发生过。
不过类似的问题却发生在 Scrum 常用的“猪”和“鸡”的比喻上出现。提出问题的主要指出有些人认为用“猪”来形容人是很冒犯性的事情。不过很多时候一些导师都指出，其实提出足够的解释是没有问题的。问题不在于用什么字眼，而是如何带出其讯息。
评论