敏捷开发/敏捷编程介绍

首先声明，本文并不是官方的或者专业术语化的介绍，只是根据自己的理解所写，如果有错误，请帮我指出来。

敏捷开发的理念已经流行了很长的时间，之所以能够成为一种开发过程的指导性理念，是因为有几个世界级的高手力挺它，甚至成立了敏捷联盟，看看联盟宣言里签下的名字，每个人背后的经历都足够我们敬仰一阵子的。

敏捷开发理念从根本上讲，跟传统的瀑布式项目管理是不同的。软件开发过程并不像生产手机或者鞋子的流水线，只要标准定好所有的步骤都一丝不苟，只要中间没有过程出错，最后的产品就是成熟的合格的。软件开发过程充满了变数，唯一不变的就是它会变，需求会变，环境会变，资源会变，一切都会影响最终的结果，所以，你不能写下一个标准流程然后就指望所有的开发人员就能依据他提交给你一个让你满意的产品。

为了应对这种变化，敏捷开发的最首要理念是：迭代式开发。在项目的构思阶段，用户也无法讲出完整的需求，甚至用户亲口告诉你的需求并不是他想要的东西，只是他没办法描述出来。在这个时候，你需要抓住用户需求里面最关键的要点，重要性低的需求点可以往后放。收集到足够的需求点之后，将这些需求贯通起来，组织出一套完整的系统需求。然后，你需要定义一个迭代周期。迭代周期分为开发周期和交付周期，如果是中小型的项目，两者可能是一致的，每一个开发周期同时就是交付周期，但是如果是大型项目，可能需要几个开发周期才能够拿出一个可以交付给用户的产品。

每一个开发周期的推荐时长为1周到6周，两个月以上的开发周期就会造成目标的混乱和过程的难于控制。敏捷开发的使用最广的一种指导方法是XP，也就是敏捷编程方法。XP强调每半小时Commit一次，每天生成项目，也就是说，所有的成员需要频繁的提交自己的代码更改，以免同别人造成过多的代码冲突，每天对整个系统进行生成，如果发现错误马上修正，这样就可以尽量的保证整个项目是完整的，不会导致积累太多的问题而致使某个模块需要做大修改才能跟上项目，影响别的模块的开发。

在项目的初期，通常会有一些公用的功能和模块，比如配置文件处理，输入输出处理等等，如果这些功能没有开发，其它依赖的模块就无法开始工作，然而开发这些功能也不是一时半会儿就能完成的，那么，当某个人员在做这些事情的时候，其它人是不是就没事可做，只能等着了呢？

这里对项目的设计水平就有了比较高的要求，各个模块之间需要做到尽可能的松散。公用的模块可以先使用空的方法（或者只有一行Return语句的方法）来填补位置，让所有人员可以开始做自己的部分，（但是别忘了写下测试这些函数的完整的单元测试代码，否则哪个函数还没有完成就无据可查了。）接口通常能够比继承更容易做到松散的结构。

每周开始的时候，所有的成员坐在一起报告上周自己的完成情况，分析剩下的需求点，对每一个需求点明确工作任务，当所有的人都明确了每一个需求点的时候，自己认领自己要完成的部分，然后开始一周的工作。当所有的需要点已经确认，成员开始了本周迭代的开发之后，任何新的需求或者发生变更的需求都不能直接影响开发人员，由某一个人（项目经理或者开发经理）汇总所有的需求，放到下周一来讨论。这里又会有一个新的问题，就是重复劳动的问题。如果本周已经确立并开始开发的需求点发生了变更，留到下周再改的话本周的工作不是白做了吗？但是，如果告诉那个负责该需求的开发人员马上去改，该需求很可能就会连累到其它相关的任务。如果每个模块或者函数的设计相对简洁，那么，等到下周修改这个需求或者干脆推倒重做也不应该引起太大的问题。重点是，你需要保持所有人员的开发进度，不能互相影响。

每天下班前，你的系统能够自动从源码管理器里取出所有的代码进行编译生成操作（甚至打包发布），有任何问题可以即时的通知管理人员，然后找到相关的开发人员解决该问题。

每个交付周期的结束，需要向客户展示已经完成的部分，（每一次迭代拿出的都是一个稳定可用的系统，但是功能可能尚未完整），当用户看到眼前的东西，就会想到更清楚的需求，可能会推翻其中某些已完成的功能，修改某些功能，放弃某些尚未完成的功能。于是给下一次迭代确定了更加明确的需求。

敏捷编程并不仅适合中小型的项目，（实际上大部分讲解敏捷编程的书上举的例子都是周期长达一年半以上的大型项目），对于总周期3到6个月的项目，开发的交付的迭代周期可以一致，每一到两周一次交付，每一次交付都是一个稳定可用的系统，每一次添加几个最重要的功能点，直到项目完成。对于6个月以上的大型项目，开发迭代周期可能在2周到4周，每三四个开发周期进行一次交付测试，然后获得新的需求。