論敏捷在軟件開(kāi)發(fā)中

敏捷的軟件開(kāi)發(fā)在軟件工程當(dāng)中的應(yīng)用隨著軟件開(kāi)發(fā)方法的不斷演進(jìn)，混合的開(kāi)發(fā)方法在各軟件企業(yè)和團(tuán)隊(duì)中應(yīng)用越來(lái)越廣泛。每一種開(kāi)發(fā)方法都有其優(yōu)點(diǎn)，如傳統(tǒng)的瀑布式方要求有詳細(xì)的項(xiàng)目計(jì)劃和文檔，部署、QA測(cè)試和交付過(guò)程嚴(yán)謹(jǐn)。而敏捷方法的優(yōu)點(diǎn)則體現(xiàn)在能夠快速迭代，更多的強(qiáng)調(diào)人員在整個(gè)開(kāi)發(fā)過(guò)程中所發(fā)揮的作用。有研究機(jī)構(gòu)數(shù)據(jù)顯示，越來(lái)越多的開(kāi)發(fā)團(tuán)隊(duì)開(kāi)始采用混合的開(kāi)發(fā)方法。其中，有的團(tuán)隊(duì)同時(shí)采用XP、SCRUM等多種敏捷方法，也有同時(shí)采用敏捷和傳統(tǒng)相結(jié)合的方法，而只采用一種敏捷方法的團(tuán)隊(duì)或企業(yè)的比例還不足三分之一。而如果換一個(gè)角度，站在客戶的立場(chǎng)上呢？也許付錢購(gòu)買軟件的客戶會(huì)有一些不同的想法。項(xiàng)目B從開(kāi)始之后一個(gè)月便交付了第一個(gè)可工作的版本，從那時(shí)起客戶就開(kāi)始使用這個(gè)軟件的部分功能，并且不斷地把自己使用的感受反饋給開(kāi)發(fā)團(tuán)隊(duì)。在真實(shí)的業(yè)務(wù)運(yùn)營(yíng)過(guò)程中，客戶甚至發(fā)現(xiàn)了一種新的盈利模式，并進(jìn)行了一次大規(guī)模的業(yè)務(wù)調(diào)整，這次調(diào)整的結(jié)果也直觀地體現(xiàn)在軟件項(xiàng)目中。雖然項(xiàng)目B的整體交付速率低于項(xiàng)目A，但它提供的所有功能都是客戶真正需要的，它們?yōu)榭蛻籼峁?shí)實(shí)在在的價(jià)值——更不用說(shuō)，客戶提前好幾個(gè)月就開(kāi)始使用這個(gè)軟件。實(shí)際上，這是一個(gè)關(guān)于軟件價(jià)值的討論。和“成功項(xiàng)目”一樣，對(duì)于“軟件的價(jià)值”，不同的人也會(huì)有不同的定義。不過(guò)作為付錢購(gòu)買軟件的客戶，他對(duì)于軟件價(jià)值的定義是一目了然的：他能夠從使用軟件中創(chuàng)造多少價(jià)值，軟件能夠?yàn)樗臉I(yè)務(wù)提供多少價(jià)值，這就是軟件的價(jià)值?；蛘哒f(shuō)得更簡(jiǎn)明一點(diǎn)：軟件價(jià)值源自使用。這正是為什么很多客戶青睞“項(xiàng)目B”的原因——這里并不是肯定所有的客戶都有同樣的觀點(diǎn)，稍后筆者會(huì)舉出反例，但至少支持這一觀點(diǎn)的客戶不在少數(shù)。因?yàn)樗麄兲幵谝粋€(gè)殘酷而快速變化的商業(yè)環(huán)境中：他們的供應(yīng)商在變化，他們的客戶在變化，他們所處的經(jīng)濟(jì)環(huán)境和政策環(huán)境也在變化。這一切的變化迫使他們的業(yè)務(wù)也要隨之變化。今天這個(gè)經(jīng)濟(jì)全球化的時(shí)代是一個(gè)“快魚(yú)吃慢魚(yú)”的時(shí)代，客戶迫切希望新的軟件系統(tǒng)為他們帶來(lái)競(jìng)爭(zhēng)優(yōu)勢(shì)——哪怕這個(gè)軟件系統(tǒng)尚未完成，只要能夠投入使用。最后，客戶對(duì)于新的軟件系統(tǒng)究竟應(yīng)該是什么樣子并沒(méi)有百分之百的把握，他們的想法往往要在真正使用軟件之后才會(huì)浮現(xiàn)成型。幾方面的因素加在一起，使得這些客戶更愿意盡快開(kāi)始使用軟件、提出反饋、并不斷完善軟件，而不是提出一組需求、然后坐等幾個(gè)月之后原封不動(dòng)地拿到這些功能。想想這個(gè)客戶會(huì)怎么定義一個(gè)“成功的軟件項(xiàng)目”？也許這個(gè)項(xiàng)目超過(guò)了預(yù)期的時(shí)間，也許投入了更多的人力，但這些并不意味著“項(xiàng)目失敗”——只是付出更高的成本。關(guān)鍵在于，他投入的這些成本能夠帶來(lái)多大的收益，他的投資回報(bào)率是否劃算。對(duì)于這個(gè)客戶而言，如果項(xiàng)目能夠隨時(shí)給他提供可用的、能夠創(chuàng)造最大價(jià)值的軟件，能夠隨時(shí)讓這種有價(jià)值的想法得以實(shí)現(xiàn)，這就是一個(gè)成功的項(xiàng)目。這里所說(shuō)明的就是一種為客戶創(chuàng)造最大化價(jià)值的軟件開(kāi)發(fā)方法。這樣的方法有很多種，但它們有一個(gè)共同的特點(diǎn)：盡快、盡可能頻繁地交付可以工作的軟件，讓客戶盡快開(kāi)始使用軟件，從使用中創(chuàng)造價(jià)值、厘清思路、提出反饋。仍然以ThoughtWorks的項(xiàng)目為例，這些項(xiàng)目通常在啟動(dòng)開(kāi)發(fā)階段之后一個(gè)月內(nèi)就會(huì)發(fā)布第一個(gè)版本，隨后每一周或每?jī)芍馨l(fā)布一個(gè)新版本——每個(gè)版本都是一個(gè)可以工作的軟件，每個(gè)版本都比前一個(gè)版本具有更豐富的功能，并且每個(gè)版本都包含客戶認(rèn)為迄今為止最有價(jià)值的那些功能?！伴_(kāi)發(fā)下一個(gè)版本”的過(guò)程叫做“迭代”，這些開(kāi)發(fā)方法最大的共同點(diǎn)就是“迭代式開(kāi)發(fā)”——不是一股腦地交付全部功能，而是每次增加一點(diǎn)、漸進(jìn)地交付最有價(jià)值的功能。對(duì)于很多軟件企業(yè)而言，項(xiàng)目A是一個(gè)“理想的”成功項(xiàng)目。那么，是什么讓情況變得不那么理想？答案是一個(gè)所有軟件開(kāi)發(fā)者耳熟能詳?shù)脑~：需求變更。在真實(shí)的項(xiàng)目中，客戶通常不會(huì)等到最后一天再照單全收整個(gè)項(xiàng)目，因?yàn)樗雷约旱臉I(yè)務(wù)正在發(fā)生變化。這時(shí)需求變更就出現(xiàn)了，伴隨著來(lái)回的扯皮和討價(jià)還價(jià)。更糟的是，大量的需求變更發(fā)生在項(xiàng)目晚期——因?yàn)橹钡竭@時(shí)客戶才真正看到、使用到這個(gè)軟件，他的很多想法才真正浮現(xiàn)成型。隨著這種“最后一分鐘的需求變更”，項(xiàng)目超期、超出預(yù)算也就成了家常便飯。能夠像項(xiàng)目A這樣完工交付的，實(shí)在是鳳毛麟角的幸運(yùn)兒。為了對(duì)付需求變更這個(gè)噩夢(mèng)，軟件開(kāi)發(fā)者們還發(fā)明了另一個(gè)詞：變更控制。這個(gè)有趣的詞暗示著：需求變更是一種“不好”的東西，是需要“控制”的東西。然而站在客戶的角度上想想，他在親身使用了軟件之后提出的要求，難道不是最有價(jià)值的東西嗎？把這種真正創(chuàng)造業(yè)務(wù)價(jià)值的要求“控制”起來(lái)，難道是合理的嗎？在前面提到過(guò)，并非所有的客戶都一定青睞迭代式開(kāi)發(fā)。那么，哪些軟件項(xiàng)目不一定需要迭代式開(kāi)發(fā)呢？從整篇文章的內(nèi)容不難看出，如果客戶的業(yè)務(wù)絕對(duì)不會(huì)變化，如果客戶的需求巨細(xì)靡遺非常明確，如果客戶不需要盡快開(kāi)始使用軟件以便收回成本，那么迭代式開(kāi)發(fā)對(duì)他的幫助就會(huì)小得多。不過(guò)，如果讀者認(rèn)真思考的話，這樣的例子也許并不多——也許比你最初認(rèn)為的要少得多。一個(gè)很好的例子是“神州六號(hào)”火箭使用的計(jì)算機(jī)控制系統(tǒng)。還有多少這樣的例子？讀者不妨試著自己想想。為了讓迭代式開(kāi)發(fā)能夠成為現(xiàn)實(shí)，為了確保盡快、盡可能頻繁地交付，為了確保每次交付的都是最有價(jià)值的功能，軟件開(kāi)發(fā)者、軟件企業(yè)和客戶——需要很多的改變。這里既有職責(zé)與權(quán)利的劃分，也有開(kāi)發(fā)過(guò)程和團(tuán)隊(duì)的重組，還有技術(shù)層面的實(shí)踐指導(dǎo)。這些正是敏捷方法學(xué)所涵蓋的內(nèi)容。缺少了這些東西，“為客戶創(chuàng)造最大價(jià)值”就只能成為一句空話。企業(yè)架構(gòu)(EA)和敏捷方法(AM)擁有共同的目標(biāo)——交付能夠跟業(yè)務(wù)需要對(duì)齊的軟件，并響應(yīng)對(duì)這些業(yè)務(wù)需要無(wú)可避免的變更。報(bào)告的標(biāo)題確實(shí)說(shuō)：“是的，但需要付出努力”，所以仍然還有希望。但需要EA組和AM項(xiàng)目認(rèn)識(shí)到對(duì)方有價(jià)值的貢獻(xiàn)，并在他們的工作中做出適應(yīng)性調(diào)整。一個(gè)曾經(jīng)使用過(guò)其中一種但因?yàn)槿狈?duì)另一個(gè)的使用而失敗了的項(xiàng)目會(huì)最大程度擁有使用兩者的經(jīng)驗(yàn)。例如，一個(gè)重要的文檔處理系統(tǒng)可以使用最好的AM實(shí)踐開(kāi)發(fā)出來(lái)，但不能協(xié)調(diào)好系統(tǒng)的EA需要如跨越需求、接口、和操作性問(wèn)題等。作為選擇，一個(gè)采用瀑布方式的項(xiàng)目會(huì)準(zhǔn)備妥當(dāng)它的所有的企業(yè)架構(gòu)，但是卻不能向及早的向客戶展現(xiàn)它的價(jià)值，或者不能夠通過(guò)有意義的迭代來(lái)解決風(fēng)險(xiǎn)問(wèn)題。所以，這些paper都是來(lái)自于經(jīng)驗(yàn)的，例如：項(xiàng)目是如何因?yàn)楹雎粤似渌尚械囊?guī)程才陷入這種境地的，有效的處理方式是什么等。一個(gè)意義更加深遠(yuǎn)的案例可能是在項(xiàng)目啟動(dòng)時(shí)均衡EA和AM。

