詩(shī)特林-sterning

敏捷開發(fā)（Agile Development）在國(guó)內(nèi)越來(lái)越紅火，隨著“敏捷”一詞出現(xiàn)在越來(lái)越多的項(xiàng)目中，于是，敏捷開發(fā)本身也被賦與了越來(lái)越多的意義，而敏捷的真正內(nèi)涵反而變得越來(lái)越模糊。如何邁出敏捷開發(fā)第一步？是按照敏捷寶典、操作指南或是教父語(yǔ)錄，還是因地制宜、因項(xiàng)目定方法？完成所有這些工作后，我們就真的“敏捷”了嗎？

一、前言

Agile是指企業(yè)能夠?qū)ν獠凯h(huán)境做出速捷、有效的反應(yīng)，是未來(lái)企業(yè)的必備素質(zhì)。21世紀(jì)企業(yè)面臨的競(jìng)爭(zhēng)環(huán)境將是一個(gè)不斷變化、不可預(yù)測(cè)的環(huán)境。由于高新技術(shù)的出現(xiàn)和更迭越來(lái)越快，產(chǎn)品的生命周期日益縮短，企業(yè)要面對(duì)這樣的新的競(jìng)爭(zhēng)環(huán)境，抓住市場(chǎng)機(jī)遇，迅速開發(fā)出用戶所需要的產(chǎn)品，就必須實(shí)現(xiàn)敏捷反應(yīng)。

狹義地講，敏捷企業(yè)就是將柔性的先進(jìn)制造技術(shù)、熟練掌握生產(chǎn)技能、有知識(shí)的勞動(dòng)力以及促進(jìn)企業(yè)內(nèi)部和企業(yè)之間的靈活管理三者集成在一起，對(duì)千變?nèi)f化的市場(chǎng)機(jī)會(huì)做出快速、有效的響應(yīng)。敏捷企業(yè)強(qiáng)調(diào)人、組織和技術(shù)的有機(jī)結(jié)合。通過(guò)這三者的緊密結(jié)合，敏捷企業(yè)可以發(fā)揮最佳的整體效益。評(píng)價(jià)一個(gè)企業(yè)敏捷性的具體指標(biāo)是時(shí)間、成本、穩(wěn)健性（Robustness）和適應(yīng)范圍。對(duì)敏捷企業(yè)的廣義理性，可以認(rèn)為敏捷企業(yè)是一個(gè)CIMS（計(jì)算機(jī)集成制造系統(tǒng)）、動(dòng)態(tài)聯(lián)盟、并行工程、擬實(shí)制造、高素質(zhì)員工等多方面的系統(tǒng)集成，是一個(gè)基于CIMS、在CMS基礎(chǔ)上發(fā)展起來(lái)的一個(gè)更高層次的集成大系統(tǒng)。

二、變味的敏捷

敏捷是大家在一起高效率地工作，清楚所有溝通上的障礙，關(guān)注于增值的活動(dòng)，從而使得開發(fā)更加成功。敏捷是大家肩并肩地工作，而不是什么都通過(guò)文檔。敏捷是管理者積極地參加到項(xiàng)目管理中而不是整天去寫狀況報(bào)告，用那個(gè)來(lái)監(jiān)督到底發(fā)生了什么事情。敏捷是開發(fā)人員和涉眾（項(xiàng)目開發(fā)中涉及的從需求到最后交付的各種人員）在一起制定實(shí)際的計(jì)劃，而不是用復(fù)雜的微軟Project去制定一些幾乎沒(méi)人看的進(jìn)度表。

公平地說(shuō)，很難設(shè)想敏捷術(shù)能如何發(fā)揮作用，尤其是在一些軟件開發(fā)本身都問(wèn)題重重的傳統(tǒng)組織中，被誤導(dǎo)過(guò)的敏捷更是難以幫上什么忙。

敏捷開發(fā)，看到過(guò)這個(gè)詞時(shí)，很多人一直沒(méi)有什么深刻的體會(huì)，也沒(méi)有仔細(xì)去研究到底什么才是敏捷開發(fā)。而一直在很多人的思想里，敏捷開發(fā)的印象就是，開發(fā)速度比較快。沒(méi)錯(cuò)，做互聯(lián)網(wǎng)的，快確實(shí)是一個(gè)制勝的法寶，那么敏捷開發(fā)似乎也就是在互聯(lián)網(wǎng)應(yīng)用的開發(fā)中最適合的方法了。那么敏捷開發(fā)中的參與者應(yīng)該是什么狀態(tài)？這似乎成了一直以來(lái)困擾很多管理者的嚴(yán)重問(wèn)題。可以說(shuō)，在敏捷開發(fā)中，并沒(méi)有覺得有多敏捷，進(jìn)度一拖再拖，問(wèn)題一個(gè)接著一個(gè)，讓我覺得我們是在進(jìn)行慌亂開發(fā)。為什么會(huì)這樣？

