什么是敏捷开发

本博在很多地方，都有人提出自己的开发方式就是敏捷开发。但本博实际上看到的情况更多的是，以敏捷开发为借口来避免写各种各样的文档，几乎是什么事情不想做，就用敏捷开发挡一挡。

比如，需求分析没有做好，就进入编码阶段，说辞是：我们要敏捷开发，快速响应需求的变化，既然能够快速响应需求的变化，那么需求做没做好就不重要了，重要的是敏捷开发能够快速响应需求的变化。又如，在开发的过程中，不进行良好的模块划分，不写测试用例，也说是敏捷开发，说代码可以重构，写测试用例浪费时间等。

本博在这里将讨论敏捷开发到底长啥样，期望通过这里的讨论让大家能够真正从敏捷开发中获利。

敏捷VS瀑布

好的敏捷开发与瀑布开发都有同样的特征：项目是可控的。 敏捷与瀑布两种开发模式只是适用的场合不同，并不是敏捷开发就优于瀑布开发。所以，如果真有人拿敏捷开发来否定瀑布开发，基本上可以肯定地说，这个人还没有懂敏捷开发。

项目为什么可控？首先，项目到达什么状态是可知的，没有可知，哪来可控。所以，一个项目会在时间先后上分出不同的阶段。每个阶段到了没有到是可知的。好的瀑布开发模式，每个阶段都产生一定的产出（如文档，代码），并
由专家对产出进行评审 （测试），评审通过之后就意味这个阶段做完了，通过每一次评审，项目参与人员就知道项目的状态是什么。这就是可知。

敏捷开发同样需要知道状态，敏捷的方式就是，将阶段划分更加细粒度，使得 非专家都可以得到项目的状态 。从这里可以看到敏捷开发与瀑布开发的区别：划分出的项目阶段的粒度不同。

在了解项目的状态之后，可以根据下一个阶段需要达到的目标分配人力或者物力。这样可以控制项目的状态变迁。很显然，瀑布开发模式需要经验丰富的人去做这样的事情。而敏捷开发由于阶段很小，对资源分配者的要求就大大降低了。

瀑布开发由于有具备经验的人主导，从而可以在项目的最开始到结束都使得开发处于控制之内。敏捷开发由于阶段更细，从而可以快速地实现部分功能并快速地响应变化的需求。

敏捷开发流程

敏捷之所以快，是因为敏捷开发划分的目标小，容易实现，并且可以将已经开发出来的部分很快地移交给客户去体验，然后根据反馈进行增量改善，从而让人看起来很快。

敏捷开发的流程：

将项目目标分解为用户可以测试的任务
根据功能的优先级将任务放入到各个版本中
依次实现各个版本

分解任务

在分解任务的时候，主要原则是，任务可以为用户所理解。从而用户能够知道一旦该任务完成意味着什么。

本博曾有文章说，项目管理就是消除不确定性，如果所有的任务都被分解完，并且所有的任务都可以被用户理解。那么目标完成与否就是很确定的事情。也就是说，一个项目完成与否的测试标准已经有了。

划分版本

将任务分解完成之后，根据优先级将各个任务放在不同的版本中，放入版本的原则是：确保每个版本可以快速完成。快速完成指，最长不超过五天的时间。如果超过五天没有完成，就要重新审视是否每个版本的任务太多了。之所以不能超过太长的时间，是因为时间太长才知道没有完成的话，风险就会很大。时间很短就知道没有完成，就可以尽快采取相应的措施（如，增加人手，减少每个版本的任务量等）。

项目管理就是消除不确定性中提到的横向划分，就是指每个版本可以由多人开发人员并行开发，从而解决速度问题。

实现各个版本

项目完成的整体标准有了，并行划分也有了，接下来就是按照各个版本去实现了。每个版本做完，都需要测试人员进行测试，并将问题写在任务列表中，再将问题划分到后续版本中去。当所有的版本都完成的时候（包括测试出来的问题形成的版本），项目就完成了。

总结

通过这里所介绍的敏捷开发流程，已经将项目管理就是消除不确定性的进行具体化。这只是消除不确定性的一种方法，针对不同的项目，还需要进行不同的考虑。虽然这只是消除不确定的一种方法，但足以应付很多场合了。

对于大型项目，或者涉及到重大安全的项目，可能要在开发前期进行反复论证，这使得项目不得不走瀑布开发模式，这时个，消除不确定性的方法就有所区别了。

本博遇到的大多数项目管理人员的是时间点，本博要强调的是，完成的测试标准确定下来，时间点才有意义。没有完成的测试标准，时间点就是给自己心理安慰一下而已。