軟件開發(fā)開始階段
軟件開發(fā)剛開始的時(shí)候，并沒有很好的經(jīng)驗(yàn)或思想來指導(dǎo)一個(gè)開發(fā)項(xiàng)目的運(yùn)行。最開始，人們標(biāo)識(shí)出軟件開發(fā)的一些關(guān)鍵假設(shè)，映射到那時(shí)已有的可理解的流程上。

最初的假設(shè)如下：
軟件開發(fā)需要很長(zhǎng)的時(shí)間
軟件發(fā)布不會(huì)頻繁，軟件構(gòu)建后很難進(jìn)行更改，所以確保第一次把事情做對(duì)，軟件開發(fā)需要很多不同的、建筑行業(yè)也有著類似的假設(shè)。建筑需要很長(zhǎng)的時(shí)間，竣工后不能簡(jiǎn)單的添加一層或把面積擴(kuò)大。建筑也涉及到很多不同的專業(yè)，從設(shè)計(jì)師到開發(fā)商，到質(zhì)量監(jiān)理以及工人、電工和水暖工等等。從這些角色的命名可以看出，軟件開發(fā)從建筑行業(yè)借鑒了很多。建筑行業(yè)遵循的流程是，把端到端的項(xiàng)目分成不同的階段，每個(gè)流程階段由不同的專業(yè)人士來負(fù)責(zé)。這種在每個(gè)階段賦予角色的做法有利于充分利用成本高昂的人力資源。

敏捷開發(fā)
人們不希望看到自己的工作被廢棄掉，因此最初的一個(gè)思想是把大型項(xiàng)目分解成小的部分，逐步迭代出解決方案。這種方法讓人們能對(duì)產(chǎn)品隨時(shí)間的進(jìn)展有更直觀的印象，讓團(tuán)隊(duì)可以收集反饋來看產(chǎn)品是否已經(jīng)解決用戶的問題。這種早期的反饋?zhàn)寛F(tuán)隊(duì)按需進(jìn)行糾正。
但是從瀑布模型轉(zhuǎn)型到迭代交付很難，很多組織就把迭代開發(fā)解釋成隨時(shí)間增量交付解決方案。敏捷這個(gè)術(shù)語很靈活，按照設(shè)計(jì)，并沒有什么敏捷流程——其關(guān)注點(diǎn)在于小型迭代、持續(xù)學(xué)習(xí)和反應(yīng)性。盡管流程很容易遵守和實(shí)現(xiàn)，不過這些軟技能很難掌握。對(duì)流程闡述不夠，會(huì)讓人們繞開一些比較困難的變革，實(shí)現(xiàn)“對(duì)他們有效”的敏捷流程，并起一個(gè)引人注目的名字，如Wagile或WaterScrumFall。敏捷開發(fā)更好的透明度限制了出現(xiàn)嚴(yán)重超限的風(fēng)險(xiǎn)，但是它沒有解決導(dǎo)致瀑布項(xiàng)目高失敗率的根本問題。仍然有項(xiàng)目會(huì)花費(fèi)比預(yù)期長(zhǎng)的時(shí)間來進(jìn)行構(gòu)建，有些項(xiàng)目會(huì)因?yàn)椴荒芙桓额A(yù)期價(jià)值的產(chǎn)品被取消。為了實(shí)現(xiàn)到迭代交付的飛躍，我們需要改變對(duì)軟件交付的假設(shè)。我們要承認(rèn)，我們前期不知道要構(gòu)建的產(chǎn)品是什么樣的，因此我們需要將預(yù)先大量設(shè)計(jì)（Big Design Up Front，BDUF）階段替換成增量設(shè)計(jì)。這樣可以讓團(tuán)隊(duì)有能力在項(xiàng)目開展過程中進(jìn)行學(xué)習(xí)，并在需要的時(shí)候改變?cè)O(shè)計(jì)。這里的挑戰(zhàn)是，設(shè)計(jì)階段是保證項(xiàng)目團(tuán)隊(duì)內(nèi)外進(jìn)行協(xié)調(diào)的關(guān)鍵階段，并匯總實(shí)現(xiàn)解決方案所需的各種時(shí)間估計(jì)。一個(gè)公司的各個(gè)流程不是孤立的，所以要改變一個(gè)流程，就會(huì)影響另外一個(gè)看起來好像沒有關(guān)聯(lián)的流程。比如，從BDUF中得到的估計(jì)，會(huì)被其他支撐流程所需要，如資金、監(jiān)管、資源分配和環(huán)境分配等等。采用這些“對(duì)我們有效的敏捷”中的問題是，沒有認(rèn)識(shí)到或解決我們對(duì)軟件交付做出的假設(shè)和現(xiàn)有情況的沖突。

