對(duì)于敏捷開發(fā)，我前面其實(shí)已經(jīng)有很多文章提到了，再次強(qiáng)調(diào)下敏捷的核心思想個(gè)人理解為三個(gè)重要的方面。其一是需求的條目化并以需求點(diǎn)進(jìn)行的全程追蹤和跟蹤；其二是短周期迭代；其三是基于持續(xù)集成思想的進(jìn)度和質(zhì)量可視化。
對(duì)于敏捷開發(fā)本身，對(duì)于很多內(nèi)容我仍然堅(jiān)持自己的觀點(diǎn)，具體如下：
對(duì)于大型全新系統(tǒng)的開發(fā)，如果是以底層數(shù)據(jù)為核心的業(yè)務(wù)系統(tǒng)，則不能單純的應(yīng)用敏捷開發(fā)。這類系統(tǒng)對(duì)全局業(yè)務(wù)建模和數(shù)據(jù)建模的要求會(huì)更高，以保證架構(gòu)完整性和概念一致性。而不是任務(wù)已經(jīng)并行分配下去，出現(xiàn)問題了再去做調(diào)整，敏捷的短周期迭代不是做這個(gè)用的。這類的總體設(shè)計(jì)個(gè)人理解主要包括了子系統(tǒng)或模塊的劃分，接口的識(shí)別，底層全局?jǐn)?shù)據(jù)概念模型，這些必須一開始就要搞清楚。
對(duì)于新組建的團(tuán)隊(duì)，團(tuán)隊(duì)成員相互不了解或能力差異過大，團(tuán)隊(duì)沒有歷史項(xiàng)目實(shí)踐的磨合和經(jīng)驗(yàn)積累，沒有比較成熟穩(wěn)定的技術(shù)框架時(shí)候，建議慎用敏捷開發(fā)。敏捷開發(fā)是迭代計(jì)劃和版本，但是當(dāng)前的迭代版本仍然是需要我們能夠做出合理的估算，而不是存在大量的不確定性。
敏捷開發(fā)里面有一個(gè)重要的實(shí)踐，即CI持續(xù)集成，這里面會(huì)涉及到單元測(cè)試，但是這不是XP極限編程里面的TDD測(cè)試驅(qū)動(dòng)開發(fā)。有人認(rèn)為沒有采用TDD就不是敏捷開發(fā)是相當(dāng)教條型的錯(cuò)誤。即使再CI持續(xù)集成和每日構(gòu)建，冒煙里面我們?nèi)匀皇嵌喾N做法。一種是只寫能夠冒煙測(cè)試通過的少量單元測(cè)試用例，一種是只對(duì)按界面展現(xiàn)和邏輯實(shí)現(xiàn)橫向分工的團(tuán)隊(duì)要求對(duì)于技術(shù)組件接口的朝外提供要首先寫單元測(cè)試代碼。TDD測(cè)試驅(qū)動(dòng)開發(fā)真正能夠?qū)嵺`好能夠堅(jiān)持下來的多內(nèi)基本很少，這個(gè)根本就不是熟悉了TDD就能降低工作量的問題，其次對(duì)于希望通過寫測(cè)試代碼來想清楚需求的方法不推薦，需求是需要可驗(yàn)證但是不代表必須測(cè)試代碼能夠?qū)懬宄枨蟛趴沈?yàn)證；再次單元測(cè)試往往比較難到UI和展現(xiàn)層，即使有Junit自動(dòng)跑了還是需要人工測(cè)試，這個(gè)工作量并沒有省。
敏捷方法論本身的思想是重視溝通和協(xié)同，減少不必要的文檔，因此敏捷并不是沒有文檔。當(dāng)前還是很多人認(rèn)為通過實(shí)施敏捷方法可以不寫文檔，認(rèn)為文檔沒有用處這又是走到一個(gè)極端。那么什么叫不必要的文檔？個(gè)人理解其一已經(jīng)在項(xiàng)目團(tuán)隊(duì)里面形成規(guī)約性質(zhì)的內(nèi)容，則已經(jīng)有歷史規(guī)約可以追溯到；其二是各種日常溝通協(xié)調(diào)中形成的討論，記錄，白板等內(nèi)容，不會(huì)太注重規(guī)范格式但是要能夠記錄下來；其三是對(duì)于他人看你的源代碼就能夠理解清楚的東西不必再文檔化。
想到哪里就做到哪里，拿著需求點(diǎn)就馬上去做，出現(xiàn)問題了不斷的返工和修改還美其名曰重構(gòu)，通過敏捷為幌子來逃避寫文檔，雖然第一個(gè)迭代快速能出來但是產(chǎn)品能夠真正上線運(yùn)行進(jìn)度周期反而成倍增加，再者或強(qiáng)調(diào)我們是敏捷每周40小時(shí)工作時(shí)間。這些都是中敏捷的毒太深，還是那句話，傳統(tǒng)的類似瀑布的軟件生命周期模型都沒有應(yīng)用好，能夠把敏捷應(yīng)用好是不可能的。團(tuán)隊(duì)人員本身編程能力和經(jīng)驗(yàn)就差距較大，對(duì)自我能力和生產(chǎn)率評(píng)估也很弱，相互也不了解情況下能夠簡(jiǎn)單的通過敏捷來糾正這些問題也是不可能的。
聯(lián)系客服
