频繁交流
客户使用发布的系统，可以保证 频繁地反馈和交流。
小组实践
小组实践1:持续集成(Continuous integration)
持续集成指不断地把完成的功能模块整合在一起。目的在于不断获得客户反馈以及尽早发现 BUG。
随时整合，越频繁越好；集成及测试过程的自动化程度越高越好。
“A Test a day ,takes the bugs away”---Siemens
什么是XP
XP is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing requirements. -- Kent Beck.

所有的小组成员应在同一个工作地点工作。

成员中必须有一个用户代表（On-site User）,由他/她来提出需求，确定开
发优先级，把握开发的动向。 通常还设一个教练（Coach）角色，来指导XP方法的实施及与外部的沟通 协调等。 小组每个成员都应围绕用户代表，充分贡献自己的技能。


交付和管理2: 计划游戏(Planning Game)
FDD－特性驱动 Feature Driven Development，
– 由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。 它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。
DSDM-Dynamic System Development Methodology，
什么是XP


极限的含义：软件开发中的优点发挥到极致(Kent Beck).
XP：给程序员提供了明确的方法，使得程序员尽管面对需求的改变，却 能够从容应对，即使着重变化发生在项目的后期，仍然能够编出代码。

XP核心：沟通、简明、反馈和勇气
XP重视沟通，客户、开发人员、管理者共同组成团队。 XP是一个实践系统
越来越多的公司开始使用敏捷开发过程
敏捷开发成功的因素
自组织团队
文化和氛围
知识和技能
开放的心态
目录
1 2 2.1
敏捷开发简介 敏捷系列
XP -eXtreme Programing
SCRUM
2.2
3
敏捷开发的误区
敏捷实践

在敏捷的两个门派：XP、Scrum中，整理归纳了很多可以 用于协助软件开发的实践，后面统称为敏捷实践。
目录
1 1.1
1.2 1.3 1.4 2 3
敏捷开发简介
敏捷的起源 敏捷方法体系 敏捷宣言
为什么要敏捷?
敏捷系列 敏捷开发的误区
我们为什么需要敏捷
项目为什么失败？
1)
软件工程试图解决这些问题：
1)
2) 3) 4)
5) 6)
7)
对用户需求理解得不清楚，甚至有 错误； 用户需求变化； 软件很难维护或扩展； 在项目后期阶段发现很严重的设计 缺陷； 软件质量或性能不合格； Test - Build - Release过程的可操作 性、可维护性很差； 人员流动； ……

13个实践 以拥抱变化的思想，协作的团队，简单的规则等为原则的13个具体实践 是知名度最高的敏捷开发方法

XP方法的贡献

Extreme Programming
XP的计划/反馈循环
XP开发工作流
XP的关键实践:
编程方法
小组实践
交付和管理
XP的关键实践
完整的 团队
编程方法
代码集体所有 测试驱动开发 现场客户
萌芽--产生敏捷方法
敏捷方法是从上个世纪 90年代开始发展起来的
同起草了敏捷软件开发 宣言，总结出方法之间 的共同点，最终就是价
HP,Microsoft,IBM等
一组方法学的总称，包
括极限编程等等。这些 方法学之间有一些差异， 但是差异不是特别大
值，并且用敏捷这个词
给这种方法学一个统称
上个世纪90年代
2) 提高开发人员的水平；
3) 提高项目成功率，降低开发成本，提升软件开发效率 项目经理： 1) 更好地和用户沟通，更清晰地理解用户需求； 2) 更充分地使用资源，更科学地调配资源，更精确地掌握开发进度。 系统分析设计： 1) 设计更加完善； 2) 更有效地更新知识，得到其他成员更多的尊重。 程序员： 1) 学习系统设计和项目管理； 2) 提高学习和工作效率，受到重视，减少加班时间，工作更高效

