敏捷開發的三種誤區和五種改進方式
三個主要誤區
第一個是重視流程忽視人。敏捷宣言開明宗義指出“人和溝通勝過過程與工具”。但是仍然有很多企業試圖通過創造一個完美的流程來實施敏捷。不可否認，合理的流程對于提高團隊效率有一定的作用，但是企業真正要從敏捷改進中獲益必須落實到人的改變上來。
第二個是重視管理輕視工程。很多團隊將敏捷等同于開開站會、做做迭代、搞搞回顧。到頭來，一切流于形式。敏捷說到底是對于軟件工藝性的認識回歸，那么持續集成、自動化測試、設計、重構這些手藝是繞不開的。不從這些根本的手藝上解決問題，各種眼花繚亂的溝通手段實際上徒然增加了團隊的成本。
第三個是重視指標輕視過程。很多團隊特別是從CMM型組織轉向敏捷的團隊，熱衷于設計所謂的敏捷度量體系。度量應該是幫助團隊增強信心和持續改進，指標不應成為目的。我們要關心的不只是站在哪里，更應關心我們將走向哪里。
要解決這些問題沒有任何靈丹妙藥，從來也不存在一個完美的、放諸四海而皆準的流程。我們在幫助各種企業進行敏捷流程改進的過程中，總結了幾種改進模式，這里跟大家分享一下。
五種改進模式
跳躍：團隊作為整體從一種實踐直接切換到另一個實踐方式上。
有些實踐我們知道其目標，并且知道這種切換對團隊的影響較小，或者不適于采用逐步推行的方案，我們就采用跳躍的方式。
例如，配置管理工具切換。某團隊原來使用的配置管理工具是ClearCase，為了享受到SVN的原子提交、低成本分支等好處，我們往往采取跳躍的方式，即整個團隊立刻從ClearCase切換到SVN上工作。這是因為配置管理的切換總的來說對于團隊的工作方式影響比較可控，而且使用簡單。
并行：團隊中部分組織或個人使用原有實踐，而另一部分切換到另一個實踐方式。
有些實踐知道其目標，但在整個團隊推行可能會對工作方式造成較大影響，或者團隊中的某些組織或個人不具備切換到新的實踐方式上的條件，我們就采用并行的方式。
例如，項目組持續集成。團隊中某個項目組具備較好的持續集成基礎，另一些項目組基礎較差。如果在整個團隊推行持續集成，就可能對團隊產生較大的沖擊。而且持續集成的具體方案可能需要在一個項目組內試驗。這時候，先在一個項目組做起來，然后推廣到其他的項目組。
階石：為了達到一個長遠的目標，先實現一個較近的目標。
有些實踐有長遠的目標，但還看不清達成目標需要的路徑，如果知道做某件事情一定有助于達成目標，可以先完成這件事情。例如，單元測試。有時候希望在某些團隊中實施單元測試，但缺少合適的測試框架，那么在確定測試框架之前，實際上很難展開后面的工作。這時就可以先全力構建這個測試框架。稱這種方式為階石。
簡化：為了達到一個長遠的目標，先實現一個較為容易實現的目標，但是這個目標仍然能夠給我們帶來好處。
有些實踐我們有一個長遠的目標，但是對于這個長遠的目標還不太清楚，或者要達成這個長遠目標，要走的路還很長。如果有些做法可以給我們帶來一些好處，雖然不如長期目標帶來的好處那么大，我們仍然可以先做起來。
系統測試和低成本測試的拉通。系統測試和低成本測試拉通是個長期而艱巨的任務，比如可能需要良好的基礎設施的配合。但是我們可以做一些簡單的事情來獲得相似的好處。
暫停：暫不實施某個實踐。
有些實踐，團隊不具備實施條件，或者對團隊的沖擊較大，可選擇暫不實施。例如TDD。實施TDD需要較高的條件。如果團隊不具備這樣的條件，貿然推行難度非常大，這個時候常常選擇暫停。
上面的5個模式所在維度并不相同。比如，并行是從組織的維度考慮的，而階石和簡化是從目標維度考慮。另外，在不同范圍內看，同樣的實踐也可能屬于不同的模式，需注意模式的目的是為幫助參與者清晰把握問題本質，認識解決方案在時間和范圍上的局限性。所以把實踐與模式綁定的做法也不提倡。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