然而，這其實(shí)非常難，很少發(fā)生，主要是因?yàn)榻M織性問(wèn)題，以及誰(shuí)在過(guò)程的哪個(gè)部分被涉及的角度。你會(huì)看到很多的失敗，例如架構(gòu)師跟客戶（更慘的是在根本沒(méi)有客戶）但沒(méi)有開(kāi)發(fā)團(tuán)隊(duì)參與的情況下整理需求，然后開(kāi)發(fā)團(tuán)隊(duì)脫離開(kāi)架構(gòu)師進(jìn)行接管。JimWatson和MichaelRosen告訴我們，關(guān)于這個(gè)專題的范圍，SOA可以被看作是EA的一個(gè)實(shí)例。因此這里所有相關(guān)的問(wèn)題和解決方案適用于采用了SOA并存在AM團(tuán)隊(duì)的組織(無(wú)需驚訝，這與InfoQ上的文章相吻合)EA和AM的交互并不依賴于SOA，但值得注意的是SOA提供了相互的興趣和問(wèn)題以允許進(jìn)程一起使用EA和AM。例如，想在一個(gè)SOA主導(dǎo)的項(xiàng)目定義真正有用的業(yè)務(wù)級(jí)別的服務(wù)可能具有難度，一個(gè)缺乏AM開(kāi)發(fā)實(shí)踐的由EA主導(dǎo)的SOA會(huì)產(chǎn)生許多的SOAshelfware，因?yàn)樗茈y實(shí)現(xiàn)或者僅僅定義出不是真正需要的接口。一個(gè)推薦的方案是，

