敏捷這個概念已經提出很多年了。敏捷對開發團隊的角色做了劃分，並且對各個角色的能力作出了高要求，另外對工作流程，迭代週期都提出了理想定義，這實際上是對組織架構的一個顛覆。
國內的很多互聯網大企業在敏捷轉型上已經取得了不錯的應用效果，但很多傳統行業的企業在轉型過程中，還是有着重重阻礙（點擊查看詳情）。
一、傳統企業內部推進敏捷轉型落地的過程中，都存在哪些問題和阻力？
首先在企業內部，無論做任何變革，都需要有一個過程。不同的人，針對同樣一件事，由於個人立場不同，得出的結論也可能不一樣。因此在敏捷導入過程中，也存在這樣的問題。在團隊初始使用敏捷的階段，最大的問題就是團隊成員的牴觸情緒。牴觸可以有多種形式，主動的或被動的，公開的或隱蔽的。
主動抵抗可能僅限於少數脾氣暴躁但與世隔絕的人，它可能會蔓延到更多的人。“主動抵制的人可能會試圖破壞敏捷轉型的過程，他們會四處亂說敏捷開發，試圖說服人們放棄它。”隨着不滿的蔓延，它會削弱士氣，因此隔離抗議者並讓嘗試他們加入轉型是很重要的。
但也不用因此產生過多焦慮，因爲實際上決定開展敏捷轉型後，公開抵制並不常見。更多會遇到的情況其實是被動抵抗。“被動的抵抗者假裝順從這個過程，站起來並口頭上表達支持，但他們的態度是：“誰在乎？”。
因此在敏捷的導入過程中，如何引導團隊成員去接受，去積極地實踐敏捷是關鍵所在。
點擊查看：DevOps方法論掌握這四點，實踐出真知
二、從敏捷能解決的提升開發效能的方面上入手，對症下藥
團隊效能的提升涉及到管理流程、技術架構、工具自動化等方方面面的因素，而敏捷關注於需求與開發之間的管理流程問題。基於不同的團隊現狀，敏捷也有不同的表現形式，這裏就不作贅述。
但總體來說，企業做敏捷轉型，仍然有一定的流程可以遵循（點擊查看“鳳凰項目”的數字化遷移之旅：如何“牽引”轉變一個產品線團隊）。
▲ 圖片來源網絡，如有侵權請聯繫刪除
如果企業完全是從原來瀑布開發模式做轉型，那麼首先在團隊層面需要引入看板方式，讓團隊能夠很好的可視化現有流程。只有可視化現有流程，才能識別並優化團隊的瓶頸問題。
其次，當團隊能夠熟練使用看板以後，就可以把團隊的組織流程轉變成Scrum。Scrum比起Kanban模式的優點在於對團隊的動作做了更多的規範化，這樣更有利於團隊建立統一的開發節奏。
第三，當團隊的組織流程運行順暢以後，就可以在技術架構層面引入更多的實踐，例如：優化團隊的開發框架、修復以前的技術債等。
最後，當團隊級別的效能提升到一定階段以後，就可以把敏捷相關的實踐拓展到整個IT部門，並且推進業務部門一起來做嘗試。這塊就涉及到規模化敏捷推廣和業務敏捷的相關內容了，後續再詳細展開談談，記得持續關注喔~