日常开发活动中，经常会遇到客户临时加塞需求，或因业务变动，领导突然要变更需求的情况。作为团队负责人或者产品负责人常会碰见这样的场景：
- 这个需求必须尽快上，不然影响业务推进；
- 用户反馈产品出现一个小BUG，极大影响用户体验，必须尽快提升优先级，先解决Bug；
- 领导说其他的先放一放，先做这个功能，觉得这个比其他的功能更着急；
像此类情况，时有发生，研发团队尽管中腹诽，充满抱怨，可还是尽心尽力完成了任务，交付产品，可是长久以往，如果没有针对性的策略应对，一来，干扰正常研发节奏，二来，不断加重团队研发工作量，影响交付质量和效率。
那么，面对这种情况，敏捷团队该如何控制需求变更或突然性需求呢？
问题分析
首先，对当前研发团队面临的情况进行问题分析：
- 研发团队成员支撑工作与开发工作没有区分，且没有明显的优先级；
- 客户、领导、用户反馈、突发性Bug时有发生，干扰正常研发工作流程；
鲸舟敏捷团队应对方案
混合模式开发
从最新的敏捷状态报告中，我们可以看到，敏捷开发方式被越来愈多的团队所采用，它在增强管理优先级、加速软件交付，提高产能、改善业务与IT协作等方面有着显著效果。
对于问题一，支撑工作与开发工作混合。日常研发工作中，出现突发性工作是常态，敏捷研发团队要使用这种工作的变化和节奏。当然，单纯的适应不能解决实际问题，需要提出解决方案。
敏捷团队可从人员分工上应对这种突发性的工作，团队人员的工作分配有一定侧重点。
一部分主要负责新功能的开发，另一部分人员侧重于应对突发性工作，比如Bug、客户临时需求，领导的需求等。负责应对突发性工作的团队人员应时刻准备应对这种风险。比如：
- 尽量领取一些简单、低耦合的工作，以便随时可从当前工作中抽离出来，而不影响到其他团队成员的工作；
- 让团队中全栈型研发人员担任“救火队员”
另外一部分团队成员则可以专注于当前迭代的开发内容，尽量减少临时加塞需求和变更需求的影响。
不过，为了确保团队成员对当前产品迭代保持一致的理解，这两部分可以定期互换角色。鲸舟团队通常是一个迭代切换一次。
开发为主模式
我们知道在研发活动中，不仅有突发性工作，还有一部分正常的需求变更。而仅前面做说的混合模式开发啊，并不能高效处理这种情况。正常的需求变更有可能涉及正常的研发成员、也可能涉及到应对突发性工作的成员。
因此，建立应对需求变更机制，从根本解决工作项优先级的问题，系统学习怎么应对需求变更才是重要的。
第一、明确需求责任人，做到需求来源唯一。
研发活动中，需求是核心出发点，为了确保整个研发活动的正常进行，并且能够交付高质量的、客户满意的产品，就需要严审需求，首先便是明确需求来源，责任人唯一。
需求责任人至少同时要面对两个方向。
一方面，需求责任人必须很多理解项目的利益干系人、客户和用户的需要、优先级，充分理解需求，将业务需求、运营需求等转化为产品需求。
另一方面，需求负责人必须于开发团队交流要构建的特性及其构建顺序、需求负责人必须建立需求的接受标准，让团队成员可以确定在什么情况下可以认为需求完成了。
第二、梳理产品待办列表
对突然变更的需求，需要对产品待办列表重新梳理、经过迭代计划，团队成员自主选择承诺完成多少工作，对对应的需求故事评估，排列优先级，形成迭代计划列表。
第三，梳理PBI
梳理是指三大重要活动：
- 确定并细化工作项；
- 对工作项估算；
- 为工作项排列优先级；
第三，重新制定计划
变更需求而影响原本的迭代计划时，为保证团队容量合适，合理更新迭代目标，通过重新制定迭代计划来解决，万不可加塞需求，团队迭代容量增大，而不变更加护，通过加班来消化容量肿大问题。
通过梳理以后，原计划准备做的部分工作项可能被移入下一迭代中实现，这样虽然在迭代中增加了新的工作过想任务，但同时我们也移除了迭代待办列表中的一个“等工作量”的任务，所以保证了工作量不变，进而保证迭代速率。
最后，是迭代回顾会
Scrum框架中的迭代回顾会，目标是持续改进流程，根据团队需要改进和制定流程，发现问题，改进优化，提高工作产出效率。
以上便是基于敏捷开发如何从容应对需求变更、临时加塞需求的应对措施，除此之外，一款优秀的敏捷实践研发管理工具，可以很大帮助研发团队提升研发效率。
最后推荐一个我们自研的精益敏捷研发管理工具——鲸舟。如果您刚好需要寻找敏捷研发管理工具，欢迎关注试用。
鲸舟——数智化精益敏捷研发管理工具平台。
适合互联网创业团队的敏捷研发管理平台，现在注册使用，30人以下团队，永久免费。
