文｜武毳

互聯(lián)網(wǎng)時(shí)代，硬件、應(yīng)用軟件更新速度趕不上人們需求的增長(zhǎng)。軟件的數(shù)量急劇膨脹，軟件需求日趨復(fù)雜，維護(hù)的難度越來越大，開發(fā)成本令人吃驚地高，而失敗的軟件開發(fā)項(xiàng)目卻屢見不鮮。“軟件危機(jī)”就這樣開始了。

軟件危機(jī)一方面是由軟件生產(chǎn)本身存在著復(fù)雜性，另一方面卻是與軟件開發(fā)所使用的方法和技術(shù)有關(guān)。軟件工程學(xué)正是為克服軟件危機(jī)而形成的新的學(xué)科，但可惜的是時(shí)至今日人們并沒有完全克服軟件危機(jī)。

軟件開發(fā)中當(dāng)連續(xù)地犯錯(cuò)誤時(shí)，我們會(huì)對(duì)錯(cuò)誤進(jìn)行診斷，并在過程中增加更多的約束和人為制品來防止以后重犯這樣的錯(cuò)誤。經(jīng)過多次這樣的增加之后，我們就會(huì)不堪巨大、笨重的過程的重負(fù)，極大地削弱我們完成工作的能力。一個(gè)大而笨重的過程會(huì)產(chǎn)生它本來企圖去解決的問題。降低了團(tuán)隊(duì)的開發(fā)效率，使得進(jìn)度延期，預(yù)算超支。它降低了團(tuán)隊(duì)的相應(yīng)能力，使得團(tuán)隊(duì)經(jīng)常創(chuàng)建錯(cuò)誤的產(chǎn)品。遺憾的是，許多團(tuán)隊(duì)認(rèn)為，這種結(jié)果是因?yàn)樗麄儧]有采用更多的過程方法引起的。因此，在這種失控的過程膨脹中，過程會(huì)變得越來越龐大。

2001年初，由于看到許多公司的軟件團(tuán)隊(duì)陷入了不斷增長(zhǎng)的過程的泥潭，一批業(yè)界專家聚集在一起概括出了一些可以使軟件開發(fā)團(tuán)隊(duì)具有快速工作、響應(yīng)變化能力的價(jià)值觀（value）原則。他們稱自己為敏捷（Agile）聯(lián)盟。在隨后的幾個(gè)月中，他們創(chuàng)建出了一份價(jià)值觀聲明。也就是敏捷聯(lián)盟宣言（The Manifesto of the Agile Alliance）。

敏捷聯(lián)盟宣言如下：

（1）個(gè)體和交互勝過過程和工具。

人是獲得成功的最為重要的因素。如果團(tuán)隊(duì)中沒有優(yōu)秀的成員，那么就是使用好的過程也不能挽救失敗的項(xiàng)目。但是，不好的過程卻可以使最優(yōu)秀的團(tuán)隊(duì)成員失去效用。如果不能作為一個(gè)團(tuán)隊(duì)進(jìn)行工作，那么即使擁有一批優(yōu)秀的成員項(xiàng)目也會(huì)失敗。

一個(gè)由平均水平程序員組成的團(tuán)隊(duì)，如果具有良好的溝通能力，將要比那些雖然擁有一批高水平的程序員，但是成員之間卻不能交流的團(tuán)隊(duì)更有可能獲得成功。

團(tuán)隊(duì)的構(gòu)建要比環(huán)境的構(gòu)建重要得多。應(yīng)該首先致力于構(gòu)建團(tuán)隊(duì)，然后在讓團(tuán)隊(duì)基于需要來配置環(huán)境。

根據(jù)調(diào)查總結(jié)：一般團(tuán)隊(duì)都具備創(chuàng)業(yè)型團(tuán)隊(duì)的特點(diǎn)：一個(gè)優(yōu)秀的lead，帶多名水平一般的員工；這樣的團(tuán)隊(duì)存在兩個(gè)問題：1）優(yōu)秀員工的引入，受lead的水平限制；2）員工各自為政的開發(fā)模式，分享不夠。

