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