我們目前快不起來，不在于我們是否采取敏捷方式，而是我們基礎太薄弱
1、開發人員不理解現有業務
2、開發人員不理解現有代碼
3、開發人員不理解現有數據表關系、關鍵字段變化、VIEW、SP、報表
4、開發人員不理解MAP在典型場景中的實際應用，不了解MAP到底有多少函數可以幫助開發
5、開發人員大多是新人，對開發過程規范不了解。我們目前采取CMMI開發過程規范，光主節點就有78個。開發部門的老人也大部分只是只開發過一個子系統，對其他子系統的業務、代碼、數據庫也不了解。只是MAP和開發過程規范比武漢開發新人熟悉一些。
6、我們的設計人員也大多是新人，不了解現有業務和系統功能
7、我們的自測沒有方法，多了工序，耗了人工和時間，但效果并不明顯。
8、我們的代碼審查沒有方法，多了工序，耗了人工和時間，但效果并不明顯。
9、我們的大數據量測試、多場景并發測試、集成跨子系統影響測試、安裝部署測試、環境兼容性測試、權限點測試、幫助文件測試也是沒有優化，消耗大量時間。
只有先把這些基礎補起來，我們的開發效率、開發質量就會比我們現在好很多。所以我們今年大力啟動多項針對性的關鍵行動計劃來提升各個方面。但這些做到后我們也并不能做到3個月快速發版。
當然，我們還可以繼續優化：
1、需求規劃不能滯后，這是常見擠壓下游設計、開發、測試時間的原因。需求分為功能增強和BUG修補。對于BUG，ERP3.0會提供BUG自動發回功能，讓需求收集需求規劃階段能夠優化縮短。
2、開發Leader在功能設計中期就進入，理解業務，設計數據庫，設計功能代碼實現和代碼修改方案、設計接口、識別公共代碼。
3、平臺提供大量穩定性功能、代碼審查工具、性能優化數據庫設計指引，平臺還提供日志、異常、輸入規則校驗底層框架，把這些都從業務代碼中抽取出去，簡化代碼開發。平臺應用架構組也梳理子系統代碼分層解耦、JS代碼縮減，力求業務子系統開發少寫代碼，只寫業務代碼。
4、設計部門進行設計模板化，平臺應用架構組也提供代碼模板，開發也盡量模板化COPY修改。簡化開發，提高效率和質量。
但要想更快起來，我們必須引入敏捷項目管理、敏捷設計、敏捷開發、敏捷測試。
敏捷測試的核心是要和開發一起并行，把BUG消滅在開發的每天中，而不是在后期集中測試集中爆發。這要求咱們并行寫測試用例、并行做自動化測試、并行持續每日自動構建自動腳本測試。咱們目前設計方法和測試方法不一致所以無法并行測試用例，這今年會解決；咱們代碼各異沒有模板，所以自動化測試跑不起來；我們功能自動化測試經驗也尚淺需要加強；
光靠敏捷測試是不夠的，保證代碼穩定還得主要靠開發人員。所以敏捷開發需要開展單元測試靠開發人員主力保證代碼穩定，在單個開發人員編碼能力不強的狀況下可以采用開發leader編寫代碼骨架普通開發人員填肉的配合結對編程，而且還得實時進行重構防止代碼逐步腐爛導致開發進度開發質量連年下降。這兩項也是咱們的空白。
單元測試，最大的誤區是很多人以為是先完代碼，然后寫測試代碼來測試已寫的函數。其實不然，而是先按照業務場景先寫測試函數，這樣便于程序員通過輸入輸出、函數的定義、函數的串聯來達到深刻理解業務需求。所以說，單元測試，其核心是測試驅動。
敏捷測試，想做到測試同步，就必須開發人員和測試人員都按照同樣的業務場景去分析思考，測試根據場景分析得到測試用例，開發根據場景分析得到單元測試代碼。這是同宗同源的。只有這樣工作，才能真正保證測試用例編寫和開發人員編寫代碼是同步的。
敏捷測試和敏捷開發的本質是讓代碼質量持續保持穩定，以便于可以隨時發布。
敏捷設計的核心是用戶故事（咱們叫用戶流程場景，在UML中變形為用例圖），這是敏捷測試、敏捷開發共同的源頭，這樣測試才好驗證代碼是否符合場景。可以采取咱們前段時間做的組織結構-崗位職責-一級流程-二級流程-功能點+UI草稿，這樣來把用戶流程場景和功能點映射在一起，并且容易做項目計劃估算。用戶故事有優先級，咱們也有。用戶故事要求獨立，咱們也是把一般和特殊分離，力求每個功能點歸類成Grid/Form/Report。用戶故事有一點比咱們做的先進，就是每個故事都必須具備驗收條件，咱們以后也需要這么做。
敏捷項目管理的核心是20個工作日迭代一次。每個迭代周期包括詳細設計、開發、測試、演示沖刺四個部分。分到每個環節也就是5天，所以必須持續穩定、同步測試。為了保證20個工作日迭代一次，就不能在這個迭代小周期內中途變更需求、變更設計。這些變更必須在下一個迭代周期去解決。通過有限的工作日來限定有限的需求，有限的人力。也就使需求穩定、人員穩定，這是開發效率開發過程不出異常的兩個基礎保證。
敏捷項目管理的任務是按小時來計算的。我們現在做不到按小時就是因為我們想在軟件設計初期就深刻理解每個功能，但其實不可能做到。而敏捷可以，是敏捷不需要在初期深刻理解每個功能，而只需要把范圍縮小到本迭代周期內要實現的功能聚焦思考即可。持續滾動迭代，會逐步思考精確。而且按小時算有個好處，每個迭代周期有多少小時是一定的（20天x8小時x人數），你放進本迭代周期的任務超出時間了，那就當然無法執行了，這也保證了迭代時間估算的準確性。
在這些支撐下，燃盡圖只是一個類似豐田可視化看板而已。很多人誤認為燃盡圖是敏捷SCRUM的核心，其實不然，燃盡圖只是表象，支撐它的東西才是核心。不過燃盡圖中的正在排隊的任務，正在開發的任務，已經開發完成的任務，需要返工修復的任務，還沒有計劃的任務，這些分類的任務在燃盡圖中倒是一清二楚，令團隊的每個人都很快明白進展和問題，并且認識信息一致。
至于：規劃會、變更會、立會、周會、沖刺演示會，所有這些會議，全體團隊成員（產品經理、PM、設計、開發leader、開發、測試、QA）都要一起參加；平時工作，項目團隊都要坐在一起。這些方法都是為了讓信息快速共享同步。這些敏捷項目管理方法大家平時已經在用了。
20天出一個小迭代版本，60天出一個大迭代版本，這是我們一切思考敏捷創新敏捷嘗試敏捷的源泉。大家以此為根，把不以此為目的的旁枝措施都砍掉。否則極有可能走向照貓畫虎邯鄲學步，成了片面追求敏捷模式了。
以上上述所有能力和基礎要想摸索通、準備好這些基礎和人員能力模型提升、和咱們現狀結合有效、并且產生規模效應，沒有2-3年的努力是無法做到的，尤其在我們連年大量新人加入的情況下。所以新人培養模式如何快速培養新人是關鍵的前提，新人提升不快，咱們這些所有的高級職責和工作要求就無法執行。