Extreme Programming
什么是极限编程
什么是极限编程?BrokenDoor(xpchina) 2003年09月15日极限编程(eXtreme Programming)是一种开发纪律，以简单性、交流、反馈和勇气为基本宗旨。
它的做法是以有效的实践规则将整个团队紧密联系起来，通过充分的反馈使团队能随时知道自己目前的状况和恰当的调节规则以适应自己的特殊情况。
在极限编程中，每一个项目贡献者都是“团队”完整的一部分。
这个队伍是围绕着一个每天和队伍坐在一起共同工作的商业代表——“客户”建立起来的。
核心实践：整体团队极限编程的队伍采用一种简单的方式来进行规划和跟踪，以决定下一步要做什么和预知项目什么时候会完成。
聚焦于商业价值，团队通过一系列的通过了客户定义的测试和完全集成的小的发布来创作软件系统。
核心实践：规划策略，小发行版，客户测试极限编程者通过成对和小组的方式共同工作，通过简单设计和强制测试的代码，不断的提升设计以保证设计总是适合当前的需求。
核心实践：简单设计，成对编程，测试优先开发，设计改进极限编程队伍会总是保持系统能够集成并且在所有的时间运行。
程序员以成对的方式编写所有的产品代码，并且在所有时间内都共同工作。
他们以相似的形式编码以保证所有成员都可以按需要理解和改进所有的代码。
核心实践：持续集成，集体代码所有权，编码标准极限编程队伍分享一个公共并且简单的系统蓝图。
所有成员可以按照一种不时保持同步的节奏进行工作。
核心实践：系统比喻，可接受的步伐核心实践团队整体一个XP项目的所有参与者都作为一个团队的成员坐在一起。
这个团队必须包括一个业务的代表——“客户”，他提供需求，设置优先度，并掌管整个项目的方向。
最好这个客户或者他的助手是一个最终用户，了解该领域，知道什么是所需要的。
团队当然还要有程序员。
团队可能会包含测试员，他帮助客户定义客户验收测试。
分析员可以作为客户的助手，帮助客户定义需求。
通常还会有一个指导,他帮助整个团队跟踪、推动开发进程。
也可能会有一个管理者，他提供资源、处理对外交流和分工协作。
ACP敏捷项目管理考试真题解析（七）
ACP敏捷项目管理考试真题解析（七）一、题目51、Karen is reviewing a value stream map that she and her agile team just created. The team is debating whether it should reduce a lead time by 90% or increase a process time by 20%. Which of the previous two actions would you suggest her team take?A.Increase process time by 20%B.Reduce lead time by 90%C.BothD.Neither. Both represent adding more waste into the value stream凯伦正在查看她们团队刚创建的一份价值流程图。
团队正在讨论是否应该减少 90%前置期，或者增加 20%流程时间。
在此，你建议团队A.增加20%流程时间B.减少90%前置期C.两者都进行D.两者都不进行，因为两者都为价值流增加更多浪费52 、 If you were shown a diagram of an existing system and the diagram had process steps, information flow, lead times, and process times, what type of diagram would you believe it to be?A.Current-state value stream mapB.Value stream analysisC.Future-state value stream mapD.Waste stream map如果你看到一份图表，里面包括流程步骤，信息流，前置期和流程时间，那么这份图表可能是A.当前价值流程图B.价值流分析C.未来价值流程图D.浪费流图53 、Jill and Stephanie are reviewing a large chart that visually depicts the flow of information from origin to customer. On the chart are times indication the duration of value-added processes and non value-added processes. What are Jill and Stephanie reviewing?A.A muda stream mapB.A kaizen stream mapC.A lean stream mapD.A value stream map吉尔和斯蒂芬妮正在查看一份大型图表，当中直观地向客户描述了信息流，也包含了价值增加流程的持续时长以及非价值增加流程的持续时长这两者的时间要求。
浅谈极限编程
浅谈极限编程1.什么是极限编程 极限编程外⽂名叫做：ExtremePrograming, 简称XP,由KentBeck在1996年提出的，是⼀种软件⼯程⽅法学，是敏捷开发中可能是最富有成效的⼏种⽅法学之⼀。
（PS：敏捷开发是以⽤户的需求进化为核⼼，采⽤迭代，循序渐进的⽅法进⾏软件开发。
）极限编程和传统⽅法学的本质不同于在于他更强调可适应性，及⾯对困难的随机应变能⼒。
当然，极限编程也有⾃⾝的缺点，并不是所有的软件开发过程都能采⽤极限编程。
本⽂主要讲述极限编程的优点。
2.为什么会出现极限编程。
在传统的软件⼯程过程中，⽅法⽂档量过于“沉重”繁琐，因此，⼈们必然要寻找相对⽽⾔轻量级的⽅法论。
但在当时敏捷⽅法论还并未出现，⼈们对轻量级的⽅法论的观念仅存在于”主观臆断“的阶段，认为⼀个完善的软件必然需要绝对完善的前期准备⼯作。
思想是对的，但是实际的开发过程并不很令⼈满意。
基于这⼀点，1993年到1999年⽤⼀种极限编程的思想诞⽣于Kent团队的⼀个项⽬中。
随后2001年2⽉11号到13号，⼀个划时代联盟，敏捷联盟成⽴。
在软件⼯程界最有影响⼒的⾮营利性组织之⼀。
3.极限编程包含什么内容。
①价值观沟通（Communication） 软件⼯程开发过程基本都是⼀个团队⼯作，极限编程⾮常强调团队之间进⾏采⽤合适的⽅式进⾏⾯对⾯的交流，⽐如有⼀块⽩板，或者其他能表达想法的绘画⼯具。
简单（Simplicity） 软件开发⼈员有时会”眼⾼⼿低“，在做需求⼯程时没有做到位，在coding的过程中想要为系统设置过于多的功能，造成⾮常复杂的局⾯，以⾄于导致后期软件交付时客户的反感，维护费⽤的⾼昂，甚⾄项⽬报废的局⾯。
因此设计的时候不要天马⾏空，仅仅设计满⾜你的需求的功能即可。
反馈（FeedBack） 通过不断的反馈，你的团队可以知道并修复软件存在的问题，不断地调整你们团队最终的产品。
勇⽓（Courage） 这⾥说的勇⽓是团队中每⼀个成员，在软件开发的过程中会遇到各种各样的问题，我们应该有勇⽓去根据⾃⼰的判断去解决⾯临的问题，⽐如我们要有勇⽓提出管理层的不⾜，我们要有勇⽓去停⽌我们觉得是是错误的开发等。
什么是Extreme Programming(极限编程,简称XP)
什么是Extreme Programming（极限编程，简称XP）Extreme Programming（极限编程，简称XP）是由Kent Beck在1996年提出的。
Kent Beck在九十年代初期与Ward Cunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有效。
Kent仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。
1996年三月，Kent终于在为DaimlerChrysler 所做的一个项目中引入了新的软件开发观念——XP。
XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。
它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。
XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
什么是软件开发软件开发的内容是：需求、设计、编程和测试！需求：不仅仅是用户需求，应该是开发中遇到的所有的需求。
比如，你首先要知道做这个项目是为了解决什么问题；测试案例中应该输入什么数据……为了清楚地知道这些需求，你经常要和客户、项目经理等交流。
设计：编码前，肯定有个计划告诉你要做什么，结构是怎样等等。
你一定要按照这个来做，否则可能会一团糟。
编程：如果在项目截止日，你的程序不能跑起来或达不到客户的要求，你就拿不到钱。
测试：目的是让你知道，什么时候算是完成了。
如果你聪明，你就应该先写测试，这样可以及时知道你是否真地完成了。
否则，你经常会不知道，到底有哪些功能是真正完成了，离预期目标还差多远。
软件开发中，客户和开发人员都有自己的基本权利和义务。
客户：•定义每个用户需求的商业优先级；•制订总体计划，包括用多少投资、经过多长时间、达到什么目的；•在项目开发过程中的每个工作周，都能让投资获得最大的收益；•通过重复运行你所指定的功能测试，准确地掌握项目进展情况；•能随时改变需求、功能或优先级，同时避免昂贵的再投资；能够根据各种变化及时调整项目计划；•能够随时取消项目；项目取消时，以前的开发工作不是一堆垃圾，已开发完的功能是合乎要求的，正在进行或未完成的的工作则应该是不难接手的。
极限编程
的特征
的特征
极限编程方法的基本特征是：
相关概念
软件开发过程 权利和义务
开发人员 其他问题
软件开发过程
软件开发的过程是：需求分析、设计、编码和测试。 需求分析：不仅仅是用户需求，应该是开发中遇到的所有的需求。比如，你首先要知道做这个项目是为了解 决什么问题；测试案例中应该输入什么数据……为了清楚地知道这些需求，你经常要和客户、项目经理等交流。 设计：编码前，肯定有个计划告诉你要做什么，结构是怎样等等。你一定要按照这个来做，否则可能会一团 糟。 编码：如果在项目截止日，你的程序不能跑起来或达不到客户的要求，你就拿不到钱。 测试：目的是让你知道，什么时候算是完成了。否则，你经常会不知道，到底有哪些功能是真正完成了，离预期目标还差多远。
极限编程技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法。它的目标是向 所有开发人员提供一个对于系统的共享的视角，而这一视角又是与系统的最终用户的视角相吻合的。为了达到这 一目标，极限编程支持设计、抽象、还有用户-程序员间交流的简单化，鼓励经常性的口头交流与回馈。
简单
极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不 同之处在于，它只于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。极限编 程的拥护者承认这样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。 然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点，因为将来的需求在他们还没提 出之前是很可能发生变化的。为了将来不确定的需求进行设计以及编码意味着在一些可能并不需要的方面浪费资 源。而与之前提到的“交流”这一价值相关联来看，设计与代码上的简化可以提高交流的质量。一个由简单的编 码实现的简单的设计可以更加容易得被小组中的每个程序员所理解。
XP的极限编程简介
XP的极限编程简介敏捷⽅法论有⼀个共同的特点，那就是都将⽭头指向了“⽂档”，它们认为传统的软件⼯程⽅法⽂档量太“重”了，称为“重量级”⽅法，⽽相应的敏捷⽅法则是“轻量级”⽅法。
正是因为“轻量级”感觉没有什么⼒量，不但不能够有效体现灵活性，反⽽显得是不解决问题的⽅法论似的。
因此，就有了⼀次划时代的会议，创建了敏捷联盟。
在敏捷⽅法论领域中，⽐较知名的、有影响⼒的，是拥有与Microsoft的操作系统相同缩写语——XP的极限编程（eXtreme Programming）。
极限编程⽅法论可以说是敏捷联盟中最鲜艳的⼀⾯旗帜，也是被研究、尝试、应⽤、赞扬、批判最多的⼀种⽅法论，也是相对来说最成熟的⼀种。
这⼀被誉为“⿊客⽂化”的⽅法论的雏形最初形成于1996—1999年间，Kent Beck、Ward Cunninggham、Ron Jeffrey在开发C3项⽬（Chrysler Comprehensive Compensation）的实践中总结出了XP的基本元素。
在此之后，Kent Beck和他的⼀些好朋友们⼀起在实践中完善提⾼，终于形成了极限编程⽅法论。
解析极限编程那么什么是XP呢？XP是⼀种轻量（敏捷）、⾼效、低风险、柔性、可预测、科学⽽且充满乐趣的软件开发⽅式。
与其他⽅法论相⽐，其最⼤的不同在于：在更短的周期内，更早地提供具体、持续的反馈信息。
在迭代的进⾏计划编制，⾸先在最开始迅速⽣成⼀个总体计划，然后在整个项⽬开发过程中不断的发展它。
依赖于⾃动测试程序来监控开发进度，并及早地捕获缺陷。
依赖于⼝头交流、测试和源程序进⾏沟通。
倡导持续的演化式设计。
依赖于开发团队内部的紧密协作。
尽可能达到程序员短期利益和项⽬长期利益的平衡。
Kent Beck曾经说过“开车”就是⼀个XP的范例，即使看上去进⾏得很顺利，也不要把视线从公路上移开，因为路况的变化，将使得你必须随时做出⼀些这样那样的调整。
⽽在软件项⽬中，客户就是司机，他们也没有办法确切地知道软件应该做什么，因此程序员就需要向客户提供⽅向盘，并且告知我们现在的位置。
极限编程XP
不采用瀑布式的软件工程方法，而采用原型法。 在软件设计中，强调简单性，就是坚决不作用不到的通用
功能。 在专业分工中，提出在开发团队中要有全职的客户人员的
参与，同时在软件团队中也要有自己的领域专家。 在软件开发的顺序上，和传统方法完全相反。传统方法是
按照整体设计、编写代码、进行测试、交付客户的方法。 而XP是按照交付客户、测试、编码、设计的顺序来开发。 在项目计划的实现上，每次的计划都是技术人员对客户提 出时间表，由最后的开发人员对项目经理提出编码的时间 表。 在分工上，强调角色轮换，项目的集体负责，分工的自愿 性。
谢谢观看！
沟通(Communication) 简单(Simplicity)
反馈(Feedback) 勇气(Courage)
规划策略（The Planning Game） 结对编程（Pair programming） 测试（Testing） 重构（Refactoring） 简单设计（Simple Design） 代码集体所有权（Collective Code Ownership） 持续集成（Continuous Integration） 现场客户（On-site Customer） 小型发布（Small Release） 每周40小时工作制（40-hour Week） 编码规范（Code Standards） 系统隐喻（System Metaphor）
XP适用范围
XP不适用的领域
XP适合规模小、进度紧、需求变 中大型的项目（项目团队超过10
化大、质量要求严的项目。
人）；
它希望以最高的效率和质量来解 决用户目前的问题，以最大的灵 活性和最小的 代价来满足用户 未来的需求，XP在平衡短期和长 期利益之间做了巧妙的选择。
重构会导致大量开销的应用；
《极限编程》课件
优势
快速反馈
灵活应对变化
极限编程强调通过频繁的评审和修改来快 速获取反馈，有助于及时发现问题并进行 调整。
极限编程鼓励拥抱变化，能够快速适应需 求变更，减少因需求变动带来的损失。
简化开发过程
提高团队沟通
极限编程提倡简单的设计和开发原则，降 低复杂度，提高开发效率。
极限编程注重团队之间的沟通与协作，有 助于提高团队的凝聚力和工作效率。
设计游戏的玩法和机制，确保 游戏具有吸引力和可玩性。
游戏资源规划
合理分配游戏开发资源，确保 游戏开发的顺利进行。
简单设计
01
设计原则
以简单、清晰的设计实现游戏功能 和用户体验。
游戏界面设计
设计游戏的用户界面，包括菜单、 界面布局和交互方式等。
03
02
游戏架构设计
设计游戏的整体架构，包括游戏系 统、模块和数据结构等。
它遵循一系列原则，如“一 次只做一件事”、“先写测 试后写代码”和“及时重构
”。
这些原则旨在帮助开发团队更 好地应对变化，提高软件质量 ，并促进团队成员之间的协作
和信任。
02 极限编程的实践
需求管理
需求管理原则
明确、可测试、可跟踪的需求是项目成功的 关键。
需求获取
通过与客户的沟通，了解他们的需求和期望 。
挑战
技术风险
由于追求快速迭代和变化，可能导致技术债务的积累，影响软件质量。
人力资源
对团队成员的技能和经验要求较高，需要具备快速学习和适应变化的能力。
需求稳定性
频繁的需求变更可能影响开发进度和稳定性，对项目管理带来挑战。
过度优化
在追求简化开发过程和快速反馈时，可能导致过度优化和过早优化的问题。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
– Developers often find it frustrating, impersonal, and heavyweight.
• Processes are inflexible. • Progress is at glacial speeds. • Most of the “interesting” decisions are made up front, and typically not by them.
CS246
Extreme Programming
4
Extreme programming (XP)
• … is relatively new, lightweight methodology for developing software.
– Aimed at systems with changing requirements or high risk. – OO, iterative development, prototyping, fast change, high customer involvement, …
Trad. waterfall-like process model
Requirements engineering Design and implementation
Testing
Deployment Deployment Maintenance and evolution
CS246
Extreme Programming
CS246 Extreme Programming 12
XP: Planning
• A release plan is created at a special meeting
– Developers estimate time to implement each story
• >3 weeks means you need to break up the story
CS246 Extreme Programming 8
The Customer’s Bill of Rights
You have the right:
• … to an overall plan, to know what can be accomplished, when, and at what cost. • … to see progress in a running system, proven to work by passing repeatable tests that you specify. • … to change your mind, to substitute functionality, and to change priorities • … to be informed of schedule changes, in time to choose how to reduce scope to restore the original date. You can even cancel at any time and be left with a useful working system reflecting investment to date.
CS246 Extreme Programming 9
The XP process model
Test scenarios
User stories
Requirements New user story Bugs
Acceptance tests
Latest version
Customer approval
• Due to requirements change or refactoring.
CS246
Extreme Programming
7
The Developer Bill of Rights
You have the right:
• … to know what is needed, via clear requirements, with clear declarations of priority. • … to say how long each requirement will take you to implement, and to revise estimates given experience. • … to accept your responsibilities instead of having them assigned to you. • … to produce quality work at all times. • … to peace, fun, and productive and enjoyable work.
CS246 Extreme Programming 10
Rules and practices of XP
• Planning • Design • Coding • Testing
CS246 Extreme Programming 11
XP: Planning
• User stories are written
• A lightweight methodology is:
– Adaptive rather than predictive
• JIT planning, design, etc. • Can deal with changing requirements
– People oriented rather than process oriented
• Developers like it better • … but you need able people
CS246 Extreme Programming 5
Extreme programming
• Originated by Kent Beck in mid-1990s
– Many others involved (Cunningham, Fowler, …) – History: Smalltalk, Chrysler C3 project, patterns mafia, RAD
• It is just possible that XP has been slightly over-hyped relative to its concrete results ☺ • This XP has nothing to do with Redmond, Washington ☺
Disclaimer: I am not an expert in this.
CS246
Extreme Programming
6
The four principles of XP
1.
–
Communication
High interaction between developers and with customer.
2.
– –
Feedback
Test before you code, test again when you change. Talk to customer.
– Similar to, but not the same as, use cases
• In practice, use cases often centred around UI
– User stories are not nearly that detailed. – In XP, detail comes later, from live customers on demand.
3.
–
Simplicity
Look for the simple, essential abstraction … but never do more than actually required.
4.
– –
Courage
Be willing and able to turn on a dime. Embrace aggressive change.
Extreme Programming
University of Waterloo
Overview
• What is XP? Why is XP?
• Four principles and two bills of rights • XP process model: Planning, Design, Coding, Testing • Summary and references
2
Trad. waterfall-like process model
• Made up of several distinct stages
– Assumption is that work on one stage is completed before going on to the next.
– Doesn’t deal well with change/evolution
• … both during initial development and after deployment. • After development, the documents (and other non-source code artifacts) are almost always out of date, wrong, poorly maintained, … wrt the source code.
• Short (~3 sentences), written by customer, no jargon • Typically, this is the only “formal” requirements document!