类似于use cases但不一样用于估计release planning meeting的时间替代详细的用户需求规格说明书替代详细的用户需求规格说明书由用户书写, 类似于用户“场景” , 但不局限于界面的描述没有技术术语能够成为验收测试的依据 Release planning通过召开 release planning meeting 来制订一份发布计划发布计划详细描述用户所要求的各版本要求这为后面的迭代计划打基础要求, 这为后面的迭代计划打基础 small releases经常向客户发布系统的迭代版本在release planning meeting上确定哪些功能单元对用户业务有重要影响并可在早期加入到系统中在早期加入到系统中越晚向用户介绍系统的重要特征, 开发队伍所获得的“搞定” 系统的时间就越短。 Project Velocity项目周转时间是衡量项目工作进度速度的值。“负载因子” 近期被引进用于项目周期的测量的测量 Iterations迭代式开发增加了开发过程的敏捷性将总体进度划分为一系列长度为1-3周的小的迭代过程. 迭代周期固定且一致, 成为项目的“心跳”为项目的“心跳”。 Iteration planning在每个迭代的开始召集迭代计划会议,明确本次迭代任务每次迭代1-3周长由用户在 User stories中确定最有价值的特征作为本次迭代的目标上次迭代时没通过验收测试的特征应当加入本次迭代 Move people around让所有人多掌握技能, 避免知识孤岛和开发瓶颈交叉培训, “结对编程”并非一个人掌握所有的代码并非一个人掌握所有的代码, 而是要每个人掌握大多数的代码, 所需要的人员可以随时被指派到最需要的地方, 实现人员的“负载平衡”每次迭代每个人试图做系统新的部分,Pair programming 能够保证这种形式而是要每 stand-up meeting目标: 在整个开发组(而非个别开发人员) 中进行沟通每天早上一次站立会议, 主要沟通问题、方案以集中小组注意力方案, 以集中小组注意力避免了策划会议的时间daily stand up meeting 不同于一般浪费时间的会议 Fix XP一旦破坏了XP流程, 就马上更正!可根据具体项目制定XP规则, 一旦制定就必须执行, 直到规则变更所有人员都明确知晓规则 DesigningSimplicity. Choose a system metaphor. Use CRC cards for design sessions. Create spike solutions to reduce risk. No functionality is added early. Refactor whenever and wherever possible. Simplicity is the Key决不增加没有列入到进度中的功能“简单化” 其实并不简单 system metaphor为系统选择一种metaphor使得开发小组能够为类及方法进行统一的命名. 命名方式易理解. CRC cardsClass, Responsibilities, and Collaboration (CRC)CRC cards的最大价值在于引导开发人员摆脱过程模型精确掌握OO技术摆脱过程模型, 精确掌握OO技术CRC Cards 允许所有的人参与设计, 参与的人越多, 就会有更多的好的主意引入 spike solutions 创建关键问题解决方案, 解决关键的技术和设计问题 大多数 spikes可能都不足以得到保持, 有可能被丢弃. 但制作SPIKE的目标降低技术风险;被丢弃. 但制作SPIKE的目标降低技术风险; 一旦技术困难对系统的开发造成了威胁, 立即派一对开发人员关注于该问题一至两周, 以降低潜在的风险 No functionality is added early切记不要实施你认为日后可能外特征可能有用的额只有10% 的额外特征会有用只关注目前进度中所要求的内容 Refactor whenever and wherever possible随时随地可以对已做过的事重新考虑毫不留情地将设计、 编码简单化, 简单得足够容易理解、 修改和扩展得足够容易理解、 修改和扩展所有的事只表达一次修饰得太好的系统往往到后期赶不上进度要求 Coding The customer is always available. Code must be written to agreed standards. Code the unit test first. All production code is pair programmed. All production code is pair programmed. Only one pair integrates code at a time. Integrate often. Use collective code ownership. Leave optimization till last. No overtime. The customer is always available随时能联系客户是XP方法的基本要求之一XP的所有阶段都要求客户的强参与最好有客户派员直接参与开发组把客户“吊住” , 并将客户由新手培养成为专家, 开发组需要专家 Code must be written to agreed standards所有代码必须采用统一标准以便理解Smalltalk projects :P ttPatternsSmalltalk Best Practice Code the unit test first创建单元测试能够帮助开发者清醒地意识到什么是真正需要的需求是由测试活动明确下来的 All production code is pair programmed 所有发布的代码都由两个程序员在一台机器上共同开发完成。 结对编程的最好方式是两人共同坐在显示器前, 将键盘和鼠同坐在显示器前, 将键盘和鼠标在两人之间“滑动” , 一人考虑所创建的方法(Method) ,而另一人同时考虑该方法如何在类中得到更好的体现。 适应结对编程需要时间, 必须度过开始面临的尴尬境况 Sequential Integration 每次加入一个模块做集成 Integrate often开发人员应不断地将代码集成到代码库中, 几小时一次, 绝不超过1天每个人需要在最后的版本上工作持续集成能够在早期避免或发现一些兼容性问题。 “现在付钱还是以后付更多的钱? ” Use collective code ownership“集体拥有代码” 鼓励每个人对项目的所有部分提出新想法任何开发人员都可改变任何代码以增加功能修改错误功能、 修改错误没有人会成为变更的瓶颈 Leave optimization till last在项目快结束之前不要去优化永远不要试图猜测系统的瓶颈在哪里,去度量它、 让系统动起来、 修正系统、去让系统变的更快!去让系统变的更快! No overtime.超时工作会吞噬开发组的精神和热情利用版本计划会来改变项目的范围和时间要求项目进度拖延时通过增加资源来改进也不是推荐的方法 Testing All code must have unit tests. All code must pass all unit tests before itcan be released. When a bug is found tests are created When a bug is found tests are created. Acceptance tests are run often and the scoreis published. All code must have unit tests 单元测试是XP方法中的小界石, 但与传统的单元测试略有不同 1、 要创建或下载一些单元测试工具以便能够自动生成测试数据 2、 测试系统中所有的类 3、 单元测试应与其所测试的代码一起发布 4、 没有单元测试的代码不能发布 5、 若发现没有进行单元测试, 则立即开始进行 All code must pass all unit testsbefore it can be released When a bug is found tests are created Acceptance tests are run often and the score is published验收测试来自user stories.每一次迭代时的迭代计划会都应选取适当的 user stories用于进行验收测试验收测试一种黑盒测试验收测试一种黑盒测试 , 客户负责确认验收测试的正确性, 并评审测试结果,以确定所发现问题的重要性产品发布之间的回归测试也是一种验收测试客户负责确认 The Third International Conference on eXtreme Programming and Agile Processes in Software Engineering, will be held May 26 29 2002 inwill be held May 26-29, 2002, in Alghero, Sardinia, Italy