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

发布时间：2020-05-02 00:56 所属栏目：27 来源：互联网

导读：迭代开发和增量开发类似，也是把一个大任务切分成N个子任务。与增量模式各模块间相对独立不同，迭代开发的每次迭代任务都是以上一次迭代为基础进行的。由于软件是分部分交付的，因此从项目开始就不需要完整的规范，

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

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

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

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

3. 看板开发

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

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

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

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

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

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

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

4. 极限编程（XP）

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

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

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

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

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