對(duì)一個(gè)AM團(tuán)隊(duì)而言它被當(dāng)作架構(gòu)的一個(gè)包含部分，作為每個(gè)團(tuán)隊(duì)的成員與EA組進(jìn)行聯(lián)絡(luò)。當(dāng)被要求闡明推薦ArchitectReloadus

或是ArchitectOryzus（其定義見(jiàn)MartinFowler的）中的哪種架構(gòu)類型時(shí)，MichaelRosen建議哪種也不采用。在大的組織中會(huì)擁有重要的EA組，一個(gè)典型的IT組可能擁有2000個(gè)員工，500個(gè)架構(gòu)性的重大項(xiàng)目，在EA組中只有70個(gè)架構(gòu)師。沒(méi)有足夠的架構(gòu)時(shí)可供應(yīng)因此ArchitectOryzus很難應(yīng)用。ArchitectReloadus同樣不能得到應(yīng)用，因?yàn)樗鼈儧](méi)有可實(shí)施的環(huán)境。有效的架構(gòu)師的使用方式是作為一個(gè)單獨(dú)的AM團(tuán)隊(duì)的咨詢顧問(wèn)，這樣，一個(gè)來(lái)自EA組的架構(gòu)師就可以發(fā)揮效用而不是嵌入到團(tuán)隊(duì)中。所以，擁有EA組和AM團(tuán)隊(duì)的組織不必要互相容忍，雖然他們擁有共同的目標(biāo)，他們的缺省操作模式是不與其它成對(duì)的并且（成對(duì)使用通常會(huì)）產(chǎn)生問(wèn)題。因此這些實(shí)踐等對(duì)達(dá)成企業(yè)的戰(zhàn)略目標(biāo)和交付戰(zhàn)術(shù)性的軟件項(xiàng)目非常有用。敏捷聯(lián)盟創(chuàng)始人之一、咨詢師兼圖書(shū)作者M(jìn)ikeCohn最近根據(jù)其自身經(jīng)驗(yàn)將“如何幫助團(tuán)隊(duì)采納敏捷”總結(jié)為。Mike建議，團(tuán)隊(duì)或者組織在逐步采用敏捷的過(guò)程中，應(yīng)該從每對(duì)模式中選出一個(gè)最適合他們自身情況的模式?！靶〔角斑M(jìn)”是指最初在一個(gè)試航團(tuán)隊(duì)中嘗試敏捷的轉(zhuǎn)型，然后逐漸推廣到整個(gè)組織中的方法。Mike建議，這種方法在以下幾個(gè)方面具有優(yōu)勢(shì)：最小化因錯(cuò)誤而導(dǎo)致的成本、將最初成功的可能性最大化、培養(yǎng)內(nèi)部的“專家”，以協(xié)助后期推廣過(guò)程的順利進(jìn)行。Mike緊接著提及三個(gè)隱患：團(tuán)隊(duì)在試驗(yàn)階段產(chǎn)生的早期的成功，可能會(huì)給整個(gè)組織帶來(lái)錯(cuò)誤的期望；組織推廣所用的時(shí)間會(huì)更長(zhǎng)；一旦失敗，懷疑者將把其視為公司無(wú)法實(shí)現(xiàn)承諾的一種信號(hào)。與其相反，“全面推廣”的特征是從一開(kāi)始就讓所有團(tuán)隊(duì)進(jìn)行轉(zhuǎn)型，它可以在以下方面讓企業(yè)受益：展現(xiàn)管理中的各種承諾，組織會(huì)變得更加靈活，避免同時(shí)使用兩個(gè)過(guò)程帶來(lái)的不一致，以及減少總體上的抵觸感。Mike同時(shí)也指出了“全面推進(jìn)”的缺點(diǎn)：高風(fēng)險(xiǎn)，高開(kāi)銷，可能需要機(jī)構(gòu)重組，會(huì)遇到來(lái)自于組織的很大壓力。“技術(shù)實(shí)踐優(yōu)先”要求團(tuán)隊(duì)接受敏捷是從關(guān)注XP的諸多實(shí)踐開(kāi)始的，比如簡(jiǎn)單設(shè)計(jì)、測(cè)試驅(qū)動(dòng)開(kāi)發(fā)、結(jié)對(duì)編程、持續(xù)集成以及短迭代周期。它帶給團(tuán)隊(duì)的好處是：轉(zhuǎn)型的啟動(dòng)非常迅速而且平滑。Mike指出這種方法的不足在于：通常較難做到，而且會(huì)導(dǎo)致開(kāi)銷激增，同時(shí)還可能將團(tuán)隊(duì)帶離以用戶為中心的思考，從而失去了敏捷的真正意義。相反，“迭代優(yōu)先”方法，它最初只關(guān)注“團(tuán)隊(duì)以迭代方式工作”，一旦這個(gè)目標(biāo)受到阻礙，才著手改變技術(shù)實(shí)踐。它的優(yōu)勢(shì)可能在于：它很容易實(shí)現(xiàn)，而且遇到團(tuán)隊(duì)成員抵觸的可能性很小。但也有另一個(gè)風(fēng)險(xiǎn)：團(tuán)隊(duì)可能永遠(yuǎn)也不會(huì)采用對(duì)于改善敏捷而言最基礎(chǔ)的工程實(shí)踐?！懊孛苄袆?dòng)”是指團(tuán)隊(duì)在采用敏捷實(shí)踐過(guò)程中積累的大量知識(shí)只保留在團(tuán)隊(duì)的內(nèi)部。它允許團(tuán)隊(duì)在受到其他人關(guān)注之前就能獲得成功，這就是它給團(tuán)隊(duì)帶來(lái)的好處；那些關(guān)注即來(lái)自于希望模仿他們的人，也來(lái)自于可能會(huì)反對(duì)他們的人。其缺點(diǎn)包括：難以獲得組織所能提供的必要的支持，同時(shí)，即使這個(gè)團(tuán)隊(duì)成功了，也不容易說(shuō)服懷疑者們?nèi)バ欧??！肮_(kāi)推廣”是指團(tuán)隊(duì)在采用敏捷過(guò)程中所做的努力對(duì)于團(tuán)隊(duì)以外甚至組織以外都是公開(kāi)的知識(shí)。它的優(yōu)勢(shì)在于：它會(huì)激勵(lì)團(tuán)隊(duì)去堅(jiān)持采用敏捷之路，幫助團(tuán)隊(duì)得到外部的支持，更早地發(fā)現(xiàn)懷疑者們的疑慮，并證明高層管理者支持這種變遷并希望它成功。其可能引起的不良后果是，假如公開(kāi)宣布開(kāi)始做某件事，最終卻沒(méi)有成功，別人會(huì)認(rèn)為這是非常魯莽的，也就是說(shuō)，此時(shí)反對(duì)者的質(zhì)疑聲就徹底抵消了這種方法的優(yōu)勢(shì)所在，而這正是“公開(kāi)推廣”的劣勢(shì)比選擇的特定迭代周期長(zhǎng)度更重要的是，開(kāi)發(fā)小組在迭代中把一個(gè)以上不精確的需求聲明變成經(jīng)過(guò)編碼、測(cè)試，實(shí)際可以交付的軟件。當(dāng)然，大多數(shù)小組不會(huì)把每次迭代的結(jié)果都交付給用戶；敏捷開(kāi)發(fā)的目標(biāo)只是讓他們可以交付。這意味著開(kāi)發(fā)小組在每次迭代中都會(huì)增加一些小功能，但是增加的每個(gè)功能都經(jīng)過(guò)編碼、測(cè)試，達(dá)到了可以發(fā)布的質(zhì)量。在每次迭代結(jié)束的時(shí)候讓產(chǎn)品達(dá)到潛在可交付狀態(tài)是很重要的。實(shí)際上，這并不是說(shuō)小組必須全部完成發(fā)布所需的所有工作，因?yàn)樗麄兺ǔ２⒉粫?huì)每次迭代都真的發(fā)布產(chǎn)品。例如，我曾經(jīng)參與一個(gè)小組的工作，他們需要在發(fā)布產(chǎn)品之前對(duì)軟硬件都進(jìn)行2個(gè)月的MTBF(MeanTimeBetweenFailure，平均無(wú)故障時(shí)間)測(cè)試。他們不能縮短這2個(gè)月的時(shí)間，因?yàn)檫@是他們的客戶通過(guò)合同約定的，而且檢查硬件故障也需要這么多時(shí)間。這個(gè)小組按照4周的迭代周期工作，他們的產(chǎn)品在每次迭代結(jié)束的時(shí)候除了沒(méi)有進(jìn)行這2個(gè)月的MTBF測(cè)試，都達(dá)到了確實(shí)可以發(fā)布的狀態(tài)。由于單次迭代并不總能提供足夠的時(shí)間來(lái)完成足夠滿足用戶或客戶需要的新功能，因此我們需要引入更廣義的發(fā)布(release)概念。一次發(fā)布由一次或以上(通常是以上)相互接續(xù)，完成一組相關(guān)功能的迭代組成。最常見(jiàn)的迭代一般是2～4周，一次發(fā)布通常是2～6個(gè)月。例如，在一個(gè)投資管理系統(tǒng)中，一次發(fā)布可能包括所有與買入和賣出共同基金和貨幣市場(chǎng)基金有關(guān)的功能。這需要6次2周的迭代來(lái)完成(大約3個(gè)月)。第二次發(fā)布可能增加了股票和債券交易，需要4次2周的迭代?？梢园床煌拈g隔進(jìn)行發(fā)布。也許需要6個(gè)月來(lái)完成第一次發(fā)布，而接下來(lái)的發(fā)布則可能在3個(gè)月以后，等等。敏捷開(kāi)發(fā)小組從兩個(gè)方面顯示出他們對(duì)業(yè)務(wù)優(yōu)先級(jí)的關(guān)注。首先，他們按照產(chǎn)品所有者所制定的順序交付功能，而產(chǎn)品所有者一般會(huì)按照使機(jī)構(gòu)在項(xiàng)目上的投資回報(bào)最大化的方式來(lái)確定功能的優(yōu)先級(jí)，并將它們組織到產(chǎn)品發(fā)布中。要達(dá)到這一目的，需要根據(jù)開(kāi)發(fā)小組的能力和所需新功能的優(yōu)先級(jí)建立一個(gè)發(fā)布計(jì)劃。要讓產(chǎn)品所有者在確定功能的優(yōu)先級(jí)時(shí)具有最大的靈活性，就必須在編寫(xiě)功能時(shí)使它們相互之間的技術(shù)依賴性最小化。如果選擇一個(gè)功能要求先開(kāi)發(fā)另外的