关于敏捷开发

进入项目组到现在也就大概一年半，而在这短短的一年半时间内，经历了传统的瀑布开发模型、XP

编程模型探索、到现在的敏捷开发。
      刚开始的半年是传统的瀑布开发模型：一个月做需求，一个月做prototype，然后两个月开发，开发出来之后QA才开始介入，然后就是两个月的bug fixing，最后产品上线。这种模式带来两个棘手的问题：1）如果需求变更频繁（很正常的），特别是越到开发的后期，这种需求的变更往往会带来越多的工作量和复杂度，而这样往往又会引入很多新的defect，从而产品的质量变得很不稳定；2）从时间上看，从开始做需求，到客户能够看到产品（还未必能使用呢），至少需要半年的时间。而对于我们这个属于市场探索型的项目组，半年的时间足以让市场变两番，也就是说产品跟不上市场。
     于是大家就想着是不是可以用一些别的开发模型。由于没有请咨询公司，所以就只好自己摸索着来。刚开始选了XP编程中的几个方法：Code Review, Standup Meeting, Story wall, Pair programming. 但实施起来真的很难，有时连做都没做，即使做了也从结果中看不出成效。就这样大概挣扎了4-5个月，“机缘巧合”，我们项目组抽调到现在这个大项目组，做另外一个系统。而这个大项目组是按照敏捷编程（Agile programming）是来工作的,他们之前请过一个蛮大的咨询公司来指导实施Agile practice。所以我们也可以借着这个机会，好好学习Agile programing应该如何实施。
      维基百科上对Agile的解释是这样的：Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.我们按照主谓宾来看看：1）敏捷开发是开发方法，但它不只是一个方法组成的，是由一组方法来实现的。2）它是基于迭代开发的。百度知道上的解释是：这种每次只设计和实现系统的一部分,逐步逐步完成的方法叫迭代开发, 每次设计和实现一个的一个阶段叫做一个迭代. 也就是说，每一次只实现了系统的一部分功能，但这部分功能是完整的，用户完全可以使用的。我觉得迭代开发是针对需求不稳定而生的，我们前面说到了瀑布开发模型对于需求变更会很烦，因为很多时候是基于需求稳定的全局设计，但需求一变就意味着整个系统都可能会变，这样的事情太恐怖了。所以迭代开发出现了，一个完整的迭代大概就一个月，如果用户觉得需要增加哪个功能，或者他要的不是这样的页面，没关系，下个月客户就可以看到他想要的。
       一个迭代式开发的流程大概如下图：

 

     除了定义之外，大家还为Agile设立了4个宣言：
1）Individuals and interactions over processes and tools（个体和交互重于 过程和工具）
2）Working software over comprehensive documentation（可用的软件重于 完备的文档）
3）Customer collaboration over contract negotiation（客户协作重于 合同谈判）
4）Responding to change over following a plan（响应变化重于 遵循计划）

Agile的定义里面说它是一组方法组成的，下面我们可以看看Agile的兵器库有哪些：

 

林林总总大概有20个主流的实施，我们这边采用的大概有13个，分别是：
1)      Automated Build/Deployed
2)      Automated Testing
3)      Coding Standards
4)      Continuous Integration
5)      Pair Programming
6)      Card Wall
7)      User Stories
8)      Refactoring
9)      Simple Design
10)  Test Driven Development
11)  Retrospectives
12)  Daily Stand-ups
13)  Iteration