黄海波 & 陶万山 with contribution by 劳晖

Presentation on theme: "黄海波 & 陶万山 with contribution by 劳晖"— Presentation transcript:

1 黄海波 & 陶万山 with contribution by 劳晖 www.chinaxp.org
Extreme Programming 黄海波 & 陶万山 with contribution by 劳晖

2 XP基础课程

3 内容概要 为什么需要XP 敏捷过程是软工发展的必然及最新成果 重要概念 12个重要惯例和规则 XP的实施过程 总结

4 前言 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 我们为什么需要XP 项目为什么失败？ 软件工程试图解决这些问题： 对用户需求理解得不清楚，甚至有错误； 用户需求变化； 软件很难维护或扩展；
在项目后期阶段发现很严重的设计缺陷； 软件质量或性能不合格； Test - Build - Release过程的可操作性、可维护性很差； 人员流动； …… 为了规范化开发过程，引进传统工程的概念（瀑布型）； 为了理解需求，提出原型法； 为了提高设计开发的效率和扩展性，提出重用和面向对象等思想； 为了让开发过程更灵活，提出了开发框架的概念； 为了降低风险，提出了风险评估、成本控制和增量开发等思想；  Copyright 2002 Chinaxp. All rights reserved

6 我们为什么需要XP 软件工程的应用现状： “特色”问题还是难以解决： 国内因为资源限制，软件工程的实施流于形式；
国内软件工程的研究及推广工作，和实践脱钩； 旧的软件工程方法一直不能有效地支持变化。 在北美，虽然软件工程提高了项目成功率，但耗费巨大资源； 以前的软件工程方法无法摆脱传统工程方法的束缚。 需求难以量化； 软件从开发到维护及扩展，需求都有可能发生大变化； 编程对设计的反馈非常重要； 项目中的设计可能会经常变化； 代码的可读性和可维护性； ……  Copyright 2002 Chinaxp. All rights reserved

7 我们为什么需要XP 公司： 项目经理： Team Lead和Architect： 程序员： 1) 培养团队合作精神，稳定开发队伍；
2) 提高开发人员的水平； 3) 提高项目成功率，降低开发成本。 项目经理： 1) 更好地和用户沟通，更清晰地理解用户需求； 2) 更充分地使用资源，更科学地调配资源，更精确地掌握开发进度。 Team Lead和Architect： 1) 设计更加完善； 2) 更有效地更新知识，得到其他成员更多的尊重。 程序员： 1) 学习系统设计和项目管理； 2) 提高学习和工作效率，受到重视，减少加班时间。  Copyright 2002 Chinaxp. All rights reserved

8 谁在用XP Fortune 500 公司中成功应用XP的公司包括Ford，Daimler-Chrysler，First Union National Bank，IBM，HP等等。 2-10人的小规模开发队伍（小规模开发队伍 小规模项目）。 越来越多的公司开始使用敏捷开发过程，或者将其与RUP等开发过程结合使用。  Copyright 2002 Chinaxp. All rights reserved

9 什么是XP Kent Beck 1996 Extreme Programming
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是把最好的实践经验提取出来，形成了一个崭新的开发方法。 Extreme Programming  Copyright 2002 Chinaxp. All rights reserved

10 软件工程发展的必然 软件工程的最新成果 www.chinaxp.org
Agile Process 软件工程发展的必然 软件工程的最新成果

11 软件生命期  Copyright 2002 Chinaxp. All rights reserved

12 Waterfall模型 Royce 1970 软件工程中的第一个模型 analysis design code test
System/information engineering 软件工程中的第一个模型  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 快速原型法 （也称为 Throw-it-away） Build 3 Build 2 商业模型 数据模型 处理模型 应用生成 测试和改造
60 – 90 天 目的是理解需求，从不清楚的需求部分开始。  Copyright 2002 Chinaxp. All rights reserved

19 优点： 不足： 需求驱动的开发模型。 帮助理解需求。 增强和用户的交流，增加用户好感。
缺乏结构化的系统和严谨的开发流程，很难作为一个项目进行管理。  Copyright 2002 Chinaxp. All rights reserved

20 面向重用的开发模式 作为一种开发模式有很多局限，但“重用” 的思想越来越普及。 确定需求 组件分析 修订需求 基于重用 系统设计 实现 集成
 Copyright 2002 Chinaxp. All rights reserved

