英语原文共 432 页，剩余内容已隐藏，支付完成后下载完整资料
第3章理解XP
XP生命周期
XP令人瞠目结舌的一个主张就是你可以越过需求、设计、测试阶段以及与之俱来的文档工作。
相对于典型的软件开发方法，这个主张显得离经叛道，以致于很多人视之为妄想而不屑 一顾。“这些XP的拥泵显然不知道自己在说些什么，”他们说，“就在上个月，我所在的项目就因为需求和设计不足而失败。我们需要更多的需求、设计和测试，而不是更少。
的确如此。软件项目需要更多的需求、设计和测试——这就是为什么XP团队每天都从事这些活动（activity)。是的，每天。
你瞧，XP强调面对面协作。它可以如此有效地消除交流中的延迟和误解，以致干XP团 队无需区分阶段（phase)。这使他们能够以“并行阶段”(simultaneous phases)每天 从事于所有的活动。
采用并行阶段，XP团队每周都产出可部署的软件。在每次迭代中，整个团队分析、设计、编码、测试和部署一部分特性。
虽然这种工作方式未必意味着XP团队更加高效，（注1)但毫无疑问的是，XP团队能够 更加及时地得到反馈。作为结果，团队能够更容易地了解成功或者失败的根本原因。另外，少量未经检验的工作也使得团队能够相对轻松地纠正错误，例如当编码揭示了一个设计上的缺陷，或者客户评审（customer review)表明用户界面的布局令人费解或者过于难看。
及时的反馈也使得XP团队能够迅速地调整他们的计划。对于用户而言，能够在要求特性的几天后就试用工作原型，意味着用户可以更容易地调整特性。同样的原则适用于测试、设计和团队策略。你在任何一个阶段了解到的任何信息都可应用于软件的其余部分。如果你在编码或者测试中发现了设计上的瑕疵，你可以在接下来的迭代里利用那些 知识继续进行需求分析和系统设计。
XP如何工作
xpffl队并行地实施几乎所有的软件开发活动。分析、设计、编码、删试甚至部署都频繁地发生。 有很多方式可以实现并行，XP的并行之道是迭代式的工作，每个迭代表示一周的工作增量。XP团队每周完成一部分发布计划、一部分设计、一部分编码、一部分测试等。XP 团队以用户故事为工作单元，用户故事是非常小的特性或者部分特性，但是它体现客户价值。每周，XP团队承诺交付4~W个用户故事。整个礼拜，他们贯穿每个用户故事的所有开发阶段。在一周结束的时候，他们部署软件以便内部评审。(有些情况下，他们把软件部署给真实用户。） 以下部分描述了传统分阶段的软件开发活动如何对应XP的迭代。
计划
每个XP团队都有几位业务专家（现场客户）负责制定业务决策。现场客户阐明项目愿 景，创建用户故事，制定发布计划并管理风险，从而指引项目朝着正确的方向前进。
程序员提供估算和建议，这些和客户的重点需求综合在一起，进入称为计划博弈的流程。整个团队一起来创建小的、频繁的发布以最大化价值。
在项目开始的前几周，团队需要在计划上投入大量精力。在项目的其余时间，客户持续地评审和改进项目愿景以及发布计划以利用新的机遇或解决意外事件。除了整个发布计划，团队会在每个迭代开始时创建好下周的详细计划。团队每天在站立会议上碰头，并且信息化工作场所也让团队成员及时了解项目的状态。
分析
相对于在先期分析阶段定义需求，现场客户全部时间和团队坐在一起。根据项目类型而定，现场客户可以是真实客户（也可以不是），但是由他们来决定软件做什么最合适。
现场客户负责决定软件需求。为了这个目标，他们需要将传统的需求收集方法与他们的客户知识综合起来。当程序员需要信息时，他们只需要提问，由客户负责提供这些信息。他们在程序员估算需求之前提供用户故事的大致需求，而当程序员动手实现时提供具体需求：
对于复杂的、难以理解的需求，客户借助于测试人员的帮助，创建客户测试（customer test)来描述需求。客户测试是一些具体的、自动检验的示例。在程序员实现用户故事的同时，客户和测试员为用户故事创建客户测试。为了便于沟通，程序员在设计和编码时 采用统一协作语言。自动化客户测试无法应用于用户界面（UI)的外观。对于用户界面，客户和团队一起创 建程序界面的样图。有些情况下，客户和程序员一起，利用用户界面构建工具来创建程序界面。有些团队包括交互设计师（负责程序界面）。
设计和编码
XP采用増量式设计和架构以持续地小步骤创建和改进设计。这一切都要归功于测试驱动开发（test-driven development, TDD)错综复杂地衔接起测试、编码、设计和架构。为了支持这一过程，程序员结对工作以增加每个任务上的脑力投入并保证每组人中有一个人有时间考虑更大的设计问题。 程序员也要负责管理他们的开发环境。他们采用版本控制系统作为配置管理并同时负责维护自动构建。每隔几小时，程序员会把他们的代码集成到版本控制系统中，并且要严格保证毎个集成可用于部署。
为了实现这个目标，程序员维护编码规范，共享代码所有权。整个团队共享编码艺术， 并且每个成员都要解决代码中的问题，不管是谁导致的。
测试
XP包含尖端的删方法。团队的每个成员（程序员、客户和涵试人员）都可以对软件质量有所贡献。运转良好的XP团队在已完成的工作中每月只会产生为数不多的bug。
程序员通过测试驱动开发构建了第一道防线。测试驱动开发产生了自动化的单元漏试和 集成测试。有些情况下，程序员还会创建端对端（end-to-end)涵试。这些测试都有助于确保软件如程序员预期地工作。
类似地，客户测试有助于确保程序员预期与客户预期相合1客户对于进展中工作的评审也有助于确保用户界；如客户预期地工作。客户还会提供一些程序员可以自动化的示例，用于描述复杂的业务规则。
最后，测试员帮助团队了解所有人的努力是否真的产出了高质量的代码。他们采用探索 性测试寻找软件中的意外和缺陷。当测试员发现了一个bug,团队进行根源分析并考虑 如何改进流程以彻底杜绝类似的bug再次发生。测试员也会测试软件的非功能特性，例如性能和稳定性。接下来，客户利用这些信息来决定是否创建额外的用户故事。
XP团队不需要执行手动回归测试（regression test)。测试驱动开发和客户测试带来了一 套成熟的自动化回归测试。当发现bug的时候，程序员创建自动化测试以证明bug已被解 决，这足以杜绝任何回归。毎次程序员集成代码的时候（每隔几个小时），他们执行整套回归测试来检查是否有任何破裂。
XP团队还通过结对编程，精力充沛地工作和迭代松弛以提髙软件质量。这些实践有助于提升每个团队成员在创建高质量软件上的脑力投入。部署在每个迭代的末尾，XP团队准备好部署软件他们每周将软件部署给内部利益攸关者以准备每周的迭代演示，而对真实用户的部署则按照业务需要进行安排。
只要团队还存在，它就需要维护已发布的软件。视组机构不同，团队或许还需要为软件提供支持（在这种情况下，一个勤务员（batman)会有所帮肋；参见第8章的“迭代 计划”）。另外一些情况下，一个独立的支持团队或许会接管支持工作。类似地，当项目结束的时候，团队有可能将维护工作移交给另外一个团队。在这种情况下，团队需要在最后几周创建文档和提供必要的培训。
XP团队
一个人忙自己的项目（“抓自己的痒 ”)的确大有乐趣。一切都毫无疑问，要开始忙哪个特性，事情应该如何工作，软件是否工作正常，利益攸关者是否满意，所有的答案都在一个头脑团队软件开发大相径庭。同样的信息在许多团队成员中传播。不同的人知道：
- 如何设计和编写软件（程序员、设计师和架构师）。
- 为什么当前软件如此重要（产品经理）。
- 软件需要遵循的规则 (领域专家）。
- 软件的行为（交互设计师）bdquo;
- 用户界面看上去如何（图形设计师）。
- 缺陷可能隐藏在哪里（涵试员）。
- 如何与公司的其他部分进行协作（项目经理）。
- 在哪些领域提高工作习惯（教练）。
所有这些知识对于成功都是必要的。XP承认这一事实，并且创建跨功能的团队，由不同的人履行整个团队的多种角色。
整个团队
XP团队一起坐在开放的工作空间里。在每次迭代开始的时候，团队聚集在一起参加一系列的活动：迭代演示、回顾和迭代计划。一般来说，这些总共耗时2~4小时。另外，团 队每天聚集参加站立会议，每个会议通常用时5〜10分钟。
除了这些事先安排的活动，团队的每个成员计划自己的工作。这并非意味着每个人各自 为政，只不过他们不需要有明确的事先安排。当团队成员需要聚集时，他们再制定出每个会议的细节，有时这些会议非常随意，就像站起来大声通报工作区的大伙儿来讨论一个问题一样。自组织是敏捷因队的特征。
现场客户
现场客户（常常称为客户）负责定义团队创建的软件。团队的其他成员能够并应该贡献建议和主意，但是客户最终负责决定什么对于利益攸关者有价值。客户最重要的活动是发布计划。这是一项多方面的活动。客户需要阐述项目的愿景发现特性和用户故事；决定如何将众多特性分成小的、频繁的发布；管理风险；协调程序员并且参与计划博弈以创建可以实现的计划。
依赖于项目的类型，现场客户可以是真实客户也可以不是。无论如何，现场客户会收集 真实客户和其他利益攸关者的反馈，以完善他们的计划。其中一个收集反馈的场合是每周的迭代演示，由客户主持。
除了计划，客户也负责按照程序员的要求提供需求细节。XP仅仅将需求文档作为客户的记忆辅助物，因为客户自己就是活的需求文档，针对程序员的使用及时地研究信息并在需要时提供。客户也通过创建实体模型，评审进展中的工作，针对复杂的业务规划创建详细的客户测试等方式帮助沟通需求。整个团队必须坐在一起这种沟通才能有效发生。
一般来说，产品经理、领域专家、交互设计师和需求分析师承担现场客户的角色。创建 一个跨职能团队最困难的一个方面就是找到合格的并乐意作为现场客户的人。不要忽视这个角色为了增加你所交付的产品的价値，这个角色必不可少。没有现场客户，一个杰出的团队能够产出技术上优秀的软件，但是要想真正成功，软件必须将价值反馈利益攸关者。这需要现场客户的帮助。
客户参与对于产品的成功至关重要。务必使客户深入地参与如果客户不搬到团队中进来。其中一个方式是搬到他们的办公室而不是让他们搬到来，那么将团队搬到你的办公室。当然，前提是客户同意并且有足够的空间。
为什么需要如此之多的客户？
两个客户对应三个程序员，看上去有点多，不是吗？开始时我采用了一个较小的比例，但是我常常观察到客户挣扎着力图跟上程序员的节奏#在几个成 功的团队中尝试了不同的比例之后，我最终决定采用二比三。我也问过其他 XP教练的经历。一致的意见是二比三差不多是正确的。
那些项目大多数都包含复杂的问题领域，所以如果你的软件非常简单易懂，你可以少包括一些客户。记住客户有很多工作要做。他们需要决定什么是最有价值的，为工作设定合适的优先级，发现程序员可能会询问的所有细节，并且及时参与客户评审和客户测试。他们需要做所有这些工作，同样，领先程序员一步，后者紧随其后，像货车一样倾轧用户故事。这是一个大活儿，不要低估它。
产品经理（亦称作产品拥有者）
产品经理在XP项目中只做一个工作，这个工作是非常独特的。即维护和提升产品愿景。 在实践中，这意味着编写产品愿景文档，将之与利益攸关者分享，吸收反馈，产生特性和用户故事，为发布计划设定优先级，为团队的现场客户提供指导，评审进展中的工 作，主持迭代演示，使真实客户参与项目，并且处理组织问题。
最好的产品经理对于他们的市场有着深刻的理解，无论这个市场是一个组织（对应于客 户软件）还是众多组织（对应于商业软件）。好的产品经理对于软件将要提供什么和为 什么这是最重要的、项目团队值得花费时间的事情有着直观的理解。
出色的产品经理也具备少有的技能组合能力。除了愿景，他必须拥有一定的权威以做出哪些特性进入产品和哪些出局的困难权衡。他必须具有政治头脑，以统一不同利益攸关者的利益，将它们合并人产品愿景，并且对于无法满足的愿望清楚地说“不”。
高质量的产品经理常常面对大量的问题。你可能遇到困难，无法得到他们足够的重视，坚持。产品经理的角色是团队中最不可或缺的。获取项目经理的帮助，提醒人们软件开 发是非常昂贵的。如果软件的价值不能匹配一个好的产品经理（一个能够左右产品成败的产品经理）付出的时间，或许软件从一开始就不值得开发。
保证产品经理全职地致力于项目。一旦团队运作顺利，产品经理有可能开始减少他在项目中的参与。虽然领域专家和其他现场客户能够顶替产品经理一次，但是项目很有可能开始偏离航线，除非项目经理能够在每个迭代中都参与。[Rooney]经历过类似问题，后果令人遗憾：
我们不确定我们需要优先考虑的事情是什么。我们不十分确定接下来的工作是什么。我们从列表中选取了一些用户故事，但是从我们应该做什么的角度来说，只有极少数符合客户[产品经理]的标准。这种状况持续了好几个月。
然后，我们发现金子持有者（Gold Owner)[执行发起人]吃错药了——真的是。我们一直忙碌的工作根本不是这个人期待的。
在一个可以预期的环境中，通过代理给几个固定的现场客户，一个产品经理有可能可以花费大多数的时间在其他事情上，但是
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[154086]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
