畢業(yè)設(shè)計(jì)（論文）外文資料翻譯：新的方法

畢業(yè)設(shè)計(jì)(論文)外文資料翻譯學(xué)院：計(jì)算機(jī)工程學(xué)院專業(yè)：通信工程姓名：學(xué)號：外文出處：MartinFowler.NewMethodogy.Microsoft(用外文寫)World.Vo1.36No.13~6附件：1.外文資料翻譯譯文；2.外文原文。指導(dǎo)教師評語：該生的英文翻譯原文是一篇關(guān)于軟件開發(fā)的科研論文，具有一定的科技含量和專業(yè)深度，符合畢業(yè)設(shè)計(jì)的要求，這篇文章的翻譯有助于做好該生的畢業(yè)設(shè)計(jì)，且可以檢驗(yàn)該生的專業(yè)英語水平。該生的翻譯文章語句通順，譯文與原文意思一致，達(dá)到了畢業(yè)設(shè)計(jì)英文翻譯的要求年月日簽名：（手寫簽名）注：請將該封面與附件裝訂成冊。附件1：外文資料翻譯譯文新的方法MartinFowler在過去的幾年里，對“輕量”原則的興趣快速增長。其獨(dú)有的特征是有對官僚主義作風(fēng)的消除的作用，軟件業(yè)已經(jīng)廣泛激起了這種興趣，這篇文章中我要對他的原因進(jìn)行求證，不是在“輕量”上，不管怎么樣，只要有意義。很多軟件的開發(fā)是一種無規(guī)則的活動，可用“編碼和安裝”來概括其性能，很多軟件代碼的書寫是事先不知道的，而且在系統(tǒng)的設(shè)計(jì)中可能是臨時想的，如果系統(tǒng)不大這種工作方式是可行的，但是隨著系統(tǒng)的增大就不能加入新的特征。另外缺陷也會隨著系統(tǒng)增大變得普及以至難以安裝。這種系統(tǒng)的典型標(biāo)志是在系統(tǒng)功能完成之后需要長期的測試階段，長時間測試階段是浪費(fèi)時間，會導(dǎo)致測試和調(diào)試不能按時完成。我們用這種開發(fā)方式已經(jīng)很久了，但我們還有另一種方式供選擇，即在軟件開發(fā)時在每一個步驟中強(qiáng)加一系列方法和原則，為了增強(qiáng)軟件的有效性。通過一個詳細(xì)的過程來說明這種方法正被其他的工程原則計(jì)劃吸收。這個方法被提出來已經(jīng)有很長時間了，它們不僅沒有被注意到，而且很少被提及，針對這些方法和原則最多的評論是過于死板。為了對它進(jìn)行改進(jìn)，新的方法和原則在過去幾年里產(chǎn)生了，“輕量”原則正在被接受。很多人認(rèn)為“輕量”原則是對現(xiàn)有原則中死板的改進(jìn)。這些方法和原則試圖嘗試在無過程和太多過程間進(jìn)行有效的協(xié)調(diào)，只提供必不可少的過程。這樣做的原因是工程方法在側(cè)重點(diǎn)上有改變。最明顯的差別是它對文檔的使用少了，通常只在給定的任務(wù)里面使用少量的文檔，而更多的使用代碼，總之，最關(guān)鍵的文檔是源代碼。但是我認(rèn)為這不是“輕量”原則的特點(diǎn)，文檔的丟失只是這他們更深層區(qū)別的表現(xiàn)。工程方法在軟件設(shè)計(jì)中喜歡花很長時間在計(jì)劃與說明。這種方式只要無突發(fā)事件都是很有用的，但是靈敏性原則接受改變，他們努力讓過程在變化中適應(yīng)和健壯，甚至可以改變他們自身來適應(yīng)變化。“輕量”原則是面向用戶的，而不是面向過程的。工程方法的目標(biāo)是找到一個過程無論誰使用它都能正常工作。靈敏性原則認(rèn)為沒有一個過程能總是適應(yīng)開發(fā)團(tuán)隊(duì)的技術(shù)需要，所以過程的特征應(yīng)是在它們工作時支持開發(fā)團(tuán)隊(duì)的需求。預(yù)測于自適應(yīng)性設(shè)計(jì)與構(gòu)造的分離通常的方法是工程學(xué)科的靈感，如民事或機(jī)械學(xué)科規(guī)劃之前把你的工程師將圖紙上的一系列工作，正說明是否需要建立一個十分重視如何將這些東西需要要放在一起。許多設(shè)計(jì)決策，例如如何處理有關(guān)橋梁的負(fù)載，是因?yàn)閳D紙，然后移交給一個不同的群體，往往是不同的公司，將假設(shè)在施工過程將遵循實(shí)踐的構(gòu)造會遇到一些問題，但這些通常圖紙指定件和他們需要如何放在一起，他們充當(dāng)基礎(chǔ)計(jì)劃。這種計(jì)劃可以計(jì)算出需要做什么依賴這些存在的任務(wù)，允許合理的可預(yù)測的時間表和詳細(xì)預(yù)算來表示。這使得智力建造不太熟練，我們在這里看到的是兩個截然不同的設(shè)計(jì)，這是很難預(yù)測的。一旦我們的設(shè)計(jì)，我們可以規(guī)劃我們在一個更加可預(yù)測的土建工程施工的工程計(jì)劃，更大的成本和時間設(shè)計(jì)和軟件工程方法方法如下：我們希望有一個可預(yù)測的時間表，可以使用低技能的人。要做到這一點(diǎn)，我們需要弄清楚如何為軟件設(shè)計(jì)，一旦規(guī)劃以何種形式參加這一計(jì)劃的設(shè)計(jì)。這是設(shè)計(jì)符號的作用，如我們可以改變這一切使用的重大決策，我們可以建立一個建設(shè)規(guī)劃，然后是建筑活動的這些設(shè)計(jì)的編碼。但是，這里的關(guān)鍵在于你的設(shè)計(jì)，能夠轉(zhuǎn)化為可預(yù)見的編碼。如果是的話，這樣做的成本足夠小，使這種做法值得嗎？所有這一切都帶來了一些問題，它可以在紙上看起來非常好，但有嚴(yán)重缺陷時，使用民用工程師是根據(jù)多年來的實(shí)踐所體現(xiàn)在工程的關(guān)鍵問題，如在設(shè)計(jì)比賽，常常只有在編碼和熟練的設(shè)計(jì)師發(fā)現(xiàn)設(shè)計(jì)等錯誤，我認(rèn)為自己是，常常感到驚訝。另一個問題是比較您構(gòu)建一座橋梁，對設(shè)計(jì)工作的費(fèi)用約為10％，其余被軟件的編碼所花費(fèi)的時間很多，更麥康奈爾建議是一項(xiàng)龐大的工程，只有15％的工程是代碼和單元測試，一個橋梁建設(shè)近乎完美的逆轉(zhuǎn)，如果您在測試過的所有建筑的一部分，那么設(shè)計(jì)還有50％的工作。這就提出了一個關(guān)于設(shè)計(jì)軟件相比，其性質(zhì)在工程其他部門作用的重要問題。這些類型的問題導(dǎo)致杰克里夫斯建議，事實(shí)上，源代碼是一個設(shè)計(jì)文件和施工階段，實(shí)際上是編譯器和任何可以視為建設(shè)可以而且應(yīng)該自動使用。這種想法得出了一個重要結(jié)論：在軟件業(yè)，構(gòu)造是很便宜的幾乎免費(fèi)。在軟件業(yè)，所有的努力是設(shè)計(jì)，需要有創(chuàng)造力和有才能的人來做。創(chuàng)造的過程不是簡單的計(jì)劃，所以可預(yù)測性不可能是個目標(biāo)。我們在開發(fā)軟件時要十分警惕傳統(tǒng)的工程思想，在不同的過程中有不同的活動和要求。不可預(yù)見性的要求我碰到的項(xiàng)目有個問題，聽到他說，我覺得對這種情況令人驚訝的是任何人都感到驚訝。在建設(shè)商業(yè)軟件需求的變化是正常的，問題是我們?nèi)绾伟巡粩嘧兓囊?，落后，貧窮的要求結(jié)果的想法，然后再開始建設(shè)的軟件，讓客戶簽署過這些要求，并設(shè)立程序，限制需求的變化后，簽收。首先，這個問題只是想了解需求的選擇是否更嚴(yán)厲的，因?yàn)殚_發(fā)組織通常不提供有關(guān)最終的成本信息的局面下，您可能有一定的愿望天窗的汽車，但推銷員不能告訴你是否增加了10美元的汽車，你怎么能弄清楚要支付費(fèi)用的天窗。很難估計(jì)軟件開發(fā)是一個設(shè)計(jì)的活動，因此難以計(jì)劃它是不斷變化的基本材料，這么多依賴于個別人，個人很難預(yù)測和量化。軟件的性質(zhì)，也無形如果它是很難看到什么價值的軟件功能削減至今為止。只有當(dāng)您使用的是早期版本的一些軟件，你真正開始了解什么功能是寶貴的，哪些部分不是。這導(dǎo)致了具有諷刺意味的一點(diǎn)，大家都期望要求所有軟件應(yīng)該不僅是需求變化，他們應(yīng)該十分關(guān)注客戶的軟件很多精力來解決需求。這更差，他們曾經(jīng)在自己涉足軟件開發(fā)，因?yàn)檫@樣他們“知道”軟件很容易改變。但即使你能解決所有的，真正能夠了解你的要求，仍然可能當(dāng)前經(jīng)濟(jì)的基本經(jīng)營力量，改變了軟件的價值準(zhǔn)確和穩(wěn)定的特性集，也許是一個好的要求，如果客戶可以修正的要求是不會停止在商業(yè)世界許多變化是完全不可預(yù)測的6個月的良好設(shè)定：任何人說，否則是誰要么說謊，或已就市場成交量1億美元。在軟件開發(fā)中的一切其他取決于不能得到穩(wěn)定的要求，您就無法獲得可預(yù)測的計(jì)劃。預(yù)測性是不可能的嗎?不是，有些軟件開發(fā)的可預(yù)測性是可能的。像NASA航天飛機(jī)軟件組就是一個軟件可被預(yù)測的例子。這套軟件的設(shè)計(jì)有大量的規(guī)則，花了很長的時間，有一個很大的開發(fā)團(tuán)隊(duì)和明確的需求。一個大的危險是當(dāng)你沒有能力遵從需求的時候假裝能遵從需求，人們在使用某些方法時并不太明確其使用的界限情況。很多原則都想讓其對任何人都有用，所以不去了解其使用的界限，這導(dǎo)致人們在有些情況下錯誤的使用某種原則，即在不可預(yù)測的情況下使用預(yù)測性方法。因此，在你不能預(yù)測的情況下不能使用預(yù)測性方法，這意味著很多軟件的模型，很多整個客戶關(guān)系模型不再有用。預(yù)測的用處如此之大以至不能失去它。困難的部分最容易被意識到這種情況在這個問題中也是這樣的，但是失去預(yù)測性并不意味著你不能控制混亂。控制不可預(yù)知的過程迭代那么，我們?nèi)绾慰刂谱约翰豢深A(yù)知的世界呢？最重要的最困難的是要準(zhǔn)確知道，我們需要一個誠實(shí)的反饋機(jī)制，可以準(zhǔn)確地告訴我們什么情況重播的。對這個反饋的關(guān)鍵是迭代開發(fā)，這不是一個新的發(fā)展，漸進(jìn)，進(jìn)化，分階段，螺旋...迭代開發(fā)的關(guān)鍵是要經(jīng)常大量生產(chǎn)工作最終系統(tǒng)的版本有一個必要的工作制度功能的子集，否則，我們應(yīng)忠實(shí)于最后的要求，應(yīng)充分整合和仔細(xì)測試，這樣一個經(jīng)過測試，對任何帶入一個現(xiàn)實(shí)的有力的劑量可以隱藏各種代碼。其實(shí)很多時候人們在前面坐一個綜合系統(tǒng)，然后有一個明顯缺陷：無論是在錯誤的條件和要求方面的誤解。迭代的發(fā)展使得作為它在適應(yīng)過程中必不可少的，因?yàn)橐粋€適應(yīng)的過程需要能夠處理所需變化可預(yù)見的流程意識導(dǎo)致規(guī)劃在長期計(jì)劃是非常流體風(fēng)格，只有穩(wěn)定的短期計(jì)劃是單一的發(fā)展作出規(guī)劃都能讓您在每次迭代堅(jiān)實(shí)的基礎(chǔ)，您可以基于您的這一關(guān)鍵問題后長期的計(jì)劃是如何應(yīng)一次迭代賦予不同建議的，反復(fù)表明了一個長度將延伸短你可以離開提供更頻繁，所以你知道你在哪里更頻繁。自適應(yīng)客戶這種適應(yīng)的過程，需要有一種比通常被視為是藝術(shù)的發(fā)展，尤其是在一個單獨(dú)的獨(dú)立的公司做軟件開發(fā)完成的，客戶的關(guān)系，不同類型，大多數(shù)客戶寧愿固定價格開發(fā)他們想要的東西，招標(biāo)要求，接受競標(biāo)，然后責(zé)任在于開發(fā)組織建立軟件。固定造價合同，必須有穩(wěn)定的要求，并因此而預(yù)測過程和不穩(wěn)定的需要，這意味著你不能與固定價格模式適應(yīng)，一種適應(yīng)過程通常的概念最終在一個非常痛苦的爆炸，這一爆炸最討厭的是，客戶的每一個受到傷害的軟件開發(fā)所有客戶在很大程度上將不會缺少一些軟件，除非他們的業(yè)務(wù)需要，他們沒有得到它的業(yè)務(wù)遭受位。因此，即使他們付錢給開發(fā)公司一無所知，他們?nèi)匀皇コ^他們支付軟件（為什么他們會支付軟件，如果該軟件的商業(yè)價值較少？）因此，這對雙方都危險在簽署的在固定價格合同的條件下一個預(yù)測的過程是不能并不意味著你不能確定一個軟體預(yù)算，它的意思是，你不能修復(fù)的時間，價格和敏捷方法通常是修復(fù)時間，并允許變化的范圍在受控是一種適應(yīng)過程，客戶有更精細(xì)，在軟件開發(fā)中他們得到每個迭代都檢查進(jìn)展和細(xì)粒度控制改變方向的軟件，導(dǎo)致更為密切的參與程度，是不是每一位客戶的組織，也不是每個軟件開發(fā)人員，但它必須作出適應(yīng)的過程正常工作。

