如何实现并改进可持续的速度?

　　作为敏捷宣言准则之一，许多将要部署敏捷的组织机构都非常看重“可持续的速度”(sustainable pace)。但要想实现可持续的速度却并不容易，这往往取决于团队管理的方式与组织机构的文化。当团队被要求加快速度的时候，他们如何能够提高节奏，并达到新的能够维持的水平?

　　Christoph Baudson制作了一个有关什么是可持续的速度的网页。首先他描述了可持续的速度的起源以及背后的概念，并参考了来自敏捷宣言的准则——在他看来，这是“得到了最广泛认可的定义”：

　　敏捷过程推荐可持续的发展。赞助者、开发者和用户应该能够无限期地维持恒定的节奏。

　　他解释了为何保持可持续的速度进行工作非常重要：

　　如果软件开发处于加班状态中，一切将会怎样?若干调查显示，在加班的第一周里生产力有所上升，但它将会快速下降并最终低于每周40小时标准下的生产力水平。在加班过程中，人们无法意识到其认知能力的下降，这将导致出错并最终降低质量等级。

　　可持续的速度并不是要放松下来并降低速度。恰恰相反，我们应该尽情地投入，并通过休息来恢复力量。长期来看，我们应该确保自己明智地投入精力，并结合“幸福理论”的研究结果来安排优先级。

　　此前InfoQ在可持续的开发速度意味着每周工作40小时吗?和可持续的速度——怎么理解?如何实现?中报道了可持续的速度。

　　在博客文章可持续的速度——最快交付软件的方法中，Neil Killick举了一个例子来说明为何保持可持续的速度进行工作很重要。对于团队在冲刺(sprint)中必须完成的用户故事数量不断增加，他这样描绘其影响：

　　我们要求团队交付的用户故事越多，团队能够花在质量方面的时间就越少，他们更容易选择抄近路，技术债务也就更容易出现，而且团队文化和效率也将更容易受影响，团队拥有的乐趣也会变得更少，团队的脑子会变得更迷糊，而对于交付软件我们也会更加难以预知。

　　为了提速而对团队的速度进行评测，将会损害团队工作所处的可持续的速度。Steve Ropa在测度的暴政中表示：

　　我见过许多团队在谈论如何加快速度，不过他们最终的结局总是相同的。他们提出某些速度方面的目标，或者更糟糕的是他们提出一个加速度的目标。这一切的逻辑结论也是可预知的。首先，团队会由于需要确保他们预估的时间完全准确而变得麻木，因为他们在面对错误时，将不会拥有调整的空间。其次，他们将开始把任何工作都预估的更高，从而给自己留出调整空间以备不时之需。这些行为都无法让我们建立起可持续的速度，也都不符合敏捷宣言中个体和交互胜过流程和工具的价值观。

　　Derek Huether撰写了流程改进中的一个教训，在其中他谈论了这样的需求，即在尝试变得更快速之前，先了解如何完成我们的工作：

　　我在组织机构中发现了一个不断出现的错误，人们在理解组织机构自身的流程之前，就尝试更快地做事情。如果在尝试提速以前，我们不停下来，认真地问自己是否优化了整个流程，那么任何成功都是短命的。我可以保证缺乏优化的速度无法持久。

　　Avienaash Shiralige在可持续的速度：文化在其中是否扮演了某个角色?中写道：

　　可持续的速度不是一场马拉松，而是一系列短途冲刺(sprint)，我们反复停下来，重新带动自己、反省而后开始新的冲刺。因此在冲刺中我们绝对需要一些放松以实现最终的目标——可持续的速度。

　　Shiralige参考了来自Geert Hofstede对文化的研究。Geert测量的参数之一是权力-距离指数：“社会中的弱势群体对权力分布不均的接受和期望程度”。在那些权力-距离指数较高的国家，实现可持续的速度的难度很大：

　　构建一个能够开放地提问、挑战理念并分享思想的组织机构，最终将能够帮助组建自组织的团队，不过完全没有等级观念的心态是极其艰难的——更何况——这是一场面对我们自己的文化/心态的不间断的斗争。

　　尽管就像Shiralige说的那样，文化难以改变，但我们无法忽视这一问题：

　　除非我们能够解决组织机构中的文化问题，否则我们不可能达成敏捷。

　　各位读者，你是如何在团队中运用可持续的速度的?你如何将团队交付的速度提升，并确定在一个新的可持续的等级上?

原文转自：http://www.infoq.com/cn/news/2013/08/sustainable-pace-achieve-improve