系统功能迭代开发规范.docxVIP

系统功能迭代开发规范

我做软件开发相关工作快十年了，前前后后待过不同规模的团队，见过太多本来口碑不错的产品，因为一次次无序的功能迭代，最后变得bug遍地、逻辑混乱，别说用户用着闹心，我们开发自己改代码都改不动，最后只能推倒重构，浪费了不知道多少人力物力。其实绝大多数问题都出在没有一套清晰可落地的迭代开发规范上，不少团队觉得迭代就是改改代码加功能，想到哪做到哪，最后自然乱了阵脚。一套好的迭代规范，从来不是为了约束大家的创造力，而是给整个团队搭好脚手架，让每一次迭代都可控、可追溯，既能快速响应用户需求，又能保证系统的长期健康。接下来我就结合自己实际踩过的坑、总结的经验，把完整的系统功能迭代开发规范梳理清楚。

1迭代开发前期的需求准入与规划规范

任何一次顺利的迭代，都从做好前期准备开始，很多迭代的隐患其实在启动之前就已经埋下了，所以第一步必须把好需求和规划的关。

1.1需求准入审核规则

任何要进入本次迭代的需求，都必须过三道审核门槛，不符合要求的一律打回需求池，不允许进入开发环节。

1.1.1需求有效性验证

也就是说这个需求不能是某个人拍脑袋想出来的，必须有实际的依据支持：要么是来自用户反馈的高频问题，要么是运营数据支撑的真实需求，要么是解决线上已经存在的严重bug。我之前就遇到过一次，管理层有人说要加一个用户等级排行榜功能，说能提高用户活跃度，结果产品没做调研就放进了迭代，两个开