團(tuán)隊(duì)中的優(yōu)秀人才并不是越多越好，優(yōu)秀人才太多反而有更大的弊端。一是人力成本太高，他們可能消耗掉產(chǎn)品創(chuàng)造的大部分效益，那么就不劃算了。二是團(tuán)隊(duì)分裂的風(fēng)險(xiǎn)太高，因?yàn)閳F(tuán)隊(duì)的空間有限，無(wú)法同時(shí)滿足很多優(yōu)秀人才事業(yè)發(fā)展的欲望；所以，團(tuán)隊(duì)的優(yōu)秀人才恰好夠用就行。

軟件開發(fā)團(tuán)隊(duì)的lead應(yīng)當(dāng)具有四項(xiàng)素質(zhì)，按級(jí)別從低到高排列；不錯(cuò)的技術(shù)才能（一段）較強(qiáng)的管理才能（二段）豐富的產(chǎn)品開發(fā)經(jīng)驗(yàn)（三段）敏銳的商業(yè)頭腦（四段）。目前大多數(shù)IT企業(yè)在物色團(tuán)隊(duì)的領(lǐng)導(dǎo)時(shí)，主要考察候選人的管理能力和技術(shù)能力。對(duì)于搞技術(shù)出身的人，如果他能當(dāng)上小頭目，一般地講他的技術(shù)才能不會(huì)太差。然而即使技術(shù)水平是團(tuán)隊(duì)里最強(qiáng)的，如果他不具備帶領(lǐng)團(tuán)隊(duì)所有成員正確干活的能力（即管理能力），那么他也就不不適合當(dāng)lead。

（2）可以工作的軟件勝過面面俱到的文檔。

沒有文檔的軟件是一種災(zāi)難。代碼不是傳達(dá)系統(tǒng)原理和結(jié)構(gòu)的理想媒介。然而，過多的文檔比過少的文檔更糟。編制眾多的文檔需要花費(fèi)大量的時(shí)間，要使這些文檔和代碼保持同步，那么就要花費(fèi)更多的時(shí)間。如果文檔和代碼之間失去同步，文檔就會(huì)變成龐大的、復(fù)雜的謊言，會(huì)造成重大的誤導(dǎo)。

（3）客戶合作勝過合同談判。

成功的項(xiàng)目需要有序、頻繁的反饋。不是依賴于合同或者關(guān)于工作的陳述，而是讓軟件的客戶和開發(fā)團(tuán)隊(duì)密切地在一起工作，并經(jīng)常地提供反饋。項(xiàng)目成功的關(guān)鍵在于和客戶之間真誠(chéng)的協(xié)作。

（4）響應(yīng)變化勝過遵循計(jì)劃。

響應(yīng)變化的能力常常決定著一個(gè)軟件項(xiàng)目的成敗。當(dāng)我們構(gòu)建計(jì)劃時(shí)，應(yīng)該確保計(jì)劃是靈活的并且易于適應(yīng)商務(wù)和技術(shù)方面的變化。

圖1

較好的做計(jì)劃的策略是：為下兩周做詳細(xì)的計(jì)劃，為下三個(gè)月做粗略的計(jì)劃，再以后就做極為粗糙的計(jì)劃。計(jì)劃中這種逐漸降低的細(xì)致度，意味著我們僅僅對(duì)于迫切的任務(wù)才花費(fèi)時(shí)間進(jìn)行詳細(xì)的計(jì)劃。一旦制定了這個(gè)詳細(xì)的計(jì)劃，就很難進(jìn)行改變，因?yàn)閳F(tuán)隊(duì)會(huì)根據(jù)這個(gè)計(jì)劃啟動(dòng)工作并有了相應(yīng)的投入。然而，由于計(jì)劃僅僅支配了幾周的時(shí)間，計(jì)劃的其余部分仍然保持著靈活性。