目录
1 1.1
敏捷开发简介
敏捷的起源
敏捷方法体系 敏捷宣言 为什么要敏捷?
敏捷系列 敏捷开发的误区
1.2 1.3
1.4 2 3
敏捷宣言
个体和交互胜过过
程和工具
可以工作的软件胜过面 面俱到的文档
核心理念： 适应和以人为本
响应变化胜过遵 循计划 客户合作胜过合 同谈判
敏捷规则
最高目标是能持续地、及早地向客户交付软件； 拥抱变化； 频繁地发布可运行的软件； 客户和开发人员在一起工作； 以人为本； 最重要的衡量开发过程的手段，是可工作的软件； 稳定的开发速度； 敏捷高效的设计； 简单有效； 重视Teamwork； 积极的调整。
电影后期制作 —> 邮递 —> 电影院播放电影。
小组实践2:隐喻(System Metaphor)
Metaphor的形成过程，是客户建立并抽象商业模型和商业概念的过程，是程序员建立 并抽象设计模型和设计概念的过程。 Metaphor使客户和程序员用共通的模型和语言进行交流 — “One Team, one language”。 Metaphor可以帮助减少“知识泄露”和“支解知识”。 Metaphor是设计过程的航标 —— 真正灵活有效的设计是针对商业原则的设计，而不 是针对商业原则表现形式的设计，更不是脱离商业需求目的的学术设计。 随着开发的继续，Team会找到更好的Metaphor。这是知识细化、深化的结果，是 “持续学习”(Continuous learning)的过程；是对商业模型和设计模型的持续重构。
为什么要敏捷?
敏捷系列 敏捷开发的误区
3
敏捷方法
XP -eXtreme Programing极限编程:
– 思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。
SCRUM：
– 是一种迭代的增量化过程，用于产品开发或工作管理 。
水晶方法Crystal:
– 由Alistair Cockburn在1990年代末提出。把不同类型的项目采用不同的方法。
敏捷开发流程与方法
BGCN交付管理部
Strictly Private and Confidential
目录
1 1.1 1.2 1.3 1.4 2 3
敏捷开发简介
敏捷的起源 敏捷方法体系 敏捷宣言 为什么要敏捷?
敏捷系列 敏捷开发的误区
敏捷开发的起源
发展—开始广为流行 正规—成立敏捷联盟
每种方法学的领导人共 500强公司中众多公司 应用敏捷;如
探索阶段
产生和评估 User Story
计划阶段
调整阶段
增加/改变 需求
发布计划
调整开发 速度 / 内容
迭代计划1
迭代计划2 ………… 实施迭代1 实施迭代2 …………
迭代计划n
1..N个发布
实施迭代n
交付和管理3:现场客户(On-Site Customer)
客户是Team成员，在开发现场和开发人员一起工作。 传统的客户任务一般是讲解需求，运行验收
– 它倡导以业务为核心，快速而有效地进行系统开发， 在英国等欧洲国家比较流行。
ASD-Adaptive Software Development，
– 由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive）
敏捷开发特点
敏捷开发包括很多方法，例如XP和FDD，同重量级的文档驱动 的开发过程相比较，敏捷方法在灵活性等方面更有吸引力。这个方 法的创始人强调了在软件实践过程中的变更而不是孤立的进行一些 实践。
Team将Domain/Sub-Domain Model，Design/Sub-Design Model以及一些关键概念等等抽象 化为比喻。通过这些比喻，加强客户和程序员之间的相互理解，消化积累知识，指导设计开发的方 向。
例：
Market —发布/浏览，价格洽谈，生成和履行合同；
String，Tree，Package，Chartroom，Spider，Robot ……；

很多方法很难独立的使用。如:测试驱动的开发，结对开发，计 划调整周期以及持续改进，不过，后来的结果证实，这些方法都取 得了成功。
使用这些方法并不能保证一定成功。开发者的经验和技术仍旧 是影响开发结果的最主要因素。对于合适的人，基于敏捷原则的开 发方法可以产生更好的结果，同时形成一个愉快地、有激情的工作 环境
测试，接收发布的系统。XP新增加的任务：
(1) 写User Story (2) 评估User Story的商业优先级
(3) 为每个User Story定义验收测试
(4) 计划开发内容 (5) 调控开发过程 (6) 建立商业模型，把隐藏在客户需求下的原则传授给开发人员 (8) 程序员分担任务的过程支解了对他们商业模型的理解 (9) 参加设计过程 (10)和程序员一起找出Metaphor，导引设计方向 (11)在Metaphor的帮助下，定义更有效更实际的功能测试，给程序员的设计制定了规范
失败 通过