第一讲-敏捷实践与极限编程概述

1、 广州大学华软软件学院软件工程系 主讲教师：谭翔纬 答疑时间：周三 10:30-12:00 周四 9:00-12:00 Tel：660028 Email： 第一讲： 敏捷实践与极限编程概述 目录目录 n敏捷实践概述敏捷实践概述 n理解敏捷宣言理解敏捷宣言 n迭代开发迭代开发 n极限编程概述极限编程概述 n极限编程实践极限编程实践 Page 3 业界敏捷浪潮 lISO 9000（09版）标准将在原来八大原则的基础上新增敏捷原则敏捷原则 l2000年美国军方软件开发标准（DOD 5000.2）推荐迭代迭代为软件开发优选模式为软件开发优选模式 l世界影响最大的美国波多里奇国家质量奖将敏捷敏捷作为核心

2、的十一大原则之一核心的十一大原则之一 Page 4 软件作坊软件作坊 软件过程控制软件过程控制 重型过程重型过程 2001今 敏捷正在流行敏捷正在流行 软件规模小，以作坊式开发为主； 硬件飞速发展，软件规模和复杂度激增， 引发软件危机； 引入成熟生产制造管理方法，以“过程为 中心”分阶段来控制软件开发（瀑布模 型），一定程度上缓解了软件危机； 软件失败的经验促使过程被不断增加约束 和限制，软件开发过程日益“重型化”， 开发效率降低、响应速度变慢； 随着信息时代到来，需求变化更快，交付 周期成为企业核心竞争力，轻量级的，更 能适应变化的敏捷软件开发方法被普遍认 可并迅速流行。 软件危机软件危机

3、20世纪60年代 80年代 90年代 软件开发顺应时代变化，从重型过程转向轻量型敏捷软件开发顺应时代变化，从重型过程转向轻量型敏捷 70年代 敏捷诞生的历史背景 Page 5 敏捷宣言揭示更好的软件开发方法 l敏捷宣言（敏捷宣言（ 20012001年）是敏捷起源的基础，由上述年）是敏捷起源的基础，由上述4 4个简单的价值观组成，敏捷宣言的签署推动了敏捷运动个简单的价值观组成，敏捷宣言的签署推动了敏捷运动 l敏捷宣言本质是揭示一种更好的软件开发方式，启迪人们重新思考软件开发中的价值和如何更好的工作敏捷宣言本质是揭示一种更好的软件开发方式，启迪人们重新思考软件开发中的价值和如何更好的工作 敏捷宣言

4、敏捷宣言 Page 6 l软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长 l敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品 传统开发传统开发 敏捷开发敏捷开发 敏捷更符合软件开发规律 Page 7 敏捷对生产率、质量、满意度、成本有明显改进 82%的项目生产率有提高的项目生产率有提高78%的项目质量有提高的项目质量有提高 78%的项目客户满意度有提高的项目客户满意度有提高37%

5、的项目成本有降低的项目成本有降低 * 以上数据来自DDJ 2008由Scott Ambler发起的网上调查结果 Page 8 对敏捷的常见误解 误解一：误解一： 敏捷开发意味着可以不需要文档、设计和计划敏捷开发意味着可以不需要文档、设计和计划 误解二：误解二： 敏捷只是一些优秀实践，或者是优秀实践的结合敏捷只是一些优秀实践，或者是优秀实践的结合 误解三：误解三： 敏捷只适用于小项目开发敏捷只适用于小项目开发 误解四：误解四： 敏捷只会对研发产生改变敏捷只会对研发产生改变 误解五：误解五： 管理者不需要亲自了解敏捷，只需要管理上支持就可以了管理者不需要亲自了解敏捷，只需要管理上支持就可以了 误解

6、六：误解六： 引入敏捷只需要按照既定的步骤去做就可以了引入敏捷只需要按照既定的步骤去做就可以了 误解七：误解七： 敏捷是敏捷是CMM的替代品，是另一种流程的替代品，是另一种流程 误解八：误解八： 敏捷只注重特性的快速交付，在敏捷下架构不重要了敏捷只注重特性的快速交付，在敏捷下架构不重要了 Page 9 统一认识：敏捷=理念+优秀实践+具体应用 理念（敏捷核心思想） 敏捷包括3 3个层次 优秀实践（敏捷的经验积累） 具体应用（能够结合自身灵活应用才是真正敏捷） 理念理念 优秀实践优秀实践 具体应用具体应用 Page 10 理念：聚焦客户价值(Value)(Value)，消除浪费 软件业：软件业：

