中英文文献翻译-新的方法

附件1：外文资料翻译译文新的方法MartinFowler在过去的几年里，对“轻量”原则的兴趣快速增长。其独有的特征是有对官僚主义作风的消除的作用，软件业已经广泛激起了这种兴趣，这篇文章中我要对他的原因进行求证，不是在“轻量”上，不管怎么样，只要有意义。很多软件的开发是一种无规则的活动，可用“编码和安装”来概括其性能，很多软件代码的书写是事先不知道的，而且在系统的设计中可能是临时想的，如果系统不大这种工作方式是可行的，但是随着系统的增大就不能加入新的特征。另外缺陷也会随着系统增大变得普及以至难以安装。这种系统的典型标志是在系统功能完成之后需要长期的测试阶段，长时间测试阶段是浪费时间，会导致测试和调试不能按时完成。我们用这种开发方式已经很久了，但我们还有另一种方式供选择，即在软件开发时在每一个步骤中强加一系列方法和原则，为了增强软件的有效性。通过一个详细的过程来说明这种方法正被其他的工程原则计划吸收。这个方法被提出来已经有很长时间了，它们不仅没有被注意到，而且很少被提及，针对这些方法和原则最多的评论是过于死板。为了对它进行改进，新的方法和原则在过去几年里产生了，“轻量”原则正在被接受。很多人认为“轻量”原则是对现有原则中死板的改进。这些方法和原则试图尝试在无过程和太多过程间进行有效的协调，只提供必不可少的过程。这样做的原因是工程方法在侧重点上有改变。最明显的差别是它对文档的使用少了，通常只在给定的任务里面使用少量的文档，而更多的使用代码，总之，最关键的文档是源代码。但是我认为这不是“轻量”原则的特点，文档的丢失只是这他们更深层区别的表现。工程方法在软件设计中喜欢花很长时间在计划与说明。这种方式只要无突发事件都是很有用的，但是灵敏性原则接受改变，他们努力让过程在变化中适应和健壮，甚至可以改变他们自身来适应变化。“轻量”原则是面向用户的，而不是面向过程的。工程方法的目标是找到一个过程无论谁使用它都能正常工作。灵敏性原则认为没有一个过程能总是适应开发团队的技术需要，所以过程的特征应是在它们工作时支持开发团队的需求。预测于自适应性设计与构造的分离通常的方法是工程学科的灵感，如民事或机械学科规划之前把你的工程师将图纸上的一系列工作，正说明是否需要建立一个十分重视如何将这些东西需要要放在一起。许多设计决策，例如如何处理有关桥梁的负载，是因为图纸，然后移交给一个不同的群体，往往是不同的公司，将假设在施工过程将遵循实践的构造会遇到一些问题，但这些通常图纸指定件和他们需要如何放在一起，他们充当基础计划。这种计划可以计算出需要做什么依赖这些存在的任务，允许合理的可预测的时间表和详细预算来表示。这使得智力建造不太熟练，我们在这里看到的是两个截然不同的设计，这是很难预测的。一旦我们的设计，我们可以规划我们在一个更加可预测的土建工程施工的工程计划，更大的成本和时间设计和软件工程方法方法如下：我们希望有一个可预测的时间表，可以使用低技能的人。要做到这一点，我们需要弄清楚如何为软件设计，一旦规划以何种形式参加这一计划的设计。这是设计符号的作用，如我们可以改变这一切使用的重大决策，我们可以建立一个建设规划，然后是建筑活动的这些设计的编码。但是，这里的关键在于你的设计，能够转化为可预见的编码。如果是的话，这样做的成本足够小，使这种做法值得吗？所有这一切都带来了一些问题，它可以在纸上看起来非常好，但有严重缺陷时，使用民用工程师是根据多年来的实践所体现在工程的关键问题，如在设计比赛，常常只有在编码和熟练的设计师发现设计等错误，我认为自己是，常常感到惊讶。另一个问题是比较您构建一座桥梁，对设计工作的费用约为10，其余被软件的编码所花费的时间很多，更麦康奈尔建议是一项庞大的工程，只有15的工程是代码和单元测试，一个桥梁建设近乎完美的逆转，如果您在测试过的所有建筑的一部分，那么设计还有50的工作。这就提出了一个关于设计软件相比，其性质在工程其他部门作用的重要问题。这些类型的问题导致杰克里夫斯建议，事实上，源代码是一个设计文件和施工阶段，实际上是编译器和任何可以视为建设可以而且应该自动使用。这种想法得出了一个重要结论：在软件业，构造是很便宜的几乎免费。在软件业，所有的努力是设计，需要有创造力和有才能的人来做。创造的过程不是简单的计划，所以可预测性不可能是个目标。我们在开发软件时要十分警惕传统的工程思想，在不同的过程中有不同的活动和要求。不可预见性的要求我碰到的项目有个问题，听到他说，我觉得对这种情况令人惊讶的是任何人都感到惊讶。在建设商业软件需求的变化是正常的，问题是我们如何把不断变化的要求，落后，贫穷的要求结果的想法，然后再开始建设的软件，让客户签署过这些要求，并设立程序，限制需求的变化后，签收。首先，这个问题只是想了解需求的选择是否更严厉的，因为开发组织通常不提供有关最终的成本信息的局面下，您可能有一定的愿望天窗的汽车，但推销员不能告诉你是否增加了10美元的汽车，你怎么能弄清楚要支付费用的天窗。很难估计软件开发是一个设计的活动，因此难以计划它是不断变化的基本材料，这么多依赖于个别人，个人很难预测和量化。软件的性质，也无形如果它是很难看到什么价值的软件功能削减至今为止。只有当您使用的是早期版本的一些软件，你真正开始了解什么功能是宝贵的，哪些部分不是。这导致了具有讽刺意味的一点，大家都期望要求所有软件应该不仅是需求变化，他们应该十分关注客户的软件很多精力来解决需求。这更差，他们曾经在自己涉足软件开发，因为这样他们“知道”软件很容易改变。但即使你能解决所有的，真正能够了解你的要求，仍然可能当前经济的基本经营力量，改变了软件的价值准确和稳定的特性集，也许是一个好的要求，如果客户可以修正的要求是不会停止在商业世界许多变化是完全不可预测的6个月的良好设定：任何人说，否则是谁要么说谎，或已就市场成交量1亿美元。在软件开发中的一切其他取决于不能得到稳定的要求，您就无法获得可预测的计划。预测性是不可能的吗?不是，有些软件开发的可预测性是可能的。像NASA航天飞机软件组就是一个软件可被预测的例子。这套软件的设计有大量的规则，花了很长的时间，有一个很大的开发团队和明确的需求。一个大的危险是当你没有能力遵从需求的时候假装能遵从需求，人们在使用某些方法时并不太明确其使用的界限情况。很多原则都想让其对任何人都有用，所以不去了解其使用的界限，这导致人们在有些情况下错误的使用某种原则，即在不可预测的情况下使用预测性方法。因此，在你不能预测的情况下不能使用预测性方法，这意味着很多软件的模型，很多整个客户关系模型不再有用。预测的用处如此之大以至不能失去它。困难的部分最容易被意识到这种情况在这个问题中也是这样的，但是失去预测性并不意味着你不能控制混乱。控制不可预知的过程迭代那么，我们如何控制自己不可预知的世界呢？最重要的最困难的是要准确知道，我们需要一个诚实的反馈机制，可以准确地告诉我们什么情况重播的。对这个反馈的关键是迭代开发，这不是一个新的发展，渐进，进化，分阶段，螺旋.迭代开发的关键是要经常大量生产工作最终系统的版本有一个必要的工作制度功能的子集，否则，我们应忠实于最后的要求，应充分整合和仔细测试，这样一个经过测试，对任何带入一个现实的有力的剂量可以隐藏各种代码。其实很多时候人们在前面坐一个综合系统，然后有一个明显缺陷：无论是在错误的条件和要求方面的误解。迭代的发展使得作为它在适应过程中必不可少的，因为一个适应的过程需要能够处理所需变化可预见的流程意识导致规划在长期计划是非常流体风格，只有稳定的短期计划是单一的发展作出规划都能让您在每次迭代坚实的基础，您可以基于您的这一关键问题后长期的计划是如何应一次迭代赋予不同建议的，反复表明了一个长度将延伸短你可以离开提供更频繁，所以你知道你在哪里更频繁。自适应客户这种适应的过程，需要有一种比通常被视为是艺术的发展，尤其是在一个单独的独立的公司做软件开发完成的，客户的关系，不同类型，大多数客户宁愿固定价格开发他们想要的东西，招标要求，接受竞标，然后责任在于开发组织建立软件。固定造价合同，必须有稳定的要求，并因此而预测过程和不稳定的需要，这意味着你不能与固定价格模式适应，一种适应过程通常的概念最终在一个非常痛苦的爆炸，这一爆炸最讨厌的是，客户的每一个受到伤害的软件开发所有客户在很大程度上将不会缺少一些软件，除非他们的业务需要，他们没有得到它的业务遭受位。因此，即使他们付钱给开发公司一无所知，他们仍然失去超过他们支付软件（为什么他们会支付软件，如果该软件的商业价值较少？）因此，这对双方都危险在签署的在固定价格合同的条件下一个预测的过程是不能并不意味着你不能确定一个软体预算，它的意思是，你不能修复的时间，价格和敏捷方法通常是修复时间，并允许变化的范围在受控是一种适应过程，客户有更精细，在软件开发中他们得到每个迭代都检查进展和细粒度控制改变方向的软件，导致更为密切的参与程度，是不是每一位客户的组织，也不是每个软件开发人员，但它必须作出适应的过程正常工作。所有这一切产生了一系列的优势为数目开始，他们得到更多的响应软件开发。奥塞布尔，虽然很小，系统能尽早投入生产上，客户可以改变的能力，依照业务变化，并从该系统如何在位作为重要的学习，因为这也将是更大的可视性在预测过程与问题的真实情况却是，工程质量是衡量是否符合人们信号时，现实和计划共同的结果是在附表中晚期大滑在一个敏捷项目是有计划的坏消息不断改造是它往往潜伏着来前，当仍然有时间来做些事情，这种风险控制是一个关键优势迭代方法采取保持迭，此事作进一步的小，而且也看到这些变化的机会。重要的问题是成功的预测项目往往是衡量以及它如何满足其项目，对时间和成本被认为是测量，是一派胡言。对于敏捷的问题是商业价值，并得到客户的软件，更为可贵的比良好的预测到项目投入将按照计划对他们的成本，良好的敏捷项目将建立不同的东西，比原来的计划，更好地预见。附件2：外文原文（复印件）TheNewMethodologyMartinFowlerInthepastfewyearstheresbeenarapidlygrowinginterestinagile(aka“lightweightsmethodologies).Alternativelycharacterizedasanantidotetobureaucracyoralicensetohacktheyvestirredupinterestalloverthesoftwarelandscape.IntheseessayIexplorethereasonsforagilemethods,focusingnotsomuchontheirweightbutontheiradaptivenatureandtheirpeople-firstorientation.FromNothing,toMonumental,toAgileMostsoftwaredevelopmentisachaoticactivity,oftencharacterizedbythephrasecodeandfix.Thesoftwareiswrittenwithoutmuchofanunderlyingplan,andthedesignofthesystemiscobbledtogetherfrommanyshorttermdecisions.Thisactuallyworksprettywellasthesystemissmall,butasthesystemgrowsitbecomesincreasinglydifficulttoaddnewfeaturestothesystem.Furthermorebugsbecomeincreasinglyprevalentandincreasinglydifficulttofix.Atypicalsignofsuchasystemisalongtestphraseafterthesystemisfeaturecomplete.Suchalongtestphraseplayshavocwithschedulesastestinganddebuggingisimpossibletoschedule.Wevelivedwiththisstyleanddevelopmentforalongtime,butwevealsohadanalternativeforalongtime:Methodology.Methodologysimposeadisciplinedprocessuponsoftwaredevelopmentwiththeaimofmakingsoftwaredevelopmentmorepredictableandmoreefficient.Theydothisbydevelopingadetailedprocesswithastrongemphasisonplanninginspiredbyotherengineeringdisciplines-whichiswhyirefertothemasengineeringmethodologies.Engineeringmethodologieshavebeenaroundforalongtime.Theyvenotbeennoticeableforbeingterriblysuccessful.Theyareevenlessnotedforbeingpopular.Themostfrequentcriticismofthesemethodologiesisthattheyarebureaucratic.Theressomuchtodotofollowthemethodologythatthewholepaceofdevelopmentslowsdown.Asareactiontothesemethodologies,anewgroupofmethodologieshaveappearedinthelastfewyears.Forawhilethesewereknownalightweightmethodologies,butnowtheacceptedtermisagilemethodologies.Formanypeopletheappealoftheseagilemethodologiesistheirreactiontothebureaucracyofthemonumentalmethodologies.Thesenewmethodsattemptausefulcompromisebetweennoprocessandtoomuchprocess,providingjustenoughprocesstogainareasonablepayoff.Theresultofallofthisisthatagilemethodshavesomesignificantchangesinemphasisfromengineeringmethods.Themostimmediatedifferenceisthattheyarelessdocument-oriented,usuallyemphasizingasmalleramountofdocumentationforagiventask.Inmanywaystheynarerathercode-oriented:followingaroutethatsaysthatthekeypartofdocumentationissourcecode.HoweverIdontthinkthisisthekeypointaboutagilemethods.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.Itsadifferentkindofactivityandrequiresadifferentprocess.TheUnpredictabilityofRequirementsTheresarefrainIveheardoneveryproblemprojectIveruninto.Thedeveloperscometomeandsaytheproblemwiththisprojectisthattherequirementsarealwayschanging.ThethingIfindsurprisingaboutthissituationisthatanyoneissurprised.Inbuildingbusinesssoftwarerequirementschangesarethenorm,thequestioniswhatwedoaboutit.Onetouteistotreatchangingrequirementsastheresultofpoorrequirementsengineering.Theideabehindrequirementsbeforeyoubeginbuildingthesoftware,getacustomersign-offtotheserequirements,andthensetupproceduresthatlimitrequirementschangesafterthesign-off.Oneproblemwiththisisthatjusttryingtounderstandtheoptionsforrequirementsistouch.Itseventougherbecausethedevelopmentorganizationusuallydoesntprovidecostinformationontherequirements.Youendupbeinginthesituationwhereyoumayhavesomedesireforasunroofonyourcar,butthesalesmancanttellyouifitadds$10tothecostofthecar,or$10000.Withoutmuchideaofthecost,howcanyoufigureoutwheatheryouwanttopayforthatsunroof.Estimationishardformanyreasons.Partofitisthatsoftwaredevelopmentisadesignactivity,andthushardtoplanandcost.Partofitisthatthebasicmaterialskeepchangingrapidly.Partofitisthatsomuchdependsonwhichindividualpeopleareinvolved,andindividualsarehardtopredictandquantify.SoftwaresintangiblenaturealsocutsinIfitsverydifficulttoseewhatvalueasoftwarefeaturehasuntilyouuseitforreal.Onlywhenyouuseanearlyversionofsomesoftwaredoyoureallybegintounderstandwhatfeaturesarevaluableandwhatpartsarenot.Thisleadstotheironicpointthatpeopleexpectthatrequirementsshouldbechangeable.Afterallsoftwareissupposedtobesoft.Sonotjustarerequirementschangeable,theyoughttobechangeable.Ittakesalotofenergyofcustomersofsoftwaretofixrequirements.Itsevenworseiftheyveeverdabbledinsoftwaredevelopmentthemselves,becausethenthey“know”thatsoftwareiseasytochange.Butevenifyoucouldsettleallthatandreallycouldgetanaccurateandstablesetofrequirementsyoureprobablystilldoomed.Intodayseconomythefundamentalbusinessforcesarechangingthevalueofsoftwarefeaturestoorapidly.Whatmightbeagoodsetofrequirementsnow,isnotagoodsetinsixmonthstime.Evenifthecustomerscanfixtheirrequirements,thebusinessworldisntgoingtostopforthem.Andmanychangesinthebusinessworldarecompletelyunpredictable:anyonewhosaysotherwiseiseitherlying,orhasalreadymadeabilliononstockmarkettrading.Everythingelseinsoftwaredevelopmentdependsontherequirements.Ifyoucannotgetstablerequirementsyoucannotgetapredictableplan.IsPredictabilityImpossible?Ingeneralno.Therearesomesoftwaredevelopmentswharepredictabilityispossible.OrganizationssuchasNASAsspaceshuttlesoftwaregroupareaprimeexampleofwheresoftwaredevelopmentcanbepredictable.Itrequiresalotofceremony,plentyoftime,alargeteam,andstablerequirements.Thereareprojectsouttherethatarespaceshuttles.HoweverIdontthinkmuchbusinesssoftwarefitsintothatcategory.Forthisyouneedadifferentkindofprocess.Oneofthebigdangersistopretendthatyoucanfollowapredictableprocesswhenyoucant.Peoplewhoworkonmethodologyarenotverygoodatidentifyingboundaryconditions:theplaceswherethemethodologypassesfromappropriateininappropriate.Mostmethodologistswanttheirmethodologies,suchasusingapredictablemethodologyinaunpredictablesituation.Theresastrongtemptationtodothat.Predictabilityisaverydesirableproperty.Howeverifyoubeliveyoucanbepredictablewhenyoucant,itleadstosituationswherepeoplebuildaplanfallsapart.Youseetheplanandrealityslowlydriftingapart.Foralongtimeyoucanpretendthattheplanisstillvalid.Butatsomepointthedriftbecomestoomuchandtheplanfallsapart.Usuallythefallispainful.Thereforeifyouareinasituationthatisntpredictableyoucantuseapredictivemethodology.Thatsahardblow.Itmeansthatmanyofthemodelsforcontrollingprojects,manyofthemodelsforthewholecustomerrelationship,justarettrueanymore.Thebenefitsofpredictabilityaresogreat.itsdifficulttoletthemgo.Likesomanyproblemsthehardestpartissimplyrealizingthattheproblemexists.Howeverlettinggoofpredictabilitydoesntmeanyouhavetoreverttouncontrollableahaos.Insteadyouneedaprocessthatcangiveyoucontroloveranunpredictability.Thatswhatadaptivityisallabout.ControllinganUnpredictableProcess-IterationsSohowdowecontrolourselvesinanunpredictableworld?Themostimportant,andstilldifficultpartistoknowaccuratelywhereweare.Weneedanhonestfeedbackmechanismwhichcanaccuratelytelluswhatthesituationisatfrequentintervals.Thekeytothisfeedbackisiterativedevelopment,Thisisnotanewidea.Iterativedevelopmenthasbeenaroundforawhileundermanynames:incremental,evolutionary,staged,spirallotsofnames.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.Afterallthecustomerwouldntbewantingsomesoftwareunlesstheirbusinessneededit.Iftheydontgetittheirbusinesssuffers.Soeveniftheypaythedevelopmentcompanynothing,theystilllose.Indeedtheylosemorethantheywouldpayforthesoftware(whywouldtheypayforthesoftwareifthebusinessvalueofthatsoftwarewer