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

迭代开发和增量开发类似，也是把一个大任务切分成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. 业务要求不能被清晰地转换成产品需求的中型定制化项目

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

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

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

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!