7、45%的软件特性客户没有使用的软件特性客户没有使用 Source：Standish Group 来自5万个软件开发项目的调查 Source：中国电信总工韦乐平 Source：如何提升软件开发效率08年统计 电信业：电信业：“电信级电信级”带来的浪费带来的浪费 “价值价值”在在“敏捷宣言敏捷宣言”中的体现中的体现 产品商业成功为目标，聚焦客户价值、围绕价值流消除浪费产品商业成功为目标，聚焦客户价值、围绕价值流消除浪费 我司：研发版本废弃特性我司：研发版本废弃特性 l07.1-08.6年某产品线所有产品中重要特性无应用 的比例达22%（需求变更和分析不足占63%） 个体和交互个体和交互胜过胜过 过

8、程和工具过程和工具 可以工作的可以工作的 软件软件 胜过胜过 面面俱到的文面面俱到的文 档档 客户合作客户合作胜过胜过合同谈判合同谈判 响应变化响应变化胜过胜过遵循计划遵循计划 Page 11 理念：激发团队(Team)(Team)潜能，加强协作 l团队是价值的真正创造者，应加强团队协作、激发团队潜能团队是价值的真正创造者，应加强团队协作、激发团队潜能 l软件开发是一种团队活动，首先应做到提升沟通效率降低交流成本软件开发是一种团队活动，首先应做到提升沟通效率降低交流成本 强调个体与交互的项目试点，效率质量改善明显强调个体与交互的项目试点，效率质量改善明显 Source: 08年测试行业超过30

9、个项目试点 Source：经济学家2003& DeMarco 研究报告 “团队团队”在在“敏捷宣言敏捷宣言”中的体现中的体现 个体和交互个体和交互胜过胜过 过程和工具过程和工具 可以工作的可以工作的 软件软件 胜过胜过 面面俱到的文面面俱到的文 档档 客户合作客户合作胜过胜过合同谈判合同谈判 响应变化响应变化胜过胜过遵循计划遵循计划 效 率 流行度 文档 录制的视 频 录制 的音频 2人 邮件沟通 2人 白板沟通 2人 电话沟通 不支持问答形式 支持问答形式 研究表明面对面的沟通最有效研究表明面对面的沟通最有效 业界调查：一个50人开发团队，每人平均30%时 间用于编码，70%的时间用于与其他

10、成员交流。 研究表明1981年来自不同公司的优秀程序员生 产率之比是7:1，而2007年最新的研究数据，则 是40:1。 人是软件开发的决定因素人是软件开发的决定因素 需求变更降 低比例 补充场景数TR4前发现 缺陷比例 版本周期缩 短（周数） 无线49.36%8855.90%2.82 核心网45%19045.18%3.5 网络31%33042.5%2.6 业软30%30048.15%2.1 公司平均38.84%90847.93%2.76 Page 12 理念：不断调整以适应(Adapting)变化 麦当劳是简单可预测生产过程麦当劳是简单可预测生产过程 l人月神话：软件开发是人类最复 杂工作之

11、一，软件具有四个属性：复 杂性、一致性、可变性和不可见性。 l软件开发是不可重复、探索性的、演 进的，适应性过程。 随软件规模增长，需求变化呈非线性增长随软件规模增长，需求变化呈非线性增长软件开发是复杂不可预测的经验控制过程软件开发是复杂不可预测的经验控制过程 “适应变化适应变化”在在“敏捷宣言敏捷宣言”中的体现中的体现 不断的根据经验调整，最终交付达到业务目标的产品不断的根据经验调整，最终交付达到业务目标的产品 软件开发规律再审视软件开发规律再审视 个体和交互个体和交互胜过胜过 过程和工具过程和工具 可以工作的可以工作的 软件软件 胜过胜过 面面俱到的文面面俱到的文 档档 客户合作客户合作胜

