改變，對任何人來講都很難，對團隊來講更是難上加難。同理，敏捷轉型帶來的重大變革也會很艱難。甚至，有時候敏捷轉型反而會帶來短期的產能降低。爲了幫助更多研發團隊順利過渡到敏捷，咱們以十餘年的管理實踐，整理了這份：微信

敏捷轉型之路的 6 大誤區markdown

01 從培訓開始

在轉型開始以前，讓整個團隊參加敏捷培訓是一個很直觀的選擇。然而在團隊真正作好準備前就去上課，也許會致使一些問題。框架

缺少足夠的心理認同或不能代入工做場景，可能讓團隊在培訓後只能消化小部分敏捷知識；少部分團隊成員甚至可能由於不認同敏捷概念而不斷提出挑戰，從而影響整個團隊的積極性。oop

**任何轉型，成功的最關鍵步驟都是瞭解爲何須要改變。**每一個人都須要瞭解敏捷帶來的好處。若是應用得當，敏捷能使團隊更快地交付，馬上爲客戶提供部分價值和更早地得到客戶反饋。在傳統的瀑布式項目中，團隊也會和客戶按期溝通。但因爲缺乏客戶的實時反饋，團隊難以快速適應需求的變化，最後交付的產品天然沒法知足客戶的須要。網站

當團隊成員理解須要敏捷轉型的緣由及其對每一個人工做的意義，而且產生認同感後，正式的培訓就變得很重要。團隊會在對敏捷的理解和溝通上保持一致，這是成功轉型的基礎。spa

這裏須要強調的是：敏捷轉型成功的團隊必需是一個自驅動的團隊，而不是一個強管制的團隊。設計

02 敏捷就是Scrum？

No! 敏捷是一種方法論，而Scrum是敏捷最主流的框架之一。code

敏捷正式誕生在2001年，17位開發者一塊兒發表了「敏捷軟件開發宣言」。在這以前，不少你們今天熟知的框架如Scrum，XP，FDD等已經存在。這些框架和後來誕生的Kanban都大量借鑑了製造業的先進理念，並將其應用於軟件開發領域。在敏捷轉型中，瞭解並選擇適合您的框架相當重要。orm

圖源[：www.systemsvalley.com/getting-bet…圖片

03 敏捷項目不須要計劃…

對於傳統的瀑布型項目，在項目開始前就有詳細計劃的任務分解甘特圖。然而真實的項目過程當中，需求總在不斷地變化，甚至一些需求或潛在問題在項目開始時是不可預測的，所以起初制定的詳細計劃就會顯得雞肋。

但這並不代表敏捷項目沒有計劃，其計劃的過程是一個持續且變化的過程。

在敏捷項目開始前，團隊應制定項目的整體目標；以後，在每一個迭代開始前制定迭代計劃（細化到此迭代的需求和相應的工做任務）。隨着迭代的持續交付和客戶的反饋，敏捷項目的計劃在不斷地調整，一切以實現對客戶交付價值的最大化爲主。

幫助團隊適應項目的不肯定性及基於變化的計劃，才能讓團隊更快地轉型。

04 輕易地回退

不多有人喜歡變化，在面臨壓力時，人們每每會恢復到他們習慣的工做方式。在每次敏捷轉型中，團隊向敏捷轉型的決心都會受到考驗。當一個正在轉型的項目遇到麻煩時，不要輕易地放棄，進而收回對一個自組織團隊的控制權。

當程序和項目遇到困難時，請相信流程，並利用敏捷框架的持續改進機制來反思哪些須要調整，在下一次迭代中改進。這可能在短時間內下降團隊的產能，但會帶來敏捷轉型的長期成功。

麥肯錫曾經對許多世界500強公司的敏捷轉型作過調研。其中就有一個亞洲電信巨頭的例子。該公司的業績是由上市時間和績效目標的實現來衡量的。在公司高層決定採起敏捷工做法以後的3個月內，業績有所降低。但三個月後，其業績開始快速增加，最終遠遠超過了公司實踐敏捷以前的水平。

05 敏捷適用於任何項目任何團隊

團隊的規模越大，靈活性就越差。按照康威定律的結論：「設計系統的組織受限於生產設計，這些設計是組織溝通結構的副本」。敏捷的最佳實踐是：把較大的團隊按照產品或項目劃分爲不一樣的敏捷小組，充分發揮溝通成本低的優點。

對於週期長，需求明確且不會變動的項目，在項目開始前可以清晰地定義出目標範圍和工做任務，因爲在項目的各個階段團隊高度聚焦，瀑布多是一個更好的選擇。但從長遠的考量出發，敏捷的團隊可以獲得更多的價值驅動，從而更好地完成交付。

06 敏捷≈更快地寫代碼？

若是一個團隊把加快開發速度做爲敏捷轉型的目標，他們極可能會失望。讓咱們重讀一下敏捷的12條原則，不難看出，敏捷關注的是更早地交付部分價值給客戶，基於反饋快速調整並持續交付價值。

對於相同工做量的產品開發，因爲敏捷項目會將開發工做分到多個迭代中，假設需求沒有變動，開發速度甚至會比瀑布型慢。也許選擇敏捷不必定等同於選擇了高速度，究其本質，敏捷不必定能保證產品的交付速度，但它能讓團隊實時調整，創造出更符合客戶需求的產品。

關注價值而不是速度，是敏捷轉型的精髓。

直到今天，敏捷誕生已有20年，傳統項目管理模式更是有超過50年的歷史。這二者並無絕對的對或錯，對於不一樣類型的工做，不一樣的團隊，如何在高速變化的時代裏找到最適合本身的工做方式才最重要。

最後附上敏捷的 12 條原則，但願對你們有所啓發：

1.咱們的最高優先級，就是儘早和持續交付有價值的軟件來知足客戶。

2.擁抱需求變動，即便在開發後期。敏捷利用變化來爲客戶創造競爭優點。

3.用數週到數月的週期，持續交付可工做的軟件，交付週期越短越好。

4.在整個項目週期，業務人員和開發人員必須天天在一塊兒工做。

5.圍繞積極進取的我的創建項目，給他們須要的環境和支持，並相信他們會完成工做。

6.信息傳遞最有效的方式是面對面的溝通。

7.可工做的軟件，是衡量進度的首要標準。

8.敏捷倡導可持續發展。贊助者、開發者和用戶應該可以一直保持恆定的速度。

9.對技術卓越的持續關注和良好的設計能夠提高敏捷性。

10.簡單，即最大程度減小不須要的工做，是敏捷的根本。

11.最好的構架、需求和設計來自自組織的團隊。

12.團隊按期反思如何提高效率，並相應地調整其行爲。