另外關(guān)于實(shí)施敏捷的效果也是充滿置疑之聲。我們經(jīng)常看到一些號(hào)稱 Agile 的國(guó)內(nèi)項(xiàng)目，按照菜譜、操作指南和教父語(yǔ)錄的提示，采用了許多花哨的技巧和實(shí)踐（做法），是啊，表面上確實(shí) Agile 了，那么結(jié)果呢？項(xiàng)目還是不能按時(shí)完成，甚至嚴(yán)重超支和超時(shí)，這能叫“敏捷”嗎？

三、敏捷十戒

 1．天報(bào)制度

就算是進(jìn)行遠(yuǎn)程開發(fā)或是兩地使用開發(fā)，項(xiàng)目組的成員每天至少碰一次，不管是當(dāng)面的，還是通過(guò)其它方式，如通過(guò)電話、email、Skype或其它。進(jìn)行敏捷開發(fā)的時(shí)間，任何團(tuán)隊(duì)都不能以任何理由進(jìn)行孤立的開發(fā)。

2．例會(huì)制度

即使每天通過(guò)Email給主管匯報(bào)工作，但有時(shí)主管還是無(wú)法及時(shí)準(zhǔn)確的掌握項(xiàng)目組成員的狀況及工作量。此時(shí)，通過(guò)每周一小時(shí)左右的例會(huì)將會(huì)有效的解決此問(wèn)題。通過(guò)例會(huì)，大家面對(duì)面的就某些問(wèn)題進(jìn)行共同的探討與討論，找到共同的解決方案。

3．版本控制

如果沒(méi)有一臺(tái)干凈的電腦來(lái)進(jìn)行團(tuán)隊(duì)代碼管理的話，則很有可能導(dǎo)致代碼的混亂。而每天只須花很少的時(shí)間，哪怕一天一次，進(jìn)行及時(shí)的數(shù)據(jù)提交與代碼提交，則可以有效的保證團(tuán)隊(duì)之前代碼的同步及代碼的備份。

4．需求失靈

即使手里拿著30頁(yè)且客戶進(jìn)行了簽字的需求說(shuō)明，有可能仍然不知所措。相對(duì)起那些良好的設(shè)計(jì)、精確的分析等，與客戶持續(xù)的溝通、及時(shí)的反饋、不斷的演示這些工作顯得更加的有效果。可以有效的獲得需求變化，減少誤解，更加準(zhǔn)確的把握用戶的需求。

5．單元測(cè)試是QA的工作

很多開發(fā)人員，甚至一些高級(jí)的軟件開發(fā)人員，對(duì)于單元測(cè)試沒(méi)有足夠的認(rèn)識(shí)，在行動(dòng)上也沒(méi)有足夠的注意。大家都一致的認(rèn)為那是QA的事情。就開發(fā)人員來(lái)講，單元測(cè)試應(yīng)該是一種白箱測(cè)試，能從功能上充分的測(cè)試軟件的功能性。而對(duì)QA來(lái)說(shuō)，只能是一種黑箱測(cè)試，無(wú)法深入的去分析代碼的優(yōu)勢(shì)，只是從用戶的角度進(jìn)行功能上的測(cè)試而已。

6．質(zhì)量保證是QA的責(zé)任

自從有了質(zhì)量管理這個(gè)詞以及后來(lái)產(chǎn)生的質(zhì)量管理部門后，很多開發(fā)人員就理所當(dāng)然的認(rèn)為質(zhì)量保證是QA的責(zé)任了。其實(shí)每一個(gè)人都需要對(duì)軟件的質(zhì)量負(fù)責(zé)，特別是開發(fā)人員。Bug越最早發(fā)現(xiàn)，那么解決它的成本就越低。

7．項(xiàng)目進(jìn)度風(fēng)險(xiǎn)控制