12、过胜过合同谈判合同谈判 响应变化响应变化胜过胜过遵循计划遵循计划 Page 13 具体应用：因地制宜选择适合的敏捷实践 团队在透彻理解敏捷理念的基础上，可以灵活选择最适合自己的实践，避免教条化团队在透彻理解敏捷理念的基础上，可以灵活选择最适合自己的实践，避免教条化 开发团队一 站立 会议 排序的工 作列表 持续 集成 持续 集成 重构 持续 集成 结对 编程 迭代 开发 + 迭代 开发+ + + + + 开发团队三 敏捷理念敏捷理念 开发团队二 敏捷理念敏捷理念 敏捷理念敏捷理念 Page 14 深入理解敏捷理念 l 深入理解深入理解“适应变化适应变化” p认请“客户是逐步发现真正需求” p小

13、批量是快速交付的关键 p通过迭代计划不断调整以适应需求变化 p应持续保持良好的软件架构 p利用多层次反馈不断调整以逼近目标 l 深入理解深入理解“激发团队激发团队” p认清团队的基本事实 p敏捷方式下管理者的转变 p敏捷方式下团队成员的转变 l 深入理解深入理解“聚焦客户价值聚焦客户价值” p标识和消除软件开发中的浪费 p交付刚刚好的系统 p随时构建质量，不容忍缺陷 p及时消除技术债务，持续保持快速响应 Page 15 浪费类别浪费类别浪费举例浪费举例 1部分完成的工作部分完成的工作部分完成但没有最终落地的工作（没有转化成代码的设计文档；未及时合入的代码 导致引发后续更多同步工作量）。 2未应

14、用特性未应用特性开发完成但没有被客户应用的特性（2000多个功能客户只用了1%）。 3再次学习再次学习人员频繁流动导致经验不能积累，反复重新学习；在多个环节移交时，接收信息者 也需要重新学习；拥有某领域的专家，但在开发过程中需要此领域经验时，他却没 参与，而是团队重新摸索。 4移交移交知识信息的传递总是伴随信息丢失，隐形知识尤其困难，分工过细往往导致过多不 必要的移交（如详细设计和实现分离，造成大量设计信息丢失）。 5任务切换任务切换研究表明多任务工作会导致效率下降20%-40%（员工多头工作或杂事繁多）。 6延迟延迟因任务或资源相互依赖而导致工作停滞（集成时被关键模块阻塞，等待测试环境就 绪

15、）。 7缺陷缺陷解决缺陷活动本身就是浪费，而且缺陷越遗留到后端浪费越大。 聚焦客户价值，标识和消除软件开发中的浪费 Source：精益软件开发 Page 16 l当质量、进度、资源冲突时，能改变的只有项目范围，即选择当质量、进度、资源冲突时，能改变的只有项目范围，即选择“交付刚刚好的系统交付刚刚好的系统” p产品交付前，客户往往期望多而全的功能，产品交付后，客户把稳定的质量放在首位，尤其在 电信领域，客户对产品质量要求是Always work，不是Sometimes。 p与其为了满足多而全的功能导致交付延迟，质量不稳定，不如按时交付刚刚好的系统，保证其 高质量运行。 p交付刚刚好的系统，基于对

16、客户需求的深入理解，并花时间了解细节，简化（simplify）需求 （降低复杂性）而不是简单地拒绝需求（delete）。 p做到“交付刚刚好的系统”，同时需要管理者有足够的勇气和果断决策 聚焦客户价值，交付刚刚好的系统 l在项目明显超负荷时，管理者简单地期望靠团队在项目明显超负荷时，管理者简单地期望靠团队 work harder来解决，最终导致来解决，最终导致： p质量下降 p项目延期 p客户不满意 p团队疲劳 p埋下长期隐患 Page 17 l缺陷遗留带来高额成本：缺陷遗留带来高额成本： p对单独质量保证活动（如后端测试）的依赖，容易形成缺陷可以遗留到下个阶 段的心理，导致缺陷发现成本升高（

17、系统测试阶段缺陷定位和解决成本是开发阶段 的10倍） 例：某公司开发阶段和测试阶段发现缺陷的比例为7：3，而大量缺陷集中在 后端发现，带来高额成本。 聚焦客户价值，随时构建质量，不容忍缺陷 l 从项目一开始就随时构建质量：从项目一开始就随时构建质量： p形成零缺陷文化，不要容忍缺陷 ：发现缺陷应立即停下来解决，以保 证在坚实的质量基础上前行。 p开发和测试紧密协作：测试人员 参与到设计和开发过程中，共同预防 缺陷的产生。 例如：持续集成暴露的问题需立即解决 Page 18 聚焦客户价值，及时消除技术债务，持续保持 快速响应 技术 商务 l为什么会有技术债务：为什么会有技术债务： p为满足短期商

