瀑布式还是敏捷式？非纯软件公司开发模式如何定

十几年前主流的IT公司几乎全部使用瀑布模式进行开发，但是随着互联网的兴起好多公司开始接受敏捷模式进行开发。

现在好多规模不大的非完全软件公司在开发软件项目时到底应该如何根据自己的实际情况选开发模式？

为了节约大佬的时间我先说结论再分析原因，对于时间紧张的大佬可以不看后面的具体分析。

结论：

第一类：工具类软件和通用产品类软件开发公司、给管理规范的大型企业开发软件系统的公司、对日外包公司 适合用瀑布模型。

第二类：小型互联网创业公司，业务变化频繁的产品软件，给大部分政府项目开发系统的外包公司等 适合敏捷开发。

第三类：许多细分行业的IT服务公司 应该使用瀑布加敏捷的模式，也就是部分功能用瀑布部分功能用敏捷。

分析：

关于瀑布模式和敏捷模式的具体运行方式和优缺点分析的书籍和资料网上一大把，最核心的大概如下几点：

瀑布式的优点：各阶段文档齐全，软件质量高，里程碑方式开发进度容易把控（相对于项目团队之外的人来说，只要关注一共有多少阶段，每个阶段完成的百分比即可。），人员可以梯队配置，加入一定量的新手不影响项目质量。

瀑布式的缺点：开发成本较大（为了保障质量要做的事情多了成本当然上去了），项目需求必须要稳定，如果需求变更频繁代价太大（需求变更频繁的话，各种文档和评审会消耗的成本比代码本身的成本要高的多），项目开发速度较慢

敏捷开发的优点：项目开发速度较快（按阶段上线开发结果），相应变化和解决BUG速度快，开发成本较小

敏捷开发的缺点：文档比较少、项目组成员需要更强的个人能力。

目前第一类公司和第二类公司在选开发模型时定位还是比较清晰的，第一类公司肯定会用瀑布式，第二类绝大公司会用敏捷开发。

第三类公司既羡慕互联网公司的开发速度，又想要第一类公司的开发质量。本来这是鱼与熊掌不可兼得的，但是特定情况下还是可以做的。

比如一家专门给银行做排队叫号系统的公司，他可能不是一家纯软件公司，因为叫号系统的硬件成本占很大一块，可以把通用功能（读银行卡号或身份证进入排队功能，叫号功能、外接大屏幕显示等）按照瀑布模式做成基础产品，有齐备的文档及接口说明。把与银行的接口和界面做成放到二次开发用敏捷开发的模式去快速对接银行内部系统（比如现在我刷一下身份证银行就知道我是几星客户，应该能排在哪个队列，这个就要与银行系统对接才能实现，而每家银行甚至同一家银行不同地区的分行系统都不一样）。

只要基础产品功能做好做稳定，以后叫号系统的开发成本就会非常低，具体到单个项目时就会又快速又稳定。

实例分析：

接下来说一下一些企业在实际工作中碰到的一些误解：

瀑布式开发相当于“结硬寨 打呆仗”，瀑布式保障项目过程中尽量不引入问题，每一个阶段都要把问题解决完，不能遗留问题到下一环节。那么如何保障每一个阶段的问题解决完就成了项目经理把握项目质量的关键。

那么怎样验证每一阶段的成果物是正确的呢？我们以详细设计文档为例。有些人以为用评审会来保障（如果是评审《项目计划书》时的确可以在一次评审会中让相关人员把该文档从头到尾仔细看一遍）。 但是随便一个普通的项目的详细设计文档起码是上百页起的，让大家在一次会议里怎么可能看的完？有的公司会在详细设计完成后安排个小组长来review详细设计的质量，然后项目经理负责把控小组长的review质量。看上去这个方案是已经有人把控《详细设计》的质量了，而且最终还有项目经理最终把控，但其实这个方案也是漏洞百出，首先小组长肯定也有自己的任务要完成，在项目紧张时（做过项目的都知道紧张是常态）怎么保障他能认真仔细的review组员的《详细设计》呢？同样的问题项目经理在繁忙的时候又有多少意愿来仔细检查小组长的工作呢？哪怕你选的项目经理是个和负责人的人，但是他面对多个小组长的工作顶多就是抽查，抽查的覆盖度才多少？那么没抽查到的文档质量如何只有天知道？

正确的做法是把人员分成设计人员、编码人员和测试人员三个独立团队，每个团队都分组且配有组长（一个大项目每个团队都可能不止一个组）。在设计人员编写好《详细设计》文档后，让编码人员和测试人员来读设计文档并根据自己的理解写出QA和测试用例，等到详细设计阶段完成开评审会的时候项目经理只要看QA数量和详细设计的修改频率就可以知道《详细设计》的质量如何。项目经理和组长在这里主要起到指导团队成员按照规范流程去操作。等到项目完成出现处理BUG时开发人员一定会首先去看设计文档是怎么写的，如果设计文档是对的但是编码的时候没实现那么就是编码人员和测试人员的责任，如果是设计文档里没有考虑到那么就是设计人员的责任，改这个BUG首先要改设计文档（甚至设计人员会追述到需求文档）然后再改测试用例和代码。按照这个瀑布流程做下来后才能保证文档和代码的质量。

其实这里是利用人性的特点打造了一个三方互相制约的机制（如果算上需求文档那么是四方） ，一旦出现BUG开发和测试人员肯定追述上一阶段的文档是否正确来给自己“开脱罪责”，而上一阶段的人员肯定也会尽量再往上追述。反过来需求和设计人员为了减少后续可能出现的“被追责”也会尽力保障产出物的质量。

要想保障这种瀑布模式真的起作用核心因素就是要把需求、设计、编码和测试这些角色独立分开，且不可一人兼任复数角色，这是保障质量的前提，虽然每一阶段产物流下去需要换人重新理解消耗了很多成本，这个重新理解的过程本身就是对上一阶段产物的把关。有的公司既想要瀑布式的优点又觉得成本太高于是把人按照功能分组，既一个小组负责从需求、设计到编码实现（测试会保障独立），这样虽然提高了效率但是没法保障每一阶段的产物质量。

还有一些项目（特别是一些政府项目）因为赶进度先把功能开发实现了，然后再去补各种文档。我敢说这些文档都是随随便便赶工出来的（数据库设计可以利用工具把数据库逆向导出成设计模型，但是其他文档据我了解没有这个办法），基本上都是没有任何价值的垃圾文档。如果是务实的企业完全要么接收瀑布式的成本换取高质量的文档和代码，要么就干脆放过可怜的程序员吧(不要求文档可能还可以在谈价格时省一笔钱)。

对于敏捷开发的项目我认为在文档质量上不如要求代码注释量，在开发时就要求注释，并且提交每一个功能的时候用工具检查注释的比例基本与代码行数在一个数量级（比如1：1或者2：1），每次修改问题都标准修改日期修改人及修改原因。这样开发人员更换的时候也容易接手。