敏捷流程

问题描述 现在，在我国来看，无论大中小三种企业，均喜欢使用软件工程过程中的“敏捷模型”。 使用了“敏捷模型”的企业，大多的软件流程如下： 产品经理产出原型 架构师/主管开始拆分模块并分配至开发人员 产品经理开始补文档 这种方法虽然开发速度快，但是实际上，整个开发团队对于需求的理解是模糊的。 这种流程，在需求确认的时候，无法拿出一份符合软件行业规范的文档，仅仅以原型作为展示，来与客户、开发、测试等人员进行沟通。 实际上，纵观软件工程的发展史，我们就会发现，一切回到了最初的起点：软件危机。 仅使用原型来与客户进行需求确认，导致客户确认的需求比较模糊 架构/主管按照原型进行模块划分，导致软件整体架构是按照当前需求最优的，后期需求一旦变更，就会导致大面积的代码变更 模块虽不会对开发人员产生模糊，但是由于需求实际上并不是“确认”的，开发人员将可能产出错误的软件实现。 将对测试人员的工作产生巨大的影响，比如，测试人员认为有问题，但是开发人员认为没问题，产品经理也坚持没问题/下一版再说。 缺少文档、需求模糊、更改耗时耗力、一再拖拉，传说中的软件危机就这样再一次出现了。 如何避免和改善： 一日没有《需求分析说明书》，开发人员和测试人员就一日不应工作。