18、业目标，不影响其外部表现的情 况下，会在技术方面进行一定的让步，这种让步虽 对当前版本的质量影响甚微，但会严重影响后续版 本响应客户需求的能力，从而形成技术债务。 时间 技术债务 开发速率 l对待技术债务的态度：对待技术债务的态度： p技术债务是有成本的，如不及时偿还，会随时间 积累利息变高，导致开发效率大幅下降，从而降低 客户响应能力。因此对待技术债务的态度是加以管 理并及时偿还（如及时重构）。 l常见技术债务常见技术债务: p日益腐烂的架构、圈复杂度高的代码、低的测试自动化率、不及时清除的静 态检查告警等。 Page 19 激发团队，认清团队的基本事实 Source: Jeff CSM T

19、raining material 信任是高绩效团队的基石信任是高绩效团队的基石 信任信任 承诺承诺 冲突冲突 创新创新 l关于团队激励：关于团队激励： p当团队自管理时效率最高 p人们对自己做出的承诺比别人要求的承诺更认真 p人们会尽力做到最好 p在强大的压力下努力工作，人们会自然而然地降 低对质量的要求 l关于团队绩效：关于团队绩效： p当团队成员不被打扰时，工作效率最高 p当团队解决自我问题时，提升最快 p广泛的、面对面的交流是团队工作最高效的方式 l关于团队构建：关于团队构建： p团队生产率大于相同数目的个体生产率之和 p当不同技能领域的人员组成团队并聚焦于工作 时，产品更健壮 Page

20、 20 激发团队，敏捷方式下管理者的转变 管理者努力“控制” 团队： l制定详细的工作计划，并做出详细 的工作安排 l指令性工作方式 l监控过程 l基于复杂规则的管理 管理者努力“激发”团队： l通过目标来牵引团队自主工作 l帮助团队提供资源，排除障碍 l营造团队自我管理的工作氛围 l作为教练辅导团队进步 l基于简单原则的管理，原则简单但必 须被遵守 敏捷方式下对管理者最大的挑战是学会放松敏捷方式下对管理者最大的挑战是学会放松”控制控制”(loose control) 传统方式敏捷方式 Page 21 激发团队，敏捷方式下团队成员的转变 团队成员是“听从安排的独立贡献听从安排的独立贡献 者者”

21、: l被动等待主管下指令安排工作 l独立工作为主，协作少 l以文档和邮件为主要沟通方式 l只关注个体任务“做完”，不关注 团队目标 l能力相对单一，学习动力不足 敏捷方式的管理者 从被动到主动的心态转变是团队成员适应敏捷开发的关键从被动到主动的心态转变是团队成员适应敏捷开发的关键 团队成员是“全方位的积极参与者全方位的积极参与者”: l共同参与计划制定和任务安排 l团队协作贯穿工作始终 l面对面交流是主要沟通方式 l关注团队目标，共担责任 l能力要求更广，主动学习适应岗位 要求 传统方式敏捷方式 Page 22 l期望客户一开始就想清楚他们真正期望客户一开始就想清楚他们真正 要的东西是不现实的

22、。要的东西是不现实的。 l我们应当通过不断的向客户交付可我们应当通过不断的向客户交付可 用的产品，启发客户逐步的发现真用的产品，启发客户逐步的发现真 正的需求。正的需求。 残酷现实残酷现实 n客户是逐步发现他真正要的东西 n开发人员逐步发现如何开发产品满 足客户需求 n在这个过程中随时可能发生变化 美好愿望美好愿望 n客户知道自己要的是什么 n开发人员知道如何开发来满足客户 需求 n在开发过程中需求不会发生变化 我们认识到 预期需求 实际需求 价值 时间 适应变化，认清“客户是逐步发现真正需求” Page 23 适应变化，小批量是快速交付的关键 l我们首先要做的是通过尽早地、持续地交付有价值的

23、软件来使客户满意。 l经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 摘自敏捷软件的十二个原则 l在需求响应周期相同的情况下，批量 （一次开发的需求量）越小，资源利用 率更高。 l在资源利用率相同的情况下，批量越小， 交付周期更短。 l减小批量不仅带来缩短交付周期，而且还带来提 高质量、促进创新、降低管理成本、更高的效率 等其他好处，大幅提升商业价值。 减少批量的好处 资源利用率 交付周期 大批量 中批量 小批量 Source：Craig Larman 减小批量减小批量 1.减少排队 3.缩短交付 周期 2.加快反馈 4.增强质量5.改善创新 6.降低管