假設(shè)
軟件開發(fā)需要很長(zhǎng)的時(shí)間
軟件發(fā)布不會(huì)頻繁
軟件構(gòu)建后很難進(jìn)行更改，所以確保第一次把事情做對(duì)，前期不可能確切知道要構(gòu)建成什么樣的產(chǎn)品，因此把大型開發(fā)分解為小部分，并在項(xiàng)目進(jìn)行中不斷學(xué)習(xí)，軟件開發(fā)需要很多不同的、成本高昂的技能集，如果前期并不能確切知道要構(gòu)建怎樣的產(chǎn)品，我們?cè)趺床拍茏龅揭淮伟咽虑樽鰧?duì)呢？軟件的大設(shè)計(jì)和最終產(chǎn)品經(jīng)常有很大的出入——這就產(chǎn)生了不能預(yù)期的挑戰(zhàn)，即要求設(shè)計(jì)根據(jù)不斷出現(xiàn)的新需求進(jìn)行調(diào)整。這說明，和建筑行業(yè)不一樣，軟件的變更在構(gòu)建后并不困難，不需要像實(shí)體建筑那樣前期做縝密的設(shè)計(jì)。我們可以簡(jiǎn)單的添加（軟件）層數(shù)，改變層高或是擴(kuò)大面積，而不需要推倒重來。因此，假設(shè)2實(shí)際是不正確的。

真正的敏捷開發(fā)
如果設(shè)計(jì)可以隨著迭代過程中的學(xué)習(xí)進(jìn)行更改，那么只做每次迭代所需的設(shè)計(jì)就會(huì)有利于減少可能的返工。
這其實(shí)是最難的一步，因?yàn)樗粌H要求改變項(xiàng)目團(tuán)隊(duì)中的一些職能部門的工作方式，還包括支持部門工作方式的改變。
我們沒有足夠的架構(gòu)師，無法為每個(gè)團(tuán)隊(duì)都配備一個(gè)，指導(dǎo)他們進(jìn)行持續(xù)的架構(gòu)選擇。架構(gòu)師們需要定義好實(shí)踐、原則和強(qiáng)制措施，確保設(shè)計(jì)符合指定的約束條件，而不是定義一個(gè)固定的架構(gòu)。開發(fā)工程師們將被賦予更多的責(zé)任。他們要完成針對(duì)問題給出最佳解決方案的任務(wù)，而不僅僅是按照需求規(guī)格說明書進(jìn)行軟件構(gòu)建。架構(gòu)師們不再面對(duì)交付的挑戰(zhàn)，因此他們的假設(shè)經(jīng)常不正確。最前線的開發(fā)人員在面臨挑戰(zhàn)時(shí)往往能提出更好的解決方案。不進(jìn)行預(yù)先的大量設(shè)計(jì)，就很難預(yù)估時(shí)間和成本。在瀑布項(xiàng)目里，時(shí)間和成本是基于項(xiàng)目啟動(dòng)時(shí)的估計(jì)確定的。在增量開發(fā)中，項(xiàng)目范圍會(huì)根據(jù)實(shí)際遇到的新情況進(jìn)行調(diào)整。時(shí)間和成本估計(jì)仍可以根據(jù)對(duì)交付的大致理解和團(tuán)隊(duì)規(guī)模進(jìn)行，不過因?yàn)轫?xiàng)目范圍會(huì)有變化，投資回報(bào)率（ROI）和價(jià)值實(shí)現(xiàn)進(jìn)度（benefits realisation schedule）無法在前期給出。這些不是能輕松解決的任務(wù)，不過還是可以解決的。我會(huì)在后續(xù)的文章中詳細(xì)談到如何解決這些困難。現(xiàn)在，我們?cè)俑孪挛覀兊募僭O(shè)。

