搜索
极限编程XPeXtremeProgramming第一章什么是极限编程？•一种软件工程方法学•极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。•它的基础和价值观是交流、朴素、反馈和勇气；即任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。•XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。计划分析设计编码测试部署计划分析设计编码测试部署迭代生命周期1~3个月1~3个月＄＄迭代迭代迭代迭代迭代迭代迭代迭代迭代迭代迭代迭代迭代迭代迭代迭代迭代＄＄＄＄＄＄＄＄＄＄＄＄＄＄＄＄＄Xp生命周期计划分析设计编码测试部署2~3周$=可能的发布历史•极限编程的创始者是KentBeck、WardCunningham和RonJeffries，他们在解决克莱斯勒公司一个系统项目时，提出了极限编程的方法。•1999年10月发行《极限编程解析》（2005第二版出版）ByKentBeck•推荐书目：•《超越传统的软件开发—极限编程的幻象与真实》雷剑文，陈振冲著•《敏捷开发修炼之道》AndyHunt瀑布模型VS极限编程强调文档没有迭代与反馈把文档理解为开发速度角色定位敏捷开发追求价值XP的目标•极限编程的主要目标在于降低因需求变更而带來的成本•极限编程透过引入基本价值、原则、方法等概念來达到降低变更更成本的目的传统V.S.XPXP价值•沟通(Communication)•简单(Simplicity)•回馈(Feedback)•勇气(Courage)沟通•问题往往是由于开发人员与设计人员、设计人员与客户之间的沟通不畅造成的。因此，项目相关人员之间进行充分、多渠道（最好面对面）的沟通。•以人为本，重视客户的参与•在开发组间交换成员•版本发布会简单•需求尽量的简单•设计尽量的简单•代码尽量的简单•文档尽量的简单•XP要求今天最好做些简单的事，而不是做更复杂但可能永远也不会用到的事。反馈•尽快获得用户的反馈，并且越详细越好。更早和常常来自客户、团队和实际最终用户的具体反馈意见为您提供更多的机会来调整您的方向。反馈可以让您把握住正确的方向，少走弯路。•尽快发布新版本•客户应该是小组的一员勇气•这是最重要核心价值。因为XP强调“拥抱变化”，因此对于用户的反馈，要有积极面对现实和修复问题的勇气，如放弃系统的代码，改进系统设计等。•勇敢的重构•敢于所有人拥有代码•敢于极限（把好的方法做到极至）优点拥抱需求变化强调团队合作XP可以让开发者专注于编写代码，避免了不必要的文案工作及会议。增强代码和产品质量，并有效的减少BUG。程序员互相帮助，互相教对方，实现能力互补。从公司管理的角度来看，这种方法可以减少对牛人的依赖。同时它也提升了员工满意度。缺点缺乏设计文档，局限于小规模项目缺乏质量规划没有提供数据的收集和使用的指导开发过程不详细全新的管理手法带来的认同度问题适用对象2-10人的小型团队总结•XP针对的是中小型团队和中小型项目，但世界上毕竟还有大型项目跟超大型项目，究竟这种重视人甚于重视工程方法论的开发方法能否成为主流呢？•当然XP，还需要时间来证明它自己！•轻量级跟重量级分别代表着两个极端，一边是注重人甚于制程，另一边则是重视制程甚于人。这代表一个不甚有经验的人，也可以照着重量级制程的种种规则一步步来，优点当然是稳定，缺点当然是僵化。轻量级制程也差不多，好处是弹性，坏处是混乱。第二章极限编程实践•2.1.1完整团队–我们希望客户、管理者和开发人员紧密地工作在一起，以便彼此知晓对方所面临的问题，并共同去解决这些问题。–XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团体。–最好的情况是客户和开发人员在同一个房间中工作。如果确实无法和客户在一起工作，那么就去寻找能够在一起工作、愿意并能够代替真正客户的人。客户和程序员是极限编程的主要角色，两者之间高效的沟通是核心。第二章极限编程实践•2.1.2用户故事•用户故事—像日志的形式记录系统需求，写在索引卡上，它是由客户编制，并由客户决定故事的优先级。–为了进行项目计划，必须要知道和项目需求有关的内容，但是却无须知道得太多。对于做计划而言，了解需求只需要做到能够估算它的程度就足够了。–需求的特定细节很可能会随实践而改变。因此，在离真正实现需求还很早的时候就去捕获该需求的特定细节，很可能会导致做无用功以及对需求不成熟的关注。用户故事•以下是一个用户故事的样例：•运行处理退款请求故事（优先级：高技术风险：低）•估算：开发时间2周•2.1获得某时间段银行的退款明细0.5天•2.2分页显示某时间段银行的退款明细列表，提供选择退款记录2.5天•2.3运行处理退款2天用户故事第二章极限编程实践•2.1.3短交付周期–XP项目2~3周交付一次可以工作的软件。每两周的迭代都实现了客户的一些需求，在每次迭代结束时，会给客户演示迭代生成的系统，以得到他们及时的反馈。–迭代计划：每次迭代通常耗时2~3周。迭代是一次较小的交付，可能会被加入到产品中，也可能不会。客户根据开发人员确定的预算，选择一些用户故事组成迭代计划。第二章极限编程实践–发布计划：XP团队通常会创建一个计划来规划随后大约6次迭代的内容。•一次发布通常需要3个月的工作。它表示了一次较大的交付，通常此次交付会被加入到产品中。•发布计划是由一组客户根据开发人员给出的预算所选择的、排好优先级别的用户故事组成。•发布计划不是一成不变的，客户可以随时改变计划的内容，他可以取消用户素材，编写新的用户素材，或者改变用户素材的优先级别。但是客户应该更改后面迭代的内容，尽量不要更改下一次迭代。第二章极限编程实践•2.1.4验收测试•在极限编程中，验收测试是由客户编写的，单元测试是由程序员编写的。–验收测试使用能够让它们自动并且反复运行的某种脚本语言编写，这些测试共同来验证系统按照客户指定的行为运转。–验收测试常常要通过系统的外部接口（如键盘输入等用户接口）的运行，有时候甚至要使用一些专门的工具，使系统的行为具有对用户的可视性。第二章极限编程实践•2.1.5结对编程—不会降低编程效率，反而会大大减少缺陷率–是指两个程序员使用同一台电脑共同完成同一编程工作，包括：设计、算法、编码和测试。结对人员中的一位控制键盘并输入代码，另一位观察输入的代码并寻找着代码中的错误和可以改进的地方。–结对的关系每天至少改变一次，以便于每个程序员在一天中可以在两个不同的结对中工作。在一个迭代期间，每个团队成员应该和所有其他的团队成员在一起工作过，并且他们应该参与了本次迭代中所涉及的每项工作。这样可以促进知识在团队中的传播。第二章极限编程实践•2.1.6测试驱动开发(Test-DrivenDevelopment)•要求程序员对完成的每段代码都要编写相应的自动化单元测试用例。先编写单元测试，再编写代码，程序员可以并行处理。–编写所有产品代码的目的都是为了使失败的单元测试能够通过。–编写测试用例和代码之间的更迭速度是很快的，基本上在几分钟左右。–这样的方式非常利于重构，也可以激发程序员去解除各个模块之间的耦合，这样能够独立地对它们进行测试。测试驱动开发结对和简单设计常见问题和解答测试编码重构集成或者丢弃测试驱动开发•1、快速加入一条单元测试用例来指定一条将要编写的功能。•2、运行所有测试用例包括步骤1的新增测试用例，并目睹用例的失败结果，因为对应的代码还没编写。•3、编写代码或修改代码使其通过新的测试•4、运行所有的代码并确认他们完全通过。•5、重构或者删除重复的代码。•测试工具：XUnit、Jester第二章极限编程实践•2.1.7集体所有–是指代码的任何部分都不是某个人单独拥有和维护的，任何人在任何时候都有权对源代码做出修改，以增加新的功能、除错或进行重构。–任何人都可以多从事自己擅长的一方面，但是不会被限制在自己的专业领域内。–若有一个主程序员负责工作，但他离开时就可能引起一系列问题，而集体所有能很好的解决这个矛盾，使开发具有更高的稳定度。第二章极限编程实践•2.1.8持续集成•持续集成最大的好处是减少风险，找出问题。–XP团队每天会进行多次系统构建，他们会重新创建整个系统。–集成时要采用系统最终结果发布的形式—CD或Web。–程序员的模块在签入/集成前必须保证模块已经通过所有测试。第二章极限编程实践•2.1.9可持续的开发速度–软件项目不是全速短跑，而是马拉松长跑。–XP团队必须要以一种可持续的速度前进，必须要有意识地保持稳定、适中的速度。–XP的规则是不允许团队加班工作。在版本发布前的一个星期是该规则的惟一例外------如果发布目标就在眼前并且可以一蹴而就，则允许加班。第二章极限编程实践•2.1.10开放的工作空间–开放的房间：桌子/椅子面对面，墙上挂满了各种图表；–人和人之间的距离必须足够近，能够互相听到对方的谈话。–密歇根大学的一项研究表明，在“充满积极讨论的屋子（warroom）”里工作，生产率非但不会降低，反而会成倍地提高。第二章极限编程实践•2.1.11简单设计–XP团队使他们的设计尽可能地简单、具有表现力（expressive）。此外，他们仅仅关注于计划在本次迭代中要完成的用户素材。他们不会考虑那些未来的用户素材。这意味着XP团队的工作可能不会从基础结构开始，只有当出现一个用户素材迫切需要基础结构时，他们才会引入该基础结构。第二章极限编程实践•2.1.12重构重构是XP的一个重要组成部分。所谓重构是指在不改变代码外在行为的前提下对代码做出的修改，以改进代码的内部结构。重构是一种有纪律的、经过训练的、有条不紊的代码整理方法，可以将整理过程中不小心引入错误的可能性降到最低。从本质上说，重构就是在代码写好之后改进它的设计。重构的节奏：重新推理、小的更改、重新推理、小的更改、重新推理重构重构例子：代码更易读，更易于维护第二章极限编程实践•2.1.13隐喻–隐喻（metaphore）是所有XP实践中最难理解的一个。隐喻通常可以归结为一个名字系统，这些名字提供了一个系统组成元素的词汇表，并且有助于定义他们之间的关系。–简单说，是所有的项目参与人员都必须对相关的抽象概念有统一的、具体的认识。–在实际操作中，选择恰当的隐喻并对其推广是不容易的。隐喻的方法体现了极限编程的简单、沟通和反馈。敏捷软件开发敏捷开发介绍敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。敏捷开发由几种轻量级的软件开发方法组成。包括：极限编程（XP），Scrum，精益开发（LeanDevelopment），动态系统开发方法（DSDM），特征驱动开发（FeatureDriverDevelopment）等等。敏捷开发敏捷软件开发是一个开发软件的管理新模式，用来替代以文档驱动开发的瀑布开发模式。2001年2月，17名编程大师分别代表极限编程、Scrum、特征驱动开发、动态系统开发方法、自适应软件开发、水晶方法、实用编程等开发流派，发表敏捷宣言。•“个体和交互胜于过程和工具”•“可以工作的软件胜于详尽的文档”•“客户协作胜于合同谈判”•“响应变化胜于遵循计划”敏捷开发介绍-scrumScrum是一个敏捷开发框架假如把工程实践看做一块糖果，那么Scrum就是糖果的包装纸。Scrum把已有的基础和工程实践封装起来。它可以被运用于软件开发，项目维护，也可以被用来作为一种管理敏捷项目的框架。Scrum被知名企业广泛采用：•微软、雅虎、谷歌、诺基亚Scrum引入：Scrum在橄榄球中叫争球，是一个8人团队。Scrum以一个紧密整合的单位来协作，每个队员都扮演一个定义明确的角色，并且在进展中完成自己所担负的任务。整个团队有一个单一的焦点，工作优先权也是清楚的。我们希望