# 无悔问题总结 ## 确定研发流程 > 经验教训：最小可行性模型退化为瀑布模型 ### 开发角度 - 开发能力与迭代规划不匹配，冲刺执行力差 - 需要在**具体冲刺过程中继续细化工时、工作量等具体指标** - 需要提出延期应急方案 ### 需求角度 - 最小、可行，两个指标中只实现了最小，没有实现可行 - 将一个大模型拆分为多个实现步骤，这是不足够可行的。因为只有将所有的步骤完成之后，才能生成一个可投产的大模型。 - 将一个大模型拆分为多个依次递进的小模型，这才是可行的。**每一个小模型都是可投产的模型**，这才是最小可行的产品。  - 如此拆分后，每一个模型都应当保持独立性，都是大模型当前完整的状态，而不是实现某些功能的过程中的一步。换一种表述，即**非当前版本实现的需求，都不被视为必须需求**（而只作为备选），在由当前版本分析产生下一个版本时，才产生下一个版本的必须需求。更简单地说，**每个版本单独执行需求分析，不提前确定下个版本的需求**。 - 每个版本在维持可行性的前提下，必须使迭代周期尽可能短，即让单个版本确定的需求尽可能少。  与典型的Scrum中一次迭代是一次冲刺（sprint）不同，这里把冲刺植入了迭代的每个子过程中，更加适合低开发能力的团队。 ### 基础设施角度 - 持续集成/持续部署已经生效 - 但缺少必要的测试（自动/人工），和灰度发布机制，无法安全投产 - 没有引入每个迭代版本的测试和发布，使最终流程实质性退化为了瀑布模型。 - 在最小可行性模型中，每一个版本都必须经历测试和发布。投产的效果是下个版本需求分析的前提——没有投产即没有下一个版本。 ### 总结 最小可行性模型产生了小而细致的版本。如果不脱离瀑布式的、一次成型的需求分析，这种架构实质上会只增加工作负担而没有收益。而把需求分析过程下放到版本迭代中，就可以明显减少无效工作的代价，取得更好的收益。 在无悔世界版中，看似拆分了小版本，但其实每个小版本要么没有达到最小可行产品的要求，要么缺少了测试、投产和重新梳理需求的过程。需求拆分和设计存在不可行问题，迭代计划和开发能力不匹配，基础设施不完备，测试和投产没有与迭代同步。这些问题需要改善。