假設(shè)
軟件開發(fā)需要很長(zhǎng)的時(shí)間
軟件發(fā)布不會(huì)頻繁，前期不可能確切知道要構(gòu)建成什么樣的產(chǎn)品，因此把大型開發(fā)分解為小部分，并在項(xiàng)目進(jìn)行中不斷學(xué)習(xí)，軟件開發(fā)需要很多不同的、成本高昂的技能集，實(shí)現(xiàn)團(tuán)隊(duì)負(fù)責(zé)在一定的邊界條件下進(jìn)行設(shè)計(jì)。迭代交付的好處很大程度上是因?yàn)樗梢垣@得關(guān)于產(chǎn)品的早期反饋。為了獲取這些反饋，需要有一個(gè)軟件的工作版本，解決了客戶的問題，能夠進(jìn)行演示，并獲得實(shí)際的反饋。為了交付這樣一個(gè)軟件版本，主要有兩個(gè)挑戰(zhàn)需要克服——軟件開發(fā)怎樣進(jìn)行優(yōu)先排序和怎樣進(jìn)行測(cè)試。傳統(tǒng)的瀑布項(xiàng)目中，最有效的方法是按組件構(gòu)建產(chǎn)品——構(gòu)建完美的輪胎、完美的底盤，最后組裝到汽車上。上下文切換會(huì)耗費(fèi)時(shí)間，因此，切換越少就可以越高效地利用開發(fā)時(shí)間。這種組件開發(fā)方式在開發(fā)團(tuán)隊(duì)中根深蒂固，即使他們采用了敏捷開發(fā)，實(shí)際的構(gòu)建方式仍相同。問題是，如果客戶想從A點(diǎn)到B地點(diǎn)，而我們給客戶展示的是一個(gè)完成了的車輪，客戶沒法給出任何有價(jià)值的反饋。這解決不了他們的問題。我們需要從基于組件的開發(fā)轉(zhuǎn)換到迭代開發(fā)方式，這要求有一個(gè)思想上的轉(zhuǎn)換，即關(guān)注于客戶問題而不是解決方案。只有不再做預(yù)先的大量設(shè)計(jì)，并承認(rèn)前期我們并不很清楚需要構(gòu)建的是什么，這種轉(zhuǎn)變才可能實(shí)現(xiàn)。但即使如此，團(tuán)隊(duì)仍需要培訓(xùn)，因?yàn)樗鼤?huì)影響到需求文檔的編寫和開發(fā)的進(jìn)行。開發(fā)人員的時(shí)間是軟件開發(fā)中一項(xiàng)很高的成本，產(chǎn)品定義改變是否值得呢？除了31%的失敗率，微軟的分析指出，高達(dá)66%的功能沒有實(shí)現(xiàn)預(yù)定的商業(yè)價(jià)值?？紤]到失敗率，確保我們是否做對(duì)了事情遠(yuǎn)比開發(fā)效率更重要。我們會(huì)很快回到這一點(diǎn)，因?yàn)樗磳⒂绊懙轿覀兊南乱粋€(gè)假設(shè)。第二個(gè)挑戰(zhàn)是關(guān)于測(cè)試的。為了得到有價(jià)值的反饋，我們需要讓軟件在客戶面前工作起來，而不僅只作為演示。但是這需要測(cè)試，要花費(fèi)很多時(shí)間和努力來完成的一項(xiàng)工作。過去，只在每次大的發(fā)布上執(zhí)行一次測(cè)試，則自動(dòng)化測(cè)試用例并不劃算。但是有兩件事改變了測(cè)試的這種情況。第一，現(xiàn)在的軟件為商業(yè)的各個(gè)環(huán)節(jié)所需要，過去那種一年花很多天進(jìn)行一次發(fā)布的情況已經(jīng)不見了。第二，和開發(fā)人員的時(shí)間一樣，項(xiàng)目中最大的浪費(fèi)就是開發(fā)了錯(cuò)誤的東西，而自動(dòng)化測(cè)試讓我們可以更頻繁的測(cè)試客戶的想法，它帶來的益處超過了其成本。自動(dòng)化測(cè)試周期讓團(tuán)隊(duì)在整個(gè)開發(fā)過程中，可以持續(xù)開發(fā)“可發(fā)布”的代碼。100%的自動(dòng)化測(cè)試是個(gè)很難達(dá)到的目標(biāo)，因此在軟件發(fā)布前還有會(huì)小量的手動(dòng)驗(yàn)收測(cè)試，但其質(zhì)量已經(jīng)足夠驗(yàn)證解決方案。

