今天要探讨的问题是，敏捷的大热话题“敏捷需求变更管理”？
可能，做敏捷给大家一个印象就是不需要流程。为啥要流程，比如需求，如果做了需求变更管理那不就是回到了传统项目吗？
在此，个人意见略有不同。
不管用什么形式的项目管理方式，用什么形式的需求管理模式。其实追其根源，需要解决的就是需求范围的清晰和明确。请注意，这里用的是清晰和明确，而不是不变。
传统项目管理模式，追求的是范围不变。尽量不变，或者实在要变也要在阶段的早期变化。避免马上要做完了再变化，对成本、进度、质量都是一项考验。
敏捷项目管理模式，难道就真的完全拥抱变化，来之不拒了吗？当然不是，敏捷追求的只是小步快跑，换句话说，他是将漫长的项目周期，切割成数个迭代。请注意这里说的是迭代，不是阶段。迭代和阶段的区别需要说一下。一个迭代完成是能够产生一个最小可执行单元。而一个阶段出来缺不一定哦。举一个敏捷领域司空见惯的例子。
如果要做一辆小汽车。用传统项目管理方式执行，就是先做车架子，然后做轮子，然后做内饰等等，直到将整车做好。而敏捷项目管理方式执行的却是他会了解这个人为什么需要一个小汽车。哦，原来提出人要解决出行问题，他希望比走路更快的到大公司。于是敏捷基于现在一穷二白的家底，会先快速做出一个滑板车，有了滑板车确实会比走路快了一点。紧接着第二阶段，在滑板车的基础上升级为自行车，这个可能会更快点；再次升级成摩托车，最后升级为小汽车。OK，这个时候，其实每个阶段都会问提出人，速度够快了吗，咱们家已经为这事儿花了这么多钱了。你看行吗，如果钱足够，速度觉得不够快。咱们还可以给你做一个小飞机，会更快...
以上，是个人从业传统项目10年，转型敏捷项目管理之后的一点心得。其实不管执行的是哪种项目管理方式。最底层的管理思想是不变的。成本、进度、质量，当然敏捷在此之外提出一个价值！
最后，奉送，我们团队自己整理的简化版的内部迭代需求管理流程及要求，其中涉及团队产品、设计、开发、测试，以及部门管理者。
题目：迭代需求管理要求：
1、需求基线明晰。产品需求规划会上，由产品向全体讲解需求内容，产品讲解完毕由开发反讲。交互过程会存在需要修改的需求点，团队约定需求内容修改最终截止时间。以此时间之后的需求版本确定为本迭代需求基线。后续再出现需要修改需求的内容，都视为需求变更（新增或补充内容、修改内容、局部删除、整体拆分等）......
2、需求变更管理流程：
【步骤1】： 需求负责人梳理变更明细。 包括：变更内容，与原需求的差异，对系统整体的影响。【特别】：此处需要发起人与技术负责人对接，技术负责人给出变更影响的工作量。
【步骤2】： 产品组内+技术评审。 需求发起人在产品组内组织需求及技术可行性评审通过。如需设计UIUE对接交互设计总监进行沟通确认。
【步骤3】 ：审批。技术评估变更工作量≤阈值，或 产品经理协调迭代内等量置换其他需求，与设计、技术、测试各口达成一致，无需走变更审批流程。除此之外其他情况，请产品经理触发走需求变更审批。 邮件发送部门领导，取得审批通过。抄送产品、设计、开发、测试组负责人+SM。
【步骤4】： 录入迭代，推开发。 按规范、规则，录入或修改项目管理工具中的需求，落实推相关开发、测试人员做必要的需求讲解。变更处要着重标记。
【步骤5】： 信息同步。 每发生变更，与产品设计内审完毕，领导审批通过后。在各小组负责人微信群同步变更信息，全体知悉。并将邮件内容截图，存放WIKI，累加记录。
3、阈值：5人时。
