什么是敏捷开发

    可配合敏捷开发入门教程一起看，文中内容参考自《敏捷软件开发 原则、模式与实践》（Agile Software Develoment Principles,Patterns,and Practices），俗称 3P。

    刚进入 21 世纪的第一（2001）年，由于看到许多公司的软件开发团队陷入不断增长的过程的泥潭，一批业界专家组成了敏捷联盟，在随后的几个月中他们发表了一份敏捷联盟宣言，如下所示。

1. 个体和交互胜过过程和工具
2. 可以工作的软件胜过面面俱到的文档
3. 响应变化胜过遵循计划

    上面价值观指出，编译器、源代码控制器、 IDE 等工具对于团队的开发者至关重要，但是不要过分夸大这些工具的作用，使用过多庞大又笨重的工具就像缺少工具一样，敏捷团队应该从小的工具开始，直到它无法适用时才去更换它，总结为一句话就是工具用的舒服才是硬道理。

    很多大型公司注重面面俱到的文档，但是他们忽略了一个很致命的问题，那就是文档是一个非常难维护的东西，文档和代码很容易失去同步，过多的文档实际上比过少的文档更糟，应该只编写一份系统原理和结构方面的文档。对于团队新人来说，最好的文档只有两份，即团队和代码。

    敏捷团队应该每天和客户在一起工作，以便于向他们进行日常性质的交付，也能快速响应客户提出的一些改动需求，响应变化的能力常常决定一个软件项目的成就，因此我们的构建计划应该是很灵活并且易于适应商业和技术变化。

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

序号	原则
1	我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
2	即使到了开发后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势
3	经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好
4	在整个项目的开发期间，业务人员和开发人员必须天天在一起
5	围绕被激励起来的个人构建项目，给他们提供所需的环境和支持，并且信任他们能够完成的工作
6	在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面交谈
7	工作的软件是首要的进度度量标准
8	敏捷过程提倡可持续的开发速度，责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
9	不断的关注优秀的技能和好的设计会增强敏捷能力
10	简单——使未完成的工作最大化的艺术——是根本的
11	最好的架构、需求和设计出自于自组织的团队
12	每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后应对自己的行为进行调整

    敏捷理论认为，人是项目取得成功的最重要的因素，所以其他因素都被认为是次要的，所以团队成员哪里不舒服了，就要对哪里进行改进，应该是个程序员都希望老板能明白这一点。

    在团队内部也没有特定的责任划分，每个人都有权利拆出任何模块并对其进行改进，而且团队成员也不需要人尽其能，比如我擅长前端方面的工作，但是如果我愿意，我也可以领取后端模块的任务，这样开发人员就会对整个项目有更加全面的了解。

    敏捷过程讲究的是迭代增量开发，将大的任务拆分成很用户故事（小需求），开发团队会快读发布一个可用但不完善的初始版本，然后不断的进行迭代，每次迭代都按照软件工程的方法论进行流程管理，会完成新的、用户可见的功能，通过迭代来逐步改进软件，并且保持高频次的交付计划，交付频次越高，最终软件质量越高。项目完成进度也以当前软件能满足客户需求的数量来度量，即客户要了 10 个功能，现在只有 3 个功能可使用，那完成进度就是 30%。

    另外建议使用测试驱动开发(TDD)方法，其好处在于程序中的每一项功能都测试来验证它的操作正确性，而且先编写测试用例会迫使我们从程序调用者的角度去审视我们编写的程序，会在不知不觉中促使我们重构代码。不仅如此，测试用例还可以作为一种无价的文档形式，而且对后面的集成工作提供了天然的支持。

    每一个软件模块都有三项职责，第一是它运行起来所要完成的功能；第二是它要应对变化；第三是要和阅读它的人进行沟通。所以重构活动应该是我们每隔一两个小时就要进行的，好比吃完饭就要洗碗清理厨房一样，重构是保持软件模块三项职责的手段。但实际上这好像只是一种愿景，大多数软件都只具备第一项职责，后面两项职责则变成了可遇不可求的东西。