日常开发活动中，经常会遇到客户临时加塞需求，或者因为业务变动，领导突然要变更需求的情况。
- 这个需求必须尽快上，不然影响业务推进
- 用户反馈产品出现一个小bug,极大影响用户体验，提升优先级，先解决Bug
- 领导说其他的放一放，先做这个功能，觉得这个比其他的功能更着急
以上这类情况在我们日常的开发工作中经常发生，研发团队尽管心中腹诽，充满抱怨，可出于职（ren）业(zai)操(wu)守(yan)，每个人都是救火队员，尽心尽力完成了任务，终于交付了产品，可也未必能够取得客户满意，能够实现客户和市场的价值。
面对这种情况，敏捷团队该如何应对这种突发性需求呢？
问题分析
- 研发团队成员支撑工作与开发工作没有区分，且没有明显的优先级。
- 客户、领导、用户反馈、突发型Bug时有发生，干扰正常研发工作进程。
敏捷团队应对方案
混合模式开发
从最新的敏捷状态报告中，我们可以看到，敏捷开发方式被越来越多的团队所采用，它在增强管理优先级、加速软件交付、提高产能、改善业务与IT协作等方面有着显著效果。
对于问题一，支撑工作于开发工作混合，在日常研发工作中，出现任何突发性工作是常态，敏捷研团队要适应这种工作的变化和节奏，当然，单纯的适应不能解决实际问题，需要提出解决方案。
敏捷团队可从人员分工上应对这种突发性的工作，团队人员的工作分配有一定的侧重点。一部分人主要负责新的功能的开发，另一部分人员侧重于应对突发工作，比如Bug、客户临时需求，领导的需求等。 负责应对突然性工作的团队人员应时刻准备着应对风险，比如，开发工作可尽量领取一些简单、低耦合的工作过，而另外一部分人专注于当前迭代的开发内容。
不过为了确保团队成员对当前产品迭代保持一致的理解，这两部分人可以定期互换角色。**在鲸舟（鲸舟敏捷研发管理工具）**研发团队中会区分出一部分研发人员，主要负责缺陷修复等一些突发型工作，两部分人通常会2周一切换，也就是一个迭代。
开发为主模式
我们知道在研发活动中，不仅有突发性工作，还有一部分正常的需求变更。需求变更属于正常的研发活动，团队应该建立应对突发性应急工作的机制，一旦出现变更需求，应急机制启动，按照机制流程，常态化处理需求。
所以如何建立应对需求变更机制，从根本解决工作项优先级的问题，系统学习怎么应对需求变更才是最重要的。
第一、明确需求责任人，做到需求来源唯一
研发活动中，需求是核心出发点，为了确保整个研发活动的正常进行，并且能够交付高质量的，客户满意的产品，就需要严审需求。首先明确需求来源，责任人唯一。
需求责任人至少同时要面对两个方向。
一方面，需求责任人必须很好理解项目的利益干系人、客户和用户的需要，及其优先级，充分理解需求，将业务需求、运营需求等转化为产品需求。
另一方面，需求负责人必须于开发团队交流要构建的特性及其构建顺序、需求负责人必须建立需求的接收标准，让团队成员可以确定在什么情况下可以认为需求完成了。
除此而外，需求负责人还要在版本、迭代和Backlog层面都能够持续作出良好的经济决策。
第二、梳理产品待办列表
产品待办列表是从用户客户和其他干系人那里获得产品需求和用户期望，经过迭代计划，团队成员自主选择承诺完成多少工作，对对应需求故事评估，排列优先级，形成迭代计划列表。如鲸舟中的产品待办列表。
第三，梳理PBI
梳理是指三大重要活动：
- 确立并细化工作项
- 对工作项估算
- 为工作项排列优先级
这一系列活动都是在迭代计划中进行的。在鲸舟中，团队成员会将故事按优先级管理起来，支持快速创建子工作项，工时规划等。
重新制定计划
变更需求而影响原本的迭代计划时，可为确保团队容量合适，合理更新迭代目标，可通过重新制定计划来解决，万不可加塞了需求，团队迭代容量增大，而不变更计划，通过加班来消化容量肿大问题。
通过梳理以后原计划准备做的工作项可能被移入下一个迭代中实现，这样虽然在迭代中增加了新的工作项任务，但是同时我们也移除了迭代待办列表中一个等工作量的任务，所以保证了工作量不变，进而保证迭代速率。
迭代回顾会
Scrum框架中的迭代回顾会，目标时持续改进流程，根据团队需要改进和制定流程，发现问题，改进优化，提高工作过产出效率。
以上内容是基于敏捷开发如何从容应对需求变更、临时加塞需求的一些解决方法，除此而外，事实证明，一款好的敏捷实践研发管理工具，可以很大帮助研发团队提升研发效率。
这里推荐：鲸舟研发管理工具，这是集招商金科研发实践、精益敏捷研发理念、云原生技术为一体的研发管理平台，致力于让软件开发更数据化、智能化，助力企业提升研发效能和交付质量。
阅读更多[敏捷知识]、[敏捷转型经验]、实践等…欢迎关注掘金账号@[鲸舟研发管理]
如果对我们的产品感兴趣，可以逛逛我们的官方网站鲸舟研发管理平台 试用了解