綜觀上述四個(gè)過程，敏捷開發(fā)強(qiáng)調(diào)以人為中心，而不是以過程為中心，強(qiáng)調(diào)盡可能的溝通（與客戶，與團(tuán)隊(duì)成員），盡可能地以最簡(jiǎn)單的設(shè)計(jì)解決問題（從而能夠擁抱變化）。

敏捷開發(fā)不同于以往的瀑布式開發(fā)，非常適合需求變動(dòng)的情況，敏捷開發(fā)的工作量是隨著需求的變化而不斷發(fā)生變化的，所以整個(gè)過程中浪費(fèi)很少（如圖1所示）。

與傳統(tǒng)的軟件開發(fā)方法懼怕需求變化相反，敏捷團(tuán)隊(duì)依靠變化來獲取活力。團(tuán)隊(duì)幾乎不進(jìn)行預(yù)先設(shè)計(jì)，因此，不需要一個(gè)成熟的初始設(shè)計(jì)。他們更愿意保持系統(tǒng)設(shè)計(jì)盡可能的干凈、簡(jiǎn)單，并使用許多單元測(cè)試和驗(yàn)收測(cè)試作為支援。這保持了設(shè)計(jì)的靈活性、易于理解性。團(tuán)隊(duì)利用這種靈活性，持續(xù)地改進(jìn)設(shè)計(jì)，以便于每次迭代結(jié)束所生系統(tǒng)都具有最適合于迭代中需求的設(shè)計(jì)。

上面的描述非常美好，讀者不禁會(huì)問：敏捷開發(fā)人員如何知道要做什么的呢？

答案是：

（1）他們遵循敏捷實(shí)踐去發(fā)現(xiàn)問題；

（2）他們應(yīng)用設(shè)計(jì)原則去診斷問題；

（3）他們應(yīng)用適當(dāng)?shù)脑O(shè)計(jì)模式去解決問題。

軟件開發(fā)的這三個(gè)方面的相互作用就是設(shè)計(jì)。

到目前為止，已經(jīng)有許多的敏捷開發(fā)方法可供選擇，包括Scrum 、Crystal 、FDD（Feature Driven Development）、ADP（Adaptive Software Development）、XP（eXtreme Programming）等。Scrum是最常用的方法之一。Scrum本意是橄欖球運(yùn)動(dòng)中的爭(zhēng)球。在一般人的印象中，橄欖球運(yùn)動(dòng)是非常野蠻的，球員目的非常明確——破門得分。你可以抱著球跑，可以傳給隊(duì)友……各種方式都可以，目的就是要快速得分。敏捷開發(fā)就需要這種精神。下面我們來看一下Scrum大概的流程（如圖2所示）。

1、在一個(gè)Scrum項(xiàng)目中，產(chǎn)品負(fù)責(zé)人（Product Owner）建立待開發(fā)的產(chǎn)品條目（Product Backlog），并確定其優(yōu)先級(jí)。開發(fā)中需求的改變也要寫進(jìn)去，對(duì)于調(diào)研、查閱資料、配置環(huán)境等也應(yīng)考慮進(jìn)去，因?yàn)檫@些也很占用時(shí)間，敏捷開發(fā)中不提倡沖刺，不提倡加班，講究發(fā)揮團(tuán)隊(duì)最大價(jià)值；

2、根據(jù)所列P r o d u c t Backlog情況，確定產(chǎn)品一個(gè)迭代（Sprint）所要完成的東西，每一個(gè)Sprint大概是2-6周的時(shí)間；

3、Sprint開始前，需要開一個(gè)迭代計(jì)劃會(huì)議（Sprint Planning Meeting）會(huì)議。會(huì)上，產(chǎn)品負(fù)責(zé)人（Product Owner）講解本次開發(fā)要開發(fā)的條目（Story），將確定的Story放入Sprint Backlog中來；

4、Sprint開發(fā)過程中，團(tuán)隊(duì)每天都要開一個(gè)站立會(huì)議（Daily Stand-up Meeting），以便團(tuán)隊(duì)之間了解彼此的開發(fā)進(jìn)度；

