本文旨在引导产品从业人员关注和重视开发模式问题，隐去了各模式的实施细节和管理复杂性。文章介绍了常见的5种开发模式，并对各模式进行了分析，与大家分享。

我一个产品经理（本文泛指产品人员）为何要关注开发模式，开发的事不是技术的事吗？那不是技术团队该关心的事吗？

一、为什么产品经理需要关注开发模式？

1. 开发模式即工作模式

首先我们要达成一个共识：产品经理除了收集分析需求、抛出草案、定方案、输出原型、prd、流程图、架构图等专业工作之外，还需要负责协调资源、上传下达等保障整个研发顺利进行的工作。产品经理是贯穿始终从头走到尾并对最终结果负责的人。

互联网软件研发周期中的各团队参与情况和当前项目所处的阶段，大略划分的话可以有如下关系：

完成软件开发所要进行的工作和各团队之间大致有如下关系：

为什么有交叉？

• 设计工作不仅仅是产品经理设计产品方案，拿到产品方案后研发团队需要构建同样重要的技术方案。
• 测试方面，测试团队肯定是主角，进行项目质量的整体验收。除了这些还有研发团队研发过程中的单元测试，提测前的整体自测，还有产品同学的辅助测试和上线后回归测试等。
• 至于部署方面，硬件方面的事情自然运维团队去处理，但设备选型则是技术方案的一部分。另外有的公司是技术团队负责发布代码，有的是运维同学进行发布。

各团队之间看起来相互独立，各司其职，实则紧密相连，不可分割。无论开发模式是不是技术团队该关心的事，它都不可避免地会影响整个研发过程。各团队为了消除这种影响，需要调整工作方式去配合，这样才能释放出相应模式的优势力量，达到整体最佳。

2. 熟练掌握开发模式的好处

第一：加入一个新团队，能识别出当前团队正在采用的开发模式，可以快速适应节奏展开工作，更顺利更少犯错。试想如果人家在采用敏捷开发，而你带着瀑布开发的思维投入工作并产出，团队首秀上来就挖坑，想想都觉得可怕。

第二：清楚团队当前工作模式的优势和局限，在局限性方面就可以提前做好准备，不至于当问题发生时措手不及，处于被动的局面被牵制住。问题的产生很有可能是团队工作方式的弊端带来的而非你个人能力的问题，这个锅不能背。

第三：以第二点为基础，清楚局限可以有意识尽所能去优化，无论对个人发展还是公司效率，都是极好的。

二、各开发模式相互对比

一款产品不是孤立的，它是和自身、公司、竞品、行业、用户群等相互关联的，共同作用下的一个结果，我们研发一款产品，是基于一定需求痛点，服务于特定人群的。在信息过载、要求快速响应的互联网世界里，开发过程的灵活性和用户参与程度被越来越多的关注和利用。

当下公司所采用的开发方式有N多种，每一种都是特定场景下的特定产物，没有绝对的优劣，适合最重要。我们先从操作灵活性、用户参与度两个维度对当下流行的开发模式做一下全局预览。

三、5种常见开发模式介绍

我们选取了4种典型的开发模式进行说明，这4种模式有的是默认选择的，可能你在用但是你自己没意识到；有的是当下热议的；有的是用于增加项目透明度可以随时引入新的变更需求的；有的是应对老板一声令下要求即刻上线的。

1. 瀑布式开发

各个阶段从上到下，一步一步地走，是不是很像瀑布，水从上流淌而下。

瀑布模型式是最典型的预见性的方法，是开发方法论的老大哥，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。只能一个阶段一个阶段的执行，不可回溯。每个阶段都需要独立评估，准确无误的输出，完整的文档。上一个阶段结束前，下一个阶段不能开始。直到最后部署交付，期间都拿不到切实可应用的项目。

这是大多数团队默认采用的一种模式，甚至常用到自己在用它，但是都不知道它就是瀑布式开发。采用瀑布开发方式的用户常见于新负责的项目经理因为这种方式对项目的估计非常方便。项目开发中涉及到的几乎一切都预先计划，从而便于确定预期的开发成本和开发时间，非常方便地把整个项目置于自己的掌握之下。

