“Sprint”一词对过渡敏捷不利？

作者 Amr Elssamadisy 译者 麦天志 发布于 2008年10月16日

领域

过程 & 实践

主题

敏捷 ,

企业级敏捷 ,

敏捷实施

标签

Scrum

于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常用的“猪”和“鸡”的比喻上出现。提出问题的主要指出有些人认为用“猪”来形容人是很冒犯性的事情。不过很多时候一些导师都指出，其实提出足够的解释是没有问题的。问题不在于用什么字眼，而是如何带出其讯息。

译者 麦天志 现就职于Odd-e从事团队教练工作，从小对编程产生兴趣，毕业於香港大学，主修计算机科学。

1. 返回顶部

   我倒认为这样的误会在发生

   发表人 徐 毅

   会有种倾向是希望尽量的在sprint中挤榨team的生产能力，长远来看，无疑也就是希望马拉松运动员不停地以高速间歇性地冲刺来完成全程。当然这种误会似乎并不是因为sprint的意思而来。

   回复

2. 返回顶部

   敏捷与效率提升

   发表人 bin benfei

   其实大多下决心推行敏捷的公司的领导，不管是否承认，都有提高团队效率的期望。让大家保持冲刺的速度跑完马拉松相信是不少主管的梦想。
   所以在引进敏捷时候，为了迎合领导的梦想，制定sprint计划的时候，冲刺的成分还是很大的。

   回复

• 更早的 >