也許一個(gè)項(xiàng)目需要18個(gè)月左右才能完成，但在沒(méi)完成之前，誰(shuí)也無(wú)法進(jìn)行比較準(zhǔn)確的時(shí)間估計(jì)。無(wú)法確定需要多長(zhǎng)的時(shí)間進(jìn)行設(shè)計(jì)、編碼及軟件組件的組合。但進(jìn)行項(xiàng)目設(shè)計(jì)、實(shí)現(xiàn)及融合的人應(yīng)該相對(duì)比較準(zhǔn)確的掌握與估計(jì)項(xiàng)目的時(shí)間。因此，需要進(jìn)行項(xiàng)目進(jìn)度的風(fēng)險(xiǎn)控制，風(fēng)險(xiǎn)總是存在的，但要進(jìn)行有力與及時(shí)的控制。充分意識(shí)到項(xiàng)目中可能會(huì)存在的風(fēng)險(xiǎn)因素，在制定計(jì)劃時(shí)預(yù)留一定的時(shí)間，如果在項(xiàng)目進(jìn)行中出現(xiàn)了沒(méi)有想到的問(wèn)題，根據(jù)其重要性，考慮壓后解決，要在計(jì)劃的時(shí)間內(nèi)把計(jì)劃的事情完成好，并為后續(xù)解決問(wèn)題爭(zhēng)取更多的時(shí)間。

8．架構(gòu)師身體力行

很多軟件架構(gòu)師基本上不寫代碼，這也許是好事。軟件架構(gòu)師嘛，當(dāng)然是比較高級(jí)的，他們對(duì)環(huán)境、語(yǔ)言、類庫(kù)方面都可能比軟件開發(fā)人員要更加在行，但他們一般不編碼。這樣的架構(gòu)師是危險(xiǎn)的，特別是那些基本上不與首席開發(fā)人員進(jìn)行溝通或咨詢的架構(gòu)師，離項(xiàng)目失敗可能已經(jīng)不遠(yuǎn)了。

9．牽一發(fā)而動(dòng)全身

很多時(shí)間，在功能上做了一個(gè)很小的變動(dòng)，往往導(dǎo)致花費(fèi)好幾天的功夫來(lái)進(jìn)行軟件的集成與整合。如果沒(méi)有持續(xù)的整合、及時(shí)的回歸測(cè)試、可靠的整體設(shè)計(jì)，一些看起來(lái)非常微小的修改都有可能導(dǎo)致很大的麻煩。

10．加大管理執(zhí)行力

目前項(xiàng)目中，開發(fā)者或者說(shuō)參與人的狀態(tài)是混亂的，或者說(shuō)是慌亂的。那問(wèn)題在哪里呢？是工作流程出了問(wèn)題？不應(yīng)該啊。在項(xiàng)目啟動(dòng)前已經(jīng)定了一個(gè)看似美好的流程，而且是經(jīng)過(guò)參與人討論一致通過(guò)的。那么問(wèn)題在哪里呢？原來(lái)是溝通、傳達(dá)出了問(wèn)題，執(zhí)行力不夠。那么，就必須加大執(zhí)行力，今日事今日畢，這是必須的。

另外，在一些產(chǎn)品級(jí)的軟件開發(fā)中，覺得要實(shí)施敏捷式開發(fā)，我覺得也有一個(gè)不好解決的問(wèn)題：沒(méi)有具體的客戶！沒(méi)有具體的客戶，那你的溝通去哪里尋找呢？一般的做法也是給一些有興趣的用戶發(fā)布Alpha版本，或者是beta版本的軟件。可是當(dāng)軟件都到了Alpha/beta版本的時(shí)候，軟件還有迭代的余地嗎？未必！從我個(gè)人理解的角度來(lái)看，敏捷開發(fā)的適用范圍還是很有局限性的。個(gè)人認(rèn)為最適合使用敏捷開發(fā)的軟件必須要有非常明確的客戶才能進(jìn)行，而有明確客戶的情況以定制型軟件為主。所以，我覺得最適合用敏捷方式開發(fā)的軟件應(yīng)該是——定制軟件！

四、小結(jié)

記得Jim Highsmith在他的《敏捷項(xiàng)目管理》一書中這樣寫道：敏捷是指在動(dòng)蕩的業(yè)務(wù)環(huán)境中，適應(yīng)變化并創(chuàng)造變化，從而獲得價(jià)值的一種能力。同時(shí)敏捷是平衡靈活性和穩(wěn)定性的一種能力。由此可見，望文生義地把“敏捷”理解為“做得快”也頗可商榷。如果缺乏有效的實(shí)施指導(dǎo)、忽視嚴(yán)格的敏捷實(shí)踐，單憑著高層面的理解甚至“文化”就開始盲目前行，往往會(huì)因?yàn)槿狈?duì)質(zhì)量的有力保障而失去平衡，最終欲速則不達(dá)。

套用一句比較俗氣的話，敏捷不是放諸四海而皆準(zhǔn)的通用理論；敏捷不是玄而又玄的文化；敏捷不是在傳統(tǒng)項(xiàng)目合作模式下包治百病的金丹；敏捷不是拋開紀(jì)律盲目求快。除了這些，敏捷還不是什么？那么，今天你真的“敏捷”了嗎？