基于什么规则来拆分需求以允许迭代开发？

Question

请教一下，当需求整体已经完成调研和分析，也已经有了原型图。此时若想让开发环节按照迭代的思想来规划，应该如何做迭代周期的安排和需求拆分。

补充描述：

需求已经细化到一定程度，甚至交互体验都做了一定程度的确认。不过仍然可能发生需求变更，仍然有调整的可能和空间。当然，客户也对最终交互产品有了具体的预期。

在此基础上，想让开发阶段能快速开发最小可用产品，并多次迭代最终完成。想问问这种上下文中，各位大牛有没有什么经验可以分享的？

Answer 1

需求已经细化到一定程度，甚至交互体验都做了一定程度的确认。

这和迭代拆分没啥必然的关系，拆迭代的标准是业务价值。

产品的目标/解决的最大痛点是什么，或者mvp要验证什么，这就是第一个迭代的范围。
之后的迭代，按照业务价值和需求闭环来拆，排期按照紧急重要四象限来规划。

再回过来：

想让开发阶段能快速开发最小可用产品，并多次迭代最终完成。

这一个方式，你得想清楚为什么采取这种方式。虽然它能让团队更容易处理需求或外部条件的变化，但这种方式并不能带来效率或速度上的收益。

Answer 2

首先明确第一期需要完成的基础功能.你得自己有这个意识.不能第一期就把功能做得完美.后续除必要的第一期需要且改动程度比较小之外,或者是开发非常前期,改动比较小,其他功能都需要排到软件的第二个版本或者第三个版本，包括你的需求变动

Answer 3

这种呢，基于版本管理工具就可以实现迭代开发的代码管理了。

首先，设定两个基础分支：release和master，这两个分支都是稳定分支master是当前开发中的稳定测试版本分支,release用于线上部署分支，需要部署的分支合并到这个分支即可。

然后，然后以不同时期为稳定版作为开发。
v1分支设为第一个版本，然后第一期大家都可以在这个分支上开发，然后开发好都合并到这个分支。然后这个分支后稳定了可以上线。
v2分支是在v1稳定版的分支上进行的二次开发，然后这个分支作为稳定分支，然后v1的修改可以拆分为v1-fix-[xxx-bug]这种类似的格式来处理v1版本的bug，然后处理好后，就合并到v1然后进行上线。然后v2分支把v1当前修改后稳定的程序合并到v2上面。而对于v2版本需要开发的功能，拆分成不同的功能分配给不同的人，比如v2-order、v2-product等类似的分支，这些分支测试稳定后再合并到v2分支，此时v2分支包含了v1分支的bug修复，以及v2-[相关功能]测试之后的稳定版本。然后v2告一段落就可以合并上线，在线上形成稳定的v2分支。然后v1分支就不用管了，后续的bug修复都是在v2分支上，修复bug的分支参考v1分支bug修复所形成的新分支。后续的版本迭代一次类推即可。

而至于团队管理和产品设计相关的管理方面，就参考你团队自身来自行处理了。