- 最新动态
- 功能总览
- 产品介绍
- 快速入门
-
用户指南
- 需求管理(CodeArts Req)使用流程
- 购买并授权使用CodeArts Req
- 访问CodeArts Req服务首页
- 创建CodeArts项目
- 管理Scrum类型项目需求
- 管理IPD系统设备类型项目需求
- 管理IPD独立软件类型项目需求
- 查看审计日志（可选）
- 最佳实践
- API参考
- 常见问题
- 视频帮助
- 通用参考
展开导读
链接复制成功！
如何移动迭代中需求变更后看板中的任务卡片
背景
围绕迭代中需求变更后，如何移动看板中的任务卡片，本文将从正常情况下的移动和需求变更情况下的移动两个方面进行细致讲解。
正常情况下的移动
使用看板主要意图之一是控制在制品数量（WIP，work in process），需要拉动式的移动，以有效控制在制品数量，防止工作项过多积压。
另外需要提示一点，在整个移动过程的前提是需要制定一套移动规则，根据团队自身情况定义规则，可以根据团队意见进行调整，最后团队满意就是合适的规则。
需求变更情况下的移动
- 不接受变更
当一个Sprint的Sprint Backlog和Sprint目标确认后，为了保持团队在很短的时间内，全力以赴的向着Sprint目标冲刺，一般情况下不接受PO提出的需求变更。在很短的周期内，PO是有责任负责整理好Sprint Backlog的，进一步说，PO至少应该整理好接下来1-3个Sprint需要做的Product Backlog，然后按优先级，挑选出最近一个Sprint的Product Backlog形成Sprint Backlog，因此经常性的需求变更建议团队不接受，另一方面也是一个好习惯的养成，促进PO对需求的把控能力。所以这种情况下，团队正常移动看板中的卡片就好。
- 拥抱变更
完全拒绝需求变更是不现实的，有的时候高优先级的需求一定要满足变更的要求。比如，有市场时效性的，本Sprint不能完成，不能抢占市场先机，但变更需要遵循“NO CHANGE”原则。接到需求变更后，首先不是直接接受或者拒绝，而是先对需求进行分析，分析对当前迭代的影响。一般分析结果为以下几种情况：
- 变更少，影响小的需求
高优先级的，对Sprint影响小的需求变更，可以柔和接纳，但要评估工作量，做等价交换。简单说，就是把未做的优先级低的需求从看板中替换出来，移动到Product Backlog中，这也是Product Backlog Refinement的过程，然后看板中加入高优先级需求的卡片就好。如果是交换已经产生工作量的需求就需要分情况处理：一种是移回到Product Backlog列，这种情况多于以完成特性需求为目标，更符合敏捷。另外一种是移到Done列，这种情况多见于物理看板中对统计度量数据比较看重的团队，团队需要对工作量进行有效统计。第二种情况在有些电子看板中也可以灵活统计来满足团队需求，那么就可以直接移动到Product Backlog列。
- 变更多，影响很大的需求
高优先级的，对Sprint影响很大的需求变更，需要停止当前Sprint，重新规划新Sprint。这里的影响很大情况是指当前Sprint中的需求可能再做下去也没有价值，这时果断停止当前Sprint，另外一种情况也可能是变更的需求本身确实需要很大的工作量才能完成，也需要停止当前迭代。这时根据最新的Sprint Backlog布置看板中的卡片就好。
- 变更少，影响小的需求
