敏捷的三種誤區和五種改進

三個主要誤區

第乙個是重視流程忽視人。敏捷宣言開明宗義指出「人和溝通勝過過程與工具」。但是仍然有很多企業試圖通過創造乙個完美的流程來實施敏捷。不可否認，合理的流程對於提高團隊效率有一定的作用，但是企業真正要從敏捷改進中獲益必須落實到人的改變上來。

第二個是重視管理輕視工程。很多團隊將敏捷等同於開開站會、做做迭代、搞搞回顧。到頭來，一切流於形式。敏捷說到底是對於軟體工藝性的認識回歸，那麼持續整合、自動化測試、設計、重構這些手藝是繞不開的。不從這些根本的手藝上解決問題，各種眼花繚亂的溝通手段實際上徒然增加了團隊的成本。

第三個是重視指標輕視過程。很多團隊特別是從cmm型組織轉向敏捷的團隊，熱衷於設計所謂的敏捷度量體系。度量應該是幫助團隊增強信心和持續改進，指標不應成為目的。我們要關心的不只是站在**，更應關心我們將走向**。

要解決這些問題沒有任何靈丹妙藥，從來也不存在乙個完美的、放諸四海而皆準的流程。我們在幫助各種企業進行敏捷流程改進的過程中，總結了幾種改進模式，這裡跟大家分享一下。

五種改進模式

跳躍：團隊作為整體從一種實踐直接切換到另乙個實踐方式上。

有些實踐我們知道其目標，並且知道這種切換對團隊的影響較小，或者不適於採用逐步推行的方案，我們就採用跳躍的方式。

例如，配置管理工具切換。某團隊原來使用的配置管理工具是clearcase，為了享受到svn的原子提交、低成本分支等好處，我們往往採取跳躍的方式，即整個團隊立刻從clearcase切換到svn上工作。這是因為配置管理的切換總的來說對於團隊的工作方式影響比較可控，而且使用簡單。

並行：團隊中部分組織或個人使用原有實踐，而另一部分切換到另乙個實踐方式。

有些實踐知道其目標，但在整個團隊推行可能會對工作方式造成較大影響，或者團隊中的某些組織或個人不具備切換到新的實踐方式上的條件，我們就採用並行的方式。

例如，專案組持續整合。團隊中某個專案組具備較好的持續整合基礎，另一些專案組基礎較差。如果在整個團隊推行持續整合，就可能對團隊產生較大的衝擊。而且持續整合的具體方案可能需要在乙個專案組內試驗。這時候，先在乙個專案組做起來，然後推廣到其他的專案組。

階石：為了達到乙個長遠的目標，先實現乙個較近的目標。

有些實踐有長遠的目標，但還看不清達成目標需要的路徑，如果知道做某件事情一定有助於達成目標，可以先完成這件事情。例如，單元測試。有時候希望在某些團隊中實施單元測試，但缺少合適的測試框架，那麼在確定測試框架之前，實際上很難展開後面的工作。這時就可以先全力構建這個測試框架。稱這種方式為階石。

簡化：為了達到乙個長遠的目標，先實現乙個較為容易實現的目標，但是這個目標仍然能夠給我們帶來好處。

有些實踐我們有乙個長遠的目標，但是對於這個長遠的目標還不太清楚，或者要達成這個長遠目標，要走的路還很長。如果有些做法可以給我們帶來一些好處，雖然不如長期目標帶來的好處那麼大，我們仍然可以先做起來。

系統測試和低成本測試的拉通。系統測試和低成本測試拉通是個長期而艱鉅的任務，比如可能需要良好的基礎設施的配合。但是我們可以做一些簡單的事情來獲得相似的好處。

暫停：暫不實施某個實踐。

有些實踐，團隊不具備實施條件，或者對團隊的衝擊較大，可選擇暫不實施。例如tdd。實施tdd需要較高的條件。如果團隊不具備這樣的條件，貿然推行難度非常大，這個時候常常選擇暫停。

上面的5個模式所在維度並不相同。比如，並行是從組織的維度考慮的，而階石和簡化是從目標維度考慮。另外，在不同範圍內看，同樣的實踐也可能屬於不同的模式，需注意模式的目的是為幫助參與者清晰把握問題本質，認識解決方案在時間和範圍上的侷限性。所以把實踐與模式繫結的做法也不提倡。