CargoSmart公司從2008年起，通過引入專業(yè)的敏捷開發(fā)咨詢公司，開始由以往的RUP開發(fā)模式（User Case Base）向敏捷開發(fā)模式（Iteration&Increasement，User Story Base）轉(zhuǎn)型，我們的敏捷開發(fā)轉(zhuǎn)型, 是先由咨詢師和一個(gè)種子團(tuán)隊(duì)（包括BA, QA, SA, Dev etc. 不同的role）以敏捷軟件開發(fā)模式一起共同完成一個(gè)項(xiàng)目完整的Release Lifecycle，然后把這個(gè)種子團(tuán)隊(duì)的成員分散到不同的開發(fā)團(tuán)隊(duì)中，由此在整個(gè)組織中傳播推廣敏捷開發(fā)的實(shí)踐，

中國(guó)敏捷實(shí)踐中的誤區(qū)（二）敏捷不應(yīng)孤立看待

    經(jīng)過兩年多的實(shí)踐經(jīng)歷，我們有所收獲也有經(jīng)驗(yàn)教訓(xùn)。

    以下就分享一些在實(shí)踐中遇到的問題和我們的認(rèn)識(shí)反思，供大家學(xué)習(xí)借鑒。

    沒有分析和設(shè)計(jì)

    敏捷開發(fā)強(qiáng)調(diào)簡(jiǎn)單設(shè)計(jì)，團(tuán)隊(duì)每個(gè)成員都從接觸客戶到分析設(shè)計(jì)，到編碼，全部承擔(dān)。但是實(shí)際上團(tuán)隊(duì)成員的素質(zhì)參差不齊，如果只有簡(jiǎn)單設(shè)計(jì)、立即編碼，而沒有后續(xù)的持續(xù)重構(gòu)等實(shí)踐，將導(dǎo)致設(shè)計(jì)混亂不一致，尤其是對(duì)老系統(tǒng)的功能升級(jí)，如果Impact分析不夠，弱化了分析設(shè)計(jì)，將導(dǎo)致很多工作在后期頻繁變更，使得團(tuán)隊(duì)的挫折感增強(qiáng)，產(chǎn)生較多的重復(fù)工作和浪費(fèi)。

    必要的系統(tǒng)架構(gòu)和設(shè)計(jì)從來(lái)都是非常重要的。只是這里的分析設(shè)計(jì)有別于傳統(tǒng)的開發(fā)模式，應(yīng)該應(yīng)用敏捷的思想，簡(jiǎn)單設(shè)計(jì)，持續(xù)重構(gòu)，盡快反饋等。

    敏捷擁抱變化，所以變化可以隨時(shí)隨地發(fā)生

    因?yàn)槊艚莸膶?dǎo)向，可能造成的問題是，前期需求比較隨意，對(duì)需求質(zhì)量的控制弱化，需求變更更加頻繁。

    （1）需求質(zhì)量的審核，仍然需要改進(jìn)，需求方向性的錯(cuò)誤將導(dǎo)致后續(xù)一系列的工作浪費(fèi)，所以團(tuán)隊(duì)內(nèi)部應(yīng)該設(shè)定里程碑和review標(biāo)準(zhǔn)，從而確�；�本的需求質(zhì)量。

    （2）在Iteration里需求盡量不要變更，明確 Iteration 的邊界。否則頻繁的變更導(dǎo)致團(tuán)隊(duì)沒有成就感，方向和目標(biāo)不明確。

    （3）敏捷講求業(yè)務(wù)價(jià)值導(dǎo)向，有些變更從業(yè)務(wù)價(jià)值上看，可能并非真正需求急切變更。

    有些變更通過更好的Impact分析和設(shè)計(jì)應(yīng)該也可以避免。BA和SA等不同的角色應(yīng)該一起配合來(lái)做出Impact 分析，以供決策，

管理資料

    一些敏捷實(shí)踐容易實(shí)行，一些比較困難。所以割裂敏捷實(shí)踐的關(guān)聯(lián)，孤立地實(shí)踐少數(shù)的敏捷實(shí)踐

    其實(shí)上面的很多問題都是由此導(dǎo)致的，敏捷開發(fā)之所以可以替代以往傳統(tǒng)開發(fā)模式，是因?yàn)橐唤M（系列）的開發(fā)實(shí)踐來(lái)共同代替以往開發(fā)模式。孤立的引入少數(shù)實(shí)踐，通常不能給團(tuán)隊(duì)成員感覺有大的改進(jìn)，從而也放棄對(duì)敏捷開發(fā)的信心。

    例如Stand-up Meeting. 這是一個(gè)比較容易的實(shí)踐，但是如果沒有背后的需求轉(zhuǎn)化為比較容易衡量的Story-base, 沒有BA、 QA 等共同參與基于Story-base去溝通, 沒有Offline of Meeting更多的面對(duì)面溝通交流，沒有大家彼此知道對(duì)方的工作內(nèi)容（Code Ownership），那么可以設(shè)想這種Stand-up meeting和以往的傳統(tǒng)的開發(fā)模式，Leader 布置任務(wù)檢查任務(wù)進(jìn)度沒有任何區(qū)別。

    再如簡(jiǎn)單設(shè)計(jì)實(shí)踐，如果沒有背后的結(jié)對(duì)編程、重構(gòu)等實(shí)踐，必然導(dǎo)致比較混亂的代碼，很難維護(hù)的架構(gòu)，難于擴(kuò)展，重復(fù)實(shí)現(xiàn)類似功能等弊端。

    再如持續(xù)集成（CI），即使這是公認(rèn)敏捷軟件領(lǐng)域內(nèi)相對(duì)沒有爭(zhēng)議的一個(gè)實(shí)踐，但是如果沒有與TDD結(jié)合，沒有與持續(xù)重構(gòu)，沒有與小的Story，快速頻繁Deliver等實(shí)踐結(jié)合在一起，并且堅(jiān)持保持CI的健康，也會(huì)讓團(tuán)隊(duì)成員覺得CI效果不如宣傳，從而對(duì)敏捷實(shí)踐等產(chǎn)生質(zhì)疑。

    以上是我們?cè)诿艚蓍_發(fā)實(shí)踐中遇到的幾個(gè)典型問題，以及部分經(jīng)驗(yàn)教訓(xùn)的反思總結(jié)。

    作者朱建偉，在業(yè)界有10年以上的經(jīng)驗(yàn)，從軟件開發(fā)到項(xiàng)目管理以及部門管理，在不同的技術(shù)領(lǐng)域和業(yè)務(wù)領(lǐng)域均有豐富經(jīng)驗(yàn)，也經(jīng)歷了不同的開發(fā)流程(瀑布/快速原型/RUP/CMMI/Agile etc.)。目前工作于CargoSmart(貨訊通)公司，從事軟件項(xiàng)目管理，開發(fā)管理以及流程優(yōu)化等相關(guān)工作。

    本文選自《程序員》雜志2010年10期，更多精彩內(nèi)容敬請(qǐng)關(guān)注10期雜志