24、理 成本 7.更高的效 率 $ 排队理论：小批量与缩短交付周期、人员 有效产出的关系 适应变化，通过迭代计划不断调整以适应需求变化 Page 24 正确做计划方法正确做计划方法 在每一轮迭代开始，只详细确定本次迭代 的工作内容，并严格执行，对后续较远的 迭代内容只做粗略的计划，避免浪费。 项目范围常发生变化项目范围常发生变化 l需求出现了增加、删除、优先级调整（如图E、 O、P、J） l工作量在需求细化后发现离原始工作量估计 有偏差，引发计划调整；（如图中I） l客户使用了产品后，发现有些需求已不再需 要（如图中D、G） l变化无法一次性预测，一开始制作大而全的计划易造成浪费变化无法一次性预测

25、，一开始制作大而全的计划易造成浪费 l应根据迭代积累的经验和需求变化的情况对计划不断调整和细化应根据迭代积累的经验和需求变化的情况对计划不断调整和细化 A B C D E F G H I J K L M N A B C E E O O F P P H IJ J K L M N 预测计划 实际情况 A B C D E F G H A B C E O F G H I J A B P H I 正确迭代 计划 C E O F J K L l良好软件架构是适应变化的基石良好软件架构是适应变化的基石 p大型软件项目的特点是庞大、复杂、生命周期长，因此需要良好架构来保 证长期的演进，避免大规模的返工； p优

26、秀的架构通过可扩展性来很好地适应需求的变化，对敏捷起到支持作用， 相反拙劣的架构会阻碍敏捷； p良好架构使系统部件处于松耦合状态，有助于制定出合适的增量开发/集 成计划，使分层分级的持续集成更加容易实施。 l软件架构需要尽早验证和持续维护软件架构需要尽早验证和持续维护 p新产品开发通过早期迭代来实现和验证架构，有利于架构的尽早稳定； p增量开发需识别影响架构的需求，优先实现，规避架构风险； p通过重构及时维护和优化架构（偿还技术债务），使架构保持生命力。 Page 25 适应变化，应持续保持良好的软件架构 Page 26 适应变化，利用多层次反馈不断调整以逼近目标 结对编程 单元测试 持续集成

27、 站立会议/回顾会议 客户验收 对代码质量的反馈 对单元功能的反馈 对团队运作的反馈 对系统功能的反馈 对客户需求的反馈 l利用多层次反馈手段，在变化的环境中让团队准确地了解与目标的差距，不断调整利用多层次反馈手段，在变化的环境中让团队准确地了解与目标的差距，不断调整 自身行为，并逐步逼近靶心自身行为，并逐步逼近靶心 多层次反馈手段多层次反馈手段 Page 27 符合敏捷软件开发的12条原则 l我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满 意。 l欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏 捷过程掌控变化。 l经常地交付可工作的软件，相隔几星期或一两个月，

28、倾向于采取较短的 周期。 l业务人员和开发人员必须相互合作，项目中的每一天都不例外。 l激发个体的斗志，围绕被激励起来的个人构建项目，为他们提供所需的 环境和支援，辅以信任，从而达成目标。 l不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 Page 28 符合敏捷软件开发的12条原则 l可工作的软件是进度的首要度量标准。 l敏捷过程倡导可持续的开发速度。责任人、开发人员和用户应能够共同 维持一个长期的、恒定的开发速度。 l坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 l以简洁为本，是极力减少不必要工作量的一门艺术。 l最好的架构、需求和设计出自于自组织团队。 l团队定期

29、地反思如何能提高成效，并依此调整团队的举止表现。 Page 29 什么是迭代式开发什么是迭代式开发 l迭代开发将整个软件生命周期分成多个小的迭 代（一般2-4周），每一次迭代都由需求分析、 设计、实现和测试在内的多个活动组成，每一 次迭代都可以生成一个稳定和被验证过的软件 版本。 迭代式开发的好处迭代式开发的好处 l通过将高技术风险的需求在早期迭代里实现， 有助于尽早暴露问题和及时消除风险 l通过提供功能渐增的产品，持续从客户获得反 馈，根据反馈及时调整，使最终产品更加符合 客户的需要 l通过小批量减少排队，提供更灵活、快速的交 付能力 l平滑人力资源的使用，避免出现瓶颈 迭代式开发的关键要点

