敏捷开发背景介绍

极限编程
– 极限编程介绍 – 极限编程12个最佳实践
极限编程
极限编程(eXtreme Programming,简称XP) 是敏捷方法中最著名的一个。它由一系列 简单却互相依赖的实践组成。这些实践结 简单却互相依赖的实践 合在一起形成了一个敏捷开发过程。 迭代：一次又一次循环逼近的过程
极限编程的12个最佳实践
敏捷软件开发简介
产品部公共服务
敏捷软件开发简介
♦ 敏捷实践 ♦ 极限编程 ♦ 持续集成
敏捷实践
– – – – 软件过程体系 软件过程程体系的缺点 敏捷联盟简介 敏捷联盟宣言
软件过程体系
♦ 近30年的发展，形成了一些标准体系。 ♦ -ISO9000 ♦ -6sigma ♦ -CMM/CMMI
软件过程体系的缺点
♦慢 ♦ 官僚 ♦ 与商业目标不一致
敏捷联盟简介
♦ 2001年初，一批业界专家聚集在一起概括
出了一些可以让软件开发团队具有快速工 作、响应变化能力的价值观和原则，他们 称自己为敏捷(Agile)联盟。在随后的几个月 中，他们创建出了一份价值观声明 价值观声明。也就 价值观声明 敏捷联盟宣言(The Manifesto of the Agile 是敏捷联盟宣言 敏捷联盟宣言 Alliance)。
持续集成
持续集成原则
♦ 1. 所有的开发人员需要在本地机器上做本地构建，然后再
♦ ♦ ♦ ♦ ♦ ♦
提交的版本控制库中，从而确保他们的变更不会导致持续 集成失败。 2. 开发人员每天至少向版本控制库中提交一次代码。 3. 开发人员每天至少需要从版本控制库中更新一次代码到 本地机器。 4. 需要有专门的集成服务器来执行集成构建,每天要执行多 次构建。 5. 每次构建都要100%通过。 6. 每次构建都可以生成可发布的产品。 7. 修复失败的构建是优先级最高的事情。
SCRUM：www.controlchaos.com。 Crystal：crystalmethodologies.org。 FDD(Feature Driven Development)：Java Modeling In Color With UML: Enterprise Components and Process, 1999。 ADP(Adaptive Software Development) ： [Highsmith2000]。 XP(eXtreme Programming)：[Beck 1999], [Newkirk2001]。 在北美,以XP(9%)为首的敏捷方法已经拥有了 15.9%的市场份额.
持续集成工具
♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦
http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix CruiseControl (http://cruisecontrol.sourceforge.net/) Hudson (https://hudson.dev.java.net/) LuntBuild (http://luntbuild.javaforge.com/) TeamCity (http://www.jetbrains.com/teamcity/) AntHill Pro (http://www.anthillpro.com/) Bamboo (http://www.atlassian.com/software/bamboo/) QuickBuild (http://www.pmease.com/)
百度文库
持续集成
– 持续集成介绍 – 持续集成活动 – 持续集成工具
持续集成
♦ 持续集成是一种软件开发实践，即团队开
发成员经常集成它们的工作，通常每个成 员每天至少集成一次，也就意味着每天可 能会发生多次集成。每次集成都通过自动 化的构建（包括编译，发布，自动化测试) 来验证，从而尽快地发现集成错误。许多 团队发现这个过程可以大大减少集成的问 题，让团队能够更快的开发内聚的软件。
敏捷联盟宣言
我们正在通过亲身实践以及帮助他人实践， 揭示更好的软件开发方法。通过这项工作， 我们认为：
个体和交互 胜过 可以工作的软件 胜过 客户合作 胜过 响应变化 胜过
过程和工具 面面俱到的文档 合同谈判 遵循计划
虽然右项也有价值，但我们认为左项具有 更大的价值。
已有的敏捷过程： 已有的敏捷过程：
极限编程的12个最佳实践
♦ 7 ♦ ♦ ♦ ♦ ♦
结对编程—所有的生产代码都是由两个程序员在通一 台机器上编写的。 8 集体所有权—任何人在任何时候都可以在系统中的任 何位置更改任何代码。 9 持续集成—每天多次集成和生成系统，每次都完成 一项任务。 10 每周工作40小时—一般情况下，一周工作不超过40小 时。不要连续两个星期都加班。 11 现场客户—在团队中加入一位真正的、起作用的用户， 他将全职负责回答问题。 12 编码标准—程序员依照强调通过代码沟通的规则来编 写所有代码。[1]
♦ 1 ♦ ♦ ♦ ♦
♦
计划游戏—通过结合使用业务优先级和技术评估来快速确定下 一个版本的范围。当计划赶不上实际变化时就应更新计划。 2 小版本—将一个简单系统迅速投入生产，然后以很短的周期发 布新版本。 3 隐喻—用有关整个系统如何运行的简单、众所周知的故事来指 导所有的开发。 4 简单设计—任何时候都应当将系统设计的尽可能简单。不必要 的复杂性一旦被发现就马上去掉。 5 测试—程序员不断地编写单元测试，在这些测试能够准确无误 地运行的情况下，开发才可以继续。客户编写测试来证明各功能已经 完成。 6 重构—程序员重新构造系统（而不更改其行为）以去除重复、 改善沟通、简化或提高柔性。