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