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