5、Sprint結(jié)束之后，需要開評(píng)審會(huì)（Review Meeting），Scrum團(tuán)隊(duì)會(huì)在評(píng)審會(huì)議上把這個(gè)迭代的開發(fā)成功展示給大家；

6、之后還要開一個(gè)反思會(huì)（Retrospective Meeting），Scrum團(tuán)隊(duì)會(huì)回顧過去這個(gè)Sprint，從中總結(jié)經(jīng)驗(yàn)教訓(xùn)。

傳統(tǒng)的項(xiàng)目負(fù)責(zé)人也罷，敏捷的項(xiàng)目負(fù)責(zé)人也罷，都會(huì)制定計(jì)劃，而且會(huì)為之投入相當(dāng)?shù)臅r(shí)間。但是他們對(duì)待計(jì)劃的態(tài)度截然不同。在敏捷開發(fā)中，我們采用“調(diào)整性行為”來說明應(yīng)該采納的一些正確做法(其中之一便有可能是糾正計(jì)劃本身)。

1、知曉變化（即不確定因素）可能隨時(shí)發(fā)生，面對(duì)突發(fā)的變化，要進(jìn)行相應(yīng)的調(diào)整，而不能繼續(xù)按原計(jì)劃執(zhí)行。

實(shí)際工作中我們會(huì)遇到：客戶提出新的要求，開發(fā)團(tuán)隊(duì)的經(jīng)驗(yàn)不能馬上告訴：這個(gè)技術(shù)需求能不能實(shí)現(xiàn)或需要多長(zhǎng)時(shí)間實(shí)現(xiàn)。一般需要三天時(shí)間進(jìn)行預(yù)研，這樣才能知道是否能做，需要多少時(shí)間完成。然后修改部分計(jì)劃。

2、必要時(shí)，對(duì)項(xiàng)目的過程和實(shí)施辦法做出隨機(jī)調(diào)整。

（1）調(diào)節(jié)項(xiàng)目中的已知和未知。

哈佛商學(xué)院教授羅布·奧斯丁(Rob Austin)和同事李德文(Lee Devin)共同執(zhí)筆發(fā)表了《藝術(shù)性管理》(Artful Making)一書。書中提到一個(gè)價(jià)值1.25億美元的IT項(xiàng)目最終失敗的案例。失敗的原因正是由于合作企業(yè)一味堅(jiān)持原計(jì)劃，亦步亦趨死板執(zhí)行，拒絕用調(diào)整來應(yīng)對(duì)突發(fā)的變化而造成的。書中寫道：“‘為工作制定計(jì)劃，然后按照計(jì)劃做事’成了讓他們盲從的真言，直接導(dǎo)致團(tuán)隊(duì)采取了毀滅性的做法，帶來慘重的代價(jià)?！?在商界，人人都以為這種問題很少發(fā)生，可實(shí)際上卻非常普遍?！?/p>

現(xiàn)實(shí)中每一個(gè)項(xiàng)目都有其已知的條件和未知的因素，有其確定的一面以及不確定的一面，因此每一個(gè)項(xiàng)目都必須在計(jì)劃和隨機(jī)調(diào)整之間取得平衡。這種平衡是必須的，因?yàn)轫?xiàng)目可以是生產(chǎn)性的，也可以是開發(fā)性的，還可以是介于兩者之間的。生產(chǎn)性的項(xiàng)目不確定性很低，而開發(fā)性的項(xiàng)目卻是高度不確定的。開發(fā)性項(xiàng)目強(qiáng)調(diào)預(yù)見性，項(xiàng)目執(zhí)行的過程，就是朝著預(yù)見的方向探索前進(jìn)的過程，而不是制定出嚴(yán)密周詳?shù)挠?jì)劃，然后嚴(yán)格實(shí)施的過程。也就是說，計(jì)劃或調(diào)整，不能說孰對(duì)孰錯(cuò)，管理者應(yīng)根據(jù)項(xiàng)目自身的具體情況、具體條件，作出最恰當(dāng)?shù)倪x擇。

實(shí)際中經(jīng)常遇到類似這樣的情況：

