敏捷软件开发学习笔记

邱志军 于2008年初

赛尔软件有限公司（筹）

前言

敏捷开发（AD）是一种面临快速变化的需求快速软件开发的能力。获取敏捷性的三要素：

1.         提供必要的纪律和反馈的实践

2.         保持软件灵活、可维护的设计原则

3.         针对特定问题平衡设计原则的设计模式

第I部分 敏捷开发

       人与人之间的交互是复杂的，并且其效果从来都难以预期，但却是工作中最为重要的方面。原则、模式、实践都很重要，但是使它们发挥作用的是人。人不是“插入即兼容的编程装置”，必须构建起有合作精神、自组织的团队。

第一章     敏捷实践

失控的过程膨胀源于对项目失败的恐惧，在这种恐惧之下过程变得越来越庞大！！！

第一节 敏捷联盟

2001年敏捷联盟发布敏捷联盟宣言，声明其价值观和原则。宣言的具体内容如下：

个体和交互胜过过程和工具

1.         人是获得成功的最为重要的因素

2.         合作、沟通以及交互能力远比单纯的编程能力更为重要

3.         使用过多庞大、笨重的工具就像缺少工具一样，都是不好的

4.         团队的构建比环境的构建重要的多

可以工作的软件胜过面面俱到的文档

1.         过多的文档比更少的文档更糟

2.         编写并维护一份系统原理和结构方面的文档

3.         给新的团队成员传递知，最好的两份文档是代码和团队

4.         直到迫切需要并意义重大时，才编制文档

客户合作胜过合同谈判

1.         成功的项目需要有序、频繁的客户反馈

2.         指明了需求、进度以及项目成本的合同存在根本的缺陷

响应变化胜于遵循计划

1.         响应变化的能力常常决定一个软件项目的成败

2.         计划不能考虑的太远

3.         较好的计划策略：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划

第二节 原则

从上述价值观中引出下面12条原则，它们是敏捷实践区别于重型过程的特征所在。

我们最优先要做的是尽早的、持续的交付有价值的软件使客户满意

1.         初期交付的系统功能越少，最终交付的系统的质量就越高

2.         敏捷实践会尽早的、经常的进行交互

即使到了开发的后期，也欢迎改变需求

1.         敏捷过程利用变化来为客户创造竞争优势

2.         敏捷团队会非常努力保持软件结构的灵活性，以应对需求的变化

经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好

1.         不赞成交付大量的文档或计划

2.         我们关注的目标是交付满足客户需求的软件

在整个项目开发期间，业务人员和开发人员必须天天都在一起工作

为了以敏捷的方式进行项目的开发，客户、开发人员和相关涉众之间必须进行有意义的、频繁的交互。

围绕被激励起来的个人来构建项目

1.         给他们提供所需的环境和支持，并且信任他们能够完成工作

2.         在敏捷项目中，人被认为是项目取得成功的最重要的因素

团队中最有效果并富有效率的传递信息的方式，就是面对面的交谈

1.         敏捷项目中，首要的沟通方式就是交谈

2.         敏捷团队不需要书面的规范、计划或者设计

工作的软件是首要的进度度量标准

1.         敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度

2.         只有当30%的必修功能完成时，才可以确定进度完成了30%

敏捷过程提倡可持续的开发速度

1.         责任人、开发者和用户应该能够保持一个长期、恒定的开发速度

2.         敏捷项目不是50米短跑，而是马拉松长跑

3.         跑得过快会导致团队精力耗尽，出现短期行为以致崩溃

不断的关注优秀的技能和好的设计会增强敏捷能力

1.         高的产品质量是获取高的开发速度的关键

2.         保持软件尽可能的简洁、健壮是快速软件开发的途径

简单——使未完成的工作最大化的艺术——是根本的

1.         敏捷团队不会构建华而不实的系统，更愿意采用和目标一致的最简单的方法

2.         在今天以最高的质量完成最简单的工作

最好的构架、需求和设计出自于自组织的团队

1.         敏捷团队是自组织的团队

2.         敏捷团队的成员共同来解决项目中所有方面的问题

每隔一段时间，团队会反省如何更有效的工作

1.         敏捷团队会不断的对团队组织方式、规则、规范、关系等进行调整

2.         为保持团队的敏捷性，团队必须随时间一起变化

第三节 结论

       敏捷软件开发的原则和价值观构成了一个可以帮助团队打破过程膨胀循环的方法，这个方法关注的是可以达到团队目标的一些简单技术。已经有许多敏捷过程可供选择，包括：SCRUM、FDD、ADP以及XP。

第二章     极限编程概述

作为开发人员，我们应该记住，极限编程并非唯一选择。

第一节 极限编程实践

       极限编程是敏捷方法中最著名的一个，由一系列简单却相互依赖的实践组成。

客户作为团队成员

1.         客户和开发人员一起紧密的工作，彼此了解对方面临的问题，并共同解决这些问题

2.         XP团队中的客户是指定义产品特性并排列这些特性优先级的个人或团体

3.         最好情况是客户和开发人员在一起工作

用户素材

1.         进行项目计划必修知道项目需求有关的内容，但无需知道太多，做到能够估算即可

2.         需求的特定细节会随着时间而改变

3.         在XP中，我们和客户反复沟通以获取对需求细节的理解，但不捕获那些细节

4.         用户素材是需求谈话的助记符，可以根据它的优先级和估算代价安排时间

短交付周期

       XP每两周交付一次可以工作的软件，实现涉众的一些需求。

迭代计划

1.         迭代计划是一次较小的交付，可能会被加入产品中，也可能不会

2.         由客户依据开发人员的预算而选择的用户素材组成

3.         开发人员依据以前迭代完成的工作量为本次迭代设定预算

4.         一旦迭代开始，客户就同意不修改用户素材的定义和优先级

发布计划

1.         发布计划是一次较大的交付，通常会被加入产品中

2.         由客户依据开发人员的预算而选择的、排好优先级的用户素材组成

3.         开发人员依据以前发布完成的工作量为本次迭代设定预算

4.         发布计划不是一成不变的，用户随时可以改变计划的内容

验收测试

1.来源：titan_dandan