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