Product owner（需求方，可以是產(chǎn)品經(jīng)理，可以是甲方，可以是單位的主管）不可能一次想清楚所有需求時(shí)，產(chǎn)品上線前的灰度發(fā)布會(huì)有些修改，上線后還要根據(jù)用戶的反饋，可能還會(huì)進(jìn)行不止一次的修改。（例如，如何鼓勵(lì)用戶進(jìn)行評(píng)價(jià)。開始是要求用戶必須評(píng)價(jià)，后來用戶評(píng)價(jià)的頻度降低了，而且大多是“哈哈哈哈哈”等無(wú)效評(píng)價(jià)；又選擇做趣味性界面，增加了動(dòng)畫，但時(shí)間長(zhǎng)了，也就降低了趣味性。有效評(píng)價(jià)還會(huì)再次降低，再次面臨新的修改。）

（2） 駕馭風(fēng)險(xiǎn)，抓住機(jī)遇

人們不想采取敏捷的做法時(shí)，往往會(huì)找各種借口、理由，甚至抱怨：“這樣做太費(fèi)時(shí)間了”，或者“這樣做成本太高”等等。所以無(wú)論是短期試點(diǎn)，更新數(shù)據(jù)，隨時(shí)整合，自動(dòng)檢測(cè)，還是其他的各種變通性做法，總是會(huì)遇到這樣的托辭。

多數(shù)情況下，雖不盡然，找種種借口拒絕調(diào)整，往往會(huì)直接導(dǎo)致效率低下，因?yàn)樗屍髽I(yè)失去了精簡(jiǎn)流程、提高隨機(jī)應(yīng)對(duì)的機(jī)會(huì)。培養(yǎng)團(tuán)隊(duì)的敏捷性，必須進(jìn)行小型的試點(diǎn)；而小型試點(diǎn)的目的就是找到方法，讓重復(fù)的工作環(huán)節(jié)能夠低成本地快速完成。而快速且低成本的工作習(xí)慣，又能促使團(tuán)隊(duì)面對(duì)變化，另辟蹊徑?？焖俚统杀镜慕鉀Q辦法，還能夠鼓勵(lì)團(tuán)隊(duì)勇于創(chuàng)新，從而鍛煉團(tuán)隊(duì)的創(chuàng)新精神。而這種創(chuàng)新又會(huì)影響到企業(yè)的其他部門，產(chǎn)生漣漪效應(yīng)。這樣一來，降低成本應(yīng)對(duì)變化，就會(huì)促使企業(yè)重新思考它的商業(yè)模式。

（3） 采取可靠的而不是可重復(fù)的步驟

必須指出“可重復(fù)的”并不意味著敏捷。雖然實(shí)施可重復(fù)的步驟，已經(jīng)成為許多企業(yè)的管理目標(biāo)，但在產(chǎn)品開發(fā)的過程中，追求可重復(fù)的目標(biāo)卻不僅是錯(cuò)誤的，而且會(huì)極大的遏制產(chǎn)品的開發(fā)?？芍貜?fù)意味著用同樣的方式，做同樣的事情，產(chǎn)出同樣的結(jié)果。而可靠性卻指的是無(wú)論遇到什么困難障礙都要實(shí)現(xiàn)既定的目標(biāo)——也就意味著不斷的做出調(diào)整，應(yīng)對(duì)各種變化，實(shí)現(xiàn)既定目標(biāo)。

