如何實現并改進可持續的速度?

　　作為敏捷宣言準則之一，許多將要部署敏捷的組織機構都非?？粗?ldquo;可持續的速度”(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