21 螺旋式开发模型 Boehm 1988 确立目标、范围 确认分析风险 以及可选方案 评估替代方案 为下阶段 做计划 开发和鉴定 风险 分析
原型1 原型2 原型3 可用的 原型 模拟，模型，基准点 可操作 的概念 需求 鉴定 产品 设计 集成和测试 计划 开发 检查 周期计划 需求计划 详细 编码 单元 测试 集成 验收 服务 确认分析风险 评估替代方案 确立目标、范围 以及可选方案 为下阶段 做计划 开发和鉴定  Copyright 2002 Chinaxp. All rights reserved

22 优点： 不足： 风险驱动的开发模型。 灵活。可以根据风险的处理情况选择需要的阶段（Loop），
因而演变为Waterfall、进化原型等模型。 各阶段都有评估和风险分析，可根据变化调整项目实施过程。 适用于复杂的、风险大的项目。 不足： 需要非常专业的风险评估技术。 需要非常丰富的项目经验。  Copyright 2002 Chinaxp. All rights reserved

23 增量型（例RUP） 迭代1 迭代2 迭代3 分析 设计 编码 测试 发布1 发布2 发布3 迭代n 最终 发布 ……..
 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； 积极的调整。  Copyright 2002 Chinaxp. All rights reserved

27 XP的增量过程 重构 简单 设计 迭代 计划 测试驱动 Pair开发 持续 集成 1..N个 Iteration 发布 Release
小发布 Task  Copyright 2002 Chinaxp. All rights reserved

28 XP中的重要概念 哲学观 管理 需求 设计

29 哲学观（Philosophy） 交流(Communication) 简单(Simplicity) 反馈(Feedback)
XP的价值观就象三个代表。 勇气(Courage)  Copyright 2002 Chinaxp. All rights reserved

30 管理 发布(Release)：每一期开发结束时提交给用户的一个可运行的系统。
迭代(Iteration)：一期开发过程中的一个开发周期。它有明确的目标，计划和实现方式，它包含了需求分析、设计、编程、测试等完整的开发过程。一个迭代的长度为1到3 周。在一期开发过程中，所有迭代的长度是相同的，比如都是3周。 小发布(Small Release)：处于开发中的系统，每集成一个新功能，都可以称为一个小发布。 理想开发时间：估计完成一项工作所需的持续工作时间，不考虑意外因素。 Spike就象投石问路，改革开放搞试点。迭代就是五年计划。  Copyright 2002 Chinaxp. All rights reserved

31 需求 客户浏览分类广告 1周 客户发布分类广告 2周
SPIKE：对不确定的需求和设计等，通过写一些程序、进行详细设计或者演算等等方式做探测和尝试，以确定可行性。这些探测过程称为SPIKE。 User Story：是对用户的一个需求的一段简洁清晰的描述，该段描述有三个属性，即商业优先级、开发时间和风险。从某个角度看，XP过程是面向User Story的。 故事卡：用户把User Story的内容和属性写在一张卡片上，该卡片即故事卡。 例，MSDN中的例子Island Hopper News： (1) 客户浏览分类广告；(2) 客户发布分类广告；…… Spike就象投石问路，改革开放搞试点。迭代就是五年计划。 客户浏览分类广告 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。 可以在卡正面加上父类名，子类名；可以在卡背后加上属性。 Class Name Responsibilities Collaborators Ad SelectSingleAd 面向对象的设计 BrowseAdDetails (aspx) Display an ad Ad  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

34 XP的惯例和规则

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 Any More? 客户是Team成员，在开发现场和开发人员一起工作。
传统的客户任务一般是讲解需求，运行验收测试，接收发布的系统。XP新增加的任务： (1) 写User Story (2) 评估User Story的商业优先级 (3) 为每个User Story定义验收测试 (4) 计划开发内容 (5) 调控开发过程 Any More? Consultant 的笑话，1、告诉客户他已经知道的东西；2、拿了不该拿的东西。  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 计划项目 增加/改变 需求 产生和评估 User Story 发布计划 1..N个发布 探索阶段 计划阶段 调整阶段 调整开发
迭代计划1 迭代计划2 迭代计划n ………… 实施迭代1 实施迭代2 实施迭代n 1..N个发布 探索阶段 计划阶段 调整阶段 调整开发 速度 / 内容 新计划经济  Copyright 2002 Chinaxp. All rights reserved