缺点也很明显，任何人都不能预知未来，做出来的方案也都不是完美无瑕，计划赶不上变化，每个阶段环环相扣，任何一个阶段出问题，都可能导致延期甚至项目失败。另外对于开发人员而言就可能显得太严酷了。因为测试过程在开发阶段之后实施，子系统测试所暴露的问题可能需要立即修改代码，而开发人员一般在同一阶段也会从事其他的开发任务，而所需要的软件修改可能会降低开发人员的生产率和工作质量，这样就显著增加了计划架构的成本。

2. 增量和迭代开发

增量和迭代其实是两种开发方式。

增量开发是把项目切割成N个相对独立的模块。像堆积木一样，每次迭代会增加新的软件模块，而在先前添加的模块中几乎没有变化。开发过程可以顺序进行，也可以并行进行，并行开发提高了交付速度。

这就要求产品经理在分析设计阶段，要充分考虑研发资源问题。如果研发资源有限，我们把项目切分成块后势必要按紧急、重要程度进行排序，业务人员会牵扯进来。如果研发资源充足，分析设计阶段产品经理会很忙，我们要在设计阶段过后输出的是供好几个研发组并行开发的子模块原型、PRD、流程图等，当然如果你是个产品leader的话，就可以授权下面人去分头行动了。

迭代开发和增量开发类似，也是把一个大任务切分成N个子任务。与增量模式各模块间相对独立不同，迭代开发的每次迭代任务都是以上一次迭代为基础进行的。由于软件是分部分交付的，因此从项目开始就不需要完整的规范，并且在开发过程中可能会对需求进行少量更改。但是，需求不能根本改变，必须在开始时就定义主要需求。

这就要求产品经理每次迭代都要留下足够清晰的文档，供后来人能接着继续迭代开发，后来人可能是公司其他产品经理，也可能是新来的产品经理。如果你是一个产品leader，如果你们公司项目采用的是迭代开发模式，如果你不想因为某个人的离职导致开发组陷入一团糟的话，就提前要有这方面的要求和准备。

如果把增量开发看作是横向开发的话，那迭代模式就是纵向开发。增量迭代模式的优点是如果失败，影响的只是一部分而非整个项目，降低了损失。软件更容易成功，通过先前的上线版本收集用户反馈，结合反馈作出下一次迭代方案，小步快跑更容易成事。缺点是因为增量开发是拆开成块，如果开发过程中没有沟通好，或者文档不清晰，会导致后期合在一起的时候出问题。

3. 看板开发

大家经常听到敏捷开发，其实敏捷开发不是一个模式，而是一组模式的统称。本节讲的看板开发和下节的极限编程都属于敏捷开发，除此之外还有Scrum。

如果说瀑布模式是一种自上而下的驱动方式，那么看板模式就是一种自下而上的驱动方式。后道工序在需要时，通过看板向前道工序发出信号，请给我需要数量的输入。前道工序只有得到相应看板后，才启动任务。用户需求为其中的原始驱动力。

看板模式没有明显的迭代过程，没有单独的计划阶段，可以随时引入新的变更需求。看板上的内容坚持“即来即增加”和“即变即更新”的原则，团队中的每个人都可以根据实际情况增加或者流动自己负责的任务。可以清晰地看到所有项目活动，任务数量，负责人和进度。这种增加的透明度有助于更准确地估计最紧要的任务，项目组也更加趋向于自动化。

站立会是看板开发方式的一个显著特征，每天开发组主要成员，一人一两分钟，交代下自己当前已完成的任务，正在进行的任务，有没有遇到问题。之所以采用站立的形式，是因为不要在会上讨论复杂的问题，产品经理需要把控好站立会的时间。

复杂问题如需讨论，单约专项会议进行。开发是环环相扣的，站立会会把问题提前抛出来，避免之前流程环节上的浪费。能带来一种类似“Stop and Fix”的氛围，出现问题时，能立刻暂停，分析根本原因，并加以解决，防止问题的再次发生。

但是这种方式，容易让大家的注意力集中到某个点上而忽略其他点，不利于思维的发散。

