浅谈JIRA之变更处理

lsekfe

敏捷的核心价值观之一就在于响应变化，响应变化高于遵守计划。而在实际开发过程中，如果来一个变更响应一个变更，又会导致大的产品/项目规划的破坏和团队执行力的扰乱，所以如何有流程有规则地响应变化就很重要。
　　变更处理的几项规则：
　　1 产品经理定义冲刺范围，冲刺启动会上团队协商范围，一旦冲刺启动后，冲刺范围即确定，无特殊原因不接受变更。
　　2 为了保证冲刺范围的稳定性，但又为了能响应变更，冲刺的时间尽可能短，推荐1～2周为一个冲刺周期。
　　3 待启动冲刺的需求随时可以接受变更，直到冲刺启动会。
　　4 排入冲刺的故事，必须有优先级，拆解数量不少于5个，故事之间的耦合性尽可能低。团队根据优先级的高低，优先开发高优先级对应的任务。每个故事都需要有开发时间或者故事点的预估。
　　5 当有变更请求的时候，产品经理决定插入变更故事的同时，应移除冲刺范围内工作量相当的已经定义好的低优先级的故事。
　　6 变更的发起方，可以是研发团队，产品经理，测试或者其他项目干系人，但是变更的决策人一定是产品经理。
　　7 当线上故障发生较为频繁的时候，做冲刺计划的时候，建议预留部分人力去专门处理故障，以减少线上问题对冲刺排期的影响。
　　提出变更的几种情况？
　　1 客户提出来的变更，可能是更高优先级的需求，也有可能是改变之前已经定义好的需求。
　　2 产品经理经理提出的需求变更。
　　3 产研团队在需求实现的过程中，发现的问题或者需求设计的不合理的地方。
　　4 线上的紧急故障，需要立即解决
　　5 公司领导层或者重要的项目干系人提出的需求变更。
　　6 公司的行政活动占用团队一定的开发时间。
　　7 其它
　　JIRA具体处理变更的方式如下图：

　　这样变更处理的意义在于？
　　1 冲刺结束后，能够统计出冲刺需求变更率，以考核产品经理对于收集客户需求，需求实现方案，干系人需求沟通方面的准确性。尽可能保证已启动冲刺的需求范围不变。
　　指标：冲刺故事完成率。
　　度量方式: 每个冲刺团队完成的故事任务数量/冲刺开始时计划的故事任务数量，完成计划是100%，越接近100%越好。
　　2 团队的研发能力的有缓冲有节奏，对于不太成熟的敏捷团队，经常会遇到的问题：研发冲刺已启动，但是有新的需求需要加进来。要求团队加班处理，以保证上线时间。或者改变冲刺周期，冲刺结束时间后移两天。
　　最佳的解决方式是，固定冲刺周期，调整冲刺范围，加入新的故事，就要移出相当工作量的低优先级的故事。团队加班主要是为了解决未知的高优先级的风险。
　　如果仅依靠加班来解决需求变更，带来最直接的问题就是过度压缩测试时间，产品质量不过关，强行上线了，大量线上故障产生，又过度占用团队研发时间，形成恶性循环。
　　3 聚焦团队价值交付，留有缓冲处理高优先级事项。敏捷变更处理的原则始终在于，优先交付高优先级的需求。