可持续的速度——怎么理解？如何实现？

以可持续的速度工作”，这是 《敏捷宣言》的原则之一，也常常是难以实现的一条。 Agile Leader新闻组最近开始讨论可持续速度的相关话题。

什么才是真正“可持续的速度”，如何始终如一地达成可持续的速度，这是讨论围之展开的两个中心。

Bob Sarni引用敏捷原则，开启了这次讨论：“敏捷过程提倡可持续的开发。出资方、开发人员和用户应该能够保持恒久稳定的进展速度。”

他进一步说明：

在我与众多组织和团队的工作经验中，可持续的速度看来是这些团队和组织共同面临的问题。要维持可持续的速度，需要很多因素——产品的路线图和承诺、愿景、速度/流/节奏、工作与生活的平衡、可见性、企业文化、个人问题、信任、多任务，等等。

团队层面要做到可持续的速度难度更高，因为团队中每个人都有自己的可持续速度，并且影响团队的整体速度。

Manoj Vadakkan认为：无法以可持续速度工作，其问题在于，组织在实施敏捷实践时，没有深入理解背后的价值观和原则。

我看到的实施Scrum主要的问题在于：它被当做迭代过程实施，没有以原则和价值观做基础。不知道大家是否同意：可持续速度的问题，是我们的流程没有以速度为基础造成的诸多问题之一。

我担心的是：总体来说，关于这一点我们强调的还不够——不以敏捷的价值观和原则为基础，这个（Scrum）不会有成效。

其他人也同意：如果不以敏捷价值观为起点，敏捷和Scrum的转换将不可持续，团队和个人会面临精疲力竭的风险。Scott Duncan讲述了自己与大型组织工作的经验：

1. 就我所知，他们现在希望人们可以“持续”的，称为“职业周”，比如50个小时，或是每天多加班2个小时，而且不会有加班费或任何补偿。
2. 基于小时数的估算方法，假定人们每周高效工作至少40个小时（即使期望人们每周只工作40个小时），每个特性和需求都会以小时数估算，然后团队中的人员数目乘以40，再乘以按周计算的开发时间段，再把得到的结果用需求和特性的小时数填满，这样团队和项目所有的小时数就被充满了。
3. 相信真正的职业人士会“一切可能把工作完成”，因此并不真正关心可持续的理念。
4. 着手工作时，假定所有的时间都已经被占用，因此任何没有事先规划的事件（比如变更、设计“发现”等）都会假定使用加班来吸收掉。

Manoj Vadakkan引用了自己在Scrum联盟网站上的一篇文章，他在其中的总结是：

当然，客户不关心你的雇员是否每天长时间工作，可你是否跟他们讨论过产出代码的质量？试着告诉他们不利一面，他们也许会开始关心。长期看来，客户如果想在下个版本中改变代码，他们才是付账的人。你是否认为可持续速度值得拥有？也许我们应该跟客户商量商量。也许他们会同意质量很重要，也许不然。有一点可以确定：我们不能替他们拿主意。

Karen Greaves基于自己的经验，提供了具体建议：

我现在在自己组织内的工作方式是：

1. 断开工作小时数和工作效率或是交付价值之间的联系。作为管理人员，永远不要度量工作小时数。也就是说，不要用工时表，不要有固定的工作小时数，甚至不要暗示员工“必须”每天工作8小时。更应该做的，是设定人们应该交付的成果的期望值。
2. 把关注点放在完成工作上，而不是保持忙碌。如果你今天工作不在状态，不如回家。如果你今天小宇宙爆发，而且工作不断取得进展，那就继续下去。引用一下Kent Beck那句话：“如果你不想工作，那么你在办公室里度过的每一个小时，都等于是加班。”
3. 永远不要让人们周末加班。
4. 提供一个有吸引力的目标，这可以激励人们达成它，而不是编造一个无法实现的截止日期。
5. 不要把工作安排得太紧。留出人们估计无法如常工作的时间。我们有特快专递日、实验室日，还有正常的周五学习时间。

目前来看，这些做法在我的团队内效果还不错，虽然业务人员很难接受，但是我对它们的坚持还是有所收获。当我一年多前接受我现在的工作时，团队会定期在周末和深夜加班。去年，我们可以做到在每个发布日期当天的下午6点之前发布版本，而且从未在周末加过班。质量改进了，大家的工作满意度提升了，人员流失率也降低了。工作效率虽然有所波动，但与其直接相关的，是版本发布的目标和规划。

在Agile Leader讨论组外，还有一些人就可持续速度的话题发表了自己的看法。

Bob Hartman（“Agilebob”）有一篇文章《刚接触敏捷吗？从以可持续的速度工作开始吧》。他在其中指出，如果无法做到以可持续的速度工作会有什么后果：

1. 缺陷会增加。疲劳的团队会产生更多缺陷。
2. 工作产出会降低。疲劳的团队在更多时间内完成的工作更少！
3. 士气会大幅降低。这会导致雇员们在项目的最低潮期时离职。
4. 互相责备的游戏会更普遍。（你之前没说X，所以不是我们的错；我当时就说了来着；当时没那么做；当时就那么做了……）
5. 团队开始抛弃优秀实践，转而选择“看起来”更快的时间。抱歉，比起只是写代码，然后抛给墙那边的QA去测试来说，测试驱动开发（TDD）确实更快！

他为敏捷团队的主管们提出强烈建议：

项目经理和Scrum Master需要观察团队的精神和身体健康程度。要维持可持续的速度，主管必须要能感受到团队的状态。把上句话再读一遍，再问问你自己：做项目经理时，如果发现团队不健康，就让他们减少工作时间，上次这么做是什么时候？

在您的团队中，“可持续的速度”意味着什么？您是如何确保可以维持下去的？