4. 极限编程（XP）

极限编程和传统开发模式的本质不同在于它更强调可适应性以及面临的困难，去掉了条条框框，更强调专注问题，快速解决。也可以理解为这是一种更“随意”的开发方式，但是设计、编码、测试环节依然存在，只是不拘泥于形式和流程。所以除了团队成员之间需要相互熟悉、默契之外，在团队文化方面也是有一定要求的，它的基础和价值观是交流、朴素、反馈、勇气和尊重。适用于经常发生变化的项目、紧急上线任务和封闭开发等。项目组人数也要进行控制，建议在2～10人之间。

在极限编程式开发中，经常见到结对编程，即代码由两个人坐在一台电脑前一起完成。一个程序员写代码关注编码细节，另外一个人主要关注整体结构性的东西，不断地对第一个程序员写的代码进行评审。团队成员能够长期维持努力工作的状态，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。

代码权限集体所有，每个人都可以更改代码的任意部分，每个人都对所有的代码负责。在XP中，没有那种传统开发模式中一次性的、针对所有需求的总体设计，设计过程几乎一直贯穿着整个项目开发，而且实现方式简单，能满足需求、通过测试即可。

不推诿不扯皮，有话直说，对事不对人，勇于承担任务，不逃避责任。这个“极限”就体现在把交流、反馈、勇气、尊重这些最朴素的东西发挥到了极致。这种模式的弊端除了挑团队之外，由于不拘泥形式，后期在文档完整性上也会有所欠缺。

如果项目组成员有流动也会给开发带来很大问题。因强调的是简单设计简单开发，更关注当下的需求满足情况，所以后期重构的几率会更大。但是这种模式所带来的效率提升，结果导向性，在某些场景下是其他模式所不能取代的。

四、不同场景下的开发模式选择

每个公司，每个团队，每个项目都有自身的独特情况，以下关系基于各开发模式本质特征进行推荐，实际情况需实际分析，也可以集合多种模式优点组合使用。

无论使用何种开发模式，想要有效实施都依赖于对原理的理解、对原则的坚持和实践时的随机应变。

1. 瀑布开发适合场景

1. 具有明确定义和不变需求的中小型项目，比如小型公司网站开发
2. 需要严格控制流程，预算和时间表可预测的项目，比如政府类项目
3. 必须遵守多个规章制度的项目，比如医疗软件
4. 使用了业内熟悉的成熟的技术方案的项目

2. 增量迭代模式适合场景

大型关键企业应用程序，最好由松散耦合的部分组成，比如微服务或web服务类

3. V模式适合场景

故障和停机时间不可接受的项目，比如医疗软件、航空管理软件

4. 螺旋模式适合场景

1. 业务要求不明确或过于雄心勃勃地创新型项目
2. 大型且复杂的项目

5. RUP适合场景

大型和高风险项目，尤其是基于用例的开发和高质量软件的快速开发

6. 敏捷开发适合场景

1. 要求处理目标用户前期反馈的新项目
2. 业务要求不能被清晰地转换成产品需求的中型定制化项目

五、开发模式只是大公司大团队该考虑的事吗？

各种开发模式的产生是因为现实开发中遇到了各种各样的问题，一个模式对应一类问题的解决方案。无论团队大小，结果导向，遇到问题都可以采用对应方案。

开发模式本质是关于工作效率、资源利用率的问题，小公司更需要关注花更少的钱办更多的事。

内耗导致的项目死亡。就像齿轮要克服相互之间的阻力才能对外做功，不合适的齿轮组合会带来更大的阻力，大公司可以利用其强大的资金、人才去克服额外阻力，消除不良影响。小公司资金、人才方面比较弱，更应规避内耗问题。

写在最后

采用什么样的开发模式直接影响到各工种用什么样的工作模式投入其中。小了说关乎效率问题，大了说关乎项目成败。与公司大小没有关系，结果导向、效率导向，希望大家避免无意中的自我毁灭。

最后，与大家分享一句《湮灭》中的经典台词：“Almost none of us commit suicide, and almost all of us self-destruct”

本文由 @产品大葱 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。