IBM Rational Unified Process]Q或U?RUP]Q是一个完善的软g开发过E框Ӟ它具有若q种卌即用的实例。源?RUP 的过E范围很q,从满短周期的小型项目需要的轻量U?RUPQ到满大型的、可能是分布式的目团队需要的更加完备的过E。各U类型和规模的项目都已成功地使用?RUP。本白皮书说明了如何在小型项目中以轻量的方式应?RUP。我们将要讲解如何在一个完整项目的上下文范围内应用极限~程QXPQ技术?/blockquote> 摘要
IBM Rational Unified Process]Q或U?RUP]Q是一个完善的软g开发过E框Ӟ它具有若q种卌即用的实例。源?RUP 的过E范围很q,从满短周期的小型项目需要的轻量U?RUPQ到满大型的、可能是分布式的目团队需要的更加完备的过E。各U类型和规模的项目都已成功地使用?RUP。本白皮书说明了如何在小型项目中以轻量的方式应?RUP。我们将要讲解如何在一个完整项目的上下文范围内应用极限~程QXPQ技术?/p>
引言
一个小故事
一天早上,一名经理找到我询问我是否可以花几个星期Z家公司刚刚启动的投资建立一个简单的信息pȝ。我正厌烦手头的目而(f)望新目启动带来刺激Q于是我个机?x)欢ƣ雀?-我快速开始行动,为新的伟大解x案进行开发,而摆脱我工作的大型机构的官僚和手l的束缚(x)?/p>
事情在开始阶D进行得很顺利。在头六个月中,我都工作很长旉q且自得其乐。我的工作效率不可思议Qƈ且一些工作堪U是我职业生涯中的杰作。开发周期是快速的Q而且我每隔几周就可以完成pȝ中一些新的主要部分。与用户的交互过E简单而直接,我们都属于一个紧密联pȝ团队Q而且可以免除一些手l和文。也没有什么正式的设计Q代码就是设计,设计也就是代码。一切都是这L(fng)完美Q?/p>
q种完美只持l了一D|间。随着pȝ开发的q行Q我们需要开展更多的工作。现有代码随着问题的变更而必进行完善,而且我们也相应精化了所需工作的概c我雇了一些开发h员帮助进行开发。我们就像一个单元一样工作,l常对一些问题互相讨论。这加强了沟通同时也免除了Ş式?/p>
一q过M?/p>
我们q在增加开发h员。整个团队从 3 个h?5 个hQ然后是 7 个h。每ơ增加h员时Q都要花很长的时间来学习(fn)Q如果没有经验,那么很隄解和解释整套pȝQ即使是一个概览。我们开始用白板图来更加正式地展示pȝ的整体结构、主要概念和接口?/p>
我们仍然在用测试作为验证系l是否满需要的主要手段。很多新来的开发h员都站在用户的立ZQ我们发现项目早期非正式的需求和个h联系已经不能满需要了。我们花费了更长的时间来计划我们要徏立的目标内容。结果由于我们保留了讨论的文字记录,而不用频J地回想已经做过的决定。我们还发现描述需求和使用场景有助于向pȝ的新用户介绍情况?/p>
pȝ的规模和复杂度不断增加,意外的情况发生了--需要清楚地描述pȝ的构架。在目初期Q构架大部分存于我的头脑中,后来潦草地记在笔记或zd挂图中。不q,随着目的h员越来越多,构架有些失控。由于不是每个h都和我一样富有经验,他们无法发现某些变更Ҏ(gu)个构架带来的影响。我们不得不使用更精的术语定义对系l构架的U束。Q何可能媄响构架的变更都需要团队进行商讨,q且最l获得我的同意。我们绕了一圈后才发Cq个问题Q接受了一些重大教训之后,q在真正认识到构架的重要性?/p>
q是一D늜实经历。它只讲qCq个目中的一部分困难l历。这些经历只在一个方面是不同d的:(x)我们中的一部分Z开始的最后一直在一P旉一q有余。开发h员经常在一个项目中半途而来Q没{结束就已经dQ丝毫看不到他们的所作所为带来的后箋影响?/p>
q个目本该使用一些过E进行管理。过E太多会(x)误事Q但是不使用q程?x)带来新的风险。就像投资高风险股票的h仅仅看到高回报一P几乎不用过E?的项目组忽略了项目环境中的关键风险,其实是在"期望得到最好的l果Q但是没有ؓ(f)最坏的情况做打??/p>
概述
本文讨论了如何将q程应用C如上文所q的目中。我们的目的是ؓ(f)了得C用过E的"恰当U别"。了解开发团队所面对的挑战以及其所处的来务环境Q可以得E用的恰当U别。如果我们理解了q些挑战Q就可以使用刚好_的过E来降低风险。不论是轻量U的q是其他Q?一刀?q程是不存在的。在以下内容中,我们来研I这一思想Q即q程的恰当别可以作Z个风险的函数?/p>
我们集中讨论如何通过使用两个行的方法得到过E的恰当U别QRational Unified Process 或简U?RUP 以及极限~程QXPQ。我们展C如何在型目中?RUP 以及 RUP 如何处理 XP 没有涉及到的领域。二者融合ؓ(f)目团队提供了所需的指?-减少风险同时完成交付软g产品的目标?/p>
RUP 是由 IBM Rational 开发的q程框架。它是一UP代的开发方法,Z六个l过行业验证的最?jng)_践(参见 RUP 附录Q。随着旉的推q,一个基?RUP 的项目将l历四个阶段Qv始阶D(InceptionQ、细化阶D(ElaborationQ、构造阶D(ConstructionQ、交付阶D(TransitionQ。每个阶D都包括一ơ或者多ơ的q代。在每次q代中,(zhn)根据不同的要求或工作流Q如需求、分析和设计{)投入不同的工作量。RUP 的关键驱动因素就是降低风险。RUP 通过数千个项目中数千?IBM Rational 客户和合作伙伴用而得到精化。下囑ֱCZ一个典型P代过E的工作:(x)
典型q代?/b>
![典型q代? src=]()
作ؓ(f)风险如何影响q程的一个例子,我们应该考虑是否需要ؓ(f)业务建模。如果由于对业务的理解中没有考虑C些重大风险,导致我们所构徏的系l是错误的,那么我们应该执行一些业务徏模工作。我们需要正式进行徏模工作吗Q这取决于我们的涉众--如果一个小团队非正式C用结果,那么我们也许只进行非正式的记录就可以。如果组l中的其他h也将使用l果或者查看结果,那么我们可能p投入更大的努力,q且保该结果的正确性和可理解性?/p>
(zhn)可以定?RUP 使其满几乎M目的需要。如果没有满x特定需要的卌即用的过E或路线图,(zhn)可以轻村֜创徏(zhn)自q路线图。\U图描述了该目如何计划使用q程Q因此代表了该项目的特定q程实例。这意味着QRUP 可以按需要变得简单或复杂Q我们将在本文中详细解释?/p>
XP 是一个用于小型项目中的以代码Z心的轻量U过E(参见 XP 附录Q。它来自 Kent Beck 的创意,在大?1997 q?Chrysler 公司?C 3 工资单项目中得到软g界的x。如?RUP 一PXP 也是Zq代的,q且体现了诸如小规模发布、简单设计、测试以及持lP代几实践,。XP 为恰当的目和环境引入了一些有效的技术;不过Q其中也存在隐藏的假设、活动和角色?/p>
RUP ?XP h不同的基本原理。RUP 是过E组件、方法以及技术的框架Q?zhn)可以其应用于Q何特定的软g目Q我们希望用户限?RUP 的用范围。XPQ从另一斚w来说Q是一个具有更多限制的q程Q需要附加内容以使其适合完整的开发项目。这些不同点解释了Y件开发界的一个观点:(x)开发大型系l的人员使用 RUP 解决问题Q而开发小型系l的人员使用 XP 作ؓ(f)解决Ҏ(gu)。我们的l验表明大部分的软g目都处于两者之?-力扑֯适用于各自情늚q程的恰当别。单U地使用两者之一是不充分的?/p>
当?zhn)?RUP 中融合了 XP 技术时Q?zhn)会(x)得到过E的正确量,既满了目所有成员的需要,又解决了所有主要的目风险问题。对于一个工作于高信ȝ境中的小型项目团队,其中用户是团队的一部分Q那?XP 完全可以胜Q。对于团队越来越分散Q代码量来大Q或者构架没有很好定义的情况Q?zhn)需要做一些其他工作。在用户交互h"契约"风格的项目中Q仅?XP 是不够的。RUP 是一个框Ӟ(zhn)可以从 RUP 出发Q在必要时以一l更健壮的技术来扩展 XP?/p>
本文的以下部分描qC一个基?RUP 四个阶段的小型项目。在每个阶段中,我们都确定了所产生的活动和工g 。虽?RUP ?XP h不同的角色和职责Q但是我们在q里不会(x)处理q些差异。对于Q何组l或目Q实际项目成员必dq程中与正确的角色关联v来?/p>
目启动Qv始阶D?/span>
对于新的开发项目来_(d)起始阶段是很重要的,在项目l进行前Q?zhn)必须处理重要的业务与需求风险。对于那些增强现有系l的目Qv始阶D|比较短暂的,但是其目的仍是确定该目的实施h(hun)值及可行性?/p>
在v始阶D中Qؓ(f)了构Y件?zhn)可以创徏业务案例。视图是起始q程中的关键工g。它是系l的高描述。它为每个h解释该系l是什么、可能用系l的用户、用系l的原因、必d备的功能Q以及存在的U束。视囑֏能很短,也许只有一两段。视囑־往包括软g必须为客h供的关键功能?/p>
下面的例子展CZ一个项目的很短视图Q该目?Rational 的外部网站进行了攚w?/p>
Z Rational 的地位达到电(sh)子开发(包括工具、服务和最?jng)_践)的世界领先程度,可以通过动态的、个性化的网站加强客户关p,问者提供自助服务、支持和目标内容。新的过E和技术启用可以内容供应商通过一U简化的、自动的解决Ҏ(gu)加速发布ƈ提高内容的质量?/i>
RUP 起始阶段?4 个重要活动ؓ(f)Q?/p>
制定目的范围。如果我们打构Z个系l,我们需要知道其内容以及它如何满x众的需要。在q个zd中,我们捕获内容和最重要的需求的_详细的信息,从而得Z品可接受的标准?/p>
计划q准备业务案例。我们用视图作为指|定义风险~和{略Q开发v始的目计划Qƈ定已知成本、日E计划,以及盈利率^衡?/p>
l合得出备选构架。如果正在计划中的系l没什么新颖性,而且使用的框架广Zh之,那么(zhn)可以蟩q这一步。我们一旦知道客L(fng)需求,p开始分配时间研I可行的备选构架。新技术能够带来解册Y仉题的新的q且l过改进的解x案。在q程的早期花些时间评估购买还是创建系l,q择技术,也可以开发出一个v始原型,q些都可以减项目的一些主要风险?/p>
准备目环境。Q何项目都需要项目环境。不论?zhn)使?XP 技术(例如l对~程Q,q是较传l的技术,(zhn)都需要确定团队将要用的物理资源、Y件工具以及步骤?/p>
q行型目开发时Qƈ不需要太多的"q程旉"来执行v始过E。?zhn)往往可以在几天中或者更的旉里完成,下面的内容说明了本阶D除了视图之外的预期工g?/p>
一个经批准的业务案?/span>
涉众有机?x)从业务的角度认定项目是值得q行的。RUP ?XP 都承认最好在早期得出项目是否值得q行的结论,以免在一个注定将要失败的目中花费宝늚资源。如同在"Planning Extreme Programming" 一书描q的那样QXP 对于目是如何Ş成的以及涉及哪些角色q两个问题的回答是比较模p的Q似乎在现有目或系l的环境中是最清晰的)Q但是在研究阶段QXP 处理的工件与 RUP 起始q程中的是相同的?/p>
不论(zhn)在 XP 中非正式地考虑业务问题Q还是在 RUP 中将业务案例做成一的目工gQ?zhn)都需要考虑q些问题。风险清单?zhn)应该在整个项目开发过E中都保持记?Risk ListQ风险清单)。用有风险清单可以是一个具有经q计划的风险~和{略的简单清单。ؓ(f)各个风险讑֮优先U。Q何与目有关的h员都可以随时看到风险的内容以及如何处理风险,但是没有提供解决风险的一般方??/p>
初步目计划
本计划包括资源估、规模以及阶D计划。对于Q何项目,q些估算都是不断变化的,(zhn)必ȝ控它们?/p>
目验收计划
(zhn)的计划正式与否依赖于项目的cd。?zhn)必须判断客户会(x)如何才能认为(zhn)的项目取得了成功。对于一?XP 目Q客户会(x)采取验收试的Ş式。在更普遍的q程中,客户可能不会(x)真正地进行测试,但是接受的标准必ȝ接由客户作出Q或者由另一个角色作出,例如与客L(fng)接接触的pȝ分析员。也可能存在其他的验收标准,例如创徏最l用h档和帮助Q但是XPq不涉及此内宏V?/p>
起始l化q代计划
在基?RUP 的项目中Q在上次q代的最后,(zhn)将详细计划下次q代。在q代的最后,(zhn)可以评估P代开始时讄的标准。XP 提供了探监控与衡量P代成功的一些优U技巧。衡量标准是单的Q?zhn)可以L地将它们合ƈ到P代计划和评估标准中?/p>
起始用例模型
虽然q听h比较正式而让人望之却步,但是它却相当单。用例与客户在XP中编写的"故事"相对应。其间的差异是一个用例就是一套完整的动作Q由参与者或pȝ外部的h员或事物发vQ这正是用例的h(hun)值所在。用例可能包括若q个XP"故事"。RUP Z定义目的边界,推荐在v始过E中定用户与角艌Ӏ从用户的观点关注整套操作有助于系l分为有价值的部分。这有助于判定恰当的实施Ҏ(gu),因此我们能够在每ơP代的最后向客户交付一些成果(可能在v始P代与l化q代早期除外Q?/p>
RUP ?XP 都可以帮助我们确保避免一U情况,x个项目已完成 80Q,但都不是可交付的形式。我们一直希望发布的pȝ对用户都是有价值的?/p>
在这一点上Q用例模型在识别用例和参与者方面几乎没有或只有很少提供支持的细节。它可以是手工或使用工具l制的简单的文本或?UMLQ统一建模语言Q图。该模型帮助我们保已经包含了涉众所兛_的正的功能Qƈ且没用忘CQ何功能,q允许我们轻村֜查看整个pȝ。用例根据若q因素设定优先Q这些因素包括风险、对客户的重要程度以及技术难炏Vv始阶D中不需要过于正式的或过大的工g。按照?zhn)的需求让它们保持单或者正式就可以。XP 包括对计划与pȝ验收的指南,但是 RUP 需要在目的早期添加更多的一些内宏V这些少量添加可能通过处理一套更完整的风险而ؓ(f)目提供很大的h(hun)倹{?/p>
l化阶段
l化阶段的目标是为系l构架设立基U,为在构徏阶段大量的设计与实施工作打下坚实的基。构枉过考虑最重要的需求(那些对系l构架媄响最大的需求)与评估风险演q而来。构架的E_性是通过一个或多个构架原型q行评估的?/p>
?RUP 中,设计zd主要xpȝ构架的概念,对于软g密集型的pȝ来说Q就是Y件构架的概念。用组件构架是?RUP 中体现的软g开?6 Ҏ(gu)?jng)_践其中之一Q该实践推荐在开发与所作所为构架上要投入一些时间。在q项工作p的时间可以减~与脆弱的、僵化日pȝ有关的风险?/p>
XP 使用"隐喻"替换了构架的概念。隐d捕获构架的一部分Q而其余构枉分则随着代码开发的自然l果而演q。XP假定构架的Ş成是从生成简单的代码开始,然后q行持箋的代码重构?/p>
?RUP 中,构架不只?隐喻"。在l化阶段中,(zhn)构建可执行的构Ӟ从中可能降低与是否满非功能性需求相关的许多风险Q例如性能、可靠性以及健壮性。通过阅读XP文献Q很可能推断Z?RUP 为细化阶D|描述的内容,其是过?XP 所U的基础设施的过分关注,都是徒劳无功的。XP 认ؓ(f)在没有必要的情况下创建基设施所做的工作D了解x案过于复杂,q且所创徏的结果对客户没有价倹{在 RUP 中,构架与基设施不是{同的?/p>
?RUP ?XP 中创建构架的Ҏ(gu)是截然不同。RUP (zhn)关注构Ӟ避免随时间变化而生的范围蔓g、增加项目规模以及采用新技术带来的风险。XP 采用_单或是很好理解的现有构架Q该构架能够随着代码而演q。XP (zhn)不要ؓ(f)明天而设计,而要Z天而实施。XP 怿如果(zhn)尽可能C持设计简单,那么来理h也轻而易举。RUP 希望(zhn)考虑该主张带来的风险。如果系l或者部分系l在未来不得不重写,那么 XP 认ؓ(f)q种举措比现在就计划q种可能性更明智而且p更少。对于一些系l,q是千真万确的,而且使用 RUP Ӟ在?zhn)l化阶段考虑风险也会(x)得出同一l论。RUP q不认ؓ(f)对于所有系l这都是正确的,而且l验表明对于那些较大型、较复杂和没有先例的pȝ来说Q这可能是灾难性的?/p>
虽然为未来的可能性(可能永远不会(x)生生Q花费太多的_֊可能是一U浪费但是对未来q行_的关注不׃ؓ(f)一件精明之举。多公司能花得起代价不断重写或者甚x重构代码呢?
对于M目Q在l化阶段(zhn)应该至完成这三项zdQ?/p>
定义、验证ƈ且设定构架的基线?/b>使用风险清单从v始阶D开发备选构架。我们关注是否能够保证构想中的Y件具有可行性。如果选定技术对于系l没什么新颖性或者复杂性,q项d不会(x)p太长旉。如果?zhn)正在向现有系l中d内容Q那么如果现有构架不需要进行变_(d)q项d׃是必要的。但是当真正出现构架风险Ӟ(zhn)ƈ不想让?zhn)的架构?运??/p>
作ؓ(f)q项zd的一部分Q?zhn)可能执行一些组仉择Qƈ且做出决定进行购?创徏/重用lg。如果这需要大量工作,(zhn)可以将其分为单独的zd?/p>
_视图?/b>在v始阶D,(zhn)开发了一个视图。因Z要确定项目的可行性,q且涉众有时间检查和评h(hun)pȝQ因此可能要对视图文及需求作Z些变更。对视图与需求的修改一般在l化阶段q行。在l化阶段的最后,(zhn)已l深ȝ解了用来构徏和计划的最关键的用例。涉众需要得到认可,在当前构架的环境中,只要按照当前的计划开发整个系l,p实现当前的设惟뀂在随后的P代过E中Q变更的数量应该有所减少Q但是?zhn)可能会(x)在每次q代中花一些时间进行需求管理?/p>
为构建阶D创P代计划ƈ且设定基U?/b>。现在,可以为?zhn)的计划填充细节了。在每次构徏q代的最后,(zhn)可以按需要重新考虑计划q且q行调整。调整过E经常是必需的,因ؓ(f)需要进行的工作往往被错误地估算Q业务环境也?x)常常变化,有时需求也?x)发生变更。ؓ(f)用例、场景以及技术工作设定优先Q然后将它们分配到P代过E中。在每次q代q程的最后,(zhn)计划生一个能够ؓ(f)涉众提供价值的工作产品?/p>
(zhn)可以在l化阶段执行其他zd。我们推荐?zhn)建立试环境q且开始开发测试。虽然详l的代码q没有完成,但是(zhn)仍然可以设计测试,也许可以实施集成试。程序员应该随时准备q行单元试Qƈ且了解如何用项目选定的测试工兗XP 推荐(zhn)在~写代码前先设计试内容。这是个独到的见解,其是当(zhn)向现有代码M中添加内Ҏ(gu)。不q,无论(zhn)选择如何q行试Q都应该在细化阶D徏立常规测试体制?/p>
RUP 描述的细化阶D包?XP 中的研究阶段和投入阶DcXP 处理技术风险(例如新颖性和复杂性)的方式ؓ(f)使用"spike"解决Ҏ(gu)Q例如花费一些时间进行试验以对工作量q行估算。这U技术在许多案例中都是有效的Q当较大风险没有体现在单个用例或"故事"中时Q?zhn)需要花些工夫确保系l的成功而且对工作量q行_的估?/p>
在细化阶D,(zhn)会(x)l常更新工gQ例如v始阶D늚需求与风险清单。在l化阶段可能出现的工件包括:(x)
软g构架文QSADQ?/b>SAD 是一个复合型的工Ӟ它提供了整个目的技术信息的单一来源。在l化阶段的最后,该文可能会(x)包含详细的介l,描述在结构上很重要的用例Qƈ且确定关键的机制和设计元素。对于增强现有系l的目Q?zhn)可以使用以前?SADQ或者如果你觉得不会(x)带来什么风险,那么决定不使用该文。在所有的情况下,(zhn)都应该深思熟虑ƈ且记录于文中?/p>
构徏q程的P代计划?/b>(zhn)可以在l化阶段计划构徏q代的次数。每ơP代都有特定的用例、场景以及其他分配的工作目。这些信息都在P代计划中有所体现q且讑֮基线。评审与核准计划可以作ؓ(f)l化阶段的出口标准的一部分。对于非常小的短期项目来_(d)(zhn)可以将l化阶段的P代与起始q程和构E合q。关键性的zd仍然可以q行Q但是P代计划和评审所需的资源都?x)有所减少?/p>
构徏阶段
构徏的目标是完成pȝ开发。构建阶D从某种意义上来看是一个制造过E,其中重点工作是理资源、控制操作以优化成本、日E和质量。从q个意义上来Ԍ理理念应该q行一个{换,从v始阶D和l化阶段的知识权开发{换到构徏和交付阶D늚部v产品的开发?/p>
XP 侧重构徏阶段。构建阶D|~写产品代码的阶DcXP所有阶D늚目的都是Zq行计划Q但?XP 的关注焦Ҏ(gu)构徏代码?/p>
构徏阶段的每ơP代都h三个关键zdQ?/p>
理资源与控制过E?/b>每个人都需要了解自q工作内容和时间。?zhn)必须保证工作负荷不?x)过(zhn)的能力Q而且工作可以按计划进行?/p>
开发与试lg?/b>(zhn)构建组件以满q代中用例、场景以及其他功能的需要。?zhn)对其q行单元试和集成测试?/p>
对P代进行评估?/b>在P代完成时Q?zhn)需要判断是否已l达Cq代的目标。如果没有,(zhn)必重新划分优先q管理范围以保能够按时交付pȝ?/p>
不同cd的系l需要用不同的技术。RUP Y件工E师提供了不同的指导Q以帮助他们创徏恰当的组件。以用例和补充(非功能)需求的形式提出的需求是_详细的,可以使工E师开展工作。RUP 中的若干zd计、实施和试不同U类的组件提供了指南。一名有l验的Y件工E师不需要详l查看这些活动。经验稍Ơ缺一些的工程师可以通过最?jng)_践获得很大的帮助。每个团队成员都可以按需要深入研I过E或者只是稍微了解一下。不q,他们都参照一个单独的q程知识基础?/p>
?XP 中,"故事"驱动实施q程。在 Extreme Programming Installed 一书中QJeffries{h认ؓ(f)"故事"是程序员??x)话承?Qpromises for conversationQ?持箋有效的交大有裨益。虽然L需要澄清一些细节,如果"故事"不够详细Q而ɽE序员不能完成他们大部分工作Q那么可以说"故事"q没有就l。用例必够详l以方便E序员实施。在许多情况下,E序员会(x)帮助~写用例的技术细节。Jeffries {h认ؓ(f)Q会(x)话应该记录在文档中ƈ且附加到"故事"中。RUP 也同意这个观点,除了以用例规D明的形式Q可以按需要用非正式的Ş式。捕获ƈ理?x)话的结果是?zhn)必ȝ理的d?/p>
XP 的长处在于构建阶Dc对于大多数团队来说Q都存在适用于他们的"智慧与指南的l晶"。XP 中最显著的实践包括:(x)
试--E序员不断地随着代码的开发编写测试。测试反映了"故事"。XP提倡?zhn)首先~写试Q这是一优U的实践,因ؓ(f)它可以迫使?zhn)深刻地理?故事"Qƈ且在必要的地Ҏ(gu)出更多的问题。不论在~写代码之前q是之后Q一定要~写试。将它们加入到?zhn)的测试包中,q且保证每次代码变更旉q行试?/p>
重构--不断重构pȝ的结构而不改变其行为,可以使其更加单或灉|。?zhn)需要判断对(zhn)的团队来说是否存在一个较好的实践。简单与复杂的判别否因h而异。有q样一个例子,一个项目中的两个很聪明的工E师每晚都要重写Ҏ(gu)的代码,因ؓ(f)他们认ؓ(f)Ҏ(gu)的代码过于复杂。这产生了一个副作用Q也是他们Lq扰W二天其他成员的工作。测试是有帮助的Q但是如果他们之间不陷入代码之争的话Q那么团队的处境?yu)׃?x)更好一些?/p>
l对~程--XP 认ؓ(f)l对~程可以在更短的旉内创建出更好的代码。有证据表明q是正确?。如果?zhn)늅q项实践Q就需要考虑许多人文与环境的因素。程序员愿意Ҏ(gu)q行试吗?(zhn)的物理环境可以满q种情况吗,x_的空间两个E序员在一个单独工作站中有效地工作Q?zhn)如何对待q程工作或者在其他地点工作的程序员Q?/p>
持箋集成--集成与构建工作需要持l进行,可能每天不止一ơ。这是一U确保代码结构完整的很好的方式,它还允许在集成测试过E中q行持箋的质量监控?/p>
集体代码所有权--M人都可以随时修改M代码。XP 依赖q样一个事实,即一l好的单元测试将?x)减这实늚风险。让大家每一件事都搞清楚的好处不能局限在一定的度?-?1 万行代码? 万行代码q是一定要于 5 万行Q?/p>
单设?-随着重构q程的进行,需要不断地修改pȝ设计使其变更单。再一ơ重画I(zhn)需要判断这工作进行到何种E度才恰好合适。如果?zhn)在细化阶D中p了必要霎旉来设计构Ӟ我们怿单的设计会(x)很快完成q且很快变得E_?/p>
代码标准--q一直都是一良好实c标准是什么都没关p,只要(zhn)用它们而且每个人都认可可以?/p>
RUP ?XP 都认为?zhn)必须理Q和控制QP代过E。衡量标准可以提供较好的计划信息Q因为它们可以帮助?zhn)选择对于(zhn)的团队来说什么是最适合的。需要衡量三件事Q时间、规模和~陷。这h可以获得所有类型?zhn)所感兴的l计数字。XP 为?zhn)提供单的衡量标准来判断进展ƈ且预成果。这些衡量标准围l着完成?故事"数量、通过试的数量以及统计中的趋势这些问题。XP Z用最量的衡量标准做Z一个优U的表率,因ؓ(f)查看太多q不一定会(x)增加目成功的机?x)。RUP 为?zhn)提供了对于(zhn)可以衡量的内容以及如何衡量的指导Qƈ且D了有兌量标准的例子。在所有的情况中,衡量标准必须单、客观、易于搜集、易于表达,q且不易产生误解?/p>
在构建阶D늚q代q程中将?x)生哪些工件呢Q这取决于P代是处于构徏阶段的早期还是后期,(zhn)可以创Z下工Ӟ(x)
lg--lg代表了Y件代码中的一部分Q源代码、二q制代码或者可执行E序Q,或者包含信息的文gQ例如,一个启动文件或者一?ReadMe 文g。组件还可以是其他组件的聚合Q例如由几个可执行程序组成的应用E序?/p>
培训资料--如果pȝ的用L(fng)面比较复杂,那么请在用例的基上尽早编写用h册和其他培训资料的初Eѝ?/p>
部v计划--客户需要一个系l。部|计划描qC一l安装、测试ƈ且有效地向用户交付品所需的Q务。对?以Web Z心的pȝ来说Q我们已l发玎ͼ部v计划的重要性又提高了?/p>
交付阶段q代计划--临近交付Ӟ(zhn)需要完成ƈ且评审交付阶DP代计划?/p>
代码完整吗?
认ؓ(f)代码是设计q且设计也就是代码。代码与自nL一致的Q这一Ҏ(gu)千真万确的。我们认费精力进行设计ƈ且沟通设计是很值得的,而不仅仅是创Z码。下面的故事会(x)说明q一炏V?/p>RUP ?XP 间的差异除了建立构架的方法以外,q包括其他方面的不同。其中一点就是关于设计概늚沟通方式。XP
一名工E师曾有两次q样的Y仉目经历,设计体现在代码中Qƈ且只能在代码中找到设计信息。这两个目都是关于~译器的Q一个是改进与维护用?Ada ~译器的优化E序Q另一个项目是一个编译器的前端移植到一个新的^CQƈ且连接一个第三方的代码生成器?/p>
~译器技术是比较复杂的,但也是广Zh知的。在q两个项目中Q该工程师想要概览编译器Q或者优化程序)的设计和实施。在每个案例中,他都接到一堆源代码清单Q大概有几英厚Q而且被告?查看q些信息"。他本应被提供一些带有支持性文字的构徏很好的图。优化程序的目没有完成。但是编译器目实取得了成功,׃在代码开发过E中q行了广泛的试Q所以代码质量很高。这位工E师p了数天时间研I调试器中的代码以弄明白其作用。个人的损失在其次Q团队的损失代h(hun)更不值得。我们ƈ没有?XP 所C的那样?40 时后完成开发,我们反而花费了大量个h努力来完成工作?/p>
只开发代码带来的主要问题是无论代码文~写得多么好Q它都没有告诉?zhn)它本w要解决的问题,它只提供了问题的解决Ҏ(gu)。一些需求文档在最初用户和开发h员l工作很长时间以后,仍然可以很好地解释项目的原始目标。ؓ(f)了维护系l,(zhn)往往需要了解最初项目团队的设计目标。一些高U设计文都是相似的--代码l常没有l过高度的抽象,所以无法提供Q何信息以表明整体的系l能够实C么功能。在面向对象的系l中Q这一点尤其是正确的,因ؓ(f)仅仅查看里面的类文g是很隄x法得出执行线E。设计文档指导?zhn)在后期出现问题时该查看的内?-在后期经怼(x)出现问题?/p>
q个故事说明p旉创徏与维护设计文确实会(x)有所帮助。这可以降低误解的风险,q且加速开发过E。XP 的方式就是花费几分钟勄计的大概内容或者?CRC 卡片?但是团队不主张这P而只是进行代码开发。他们有一个隐含的假设Q那是d很简单,我们已经知道该如何进行了。即使我们成功地完成了Q务,那么下一个新来的人可能就不会(x)如此q运。RUP(zhn)多p一些时间创建ƈl护q些设计工g?/p>
交付阶段
交付阶段的焦点就是确保Y件对于最l用h可用的。交付阶D包括ؓ(f)发布q行产品的测试,在用户反馈的基础上做微小的调整等几方面内宏V在生命周期的这个时刻,用户反馈主要集中在精调整品、配|、安装,以及可用性等问题上?/p>
较早发布、经常性发布都是很好的办法。但是,我们通过发布要达到的目的是什么呢QXP 没有清楚地解释这个问题,也没有处理发布商业Y件所必须刉问题。在内部目中,(zhn)可以ؓ(f)解决q些问题扑ֈ捷径Q但是即使这P(zhn)仍焉要编辑文档、员工培训等工作。那么技术支持与变更理又如何呢Q希望现场客h制这些内容,q是可行的吗QBruce Conrad 在他?XP ?InfoWorld 评论 中指出用户ƈ不希望得到的软gL在持l变更。?zhn)必须对快速变更Y件的利益和变更的劣势及可能带来的不稳定性进行权衡?/p>
当?zhn)军_发布的时候,(zhn)必Mؓ(f)最l用h供比代码多得多的东西。交付阶D늚zd和工件会(x)指导(zhn)完成本部分软g开发过E。这些活动主要是Z向?zhn)的客h供可用的产品。交付阶D늚关键zd如下Q?/p>
定最l用h持资料。该zd比较单,(zhn)只需提供一个清单即可。但是务必要保(zhn)的l织已准备好对客戯行技术支持?/p>
在用L(fng)环境中测试可交付的品。如果?zhn)能够在公司内部模拟用L(fng)境,那是最好不q的。否则,到客户的公司去Q安装Y件ƈ且保证其可以q行。?zhn)一定不惛_地回答客户Q?但是在我们的pȝ上工作很正常?
Z用户反馈_调整产品。如果可能的话,在?zhn)向有限数量客户交付Y件时计划一ơ或者多?Beta 试周期。如果进行该试Q那么就需要对 Beta 试周期q行理Qƈ且考虑(zhn)?收尾工作"中的客户反馈?/p>
向最l用户交付最l品。对于不同类型的软g产品和发布版本,需要处理许多有x包、制造和其他产品问题。?zhn)肯定不?x)仅仅Y件复制到一个文件夹中,然后向客户发一邮件告诉他们Y件已l到位了?/p>
与其他阶D一Pq程的格式与复杂度都有所不同。不q,如果(zhn)没有注意部|细节,那么可能D数周或数月的良好开发工作前功尽弃,从而在q入目标市场时以p|告终?/p>
在交付阶D中(zhn)可以生成若q工件。如果?zhn)的项目涉及到来的发布(有多项目没有涉及到呢?Q,那么(zhn)就应该开始ؓ(f)下次发布定功能和缺陗对于Q何项目,下列工g都至关重要:(x)
部v计划--完成(zhn)始于构建阶D늚部v计划q且其作ؓ(f)交付的\U图?/p>
版本注释--它是一个比较少见的软g产品Q不包含Ҏ(gu)l用戯关重要的指o(h)。可以对其做划,对于注释要有一个可用的、一致的格式?/p>
交付阶段资料与文?-q类资料可以采取很多形式。?zhn)可以在线提供所有内容吗Q?zhn)会(x)进行指导吗Q?zhn)的品帮助完整ƈ且可用吗Q不要认为?zhn)所了解的,客户也同样了解。?zhn)的成功就在于帮助?zhn)的客户取得成功?/p>
l束?/span>
构徏软g的工作远q多于编写代码所工作。一个Y件开发过E必集中处理向用户发布高质量Y件的所有必需zd。一个完整的q程不必是庞大的。我们通过集中目中的主要zd和工Ӟ已经向?zhn)展示了如何进行一个小型但是完整的q程。如果执行某Ҏ(gu)动或者创建某个工件对于缓解项目中的风险是有帮助的Q那么就误行。?zhn)可以按需要ؓ(f)(zhn)的目团队和组l用或多或的q程和格式?/p>
RUP ?XP q不必是互相排斥的。通过l合使用q两U方法,(zhn)完全可以得C个过E,帮助(zhn)比现在更快C付更高质量的软g。Robert Martin 描述了一个叫?dX 的过E,他将其作?RUP 的附属品 。它?yu)是一个从 RUP 框架中构建的q程的实例?/p>
一个优U的Y件过E可以用经业界验证的最?jng)_c最?jng)_践已l在真实的Y件开发组l中使用Qƈ且经历了旉的考验。XP 是目前广为关注的Ҏ(gu)。它以代码ؓ(f)中心Qƈ提供了一Ҏ(gu)诺:(x)p最的q程开销得到最大的生力。XP 中的许多技术值得在恰当的情况中考虑和采用?/p>
XP x"故事"、测试和代码--它以一定的深度讨论了计划,但没有详l阐q如何获取计划。XP 意味着(zhn)可以完成其他一些工作,例如"使用一些卡片进?CRC 设计或者草拟某U?UML…?或?请不要生成ƈ不用的文或者其他工?Q但只是一带而过。RUP 希望(zhn)在定制和更新开发计划时Q仅仅考虑创徏有用和必ȝ东西Qƈ且指Zq些东西该是什么?/p>
RUP 是一个可以处理整个Y件开发周期的q程。它x最?jng)_践,q且l过了数千个目的洗C{我们鼓qI和发明新的技术以产生最?jng)_c随着新的最?jng)_践崭露头脚,我们希望它们纳?RUP 中?/p>
附录QRational Unified Process
Rational Unified ProcessQ或者简U?RUPQ提供了软g开发的规律性方法。它是由IBM Rational开发ƈl护的过E品。它为来同类型的目提供了几U即装即用的路线图。RUP q提供了一些信息,帮助(zhn)在软g开发过E中使用其他 Rational 工具Q但是它不要求将 Rational 工具有效地应用于整个l织Q?zhn)也可以?Rational 工具与其他供应商的品进行集成?/p>
RUP Y仉目所有方面提供了指导。ƈ不需要?zhn)执行M特定的活动或者创ZQ何特定的工g。它只ؓ(f)(zhn)提供信息和指南Q?zhn)可以军_哪些应用于(zhn)的l织。如果没有特定的路线N合(zhn)的目或者组l,RUP q提供了一些指南来帮助(zhn)量w定做你的过E?/p>
RUP 采用C软g开发的一些最?jng)_践,作ؓ(f)一U降低开发新软g所带来的内在风险的方式。这些最?jng)_践包括:(x)
1Q?q代开?br xmlns="" />2Q?理需?br xmlns="" />3Q?使用Zlg的构?br xmlns="" />4Q?可视建模
5Q?持箋的质量验?br xmlns="" />6Q?控制变更
q些最佳经验融合到 Rational Unified Process 的以下定义中Q?/p>
角色--执行的系列活动和拥有的工件?
学科--软g工程中的关键领域Q例如需求、分析与设计、实施与试?br xmlns="" />zd--工g生成与评估方式的定义?br xmlns="" />工g--在执行活动中所使用的、生成的或修改的工作产品?/p>
RUP 是一个P代过E,定了Q何Y件开发项目的四个阶段。随着旉的推q,每个目都要l历起始阶段、细化阶Dc构建阶D和交付阶段。每个阶D包括一ơ或多次q代Q其中?zhn)可以生成可执行文Ӟ但是pȝ可能不完_(d)可能起始阶段除外Q。在每次q代q程中,(zhn)以不同的细节别执行几个学U中的活动。下文是 RUP 的概q图?/p>
RUP 概览?/b>
![RUP 概览? src=]()
The Rational Unified Process, An Introduction, Second Edition 一书是 RUP 的好的概q。?zhn)可以?Rational ?Web 站点 www.rational.com 上找到更q一步的信息和对?RUP 的评仗?
附录Q极限编E?/span>
极限~程QXPQ是?Kent Beck ?1996 q开发的一UY件开发学U。它Z四个价|(x)沟通、简单、反馈和勇气。它客户与开发团队成员的持箋沟通,在开发进E中讄一名现场客戗该现场客户军_创徏的内容和序。通过持箋重构代码q创建最的非代码工仉合而体现简单。许多短期发布和持箋单元试建立了反馈机制。勇气意味着完成正确的事情,即q不是最行的事情。它q意味着诚实面对(zhn)能做的和不能做的事情?/p>
12 ?XP 实践四个价值提供支持。它们是Q?/p>
有计划的开发:(x)通过l合使用优先U?故事"和技术估,定下一版本的功能?/p>
版本:(x)以小的增量版本经常向客户发布软g?/p>
隐喻Q隐L一个简单、共享的"故事"或描qͼ说明pȝ如何工作?/p>
单设计:(x)通过保持代码单从而保证设计简单。不断的在代码中L复杂点ƈ且立刻进行移除?/p>
试Q用L(fng)写测试内容以?故事"q行试。程序员~写试内容来发C码中的Q何问题。在~写代码前先~写试内容?/p>
重构Q这是一简化技术,用来U除代码中的重复内容和复杂之处?/p>
l对~程Q团队中的两个成员用同一台计机开发所有的代码。一个h~写代码或者驱动,另一个h同时审查代码的正性和可理解性?/p>
集体代码所有权QQ何h都拥有所有的代码。这意呌每个人都可以在Q何时候变更Q何代码?/p>
持箋集成Q每天多ơ创建和集成pȝQ只要Q何实CQ务完成就要进行?/p>
每周 40 个小Ӟ(x)E序员在疲劳时无法保证最高效率。连l两周加班是l对不允许的?/p>
现场客户Q一名真实的客户全时工作于开发环境中Q帮助定义系l、编写测试内容ƈ回答问题?/p>
~码标准Q程序员采用一致的~码标准?/p>
目前有三本描q?XP 的书Q?/p>
1.解析极限~程QeXtreme Programming ExplainedQ?br xmlns="" />2.极限~程实施QExtreme Programming InstalledQ?br xmlns="" />3.规划极限~程QPlanning Extreme ProgrammingQ?/p>
一?Web 站点上也有关于XP的进一步信息?/p>
参考资?
- (zhn)可以参阅本文在 developerWorks 全球站点上的 英文原文?br />