持續(xù)交付/部署(DevOps)
持續(xù)集成的好處在于代碼在任何階段都是可供部署的。這樣即使項(xiàng)目即將被叫停，我們也有可部署的代碼。不過和前面提到的測(cè)試一樣，部署代碼成本高而且耗時(shí)多。即使軟件已經(jīng)就緒，人們?nèi)匀恍枰恍r(shí)間在環(huán)境間移動(dòng)代碼并完成部署步驟。而且軟件還可能遇到新的問題，比如負(fù)載性能差。所以你以為軟件已經(jīng)可以發(fā)布了，但實(shí)際不是。越早發(fā)現(xiàn)軟件問題，解決的成本就越低。所以理想情況下，團(tuán)隊(duì)?wèi)?yīng)該在每次迭代結(jié)束后，發(fā)現(xiàn)是否有非功能性需求的問題需要解決。手動(dòng)部署占用時(shí)間很長(zhǎng)，因此部署也應(yīng)該自動(dòng)化。持續(xù)交付縮減了代碼發(fā)布的時(shí)間，但有時(shí)可能不需要發(fā)布。比如，你可能只完成了某個(gè)特性的一半，那么在第二個(gè)迭代完成后發(fā)布也是合理的。了解整個(gè)部署階段有助于我們發(fā)現(xiàn)問題，所以應(yīng)該更頻繁的進(jìn)行部署。這樣就引入了功能發(fā)布控制（feature toggles/feature flags）。在標(biāo)識(shí)后面開發(fā)新功能，這樣我們可以部分發(fā)布已完成的功能，但讓它們處于關(guān)閉狀態(tài)。用戶甚至都不會(huì)意識(shí)到這些新功能，但我們可以測(cè)試到，這些代碼不會(huì)對(duì)其它部分造成破壞。功能發(fā)布控制還有其它的好處。將功能置于一個(gè)動(dòng)態(tài)的轉(zhuǎn)換中，我們可以開始在測(cè)試環(huán)境下進(jìn)行A/B測(cè)試和多元測(cè)試，進(jìn)而更精確的量化出變更的效果，這可以讓我們更精準(zhǔn)的驗(yàn)證我們對(duì)于客戶的假設(shè)，必要時(shí)進(jìn)行修正。我們可以動(dòng)態(tài)打開或關(guān)閉某個(gè)功能，因此可以在生產(chǎn)環(huán)境進(jìn)行用戶驗(yàn)收測(cè)試，從而節(jié)省時(shí)間和成本。經(jīng)過這些變化后，我們?cè)賮砘仡櫹挛覀兊募僭O(shè)。團(tuán)隊(duì)將交付時(shí)間從幾個(gè)月縮減到幾天，到一天幾次。我們真的不能說軟件開發(fā)花費(fèi)很長(zhǎng)的時(shí)間。如果它花的時(shí)間不長(zhǎng)，我們是否能讓專業(yè)人員分布到不同的階段呢——每天怎樣對(duì)多個(gè)階段進(jìn)行管理？我們沒有減少所需的技能集，因此我們?nèi)匀恍枰軜?gòu)師、業(yè)務(wù)分析師、手動(dòng)測(cè)試工程師、自動(dòng)化測(cè)試工程師、開發(fā)人員、運(yùn)營(yíng)人員、安全、管道開發(fā)人員等等。每個(gè)人只貢獻(xiàn)一小部分，因此我們不需要讓這些人員一直在一個(gè)團(tuán)隊(duì)，這樣成本太高了。但同樣的，我們不能讓他們獨(dú)立于團(tuán)隊(duì)之外，因?yàn)檫@樣響應(yīng)會(huì)太慢。如之前描述的架構(gòu)師一樣，確定邊界和限制后，部分角色不再需要很深地介入到項(xiàng)目。然而，項(xiàng)目其他人員將要承擔(dān)更多的責(zé)任。這類人員被稱為T型人才。他們?cè)谀硞€(gè)領(lǐng)域有很深的專業(yè)知識(shí)，同時(shí)對(duì)其它領(lǐng)域有廣博的了解。廣博的知識(shí)面讓他們?cè)跊]有全職人員參與的領(lǐng)域內(nèi)，也可以解決相關(guān)的問題。