41 测试驱动开发 （在第二天的课程将详细阐述） 设计 先写 单元测试 重构 运行 编程 发现BUG 集成 功能测试 User Story
失败 通过 时间 单元测试 100% 通过 考试大纲 （在第二天的课程将详细阐述）  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）
需求 分析 设计 编码 测试 集成 使用和维护 Planned Design XP 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 aren’t 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和个人在很长的时期内保持一定的开发效率。 保证了项目速度和计划过程的有效性和准确性；
加班多导致开发效率和质量下降，简洁增加了开发成本； Pair Programming已经加大了工作强度，并且和其它XP的规则一起提高了工作效率，使少加班和维持平稳的工作效率可能而且可行。 提倡平稳的工作效率，体现了XP以人为本的价值观。  Copyright 2002 Chinaxp. All rights reserved

51 XP过程

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 开发 发布 多个迭代 计划 多期 产生Story 评估Story 开始提炼 Metaphor 迭代计划 CRC卡设计 分解Task
Pair进行 测试驱动的开发 持续集成和发布 迭代结束 发布 计划 产生Story 评估Story 开始提炼 Metaphor 多个迭代 多期  Copyright 2002 Chinaxp. All rights reserved

55 总结

56 EXTREME的来由 if the code review is good, we‘ll 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 交流 有交流过度的项目吗？ 交流 开发 讨论设计 Pair Programming QA 交谈 文档 卡片 图 表 代码 测试 文件 编程
规范 工作环境 会议 计划会议 Standup Meeting 回顾 发布 计划 迭代 System Metaphor 代码集体所有 Team 其它 价值观 勇气 简单 反馈 有交流过度的项目吗？  Copyright 2002 Chinaxp. All rights reserved

59 反馈 反馈就是抱怨？ 反馈 验收测试 Programming Coach 程序员 持续集成 之间 集成测试 Pair 单元 开发 测试 学习
回顾 Coach Pair 文档 Spike 其它 价值观 勇气 简单 交流 开发 集成测试 Programming 单元 测试 持续集成 验收测试 迭代 小规模发布 产品 计划 评估 On-site Customers 调控 风险 时间 价值 反馈就是抱怨？  Copyright 2002 Chinaxp. All rights reserved

60 勇气 勇气 集体 骄傲 拥有代码 品质 合作 自信 好胜 态度 Team 统一 规范 迭代 计划 开发 反馈 其它 价值观 简单 编程
交流 态度 自信 品质 好胜 骄傲 迭代 计划 开发 Refactoring 编程 配置 管理 Simple Design 测试 取舍  Copyright 2002 Chinaxp. All rights reserved

61 简单 简单 需求 CRC On-Site Customers 项目 计划 其它 价值观 勇气 反馈 交流 质量 持续集成 开发 轻量极
开发环境 系统 Simple Design Refactoring 做最简单的事情 让系统运行 System Metaphor  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

64 XP中级课程

65 XP项目管理

66 项目速度 （Project Velocity）
1、项目速度：一个迭代（Iteration）完成的理想开发周（Ideal week）。 例：一个开发小组在一个迭代里能完成10个理想开发周的工作，那么项目开发速度就是10。这个10周的工作可能包括一个3周的User Story、两个2周的User Story和三个1周的User Story。 2、开发速度的设定依据“yesterday’s weather”的原则。第一个迭代的速度可以按照“程序员数 X 1”计算。 Iteration (3周) 计划速度 实际完成 1 6 2 8 3 10 4 5 n …… 假设有6个程序员。  Copyright 2002 Chinaxp. All rights reserved

67 项目速度 （Project Velocity）
个人承担任务时，估计该任务的理想开发天。 第一个迭代中，个人可以按照5个理想开发天的总数来承担任务。例：1个2天的任务，3个1天的任务。 个人承担的任务量按照“Yesterday’s Weather”原则计算。 Iteration (3周) 承担任务 实际完成 1 5 4 2 6 3 8 7 n …… 一开始很难估计的东西，在实际开发中变得越来越清楚。 某程序员的开发速度  Copyright 2002 Chinaxp. All rights reserved

