XP基础课程.ppt

Extreme Programming,XP基础课程,内容概要 为什么需要XP 敏捷过程是软工发展的必然及最新成果 重要概念 12个重要惯例和规则 XP的实施过程 总结,前言,Software development fails to deliver; and fails to deliver value. This failure has huge economic and human impact. We need to find a new way to develop software. - Kent Beck,5, Copyright 2002 Chinaxp. All rights reserved,我们为什么需要XP,6,我们为什么需要XP, Copyright 2002 Chinaxp. All rights reserved,7,我们为什么需要XP,公司： 1) 培养团队合作精神，稳定开发队伍； 2) 提高开发人员的水平； 3) 提高项目成功率，降低开发成本。 项目经理： 1) 更好地和用户沟通，更清晰地理解用户需求； 2) 更充分地使用资源，更科学地调配资源，更精确地掌握开发进度。 Team Lead和Architect： 1) 设计更加完善； 2) 更有效地更新知识，得到其他成员更多的尊重。 程序员： 1) 学习系统设计和项目管理； 2) 提高学习和工作效率，受到重视，减少加班时间。, Copyright 2002 Chinaxp. All rights reserved,8,Fortune 500 公司中成功应用XP的公司包括Ford，Daimler-Chrysler，First Union National Bank，IBM，HP等等。 2-10人的小规模开发队伍（小规模开发队伍 小规模项目）。 越来越多的公司开始使用敏捷开发过程，或者将其与RUP等开发过程结合使用。,谁在用XP, Copyright 2002 Chinaxp. All rights reserved,9,什么是XP Kent Beck 1996,XP is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing requirements. - Kent Beck. XP是勇气，交流，反馈和简单。 XP是软件开发过程中的纪律，它规定你：必须在编程前些测试，必须两个人一起编程，必须遵守编程规范。 XP是把最好的实践经验提取出来，形成了一个崭新的开发方法。, Copyright 2002 Chinaxp. All rights reserved,Agile Process,软件工程发展的必然 软件工程的最新成果 www.chinaxp.org,11,软件生命期, Copyright 2002 Chinaxp. All rights reserved,12,软件工程中的第一个模型,Waterfall模型 Royce 1970, Copyright 2002 Chinaxp. All rights reserved,13,有反馈的Waterfall模型, Copyright 2002 Chinaxp. All rights reserved,14,V 模型（另一种改良）, Copyright 2002 Chinaxp. All rights reserved,15,优点 文档驱动的开发模型。 改良后的模型很注重反馈和测试，其中V模型提出了测试驱动开发的概念。 在需求非常明确的前提下可以使用，也适用于有长期专职开发人员的小型项目开发。 不足： 严格限定了开发的各阶段，缺乏迭代性。 缺乏对变化的支持。, Copyright 2002 Chinaxp. All rights reserved,16,原型法 Brooks 1975, Copyright 2002 Chinaxp. All rights reserved,17,目的是和用户一起开发并完善一个原型，从最清楚的需求部分开始。,进化原型法, Copyright 2002 Chinaxp. All rights reserved,18,快速原型法,Build 1,Build 2,Build 3,（也称为 Throw-it-away）,目的是理解需求，从不清楚的需求部分开始。, Copyright 2002 Chinaxp. All rights reserved,19,优点： 需求驱动的开发模型。 帮助理解需求。 增强和用户的交流，增加用户好感。 不足： 缺乏结构化的系统和严谨的开发流程，很难作为一个项目进行管理。, Copyright 2002 Chinaxp. All rights reserved,20,作为一种开发模式有很多局限，但“重用” 的思想越来越普及。,面向重用的开发模式, Copyright 2002 Chinaxp. All rights reserved,21, Copyright 2002 Chinaxp. All rights reserved,螺旋式开发模型 Boehm 1988,22,优点： 风险驱动的开发模型。 灵活。可以根据风险的处理情况选择需要的阶段（Loop）， 因而演变为Waterfall、进化原型等模型。 各阶段都有评估和风险分析，可根据变化调整项目实施过程。 适用于复杂的、风险大的项目。 不足： 需要非常专业的风险评估技术。 需要非常丰富的项目经验。, Copyright 2002 Chinaxp. All rights reserved,23,增量型（例RUP）, Copyright 2002 Chinaxp. All rights reserved,24,优点： 开发过程分解为多个迭代过程，每个过程可以有自己的开发模型。 可以快速提交可用的系统，然后根据反馈实施下一个迭代。 不足： 是一个开发框架，对每个迭代的具体过程缺乏支持： 1）如果迭代太少，很容易会蜕变为Code-Fix模式，迭代太多则往往因文档驱动而导致测试和集成的复杂度和费用太大。 2）因而无法克服以往开发模型的不足。经常蜕变成Waterfall模型。, Copyright 2002 Chinaxp. All rights reserved,25,软工革命 Agile Process,程序员进行的是有创造性的脑力活动 以人为本 Open Source的启示 更好的Code Review和测试 对设计过程的重新思考 传统设计的缺陷 编程中的设计和编程外的设计 开发过程应该更多地面向代码而不是文档 轻量级 增量开发的趋势 迭代越来越频繁 新方法有Crystal，Scrum，XP等 XP结合“纪律性”和“适配性”，发展得最好, Copyright 2002 Chinaxp. All rights reserved,26,Principles of Agile Processes,最高目标是能持续地、及早地向客户交付软件； 拥抱变化； 频繁地发布可运行的软件； 客户和开发人员在一起工作； 以人为本； 最重要的衡量开发过程的手段，是可工作的软件； 稳定的开发速度； 敏捷高效的设计； 简单有效； 重视Teamwork； 积极的调整。 http:/www.agilemanifesto.org/principles.html, Copyright 2002 Chinaxp. All rights reserved,27,XP的增量过程, Copyright 2002 Chinaxp. All rights reserved,XP中的重要概念 哲学观 管理 需求 设计,www.chinaxp.org,29,哲学观（Philosophy）,交流(Communication),勇气(Courage),简单(Simplicity),反馈(Feedback), Copyright 2002 Chinaxp. All rights reserved,30,管理,发布(Release)：每一期开发结束时提交给用户的一个可运行的系统。 迭代(Iteration)：一期开发过程中的一个开发周期。它有明确的目标，计划和实现方式，它包含了需求分析、设计、编程、测试等完整的开发过程。一个迭代的长度为1到3 周。在一期开发过程中，所有迭代的长度是相同的，比如都是3周。 小发布(Small Release)：处于开发中的系统，每集成一个新功能，都可以称为一个小发布。 理想开发时间：估计完成一项工作所需的持续工作时间，不考虑意外因素。, Copyright 2002 Chinaxp. All rights reserved,31,需求,SPIKE：对不确定的需求和设计等，通过写一些程序、进行详细设计或者演算等等方式做探测和尝试，以确定可行性。这些探测过程称为SPIKE。 User Story：是对用户的一个需求的一段简洁清晰的描述，该段描述有三个属性，即商业优先级、开发时间和风险。从某个角度看，XP过程是面向User Story的。 故事卡：用户把User Story的内容和属性写在一张卡片上，该卡片即故事卡。 例，MSDN中的例子Island Hopper News： (1) 客户浏览分类广告；(2) 客户发布分类广告；, Copyright 2002 Chinaxp. All rights reserved,32,设计,1. CRC： Class Responsibility Collaboration。1989年， Kent Beck和Ward Cunningham提出的OO分析和设计方法，现在得到了广泛应用。 Responsibility：Class的行为。 Collaboration： Class之间的相互联系和作用；Collaborator指和某行为(Responsibility)相关的Class。 可以在卡正面加上父类名，子类名；可以在卡背后加上属性。, Copyright 2002 Chinaxp. All rights reserved,33,设计,2. Engineering Task：Team一起分析设计一个User Story，把该Story要完成的事情分解，就形成了一些任务(Engineering Tasks)。这些任务要足够小，以至于每个程序员都非常清楚要做什么，并能估计出完成该任务所需要的理想开发天。 每个程序员挑选了一个Task后，就成为该Task的Owner，并估计完成该Task所需的理想开发天数。 Task的粒度由理想开发天限制，大于1天且小于3天。 从某个角度看，程序员的工作安排是面向Task的。 3. Task卡：Task的内容、Owner和理想开发天都记录在一张Task卡上。 例： 上个例子中每个CRC卡可以做为一个单独的任务被承担和估计。, Copyright 2002 Chinaxp. All rights reserved,XP的惯例和规则,www.chinaxp.org,35,十二条惯例和规则,On-Site Customer （现场客户） 计划项目 （Planning Game） 频繁地小规模发布软件 （Small Releases） 简单设计 （Simple Design） 测试驱动开发 （Test Driven Development） 持续集成 （Continuous Integration）,集体拥有代码 （Collective Code Ownership） 编程规范 （Coding Standards） 重构 （Refactoring） System Metaphor （系统隐喻） Pair Programming （结对编程） 平稳的工作效率 （Sustainable Pace）, Copyright 2002 Chinaxp. All rights reserved,36,On-Site Customer,客户是Team成员，在开发现场和开发人员一起工作。 传统的客户任务一般是讲解需求，运行验收测试，接收发布的系统。XP新增加的任务： (1) 写User Story (2) 评估User Story的商业优先级 (3) 为每个User Story定义验收测试 (4) 计划开发内容 (5) 调控开发过程 Any More?, Copyright 2002 Chinaxp. All rights reserved,37,On-Site Customer,建立商业模型，把隐藏在客户需求下的原则传授给开发人员： 程序员理解的是表象，而不是本质； 程序员分担任务的过程支解了对他们商业模型的理解； 某些开发外包或分阶段开发(例如增量、迭代等)导致“知识泄露”。 参加设计过程： 和程序员一起找出Metaphor，导引设计方向： 在Metaphor的帮助下，定义更有效更实际的功能测试，给程序员的设计制定了规范； CRC卡鼓励客户更多地参加设计过程。, Copyright 2002 Chinaxp. All rights reserved,38,System Metaphor,“The system metaphor is a story that everyone - customers, programmers, and managers - can tell about how the system works.” Kent Beck Team将Domain/Sub-Domain Model，Design/Sub-Design Model以及一些关键概念等等抽象化为比喻。通过这些比喻，加强客户和程序员之间的相互理解，消化积累知识，指导设计开发的方向。 例： Market 发布/浏览，价格洽谈，生成和履行合同； String，Tree，Package，Chartroom，Spider，Robot ； 电影后期制作 邮递 电影院播放电影。, Copyright 2002 Chinaxp. All rights reserved,39,System Metaphor,Metaphor的形成过程，是客户建立并抽象商业模型和商业概念的过程，是程序员建立并抽象设计模型和设计概念的过程。 Metaphor使客户和程序员用共通的模型和语言进行交流 “One Team, one language”。 Metaphor可以帮助减少“知识泄露”和“支解知识”。 Metaphor是设计过程的航标 真正灵活有效的设计是针对商业原则的设计，而不是针对商业原则表现形式的设计，更不是脱离商业需求目的的学术设计。 随着开发的继续，Team会找到更好的Metaphor。这是知识细化、深化的结果，是“持续学习”(Continuous learning)的过程；是对商业模型和设计模型的持续重构。, Copyright 2002 Chinaxp. All rights reserved,40,计划项目, Copyright 2002 Chinaxp. All rights reserved,41,测试驱动开发,（在第二天的课程将详细阐述）, Copyright 2002 Chinaxp. All rights reserved,42,重构,减少重复设计，优化设计结构，提高技术上的重用性和可扩展性。 在Metaphor指引下的重构，是为商业模型服务的。不要把重构变成不断的盲目精简代码。 重构和编程前的计划型设计(Planned Design)结合，使XP的简单设计可行有效。 XP提倡毫不留情的重构(Refactor mercilessly)。 任何人可以重构任何代码，前提是重构后的代码一定要通过100%测试单元测试后才能被Check-in。 可以根据需要，将一个迭代的全部目标定为重构。 不要太在意什么是最简单的设计 愿意在最后重构，比知道如何做简单的设计重要得多。,（在第三天的课程将详细阐述）, Copyright 2002 Chinaxp. All rights reserved,43,简单设计 XP中的演进设计（Evolutionary-design）,如果没有它和众多惯例规则之间的耦合，XP的演化设计就蜕化成CODE-FIX。 XP的演化设计是在Up-front design和Refactoring之间找到新的平衡。, Copyright 2002 Chinaxp. All rights reserved,44,简单设计 简单可行，不要增加现阶段不需要的复杂功能。,简单设计 Do the simplest thing that could possibly work；You arent going to need it(YAGNI)。 标准(依重要性)：通过所有测试，可读性高的代码，避免重复，最少数量的类别或方法。 System Metaphor给设计提供了指引，加强Team对设计的理解； 第一个迭代搭建了基本的系统框架。 以后的迭代过程，是在反馈和编程的基础上做交互式设计，减少了设计的投机性。 迭代过程中的CRC卡帮助Team交流设计思想，简化了设计文档。 重构对设计进行优化。, Copyright 2002 Chinaxp. All rights reserved,45,编程规范,规定了程序的风格，包括注释如何写，变量命名的规范，代码的格式等等。 Teamwork 的前提之一，其它众多惯例和规则(如Pair Programming， Collective Code Ownership等)的前提之一。, Copyright 2002 Chinaxp. All rights reserved,46,集体拥有代码,“我们”的代码，而不是“我”的代码。 任何人可以改动任何一段代码，但改动后的代码必须通过所有相关的测试。 简单设计，编程规范和Pair Programming，使阅读和修改Team内其他人的代码变得实际可行。, Copyright 2002 Chinaxp. All rights reserved,47,Pair Programming,两个程序员使用同一台电脑共同开发。XP的必须组成部分，XP中最有争议的规则之一。,（在第二天的课程将详细阐述）, Copyright 2002 Chinaxp. All rights reserved,48,持续集成,测试先行是持续集成的一个重要前提。 持续集成指不断地把完成的功能模块整合在一起。目的在于不断获得客户反馈以及尽早发现BUG。 随时整合，越频繁越好；集成及测试过程的自动化程度越高越好。 每次只有一个PAIR在整合，而且必须运行功能测试。, Copyright 2002 Chinaxp. All rights reserved,49,频繁地小规模发布软件,发布过程应该尽可能地自动化、规范化。 不断地发布可用的系统可以告诉客户你在做正确的事情。 客户使用发布的系统，可以保证频繁地反馈和交流。 保证客户有足够的依据调控开发过程(增加、删除或改变User Story)。 降低开发风险。 随着开发的推进，发布越来越频繁。 所有的发布都要经过功能测试。, Copyright 2002 Chinaxp. All rights reserved,50,平稳的工作效率,平稳的工作效率指Team和个人在很长的时期内保持一定的开发效率。 保证了项目速度和计划过程的有效性和准确性； 保证了程序员可以持续地完成任务，Team可以持续地向客户交付可运行的系统(见敏捷开发宣言)； 加班多导致开发效率和质量下降，简洁增加了开发成本； Pair Programming已经加大了工作强度，并且和其它XP的规则一起提高了工作效率，使少加班和维持平稳的工作效率可能而且可行。 提倡平稳的工作效率，体现了XP以人为本的价值观。, Copyright 2002 Chinaxp. All rights reserved,XP过程,www.chinaxp.org,52,Team,Product Manager/Project manager Coach Team lead Developers Tracker QA (On-Site) Customers, Copyright 2002 Chinaxp. All rights reserved,53,环境,既有无隔墙隔板的工作场地，也又单独的工作间； 一个足够宽敞的地方供大家开会； 足够大的白板； 足够长的电脑桌，可以让两个人并排坐在同一台电脑前面； 每一个人都能很容易地看到其他人并和他们交流。 一些白纸或者卡片。 更理想的条件： POP 电视机 Video Game 落地玻璃窗, Copyright 2002 Chinaxp. All rights reserved,54,开发, Copyright 2002 Chinaxp. All rights reserved,总结,www.chinaxp.org,56,EXTREME的来由,if the code review is good, well review code all the time (pair programming). if testing is good, everybody will test all the time (unit testing ) even the customer (functional test). if design is good, we'll make it part of everybody's daily business (refactoring). if simplicity is good, we'll always leave the system with the simplest design that supports its current functionalities (simple design). if architecture is important, everybody will work defining and refining the architecture all the time (metaphor). if integration testing is important, then we'll integrate and test several times a day (continuous integration). if short iterations are good, we'll make the iterations really really short- seconds and minutes and hours, not weeks and months and years (planning game)., Copyright 2002 Chinaxp. All rights reserved,57,惯例和规则,频繁的反馈 测试驱动开发 计划项目 On-site Customer Pair Programming 共同理解交流 简单设计 System Metaphor 集体拥有代码 编程规范,持续的增量开发 持续集成 重构 频繁地小发布 以人为本 稳定的工作效率, Copyright 2002 Chinaxp. All rights reserved,58,交流,有交流过度的项目吗？, Copyright 2002 Chinaxp. All rights reserved,59,反馈,反馈就是抱怨？, Copyright 2002 Chinaxp. All rights reserved,60,勇气, Copyright 2002 Chinaxp. All rights reserved,61,简单, Copyright 2002 Chinaxp. All rights reserved,62,XP ON-SITE Everything is public！,宽敞明亮舒适的工作场地。 巨幅的表格挂在墙上，每个人都能马上知道项目的进展情况。 所有的DESIGN都是公开展示的。 巨幅的Story卡挂在墙上，客户正在给程序员们解释需求。 一些程序员正在对墙上贴的TASK卡进行讨论。 一些程序员正在用用CRC卡和客户一起设计一个Story。 不断地见到有人在讨论交流，没有人是独自躲在角落里静悄悄地写程序。 , Copyright 2002 Chinaxp. All rights reserved,63,怎么开始XP,在项目开发中尝试一些规则？裁减成“我的XP”?全面采用？我们的建议是： 设计和项目管理经验不足： 先在一些小的，或者风险低的，或者比较有把握的项目中运用。跟踪观察，逐步熟悉。对公司管理过程中的相关部分进行调整。再运用到更复杂的项目中去。 有比较丰富的经验： 全面使用，但是在开始几个月应该严格遵循XP的规定，熟练之后再做调整。 购买我们的服务。, Copyright 2002 Chinaxp. All rights reserved,XP中级课程,www.chinaxp.org,XP项目管理,www.chinaxp.org,66,项目速度 （Project Velocity）,假设有6个程序员。,1、项目速度：一个迭代（Iteration）完成的理想开发周（Ideal week）。 例：一个开发小组在一个迭代里能完成10个理想开发周的工作，那么项目开发速度就是10。这个10周的工作可能包括一个3周的User Story、两个2周的User Story和三个1周的User Story。 2、开发速度的设定依据“yesterdays weather”的原则。第一个迭代的速度可以按照“程序员数 X 1”计算。, Copyright 2002 Chinaxp. All rights reserved,67,项目速度 （Project Velocity）,个人承担任务时，估计该任务的理想开发天。 第一个迭代中，个人可以按照5个理想开发天的总数来承担任务。例：1个2天的任务，3个1天的任务。 个人承担的任务量按照“Yesterdays Weather”原则计算。,某程序员的开发速度, Copyright 2002 Chinaxp. All rights reserved,68,计划项目 一、探索阶段（Exploration Phase）,所有的内容写在卡片上。 估计的时间是指：按照平均的技术水平，一个人开发该User Story的理想时间。 用数字1、2、3表示商业价值的高低级别。 用数字1、2、3表示开发风险的高低级别。 开发风险是针对具体技术和整体设计。 评估开发风险时，卡片的移动次序是由高向低的。, Copyright 2002 Chinaxp. All rights reserved,69,计划项目 二、计划阶段（Planning Phase）, Copyright 2002 Chinaxp. All rights reserved,70,计划项目 三、调整阶段（Steering Phase）,Q：在某个迭代中一些User Story的实际开发时间和理想开发时间不同，在下一个迭代开始前是否应该重新评估每个User Story的理想开发时间？ A：不是重新评估，而是调整开发速度（升高/降低）。同理，程序员在每此进行Iteration Plan时会增加或者减少承担的Task数目。 Q：正在开发时如果增加一个User Story，评估时要注意什么？ A：不要故意将理想开发时间评估低（因为这个迭代实际开发速度太高，下个迭代任务就会增多），否则会破坏计划过程。 Q：开发速度下降了怎么办？ A：Coach要找到速度下降的原因，速度下降可能是项目失败的先兆。, Copyright 2002 Chinaxp. All rights reserved,71,Pair Programming,迭代计划会议结束后，每个Task的Owner会寻找一个Partner进行Pair开发。 Task开发的次序由程序员们自己协商。一个程序员不能同时担当Owner和Partner的角色，他(她)可以先作为Partner和其他Owner一起开发某个Task，然后再找另一个程序员作为Partner来共同开发自己承担的Task。, Copyright 2002 Chinaxp. All rights reserved,72,程序员的一天, Copyright 2002 Chinaxp. All rights reserved,73,风险管理,需求阶段：SPIKE和Story的风险评估。 计划过程：发布计划和迭代计划中，根据需求变化进行相应调整。 设计过程：简单设计避免Over-Engineering。 开发过程： 1) 设计驱动的开发过程； 2) Pair Programming； 3) 持续集成； 4) 频繁的小发布。, Copyright 2002 Chinaxp. All rights reserved,剖析XP的重要概念,www.chinaxp.org,75,术语表： 客户： 分类广告： ,补充说明： 可用性： 可靠性： 可维护性： ,User Story 和 Use Case 的区别,Presentation Requirement Mock-up Window , Copyright 2002 Chinaxp. All rights reserved,76,User Story 和 Use Case 的区别, Copyright 2002 Chinaxp. All rights reserved,77,System Metaphor,开发过程中可能会形成很多Metaphor。第一个Metaphor是在Exploration阶段形成的 在完成User Story和Spike之后，Team通过“诸葛亮会”抽象商域模型。 同一个概念或模型，可能有多个Metaphor从不同角度理解。 Metaphor虽然提供了不精确的描述，但留下了扩展和思考的空间。 最差的Metaphor是平铺直叙的描述(Naïve Metaphor)；Metaphor不是图（例如Use Case Diagram，Activity Diagram，类图等等）。 Metaphor提供了开发过程中命名的Context，好的Metaphor有时可以作为顶级类名。 如果Metaphor在开发过程中变得毫无用处，或者对Metaphor的理解出现很大差异，Team应该检讨需求和设计。 最后最好的Metaphor表达了艰苦获得的知识，可以作为文档保留下来。, Copyright 2002 Chinaxp. All rights reserved,78,XP的Anti-Patterns,“有些规则好像不适用，比如Pair Programming，可以去掉。XP是灵活的。” XP的灵活是建立在所有的惯例和规则上的。 “简单设计，还没做到那里，就不要想那个需求的实现细节。” 不要忘了XP的Spike是什么。 “时间太紧了，别写测试了。” 测试只会帮你节省时间。 “重构就是让不断地压缩code。” 最后没有人知道怎么改那些code。 “要简单，想那些Metaphor太复杂了。” XP的价值观不仅仅是简单。 “我们的XP项目不用Metaphor也能成功。” XP是个不断练习的过程，你需要逐步增加建模和交流的能力。 “别问我，我不知道。我现在很忙，你去问他。” XP的交流反对这种拒绝。 “我们用的是XP，不需要天才，而且任何人走都没关系。” 成功的XP项目非常吸引程序员，让他们充分发挥自己的潜力；而不是把他们变成编程机器。 , Copyright 2002 Chinaxp. All rights reserved,XP过程,www.chinaxp.org,80,XP过程,1、准备开发环境。 2、Exploration Phase 程序员和用户一起把需求分解为User Story，用户写Story卡。 用户把在Story卡上标上商业优先级(1，2，3)。 程序员看卡片，估计所需要的理想开发周，把估计的时间写在Story卡上(1，2，3) 。 (3.1) 由一个Senior估计时间。 (3.2) 如果估计不出来，做Spike。 (3.2) 如果时间大于三周，分解Story，撕掉旧Story卡，写下新的Story卡。回到(3)，重新估计。 (3.3) 由一个Junior估计时间。衡量二者的差异，取平均值。 (3.3) 如果时间大于三周，回到(3.2)。 (3.4) 如果时间小于一周，尝试和其它Story合并。合并后，撕掉原来的Story卡，写下新的Story卡。 程序员看卡片，估计开发风险。把风险级别写在Story卡上(1，2，3) 。 (4.1) 程序员将所有卡片放在一起，然后阅读。如果认为风险低，就放在第二堆，否则不移动。 (4.2) 程序员阅读第二堆卡片。如果认为风险低，就放在第三堆，否则不移动。 (4.2) 对三堆卡片分别标记。, Copyright 2002 Chinaxp. All rights reserved,81,XP过程,3、Release Plan 确定该Release中Iteration的长度(例如3周)。计算，开发总时间/迭代长度 = 迭代数。 计算可完成的开发量，告诉客户。 (2.1) 根据经验，估计程序员的平均开发速度(例每个Iteration完成1个理想周)。 (2.2) 计算，平均开发速度 x 程序员数 x 迭代数 = 可完成的工作量。 客户挑选Story卡，累计这些卡片上的估计开发时间，不要超过宣布的可完成工作量。挑选的原则为商业价值优先。 把要完成的Story卡贴在墙上或白板上，要让所有的人都能容易地，清楚地看到。 整个Team，包括客户，在一起做快速设计，并想出Metaphor。, Copyright 2002 Chinaxp. All rights reserved,82,XP过程,4、Iteration Plan (1) Tracker宣布该Iteration的计划速度。 (1.1) 如果是第一个Iteration，则计划速度 = 程序员数 x 1。 (1.2) 否则，计划速度 = 上一个Iteration实际完成的理想开发周数目。 (2) Team挑选要实现的Story，累计这些Story卡上的估计开发时间，不要超过计划速度。客户挑选商业价值最高的User Story，商业价值相同时挑选开发风险最高的。 (3) 客户宣读并解释User Story卡。 (4) Team用CRC卡或者其它方式设计该Story，并将其分解成Engineering Task，记录在Task卡上。 (5) Tracker宣布各程序员在该Iteration的计划速度。 (5.1) 如果是第一个Iteration，则计划速度 = 5 理想开发天。 (5.2) 否则，计划速度 = 上一个Iteration实际完成的理想开发天数目。 (6) 每个程序员挑选一个Task，并估计所需要的理想开发天。如果大于三天就分解Task，小于1天就和其它的Task合并。 (7) 把天数和程序员的名字写在Task卡上。 (8) 每个程序员重复(6)的过程，直至所有Task的理想开发天的总和等于自己的计划速度。 (9) 留下的Task卡可以放在一个Iterati