*1、背景
? ? 傳統金融企業，系統交付一直用瀑布模式。2016年，因為敏捷開發很火，我主導發起了敏捷轉型項目，經過與部門各方溝通，確定了試點項目。
2、參與方
? ? 需求管理、系統開發、測試管理
3、問題
? ? 項目開展以后，咨詢顧問進場先進行了基礎知識培訓，大多數人對Scrum表示有一定程度的理解，但是認證考試的結果不甚理想，通過率不過50%。
? ? 試點項目開始時在團隊角色確定上遇到問題，大家對team成員沒有意見，但是對PO和SM有不同觀點，具體的爭論如下：
? ? 1）SM由PM還是系統資深開發主管擔任？
2）PO是由系統負責人還是需求負責人擔任？
最后為了讓項目順利推進，在原來的開發團隊中選出了PO和SM，需求團隊繼續寫需求文檔給測試人員使用，大家一起寫用戶故事。
接下來又遇到問題。在瀑布開發模式下測試團隊總是最后一個出現，之前參加會議也是基本不說話，最多要個需求分析文檔，評估工期。而敏捷開發模式里面要求測試前期參與，與原有的工作習慣有很大的變化，測試一直未完全進入沖刺，因此前面幾個沖刺實質還是瀑布模式。
然后，沖刺的交付不遵守MVP原則，往往需要幾個沖刺才能完成一個獨立可交付模塊，測試等待完整功能的測試代碼前無事可做。
還有需求變更頻繁，業務方隨意調整需求優先級，導致沖刺里面很多任務中途擱置，造成很大的投入浪費。
4、項目成果
大家對敏捷有了深入的了解，但是限于既有的管理模式，很多好的機制和方法不能有效運作，需要管理層在組織機制上的支持。
由于部分試點團隊是全功能團隊，因此落地效果較好，交付效率和質量都有提升。所有團隊能使用熟練使用看板方法，規劃會、每日站會、回顧會已經形成工作習慣。
5、回顧分析
1）管理層的信心和支持至關重要，新模式導入會有一段時期的不適，需要各個層面理解和支持；
2）Scrum的理念和基礎知識培訓很有必要，避免一些人一知半解的情況下隨意發揮，導致糾偏困難；
3）很多明顯是正確的道理和方向，往往因為各種原因無法遵從或落實，需要極大的耐心和很長的時間來說服，阻力可能會超出想象，終歸是利益或意愿方面的問題，可能短期無解。
6、總結
傳統企業推行敏捷是一項系統工程，組織機制、管理制度、績效指標、團隊利益、個人意愿等等，都有可能對敏捷落地有負面影響，知易行難。