30、迭代式开发的关键要点 l每一次迭代都建立在稳定的质量基础上，并做 为下一轮迭代的基线，整个系统的功能随着迭 代稳定地增长和不断完善。 l每次迭代要邀请用户代表（外部或内部）验收 ，提供需求是否满足的反馈 l迭代推荐采用固定的周期（2-4周），迭代内 工作不能完成，应当缩减交付范围而不是延长 周期 敏捷软件开发核心迭代开发 迭代1迭代2迭代3 反馈反馈 迭代开发是有节奏地小步快跑，但建立在坚实的质量基础上迭代开发是有节奏地小步快跑，但建立在坚实的质量基础上 敏捷软件开发典型场景 Page 30 PO（product owner产品拥有者，即客户） 和开发团队对产品业务目标形成共识 PO建立和维护

31、产品需求列表（需求会不 断新增和改变）,并进行优先级排序 PO每轮迭代前，Review需求列表，并筛 选高优先级需求进入本轮迭代开发 开发团队细化本轮迭代需求，并按照需 求的优先级，依次在本轮迭代完成 开发团队每日站立会议、特性开发、持 续集成，使开发进度真正透明 PO对每轮迭代（24周）交付的可工作 软件进行现场验收和反馈 回到第3步，开始下一轮迭代 迭代 每日工作 站立 会议 特性开发 特性测试 持续集成 交付 可以工作 的软件 迭代计划 回顾 确定一个迭代 的工作内容 产品和利 益相关人 、 Page 31 极限编程概述 l历史历史 极限编程的创始者是肯特贝克、沃德坎宁安和罗 恩杰弗里斯

32、，他们在为克莱斯勒综合报酬系统 （Chrysler Comprehensive Compensation System）(C3) 的薪水册项目工作时提出了极限编程方法 ； p1999年10月发行极限编程解析 p(2005第二版出版) Kent Beck l什么是极限编程？什么是极限编程？ Extreme Programming（极限编程，简称XP）是由KentBeck在1996年提出的； XP是一个轻量级的、灵巧的软件开发方法 ，是敏捷方法中罪著名的一个； 强调程序设计师团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档 更有效）、频繁交付新的软体版本、紧凑而自我组织型的团队、能够很

33、好的适应需求 变化的代码编写和团队组织方法，也更注重做为软体开发中人的作用。 极限编程实践 l完整团队完整团队 p我们希望客户、管理者和开发人员紧密 地工作在一起，以便彼此知晓对方所面临 的问题，并共同去解决这些问题。 pXP团队中的客户是指定义产品的特性 并排列这些特性优先级的人或者团体。 p最好的情况是客户和开发人员在同一个房间中工作，次一点的情 况是客户和开发人员之间的距离在100米内。 p如果确实无法和客户在一起工作，那么就去寻找能够在一起工作、 愿意并能够代替真正客户的人。 极限编程实践 l用户故事用户故事 p为了进行项目计划，必须要知道和项目需求有关的内容，但是却无 须知道得太多。

34、对于做计划而言，了解需求只需要做到能够估算它 的程度就足够了。 p需求的特定细节很可能会随实践而改变。因此，在离真正实现需求 还很早的时候就去捕获该需求的特定细节，很可能会导致做无用功 以及对需求不成熟的关注。 p用户故事用户故事-就是正在进行的关于需 求谈话的助记符。它是一个计划工具， 客户可以使用它并根据它的优先级和 估算代价来安排实现该需求的实践。 极限编程实践 l 短交付周期短交付周期 XP项目每两周交付一次可以工作 的软件。每两周的迭代都实现了利 益相关者的一些需求，在每次迭代 结束时，会给利益相关者演示迭代生成的系统，以得到他们的反馈。 p迭代计划：迭代计划：每次迭代通常耗时两周。