可重復(fù)的步驟，通過制定標(biāo)準(zhǔn)和對(duì)流程的不斷改進(jìn)，來減少產(chǎn)品的質(zhì)量變化。這是一個(gè)源于制造業(yè)的詞。因?yàn)樵谏a(chǎn)制造中，產(chǎn)出什么樣的產(chǎn)品，是已經(jīng)定義好的。那么可重復(fù)性就意味在生產(chǎn)過程中，只要連續(xù)輸入，就可以產(chǎn)出預(yù)期的結(jié)果?？梢灾貜?fù)意味著從輸入到產(chǎn)出的轉(zhuǎn)換過程是可以復(fù)制的，而無(wú)需任何變化。它還意味著生產(chǎn)的過程不會(huì)有任何新情況發(fā)生，因?yàn)樗行畔⒍既款A(yù)先知道，來保證最終的精準(zhǔn)產(chǎn)出。但是，可重復(fù)的步驟在產(chǎn)品開發(fā)中毫無(wú)用處，因?yàn)槭紫群茈y精準(zhǔn)地判斷出最終的結(jié)果；其次項(xiàng)目不同，項(xiàng)目的投入也大不相同；第三，開發(fā)不同產(chǎn)品，從輸入到產(chǎn)出的轉(zhuǎn)換過程本身更是大相徑庭。

可靠的步驟過程關(guān)注的是產(chǎn)出，而不是投入。哪怕是投入完全不同，通過采取可靠的步驟，項(xiàng)目成員也能夠想出各種辦法，不斷向既定的目標(biāo)靠攏。也正因?yàn)橥度氲牟町?，他們決不會(huì)把一個(gè)項(xiàng)目所采用的步驟或做法，亦或是試點(diǎn)，復(fù)制到另一個(gè)項(xiàng)目中。

可靠性是受結(jié)果驅(qū)動(dòng)的；而可復(fù)制性是受輸入驅(qū)動(dòng)的。如果把項(xiàng)目的步驟固定下來，那么項(xiàng)目本身就會(huì)因?yàn)橥度牒娃D(zhuǎn)化的巨大差異，而變得極其危險(xiǎn)。即便是那些聲稱采用了固定步驟且獲得成功的企業(yè)，他們的成功并非來自于固定的、可重復(fù)的過程本身，而是來自于企業(yè)員工在實(shí)施這些步驟時(shí)，進(jìn)行的敏捷調(diào)整。

敏捷開發(fā)項(xiàng)目管理（APM)既是可靠的，又是可預(yù)測(cè)的：這樣的項(xiàng)目過程，由于考慮到了各種不確定性因素，因而在規(guī)定的時(shí)限內(nèi)開發(fā)出的產(chǎn)品，最能滿足客戶不斷變化的各種需求。這一點(diǎn)是其他任何一種管理方式都無(wú)法比擬的。而之所以能夠這樣，不是因?yàn)轫?xiàng)目經(jīng)理制定出了極其周詳?shù)娜蝿?wù)計(jì)劃，也不是對(duì)這個(gè)計(jì)劃實(shí)施了精微細(xì)致的管理，而是因?yàn)槊艚莸捻?xiàng)目管理者，營(yíng)造了一個(gè)這樣的工作環(huán)境和氛圍：人人追求卓越，并愿意為實(shí)現(xiàn)目標(biāo)而努力。

敏捷管理雖然是可靠的，但也并非是無(wú)往而不勝的，因?yàn)樗⒉荒芟械牟淮_定性，也無(wú)法避免全部的意外。但是，這樣的管理方式能夠設(shè)法轉(zhuǎn)化意外和不確定性，使項(xiàng)目最終走向成功。

總結(jié)來說：敏捷設(shè)計(jì)是一個(gè)過程，不是一個(gè)事件。它是一個(gè)持續(xù)的應(yīng)用原則、模式以及實(shí)踐來改進(jìn)軟件的結(jié)構(gòu)和可讀性的過程。它致力于保持系統(tǒng)設(shè)計(jì)在任何時(shí)間都盡可能得簡(jiǎn)單、干凈以及富有表現(xiàn)力。

軟件大師、C++之父Bjarne Stroustrup曾經(jīng)說過：設(shè)計(jì)和編程都是人的活動(dòng)。忘記了這一點(diǎn)，將會(huì)失去一切。敏捷軟件開發(fā)方法正是認(rèn)識(shí)到軟件開發(fā)的這一本質(zhì)特征而提出的革新性開發(fā)方法。雖然完全做到很困難，但堅(jiān)持使用敏捷開發(fā)方法一定會(huì)給我們帶來巨大的好處。