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

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

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

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

3. 看板开发

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

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

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

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

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

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

4. 极限编程（XP）

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

（编辑：西安站长网）

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