假設(shè)
軟件發(fā)布可以很快很頻繁
前期不可能知道確切知道要構(gòu)建成什么樣的產(chǎn)品，因此把大型開發(fā)分解為小部分，并在項(xiàng)目進(jìn)行中不斷學(xué)習(xí)，持續(xù)交付中，T型人才是最有效的
實(shí)現(xiàn)團(tuán)隊(duì)需要在已定義的邊界下負(fù)責(zé)設(shè)計(jì)、開發(fā)和發(fā)布，如果我們快速迭代地進(jìn)行發(fā)布，那么如何進(jìn)行完工定義？如果我們有既定的范圍和時(shí)間，這個(gè)問題很簡(jiǎn)單?，F(xiàn)在，我們要隨時(shí)部署代碼，什么東西會(huì)妨礙我們這樣做？我們?cè)趺床胖朗裁磿r(shí)候產(chǎn)品已經(jīng)足夠好呢?如果軟件交付不再需要很長(zhǎng)時(shí)間，它就給我們打開了一個(gè)實(shí)驗(yàn)和驗(yàn)證的世界。相應(yīng)的，這也允許我們確認(rèn)每次小的迭代的效果是否能達(dá)到用戶的需求和我們的業(yè)務(wù)底線。
業(yè)務(wù)流程被相互協(xié)調(diào)的團(tuán)隊(duì)所代替，這些團(tuán)隊(duì)必須交付業(yè)務(wù)所需的產(chǎn)品。該團(tuán)隊(duì)實(shí)驗(yàn)并迭代需要開發(fā)的產(chǎn)品理念，從而確?？梢赃_(dá)成既定的目標(biāo)。
該結(jié)構(gòu)確保持續(xù)的交付來驗(yàn)證我們的嘗試，但是仍存在一些效率低下的情況，因?yàn)樵诋a(chǎn)品/用戶體驗(yàn)/設(shè)計(jì)和實(shí)現(xiàn)團(tuán)隊(duì)之間，可能缺乏一致性。這種隔離通常被歸類為“業(yè)務(wù)”（定義需開發(fā)產(chǎn)品的范圍）和“IT”（做實(shí)際的交付工作）。這意味著只有一半的團(tuán)隊(duì)真正負(fù)責(zé)完成目標(biāo)，另一半則作為交付的工具。我們?nèi)孕柽M(jìn)行從交付物到交付業(yè)務(wù)成果的思想轉(zhuǎn)變。

假設(shè)
軟件發(fā)布可以很快很頻繁
前期不可能知道確切知道要構(gòu)建成什么樣的產(chǎn)品，因此把大型開發(fā)分解為小部分，并在項(xiàng)目進(jìn)行中不斷學(xué)習(xí)，持續(xù)交付中，跨團(tuán)隊(duì)的T型人才是最有效的，實(shí)現(xiàn)團(tuán)隊(duì)為交付的產(chǎn)品成果負(fù)責(zé)，我們將有一個(gè)真正的跨職能產(chǎn)品團(tuán)隊(duì)，挖掘需求，交付產(chǎn)品，為客戶和業(yè)務(wù)創(chuàng)造成果。讓開發(fā)工程師在概念階段就介入進(jìn)來，可以集思廣益，還能對(duì)交付它們的復(fù)雜度提供輸入信息。設(shè)計(jì)人員自始至終參與到開發(fā)團(tuán)隊(duì)中，可以更好地了解設(shè)計(jì)對(duì)于客戶的影響。為了全面從瀑布項(xiàng)目已經(jīng)定義好的階段遷移到產(chǎn)品團(tuán)隊(duì)的持續(xù)流中，需要不斷的嘗試和創(chuàng)新，從而消除可能遇到的阻礙。但是萬事都在變化中。團(tuán)隊(duì)隨著產(chǎn)品需求不斷成長(zhǎng)，包括市場(chǎng)、客服和運(yùn)維。流程的演進(jìn)從不停止。我會(huì)增加最后一個(gè)假設(shè)：最好的流程來源于持續(xù)的反饋和嘗試。

軟件交付實(shí)施流程
流程是很神奇的。當(dāng)做一些重復(fù)性工作時(shí)，清晰的流程可以幫助我們明確需要做什么，需要避免那些已知的錯(cuò)誤。在大型公司里，流程制度化是更有效的做事方式。但有時(shí)候這也會(huì)有問題?！昂玫牧鞒虨槲覀兎?wù)，進(jìn)而為客戶服務(wù)。但是，如果我們不保持警惕，流程就會(huì)成為問題。流程成了你希望獲得的結(jié)果的替代品。”所有流程的通病是它們包含了流程建立之初的假設(shè)和限制。隨著時(shí)間遷移，那些已經(jīng)嵌入流程之中的最初假設(shè)被遺忘了。問題在于，假設(shè)和限制不再有意義時(shí)，流程會(huì)阻礙我們的工作。做這種轉(zhuǎn)變并不容易，我在接下來的文章中會(huì)深入探討，為了支持產(chǎn)品團(tuán)隊(duì)的轉(zhuǎn)變，整個(gè)組織需要做那些相應(yīng)改變，包括：
管理層/組織架構(gòu)變化
監(jiān)管層變化
財(cái)務(wù)制度變化
用戶體驗(yàn)和設(shè)計(jì)變化
開發(fā)變化
測(cè)試變化