所有這一切產(chǎn)生了一系列的優(yōu)勢為數(shù)目開始，他們得到更多的響應(yīng)軟件開發(fā)。奧塞布爾，雖然很小，系統(tǒng)能盡早投入生產(chǎn)上，客戶可以改變的能力，依照業(yè)務(wù)變化，并從該系統(tǒng)如何在位作為重要的學(xué)習(xí)，因?yàn)檫@也將是更大的可視性在預(yù)測過程與問題的真實(shí)情況卻是，工程質(zhì)量是衡量是否符合人們信號時，現(xiàn)實(shí)和計(jì)劃共同的結(jié)果是在附表中晚期大滑在一個敏捷項(xiàng)目是有計(jì)劃的壞消息不斷改造是它往往潛伏著來前，當(dāng)仍然有時間來做些事情，這種風(fēng)險控制是一個關(guān)鍵優(yōu)勢迭代方法采取保持迭，此事作進(jìn)一步的小，而且也看到這些變化的機(jī)會。重要的問題是成功的預(yù)測項(xiàng)目往往是衡量以及它如何滿足其項(xiàng)目，對時間和成本被認(rèn)為是測量，是一派胡言。對于敏捷的問題是商業(yè)價值，并得到客戶的軟件，更為可貴的比良好的預(yù)測到項(xiàng)目投入將按照計(jì)劃對他們的成本，良好的敏捷項(xiàng)目將建立不同的東西，比原來的計(jì)劃，更好地預(yù)見。附件2：外文原文（復(fù)印件） TheNewMethodologyMartinFowlerInthepastfewyearsthere’sbeenarapidlygrowinginterestinagile(aka“l(fā)ightweight’s’methodologies).Alternativelycharacterizedasanantidotetobureaucracyoralicensetohackthey’vestirredupinterestalloverthesoftwarelandscape.IntheseessayIexplorethereasonsforagilemethods,focusingnotsomuchontheirweightbutontheiradaptivenatureandtheirpeople-firstorientation.FromNothing,toMonumental,toAgileMostsoftwaredevelopmentisachaoticactivity,oftencharacterizedbythephrase‘codeandfix’.Thesoftwareiswrittenwithoutmuchofanunderlyingplan,andthedesignofthesystemiscobbledtogetherfrommanyshorttermdecisions.Thisactuallyworksprettywellasthesystemissmall,butasthesystemgrowsitbecomesincreasinglydifficulttoaddnewfeaturestothesystem.Furthermorebugsbecomeincreasinglyprevalentandincreasinglydifficulttofix.Atypicalsignofsuchasystemisalongtestphraseafterthesystemis‘featurecomplete’.Suchalongtestphraseplayshavocwithschedulesastestinganddebuggingisimpossibletoschedule.We’velivedwiththisstyleanddevelopmentforalongtime,butwe’vealsohadanalternativeforalongtime:Methodology.Methodologysimposeadisciplinedprocessuponsoftwaredevelopmentwiththeaimofmakingsoftwaredevelopmentmorepredictableandmoreefficient.Theydothisbydevelopingadetailedprocesswithastrongemphasisonplanninginspiredbyotherengineeringdisciplines-whichiswhyirefertothemasengineeringmethodologies.Engineeringmethodologieshavebeenaroundforalongtime.They’venotbeennoticeableforbeingterriblysuccessful.Theyareevenlessnotedforbeingpopular.Themostfrequentcriticismofthesemethodologiesisthattheyarebureaucratic.There’ssomuchtodotofollowthemethodologythatthewholepaceofdevelopmentslowsdown.Asareactiontothesemethodologies,anewgroupofmethodologieshaveappearedinthelastfewyears.Forawhilethesewereknownalightweightmethodologies,butnowtheacceptedtermisagilemethodologies.Formanypeopletheappealoftheseagilemethodologiesistheirreactiontothebureaucracyofthemonumentalmethodologies.Thesenewmethodsattemptausefulcompromisebetweennoprocessandtoomuchprocess,providingjustenoughprocesstogainareasonablepayoff.Theresultofallofthisisthatagilemethodshavesomesignificantchangesinemphasisfromengineeringmethods.Themostimmediatedifferenceisthattheyarelessdocument-oriented,usuallyemphasizingasmalleramountofdocumentationforagiventask.Inmanywaystheynarerathercode-oriented:followingaroutethatsaysthatthekeypartofdocumentationissourcecode.HoweverIdon’tthinkthisisthekeypointaboutagilemethods.Lackofdocumentationisasymptomoftwomuchdeeperdifferences:Agilemethodsareadaptiveratherthanpredictive.Engineeringmethodstendtotrytoplanoutalargepartofthesoftwareprocessingreatdetailforalongspanoftime,thisworkswelluntilthingschange.Sotheirnatureistoresistchange.Theagilemethods,however,welcomechange.theytrytobeprocessesthatadaptandthriveonchange,eventothepointofchangingthemselves.Agilemethodsarepeople-orientedratherthanprocess-orientedThegoalofengineeringmethodsistodefineaprocessthatwillworkwellwhoeverhappenstobeusingit.Agilemethodsassertthatnoprocesswillevermakeuptheskillofthedevelopmentteam,sotheroleofaprocessistosupportthedevelopmentteamintheirwork.PredictiveversusAdaptiveSeparationofDesignandConstructionTheusualinspirationformethodologiesisengineeringdisciplinessuchascivilormechanicalengineering.Suchdisciplinesputalotofemphasisonplanningbeforeyoubuild.Suchengineerswillworkonaseriesofdrawingsthatpreciselyindicatewhatneedstobebuiltandhowthesethingneedtobeputtogether.Manydesigndecisions,suahashowtodealwiththeloadonabridge,aremadeasthedrawingsareproduced.Thedrawingsarethenhandedovertoadifferentgroup,oftenadifferentcompany,tobebuilt.Itsassumedthattheconstructionprocesswillfollowthedrawings.Inpracticetheconstructorswillrunintosomeproblems,buttheseareusuallysmall.Sincethedrawingsspecifythepiecesandhowtheyneedtobeputtogether,theyactasthefoundationforadetaiedcostructionplan.Suchaplancanfigureoutthetasksthatneedtobedoneandwhatdependenciesexistbetweenthesetasks.Thisallowsforareasonablypredictablescheduleandbudgetforconstruction.Italsosaysindetailhowthepeopledoingtheconstructionworkshoulddotheirwork.Thisallowstheconstructiontobelessskilledintellectually,althoughtheyareoftenveryskilledmanually.Sowhatweseeherearetwofundamentallydifferentactivites.Designwhichisdifficulttopredictandrequiresexpensiveandcreativepeople,andconstructionwhichiseasiertopredict.Oncewehavethedesign,wecanplantheconstruction.Oncewehavetheplanfortheconstructioninamuchmorepredictableway.Incivilengineeringconstructionismuchbiggerinbothcostandtimethandesignandplanning.Sotheapproachforsoftwareengineeringmethodologieslookslikethis:wewantapredictableschedulethatcanusepeoplewithlowerskills.Todothiswemustseparatedesignfromconstruction.Thereforeweneedtofigureouthowtodothedesignforsoftwaresothattheconstructioncanbestraightforwardoncetheplanningisdone.Sowhatformfoesthisplantake?Formany,thisistheroleofdesignnotationssuchastheUML.IfwecanmakeallthesignificantdecisionsusingtheUML,wecanbuildaconstructionplanandthenhandthesedesignstocodersasaconstructionactivity.Here,however,liesthecrucialquestion.Canyougetadesignthatiscapableofturningthecodingintoapredictableconstructionactivity?Ifso,iscostofdoingthissufficientlysmalltomakethisapproachworthwhile?Allofthisbringsafewquestiontomind.ThefirstidthematterofhowdifficultitistogetaUML-likedesignintoastatethatitcanbehandedovertoprogrammers.TheproblemwithaUML-likedesignisthatitcanlookverygoodonpaper,yetbeseriouslyflawedwhenyouactuallyhavetoprogramthething.themodelsthatcivilengineersusearebasedonmanyyearsofpracticethatareenshrinedinengineeringcodes.Furthermorethekeyissues,suchasthewayforcesplayinthedesign,areamenabletomathematicalanalysis.TheonlycheckingwecandoofUML-likediagramsispeerreview.Whilethisishelpfulitleadstoerrorsinthedesignthatareoftenonlyuncoveredduringcodingandtesting.Evenskilleddesigners,suchasIconsidermyselftobe,areoftensurprisedwhenweturnsuchadesignintosoftware.Anotherissueisthatofcomparativecost.Whenyoubuildabridge,thecostofthedesigneffortisabout10%ofthejob,withtherestbeingconstruction.Insoftwaretheamountoftimespentincodingismuch,muchlessMcConnellsuggeststhatforalargeproject,only15%oftheprojectiscodeandunittest,analmostperfectreversalofthebridgebuildingratios.Evenifyoulumpinalltestingaspartofconstruction,thendesignisstill50%ofthework.Thisraisesanimportantquestionaboutthenatureofdesigninsoftwarecomparedtoitsroleinotherbranchesofengineering.ThesekindsofquestionledJackReevestosuggestthatinfactthesourcecodeisadesigndocumentandthattheconstructionphaseisactuallytheuseofthecompilerandlinker.Indeedanythingthatyoucantreatasconstructioncanandshouldbeautomated.Thisthinkingleadstosomeimportantconclusions:Insoftware:constructionissocheapastobefreeInsoftware:alltheeffortisdesign,andthusrequirescreativeandtalentedpeopleCreativeprocessesarenoteasilyplanned,andsopredictabilitymaywellbeanimpossibletarget.Weshouldbeverywaryofthetrationalengineeringmetaphorforbuildingsoftware.It’sadifferentkindofactivityandrequiresadifferentprocess.TheUnpredictabilityofRequirementsThere’sarefrainI’veheardoneveryproblemprojectI’veruninto.Thedeveloperscometomeandsaytheproblemwiththisprojectisthattherequirementsarealwayschanging.ThethingIfindsurprisingaboutthissituationisthatanyoneissurprised.Inbuildingbusinesssoftwarerequirementschangesarethenorm,thequestioniswhatwedoaboutit.Onetouteistotreatchangingrequirementsastheresultofpoorrequirementsengineering.Theideabehindrequirementsbeforeyoubeginbuildingthesoftware,getacustomersign-offtotheserequirements,andthensetupproceduresthatlimitrequirementschangesafterthesign-off.Oneproblemwiththisisthatjusttryingtounderstandtheoptionsforrequirementsistouch.It’seventougherbecausethedevelopmentorganizationusuallydoesn’tprovidecostinformationontherequirements.Youendupbeinginthesituationwhereyoumayhavesomedesireforasunroofonyourcar,butthesalesmancan’ttellyouifitadds$10tothecostofthecar,or$10000.Withoutmuchideaofthecost,howcanyoufigureoutwheatheryouwanttopayforthatsunroof.Estimationishardformanyreasons.Partofitisthatsoftwaredevelopmentisadesignactivity,andthushardtoplanandcost.Partofitisthatthebasicmaterialskeepchangingrapidly.Partofitisthatsomuchdependsonwhichindividualpeopleareinvolved,andindividualsarehardtopredictandquantify.Software’sintangiblenaturealsocutsinIfit’sverydifficulttoseewhatvalueasoftwarefeaturehasuntilyouuseitforreal.Onlywhenyouuseanearlyversionofsomesoftwaredoyoureallybegintounderstandwhatfeaturesarevaluableandwhatpartsarenot.Thisleadstotheironicpointthatpeopleexpectthatrequirementsshouldbechangeable.Afterallsoftwareissupposedtobesoft.Sonotjustarerequirementschangeable,theyoughttobechangeable.Ittakesalotofenergyofcustomersofsoftwaretofixrequirements.It’sevenworseifthey’veeverdabbledinsoftwaredevelopmentthemselves,becausethenthey“know”thatsoftwareiseasytochange.Butevenifyoucouldsettleallthatandreallycouldgetanaccurateandstablesetofrequirementsyou’reprobablystilldoomed.Intoday’seconomythefundamentalbusinessforcesarechangingthevalueofsoftwarefeaturestoorapidly.Whatmightbeagoodsetofrequirementsnow,isnotagoodsetinsixmonthstime.Evenifthecustomerscanfixtheirrequirements,thebusinessworldisn’tgoingtostopforthem.Andmanychangesinthebusinessworldarecompletelyunpredictable:anyonewhosaysotherwiseiseitherlying,orhasalreadymadeabilliononstockmarkettrading.Everythingelseinsoftwaredevelopmentdependsontherequirements.Ifyoucannotgetstablerequirementsyoucannotgetapredictableplan.IsPredictabilityImpossible?Ingeneralno.Therearesomesoftwaredevelopmentswharepredictabilityispossible.OrganizationssuchasNASA’sspaceshuttlesoftwaregroupareaprimeexampleofwheresoftwaredevelopmentcanbepredictable.Itrequiresalotofceremony,plentyoftime,alargeteam,andstablerequirements.Thereareprojectsouttherethatarespaceshuttles.HoweverIdon’tthinkmuchbusinesssoftwarefitsintothatcategory.Forthisyouneedadifferentkindofprocess.Oneofthebigdangersistopretendthatyoucanfollowapredictableprocesswhenyoucan’t.Peoplewhoworkonmethodologyarenotverygoodatidentifyingboundaryconditions:theplaceswherethemethodologypassesfromappropriateininappropriate.Mostmethodologistswanttheirmethodologies,suchasusingapredictablemethodologyinaunpredictablesituation.There’sastrongtemptationtodothat.Predictabilityisaverydesirableproperty.Howeverifyoubeliveyoucanbepredictablewhenyoucan’t,itleadstosituationswherepeoplebuildaplanfallsapart.Youseetheplanandrealityslowlydriftingapart.Foralongtimeyoucanpretendthattheplanisstillvalid.Butatsomepointthedriftbecomestoomuchandtheplanfallsapart.Usuallythefallispainful.Thereforeifyouareinasituationthatisn’tpredictableyoucan’tuseapredictivemethodology.That’sahardblow.Itmeansthatmanyofthemodelsforcontrollingprojects,manyofthemodelsforthewholecustomerrelationship,justare’ttrueanymore.Thebenefitsofpredictabilityaresogreat.itsdifficulttoletthemgo.Likesomanyproblemsthehardestpartissimplyrealizingthattheproblemexists.Howeverlettinggoofpredictabilitydoesn’tmeanyouhavetoreverttouncontrollableahaos.Insteadyouneedaprocessthatcangiveyoucontroloveranunpredictability.That’swhatadaptivityisallabout.ControllinganUnpredictableProcess-IterationsSohowdowecontrolourselvesinanunpredictableworld?Themostimportant,andstilldifficultpartistoknowaccuratelywhereweare.Weneedanhonestfeedbackmechanismwhichcanaccuratelytelluswhatthesituationisatfrequentintervals.Thekeytothisfeedbackisiterativedevelopment,Thisisnotanewidea.Iterativedevelopmenthasbeenaroundforawhileundermanynames:incremental,evolutionary,staged,spiral…lotsofnames.Thekeytoiterativedevelopmentistofrequentlyproduceworkingversionsofthefinalsystemthathaveasubsetoftherequiredfeatures.Theseworkingsystemsareshortonfunctionality,butshouldotherwisebefaithfultothedemandsofthefinalsystem.Theyshouldbefullyintegratedandascarefullytestedasafinaldelivery.Thepointofthisisthatthereisnothinglikeatested,integratedsystemforbringingaforcefuldoseofrealityintoanyproject.Documentscanhideallsortsofflaws.Untestedcodecanhideplentyofflaws.Butwhenpeopleactuallysitinfrontofasystemandworkwithit,thenflawsbecometrulyapparent:bothintermsofbugsandintermsofmisunderstoodrequirements.Iterativedevelopmentmakessenseinpredictableprocessesaswell.Butitisessentialinadaptiveprocessesbecauseanadaptiveprocessneedstobeabletodealwithchangesinrequiredfeatures.Thisleadstoastyleofplanningwherelongtermplansareveryfluid,andtheonlystableplansareshorttermplansthataremadeforasingleiteration.Iterativedevelopmentgivesyouafirmfoundationineachiterationthatyoucanbaseyourlaterplansaround.Akeyquestionforthisishowlonganiterationshouldbe.Differentpeoplegivedifferentanswers.XPsuggestsiterationsofbetweenoneandthreeweeks.SCRUMsuggestsalengthofamonth.Crystalwillstretchasshortasyoucangetawaywith.Thisprovidesmorefrequentfeedbake,soyouknowwhereyouaremoreoften.TheAdaptiveCustomerThiskindofadaptiveprocessrequiresadifferentkindofrelationshipwithacustomerthantheonesthatarteoftenconsidered,particularlywhendevelopmentisdonebyaseparatefirm.Whenyouhireaseparatefirmtodosoftwaredevelopment,mostcustomerswouldpreferafixed-pricecontract.Tellthedeveloperswhattheywant,askforbids,acceptabid,andthentheonusisonthedevelopmentorganizationtobuildthesoftware.Afixedpricecontractrequiresstablerequirementsandhenceapredictiveprocess.Adaptiveprocessesandunstablerequirementsimplyyoucannotworkwiththeusualnotionoffixed-price.Tryingtofitafixedpricemodeltoanadaptiveprocessendsupinaverypainfulexplosion,Thenastypartofthisexplosionisthatthecustomergetshurteverybitasmuchasthesoftwaredevelopmentcompany.Afterallthecustomerwouldn’tbewantingsomesoftwareunlesstheirbusinessneededit.Iftheydon’tgetittheirbusinesssuffers.Soeveniftheypaythedevelopmentcompanynothing,theystilllose.Indeedtheylosemorethantheywouldpayforthesoftware(whywouldtheypayforthesoftwareifthebusinessvalueofthatsoftwarewereless?)Sothere’sdangersforbothsidesinsign