敏捷开发，英文是Agile，我所理解的敏捷

理论上的知识我看的不多，没有很准确的概念，我想无论哪种开发方式都有自己的理论基础，和相应的方法步骤，比如 瀑布模型，增量模型，迭代模型，敏捷方法等，

并且由于项目不同，比如是否是新项目，二次开发项目，或者是维护项目，采用的方法也不尽相同，没有固定不变的，不同的公司也可能不一样，所以我只是说说我所理解的敏捷，和项目中用到的敏捷方法

我的理解是快速迭代，持续交付，一种轻量级，高效，低风险，更强调团队协作和沟通的开发方式，客户需求模糊或多变，

适用于中小团队开发，每个团队人员不宜多于6，7个，

敏捷我认为首先最重要的是沟通，就是 BA和开发人员，和QA的高效沟通，缺少任何一个都不会很有效率和效果

敏捷的过程中基本保证每个迭代都是可以测试并验证的，项目上要有完成一个迭代的时间，比如2周，3周，这包括如下几部分

1，BA，系统需求的人尽量要知道他要什么功能点，也就是function point，

2，开发人员要理解这个功能点，并和BA做沟通，要保证自己能理解这个需求，如果不是很理解，就要进一步沟通，这个过程中沟通很重要，因为BA可能并不完全了解系统的数据流，所以互相之间可能有偏差，沟通的目的就是确保开发人员完全理解这个需求，并实现它，开发完成后，要有时间做单元测试，集成测试等

3， 当上一步完成后需要BA去验证这个功能点的正确性

4， 当BA完成后，QA不仅要做这个功能点的测试，还要做一个系统相关性的会回归测试，保证没有影响到其他功能点

但实际上，我在有一个项目中用到的敏捷，虽然从一开始就在用，但是也不是很流畅，我认为其中的原因就是，用户的需求不能及时的得到沟通和反馈，其中的原因是BA和开发，测试的人，不在一起，不在一个时区里，很多时候只能通过写邮件的方式沟通，这显然不是高效的方式，后来项目做了些改进，就是开发团队开始有BA了，情况得到了一些改善， 

所以我认为下面两点很重要 

1 真正的用户需求，

2 软件持续交付过程中的，全方位的自动化测试，你新加个功能还好说，如果不对现有的功能产生影响，只要保证这个新的好用基本就可以了，但是如果这功能需要修改已有的代码，那么就不只要保证当前这个功能好用，还要对相关项做全方位的回归测试，从业务上，功能上，保证系统的可用性，


敏捷开发每个人每天要做的

项目里要有个黑板，这个黑板每个人都要参与进来，用来跟踪功能点的状态，

找个时间，比如时间控制在10分，15分钟内，根据实际需要或者项目组制定的流程，选择性的做下面当中的一个或几个

每个人都要做下面这3件事， 

1 昨天做了什么

2 今天做什么

3 有没有什么问题导致你不能往下开发

每个人都把自己的功能点的今天的状态向大家说出来，说出来的目的是让大家了解你做的东西和他们的有没有相关性

每个人都把自己的功能点在黑板上挪动到你当前的状态，之后把他风险提出来，大家看看有没有遇到类似的问题，集思广益，会后也许会有思路

这么做的最主要的目的，我感觉就是尽早的发现每个迭代可能遇到的风险，做到提前预知和可控

我认为无论哪种方法，都是要达到快速，高效，准确，低风险的完成项目的目标，所以他的步骤并不是固定不变的，只要达到这个目的就可以了

我本身不喜欢所谓的流程，及文档，因为好的代码结构就是文档，文档适当记载系统大概业务及数据流向即可，因为如果文档不能一直维护就会成为麻烦。

但实际上，我认为最好的开发方式就是，BA在开发者身边，有问题随时沟通，做到快速，高效，

其他的所谓流程，步骤都不重要，只要完成的东西达到BA的要求才是最重要的