【软件工程】敏捷开发方法的总结
（一） 说明
本文是阅读Alistair Cockburn的Agile Software Development和William C. Wake的XP Explored的一些笔记和想法，Agile Software Development是一组软件开发方法的总称，包括（Crystal , Extreme Programming , Adaptive software development等等）。敏捷开发方法又称为“轻量级”开发方法。
下面这段话摘自Martin Fowler的一篇文章：
从无到繁重再到敏捷
多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” （code and fix）。设计过程充斥着短期的，即时的决定，而无完整的规划。这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来越困难。同时错误故障越来越多，越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而对项目的完成产生严重的影响。
我们使用这种开发模式已有很长时间了，不过我们实际上也有另外一种选择，那就是“正规方法”（methodology）。这些方法对开发过程有着严格而详尽的规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他工程领域的实践。
这些正规方法已存在了很长时间了，但是并没有取得令人瞩目的成功，甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐，要是按照它的要求来，那有做太多的事情需要做，而延缓整个开发进程。所以它们通常被认为是“繁琐滞重型”方法，或Jim HighSmith 所称的“巨型”（monumental)方法。
作为对这些方法的反叛，在过去几年中出现了一类新方法。尽管它们还没有正式的名称，但是一般被称为“敏捷型”方法。对许多人来说，这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡，使得能以不多的步骤过程获取较满意的结果。
敏捷型与滞重型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档，对于一项任务，它们通常只要求尽可能少的文档。从许多方面来看，它们更象是“面向源码”（code-oriented）。事实上，它们认为最根本的文档应该是源码。
但是，我并不以为文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表象，它其实反映的是更深层的特点：
? 敏捷型方法是“适配性”而非“预设性”。 重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。
? 敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。
我认为以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心
（二） 方法背后的思想
Alistair Cockburn在Agile Software Development中讲述了敏捷开发方法背后的思想
人们掌握过程（process）可以分为3个阶段：
1 following 遵循一个定义好的process
2 detaching 知道不同process的适用范围，在不同的场合使用不同的process
3 fluent 不关心是否遵循特定的process，知道在什么情况下采用什么动作
软件开发是一个充满发明和交流的协作性游戏(cooperative game of invertion and communication)。软件开发的首要目标是生产出软件，遵循特定的过程和模型只是手段，只要传递了足够的信息，手段是次要的。交流的效果要远远重于交流的形式（Effect of communication is more important than the form of communication）。
一般软件开发有两个目标：1 尽快的生产出软件2 为下一个team或项目做准备，有时这两个目标是矛盾的，我们要在这两个目标之间寻求平衡
在软件开发中，人的因素要远远大于过程和技术。人是有缺陷的：
1 容易犯错误，因此必须在错误扩散之前找到并改正错误
2 当觉得可能失去较多的时候，不愿意冒险
3 重新构造而不愿意重复使用已有的东西
4 难于坚持一个习惯
针对个人因素的几个建议：
1 具体的模型较抽象的模型更容易理解
2 从一个例子开始是容易的
3 通过观察他人的成果学习
4 要有足够的不受打扰的时间
5 分配的工作要与个人意向，能力匹配
6 不正确的奖励会有坏作用，从长期看个人兴趣比奖励更重要，培养在工作中的自豪感：
1) pride in work参与工作的自豪感，通常参与一个重要的工作会有自豪感
2) pride in accomplishment 完成工作的自豪感，长期未完的工作会使士气低落
3)pride in contribution 为他人贡献的自豪感
7 鼓励关心其他人的工作和整体的工作
在一个团队之间，交流是最重要的，实践证明面对面的实时的交流是最有效的，对交流的延误会损失信息，白板是最好的交流工具，交流工具的先进并不能提高交流效果。文档的作用是记录和备忘，不能通过文档交流。
敏捷开发方法要避免的过程设计的几个常见错误
1 对所有的项目使用同一种过程
2 没有弹性
3 过于沉重
4 增加不必要的“必须完成”（“should do” is really should？）
5 没有经过实践检验
敏捷开发方法过程设计的几个原理：
1 交互的面对面的交流是代价最小，最迅速的交换信息的方法
2 超过实际需要的过程是浪费的
3 大的团队需要重量级方法
4 处理重大问题的项目需要重量级方法强调
5 增加反馈和交流可以减少中间产品和文档的需求
6 轻量级方法更强调理解（understanding）,自律（discipline）和技能(skill)，重量级方法更强调文档（documentation），过程（process）和正式（formality）
understanding指整个团队关于项目的全部知识，包括讨论的过程，documentation只能记录其中的一部分
discipline是指个人主动的完成工作，process指个人根据指令完成工作
skill指具有良好技能的人可以省略中间的产品，formality指必须按照规定步骤完成工作
7 确定开发中间的瓶径，提高它的效率
对于瓶径处的工作应该尽量加快，减少重复，（使用更熟练的人，使用更多的人，使用更好的工具，使瓶径处的工作的深入尽量稳定）对于非瓶径处的工作可以多一些重复，在输入还不确定的情况下也可以尽早开始。
这些原理的几个结论：
1 向一个项目增加人员要花费较大代价（constly），因为原有人员和新人员之间的交流要花费大量时间
2 团队的规模经常是跳跃的，例子：需要6个熟练的程序员，但是只有4个，于是增加不熟练的程序员，结果团队的大量时间花费在培训不熟练的程序员上面，最后增加到了20个不熟练的程序员。
3 应该侧重于提高团队的技能而不是扩充团队
4 对不同的项目使用不同的过程
5 在适用的条件下，轻量级的方法优于重量级的方法
6 对不同的项目要裁减过程
敏捷开发方法的原则是“刚刚好”（Light and Sufficient）
（三） Crystal
Crystal是Alistair Cockburn提出的一组开发方法，分为Crystal Clear,Crystal Yellow, Crystal Orange和Crystal Red分别适用于不同的项目。项目可以按照参加的人员和重要性划分。重要性根据项目中的错误引发的后果分为：
C Loss of comfort （某些不舒适）
D Loss of discretionary money (经济损失)
E Loss of Essential Money (严重经济损失)
L Life Critical (生命危险)
一个项目称为C6说明参加人员在6人以下，重要性是C级，D20说明人员在6-20人，重要性是D级。
Crystal Clear适用于 C6,D6项目
Crystal Yellow适用于 C20,D20,E20项目
Crystal Orange 适用于 C40,D40,E40项目
Crystal Red 适用于 C80,D80,E80项目
Crystal Clear
适用于一个办公室内的一个小组
角色有： sponsor发起人，任务下达者
Senior Designer-Programmer 高级设计开发人员
Designer-Programmer 设计开发人员
User 用户
其中一个人是项目协调者(Project Coordinator)。Senior Designer-Programmer是关键人员
策略：
1 软件的开发采用有规则的周期性递增方法，每2-3个月提交（deliver）一个版本
2 使用里程碑(milestone)跟踪进度（包括delvier和开发期间的重大决定）
3 自动回归测试（automated regression test）
4 用户直接参与
5 每个release有两个user viewings(用户审核?)
6 在上一个步骤足够稳定（stable enough to review）时立即开始下一个步骤，尽量并行开发
7 在每个周期的开始和中间进行产品和过程调整
过程产品（指整个过程产生的所有产品，包括软件和文档）
1 软件释放顺序（release sequence）
2 用户审核的计划
3 用户案例（usecase）或需求描述
4 设计框架和必要的说明
5 界面草图
6 基本的对象模型
7 执行代码
8 migration code
9 测试用例
10 用户手册
11 local matters有项目组决定：
上述product的摸班
编码和用户界面的标准
回归测试的标准和细节
其他文档
需要的工具：
版本控制工具
白板（最好可打印）
Crystal Orange
角色：sponsor 发起人
business export/usage export 业务专家
technical facilitator 技术专家
business analyst/designer 业务分析和设计人员
project manager 项目管理员
architect 系统架构人员
Design Mentor 设计指导人员
Lead Designer-Programmer 主要设计编码人员、
Other Designer-Programmer设计编码人员
UI Designer 用户界面设计人员
Writer 文档写作人员
Tester 测试人员
策略：
同Crystal Clear (周期可以为3-4个月)
过程产品：
需求文档
计划
状态报告
用户界面设计文档
基本对象模型
外部接口标准
用户手册
源代码
测试用例
migration code
local matters 同Crystal Clear
（四） The Agile Alliance
敏捷联盟是17位不同敏捷开发方法的提倡者共同成立的，目的是推进敏捷开发方法的研究和应用，他们并不要求强制使用某种开发方法，而是提出了敏捷开发的几个核心价值和基本原则：
core value:
Individuals and interactions over processes and tools
个人和交流重于过程和工具
Working software over comprehensive documentation
正在运行的软件本身重于复杂的文档
Customer collaboration over contract negotiation
与客户的沟通和交流重于使用合同约束客户
Responding to change over following a plan
对变化的快速响应重于跟随计划
principles
1 最高目标是通过快速的和经常的发布软件满足客户的需要
2 提交软件的周期为几个星期到几个月
3 产生正确的软件是衡量进度的首要标准
4 主动接受需求的改变而不是拒绝
5 商务人员和开发人员工作在一起
6 个人必须有动力，要创造环境支持他们的要求，信任他们
7 最有效的交流方法是面对面的交流
8 最好的结构，需求和设计来自于自组织的团队（self-organizing team），允许任何人提出想法和建议
9 持续改进设计和编码
10 鼓励正常工作，减少长时间加班
11 保持简单，减少不必要的部分，认识到简单的设计比复杂的设计更难（simple design is harder to produce）
12 定期调整过程，获得更高效率
（五） Extreme Programming
Extreme Programming（XP，极限编程） 是一种轻量级的软件开发方法，它使用快速的反馈，大量而迅速的交流，经过保证的测试来最大限度的满足用户的需求。XP强调用户满意，开发人员可以对需求的变化作出快速的反应。XP强调team work。项目管理者，用户，开发人员都处于同一个项目中，他们之间的关系不是对立的，而是互相协作的，具有共同的目标：提交正确的软件。XP强调4个因素：
交流(communication)，XP要求程序员之间以及和用户之间有大量而迅速的交流
简单（simplicity），XP要求设计和实现简单和干净
反馈（feedback）通过测试得到反馈，尽快提交软件并根据反馈修改
勇气（courage）。勇敢的面对需求和技术上的变化
XP特别适用于需求经常改变的领域，客户可能并系统的功能并没有清晰的认识，可能系统的需求经常需要变动。
XP也适用于风险比较高的项目，当开发人员面对一个新的领域或技术时，XP可以帮助减低风险
XP适用于小的项目（人员上），人员在2-12人之间，XP不适用于人员太多的项目，事实上，在需求经常变化或风险比较高的项目中，少量而有效的XP开发人员效率要远远高于大量的开发人员。
下面是XP的开发流程
XP的原则和实践：
1 Planning:
1)user stories。
User stories类似use case，描述用户所见的系统功能，但避免使用大量的文档，user stories由用户编写（不仅限于描述用户界面）。User stories使用用户的语言编写，不使用技术性的语言，每个user stories限于几句话。User stories用于在release plan会议上对开发时间进行评估，也用于产生验收测试（acceptance test），必须使用可以自动进行的验收测试保证软件的正确性。User stories与传统的用户需求的区别在于详细的程度，user stories并不会确定需求的每个细节，它只是用来简单的描述系统功能，供开发人员进行估计开发进度，在开发过程中开发人员和用户会不断的交流以讨论细节问题。User story应该专注于功能，不应该过分注重用户界面等细节。一般一个user storiy在1-3周的时间完成，如果估计超过3周，说明user story太大了，需要细分。
2)release plan.
召开一个release plan会议，产生release plan。Release plan将用于指定每个iteration的计划。开发人员对每个user story估计开发时间（在不被打断，无其他工作情况下的开发时间，包括测试），用户对user stories给出优先级，release plan会议并不制订每个iteration的计划。Release plan要用户，开发人员和管理者都同意，在完成功能范围（scope），使用资源（resource）,时间（time）和质量(quality)上达成一致（一般质量是不能改变的）
3) small release
often and small release是XP的一个原则，每个release完成一些用户有意义的功能集合，尽快的提交给用户以获得反馈，及时调整，提交的越晚，调整越困难。
4）project velocity
团队在开发过程中要收集数据，以便于对自己的开发速度进行评估，用于以后的releazse plan
5)iteration
每个small release的周期称为iteration，每个iteration约为1-3周，在一个项目中保持每个iteration的时间相等，不要超前制定计划，每个iteration的计划在iteration的开始时制定。这样能够更灵活的应付变化。不要急于完成本次iteration没有包括的功能。要注重每个iteration的时间限制，当团队觉得不能按时完成iteration时，召开一次iteration plan会议，重新评估，减少一些user stories。
下面是iteration的图示：
6）iteration plan
在每个iteration开始的时候召开会议，从release plan中选择还没有实现的用户最迫切需要的user stories。上一个iteration中没有通过验收测试的功能也要在这个iteration中实现。可以根据上一个iteration的实践调整团队速度。User stories和失败的测试被分解成programming task，task使用技术语言编写，作为iteration plan的详细描述。程序员主动领取task并估计完成时间，每个task应该在1-3天内完成，超过3天的task应该被细分。如果整个团队需要的时间多于或少于规定的iteration时间，调整user stories。
7）move people around
不要使每个开发人员局限于一项工作，不要使某项工作依赖于一个开发人员，增加知识共享，减少信息孤岛，多进行交流和培训。当项目中的所有人对所有模块都了解并可以进行开发时是效率最高的，鼓励开发人员在不同iteration中开发不同的模块。
8) stand-up meeting
每天工作开始之前，开5-10分钟的stand-up会议（站立会议），站立的目的是为了强迫节省时间，会议的目的是交流，提出存在的问题，但不要在会议上解决问题。开一个所有人员参加的短会比多个个别人员参加的会议要高效。在会议上提出的问题可以由少数人讨论解决，这个少数人参加的会议如果涉及到代码，可以在计算机前讨论。
9) fix XP when it breaks
XP并不是一成不变的，当团队觉得需要修改的时候，可以根据自己的情况进行修改，任何修改都要经过整个团队的讨论和达成一致
2 Designing
1) Simplicity
保持简单的设计，在完成同样的功能的情况下，选择简单的设计，不要急于设计没有计划的功能，应该认识到：keeping a design simple is hard work
2）system metaphor
使用统一的术语描述系统，在用户，管理者和开发人员之间使用统一的术语。这将使交流清晰。
3）CRC card
使用CRC(Class, Responsibilities, and Collaboration) card进行系统设计，鼓励更多的人参加设计。每个CRC卡片表示系统中一个对象，写上对象的名字，责任和每个责任需要交互的其他对象。可以模拟对象之间的交互。CRC卡片是易于理解的，但是是非正式的，如果需要正式的文档，要将卡片转换为相应的文档。
4) spike solution
使用spike solution减低风险，当遇到技术难题或设计问题时，使用简单的程序进行测试，找出问题，在不同的解决方法之间进行评估。在早期进行实验可以有效的降低风险。
5）never add function early
不要过早的设计没有计划的功能，在一个需求经常变化的环境中，过早的设计经常是没有用的。
6）refactoringwhenever and wherever
XP鼓励对设计和代码经常进行重构（Refactoring），目的是去除冗余，提高质量，保持设计简单。重构必须以完全测试为检验条件
3 Coding
1) customer is alaways available
用户是项目组的成员之一，用户的参加贯穿整个开发过程，用户与开发人员之间的交流是重要的
2) coding standard
使用统一的编码标准，这是保持代码整洁和共享代码的基础
3）coding unit test first
test first是XP的一个特点，在编写代码之前先编写单元测试代码，单元测试代码和代码由同一个程序员完成。先编写测试代码可以使程序员更好的理解需求，避免直接编码造成的理解偏差，对需求的不清晰，可以在编写测试代码时就发现。测试代码也是检验程序是否完成的标准。编码工作应该是以下工作的循环：
1 编写测试代码
2 运行测试程序，确认失败
3 编写实现这个测试程序要求功能的代码，不需要实现其他的功能，只需要实现刚刚满足测试程序的功能
4 运行测试程序，确认成功
实践证明，test first方式需要的编码实践少于先编码，后写测试代码
4) Pair Programming
Pair programming是XP的特色，它要求两个程序员在一台计算机上同时进行编程工作。共用鼠标和键盘，通常一个人进行战略上的思考，程序架构和函数，类之间的关系，一个人进行输入和战术上的思考，完成函数和类。两个人可以经常交换角色。Pair programming需要一段时间学习和适应，实践证明pair programming并不消耗更多的时间(人*小时)，但是代码的质量得到很大的提高。（避免将两个新手放在一个pair中）
5）sequential integration
要保证源代码库的状态是可标识的，同一时间，只允许一个pair的程序进行整和和测试，这样可以缩小问题产生的范围。不同的pair可以在自己的机器上随时进行整和和测试.
6) integrate often
只要有可能就进行代码整合，周期可以在几个小时，最好不要超过一天。经常的整合可以避免错误的积累，可以增加可重用的代码。在一个pair认为适当的时候并通过了所有的unit test，就可以进行整合，整合后的代码必须通过测试。同一时间，只允许一个pair进行整合。(整合失败是不是要退回原有状态，供其他pair整合？？)
7) 共同拥有代码
鼓励每个人对项目中的任何人提出新的想法，任何开发人员对项目中的任何代码都可以进行增加功能，改正错误和重构。没有代码或开发人员成为瓶颈。（我的想法：这确实很难理解，但是这确实是我梦想的目标）。为了达到这个目标，任何的代码都必须有相应的测试代码，任何代码的修改必须100%通过测试。必须加强开发人员的交流和知识共享，必须坚持统一编码标准。Pair programming可以经常交换伙伴。
8）优化工作放在最后
先使系统能够正常工作，不要猜测系统的瓶颈，要实际测量
9）NO overtime
不要长时间的加班，大多数加班并不能挽回已有的延迟，连续超过两个星期的加班说明有问题存在。向一个已经延迟的项目填加人员也不是一个好的选择。
4Testing
1)所有的代码都有单元测试
单元测试是XP的基石，XP中的单元测试应该是可以自动进行的，所以可以很快的进行所有的单元测试，单元测试应该在编码之前创建。单元测试的代码和代码一起release，没有单元测试的代码不能够release。使用自动单元测试可以系统整合时节省大量的发现错误和改正的时间。单元测试越完善，节省的时间越多。对面向对象的编程来说，应该对每个类都有单元测试。完善的单元测试也是共同拥有代码的保证。单元测试也是可以经常重构的保证，每次重构后的代码都要重新进行测试
（这里的unit test好象不只限于测试某个模块的功能？？？，应该可以测试整合起来的整个系统，这样才能保证整合的正确性。）
2）代码在release前必须通过所有的单元测试
3) 发现bug后，首先增加测试
在实际运行中发现bug,首先增加acceptance test，然后增加unit test，在增加完测试后在查找和修改代码，增加的测试保证同样的错误不会再出现
4) acceptance test
acceptance test根据user stories在iteration plan会议上创建，它也应该可以自动运行以便可以经常运行。User stories是否完成是以是否通过acceptance test为检验标准。
XP中的角色：
1 customer 用户
在XP中，用户是项目组的一部分，用户负责编写use stories，确定优先级，和开发人员讨论需求，编写accept test，运行accept test，用户驱动iteration(release plan, iteration plan)
2 开发人员
与用户讨论user stories，估计开发时间，将user stories细化成programming task
编写unit test
编码
进行重构
整合及测试，保证100通过
3 manager
负责对外联系，组织团队，获取必要的资源，管理团队
4 tracker
跟踪release plan/iteration plan/acceptance test
5 coach
起顾问指导作用，mentor, monitor and help
A Coach is respected, but also respectful. They’re willing to talk, but also willing to listen. They let the team explore, but provide a guard-rail in case of danger.
监督进展，确保过程和规则，必要时改变过程，帮助解决问题，也可以参加pair programming。