敏捷式流程与瀑布式流程

敏捷式流程

什么是敏捷？

    敏捷是指能够让团队思考更加有效，工作更加高效，并且作出更好决策的一组方法和相关理念。

敏捷能够带来的直接效益

1. 项目可以按时完成。
2. 项目会交付高质量的软件。
3. 项目的代码结构优良且易于维护。
4. 不会交付无法为用户带来价值的软件。
5. 开发人员不用加班。

敏捷软件开发宣言

1. 个体和互动高于流程和工具。
2. 可工作的软件高于详尽的文档。
3. 客户写作高于合同谈判。
4. 响应变化高于遵循计划。

敏捷的核心

    敏捷是一种思维模式，所有敏捷方法的重点都是改变团队的思维模式，正确的思维模式有助于团队成员共享信息，从而共同做出重要的项目决策，而不是让经理独自负责所有的决策。

敏捷小试-每日站立会议的困惑

    一个项目经理想要在团队中开展每日站立会议，却惊讶的发现并不是所有人都立即表示赞同，有的人觉得每天的会已经够多了，又要增加一个会议，会耽误自己开发代码的时间，会导致加班。

    那么这个时候项目经理就要给大家说明，站立会议不仅仅是为了检查团队成员是否偏离了自己的计划，还要尝试李解群策群力下计划可能要发生怎样的改变。要让每个开发人员意识到，在项目中所有人都是平等的，都是项目的决策者，在站立会议中可以聆听其他项目参与者将项目开发到什么方向，一个优秀的开发人员不仅对自己的代码有想法，而且常常对整个项目的发展方向怀有见解。

    即使还是仍然有人觉得每日站立会议就是仓促的汇报每日的进度，那么从长远角度来讲，站立会议还是有必要的，他会对项目经理自己和整个团队都有帮助。

瀑布式流程

瀑布式的一般流程

    首先会有人对要开发的软件写出一份详尽的描述。然后将这份文档交付，由用户、经理和主管同意后，将这些描述写一份需求文档，再将这份需求文档交给开发团队进行构建，最后测试团队介入，验证完成的软件与需求文档是否匹配。

瀑布式流程经常遇到的困难

1. 需求说明书经常变化，到达开发团队手中的那一刻，需求说明书可能已经不是很准确了，当开发团队完成软件构建的时候，需求说明书可能已经面目全非了。经常会出现客户中途反悔，要求开发和最初计划完全不同的功能。又或者出现客户和客户经理以及主管确定了要更改的功能，但是并未即使通知开发团队，直至最后才发现做的不是所要的内容。
2. 即使团队完全理解了需求，需求不予变更，也会常常因为使用糟糕的工具，而且在软件设计和架构设计上遇到了很多困难，结果团队总是开发出有很多bug的软件，并且往往混乱而不可维护。又或者需求变更了，但是开发人员并不愿意舍弃大量已经编写完毕的代码，就会在现有代码上商定出一个修改方案，这样完成的修改极易出现bug。

瀑布式流程缺点

1. 过分严格的文档。
2. 糟糕的沟通。
3. 代码中的大量bug。

瀑布式流程完成优秀软件的特点

    虽然瀑布式流程有一些缺点，但是仍然有很多优秀的软件是使用瀑布式流程完成的，并且稳定的需求并不是瀑布式流程成功的唯一因素。优秀的瀑布式流程开发的软件都有如下特点：

1. 沟通顺畅。开发团队会不断的与用户、经理和主管沟通，确保所有的修改都在最开始阶段。
2. 实践得力。积极引入代码审查以及自动化测试。阶段性的进行代码审查，自行查看代码中的问题，并且引入自动化单元测试，辅助定位。也就是说，要求团队主动思考bug是怎样产生的。
3. 多数文档很少打开。大部分瀑布式的团队都明白，写下计划的重要性远远比严格执行这份计划要重要的多。