35、迭代是一次较小的交付，可能 会被加入到产品中，也可能不会。它由客户根据开发人员确定的预 算而选择一些用户故事组成；一旦迭代开始，客户就统一不再修改 当次迭代中用户素材的定义和优先级别；迭代期间，开发人员可以 自由地将用户素材分解成为任务（task），并根据最具技术和商务 意义的顺序来开发这些任务。 极限编程实践 l短交付周期（续）短交付周期（续） p发布计划：发布计划：XP团队通常会创建一个计划来规划随后大约6次迭代的 内容。 n一次发布通常需要3个月的工作。它表示了一次较大的交付，通常此次交付会被 加入到产品中。 n发布计划是由一组客户根据开发人员给出的预算所选择的、排好优先级别的用 户故事

36、组成。 n发布计划不是一成不变的，客户可以随时改变计划的内容，他可以取消用户素 材，编写新的用户素材，或者改变用户素材的优先级别。但是客户应该更改后 面迭代的内容，尽量不要更改下一次迭代。 极限编程实践 l验收测试验收测试 p可以以客户指定的验收测试（Acceptance Tests）的形式来记录有 关用户故事的细节。用户故事的验收测试是在就要实现该用户故事 之前或实现该用户故事的同时进行编写的。 p验收测试使用能够让它们自动并且反复运行的某种脚本语言编写， 这些测试共同来验证系统按照客户指定的行为运转。 p验收测是由业务分析师、质量保证专家以及测试人员在迭代期间编 写的，这些测试成为真正的项

37、目需求文档 p一旦通过一项验收测试，那么就加入到已通过的验收测试集中，并 决不允许该测试再次失败。 极限编程实践 l结对编程结对编程不会降低编程效率，反而会大大减少缺陷率不会降低编程效率，反而会大大减少缺陷率 p所有产品（production）代码都是由结对的程序员使用同一台电脑 共同完成的。结对人员中的一位控制键盘并输入代码，另一位观察 输入的代码并寻找着代码中的错误和可以改进的地方。 p结对编程的代码是由两人共同设计、共同编写的，两人功劳均等。 p结对的关系每天至少改变一次，以便于每个程序员在一天中可以在 两个不同的结对中工作。在一个迭代期间，每个团队成员应该和所 有其他的团队成员在一起工

38、作过，并且他们应该参与 了本次迭代中所涉及的每项工作。 这样可以促进知识在团队中的传播。这样可以促进知识在团队中的传播。 专家专家”也需要与团队中的其他成员结对。也需要与团队中的其他成员结对。 极限编程实践 l测试驱动开发测试驱动开发 p编写所有产品代码的目的都是为了使失败的单元测试能够通过。首 先编写一个单元测试，由于它要测试的功能还不存在，因此它会运 行失败，然后，编写代码使测试通过。 p编写测试用例和代码之间的更迭速度是很快的，基本上在几分钟左 右。 p这样的方式非常利于重构。 p这样一种方式可以激发程序员去解除各个模块之间的耦合，这样能 够独立地对它们进行测试。面向对象设计的原则在进行

39、这种解除耦 合方面具有巨大的帮助作用。 极限编程实践 l集体所有集体所有 p结对编程中的每一对都具有签出（check out）任何模块并对它进 行改进的权力。 p没有程序员对任何一个特定的模块或技术单独负责，每个人都参与 GUI方面的工作；每个人都参与中间件方面的工作；每个人都参与 数据库方面的工作。没有人比其他人在一个模块或者技术上具有更没有人比其他人在一个模块或者技术上具有更 多的权威。多的权威。 p任何人都可以多从事自己擅长的一方面， 但是不会被限制在自己的专业领域内。 极限编程实践 l持续集成持续集成 pXP团队每天会进行多次系统构建，他们会重新创建整个系统。 p集成时要采用系统最终结果发布的形式CD或Web。 p程序员的模块在签入/集成前必须保证模块已经通过所有测试。 l可持续的开发速度可持续的开发速度 p软件项目不是全速短跑，而是马拉松长跑。 pXP团队必须要以一种可持续的速度前进，必须要有意识地保持 稳定、适中的速度。 pXP的规则是不允许团队加班工作不允许团队加班工作。在版本发布前的一个星期是 该规则的惟一例外-如果发布目标就在眼前并且可以一蹴 而就，则允许加班。 极限编程实践 l开放的工作空间开放的工作空间 p开放的房间：桌子/椅子面对面，墙上挂满了各种图表； p人和人之间的距离必须足够近，能够互相听到对方的谈话。 p密歇根大学的一项研究表明，在“充满积极讨论