68 计划项目 一、探索阶段（Exploration Phase）
所有的内容写在卡片上。 估计的时间是指：按照平均的技术水平，一个人开发该User Story的理想时间。 用数字1、2、3表示商业价值的高低级别。 用数字1、2、3表示开发风险的高低级别。 开发风险是针对具体技术和整体设计。 评估开发风险时，卡片的移动次序是由高向低的。 写Story 估计理想 开发时间 分拆 Story 合并 SPIKE U P&U P 评估 商业价值 开发风险 P：程序员 U：用户 > 3 周 < 1 周 很难 估计  Copyright 2002 Chinaxp. All rights reserved

69 计划项目 二、计划阶段（Planning Phase）
宣布 开发速度 速度 X 迭代 =总开发量 P 客户 挑选Story Story总和 U 宣布最近 Team & =迭代开发量 发布计划 (商业优先) 迭代计划 (商业优先 和 风险优先) 任务计划 (风险优先) 分解Story 成Task 承担 估计Task S/P >3天 分解 <1天 合并 宣读解释 Story  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 程序员的一天 9AM Standup Meeting Pair Up 编码 QA 测试 重构 集成 5PM 结束
 Copyright 2002 Chinaxp. All rights reserved

73 风险管理 需求阶段：SPIKE和Story的风险评估。 计划过程：发布计划和迭代计划中，根据需求变化进行相应调整。
设计过程：简单设计避免Over-Engineering。 开发过程： 1) 设计驱动的开发过程； 2) Pair Programming； 3) 持续集成； 4) 频繁的小发布。  Copyright 2002 Chinaxp. All rights reserved

74 剖析XP的重要概念

75 User Story 和 Use Case 的区别
发布分类广告 浏览分类广告 Use Case 说明： 名称 简短描述 事件流程 初始状态 结束状态 异常 …… 术语表： 客户： …… 分类广告：…… …… 补充说明： 可用性： …… 可靠性： …… 可维护性：…… …… Presentation Requirement Mock-up Window ……  Copyright 2002 Chinaxp. All rights reserved

76 User Story 和 Use Case 的区别
Use Case Modeling 从用户角度看 从开发人员角度看 由用户写 由开发人员写 给开发人员看 给用户看 一张卡片上的一段描述 图 每张卡必须有商业价值、开发风险和开发时间三个评估值 每个图通常常有正规的说明、术语表等等 不包含细节流程 包含细节流程 1周〈 粒度〈 3周 无 一张卡片只有一个User Story 一个图通常有多个Use Case 开发计划以User Story为单位 开发速度根据User Story计算  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

79 XP过程

80 XP过程 1、准备开发环境。 2、Exploration Phase 程序员和用户一起把需求分解为User Story，用户写Story卡。
(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卡可以放在一个Iteration，或者程序员提前开发完后承担。  Copyright 2002 Chinaxp. All rights reserved

83 XP过程 4、Iteration Development (1) 客户为每个User Story定义功能测试。
(2) 每天早晨开一个简短的Standup Meeting。每个人简要讲述昨天做的工作，今天准备做的工作，和碰到哪些困难。 (3) 程序员进行Pair Programming (3.1) 根据难度和重要性决定Senior，Intermediate和Junior的搭配。Pair每天互换。 (3.2) Pair自由决定先开发谁的Task。 (3.3) Pair开发时，自由决定谁是Driver，谁是Navigator。 (4) 设计该项Task。 (5) 为该设计的所有类和方法写Unit Test。 (6) 写程序实现该设计的所有类和方法。 (7) 运行所有的Unit Test，在100%通过后Check In。 (8) 重构。完成后执行(7)。  Copyright 2002 Chinaxp. All rights reserved

84 XP过程 4、Iteration Development (9) Build系统，只放入一个Pair完成的功能。
(10) 运行功能测试，通过则进入(11)，否则如下： (10.1) 如果失败或者发现BUG，找到原因后要先写Unit Test。 (10.2) 写程序。通过所有Unit Test后Check In。 (10.3) 重新执行(9)。 (11) 进行小发布。 (12) 客户使用，给予反馈。 (12.1) 如果发现BUG，进入步骤4-10.1。 (12.2) 在此基础上产生的新需求或变化，做为一个Story或Task。 (12.2.1) 客户和Team协商何时评估该Story/Task，以及放在那个Iteration中。 (12.2.1) 评估过程参考2。 (13) Tracker跟踪统计Story和Task的完成情况。 5、开始下一个Iteration，重复4。  Copyright 2002 Chinaxp. All rights reserved