敏捷需求 变！变！变！

作者：​巫婆艾 原IBM Advisory Software Engineer，参与并见证IBM敏捷成功转型。原汇丰科技西安有限公司资深项目经理。现任某外企Scrum Master。
擅长基于不同文化形态下的敏捷实践裁剪。相信实践是检验真理的唯一途径。

这是一篇又臭又长的文章，尽管作者已经榨干脑汁想把这个很大的topic尽量浓缩成短小精悍的文章，但是看完本篇文章，仍然需要一辈子的时间，你敢来了么？

真爱生命，减少浪费，教你阅读小窍门，竖起你的大拇指，滑呀滑，滑呀滑，滑呀滑，滑呀滑，滑到文章最后，看下思维脑图，你已经可以get到80%的点了。

如果你对某个特定topic很感兴趣，但是我又写的很粗糙，没错，你遇到了女坑王。不用着急，我计划写一些系列文章填坑，等着我。

01丨项目背景

2013年，我负责一个国有企业研究所的数字化建设项目。在交付过程中，需求发生了多次变更，造成了一定浪费，最终借助敏捷框架的支撑，团队成功交付了项目。

在项目启动初期，作为项目对接人，我带领开发团队成员拜见了项目的负责人聂所长。聂所长是项目出资人，是最重要的项目干系人。她主要关注项目方向定位，工期以及预算控制等情况。

项目实施方面，聂所长委任李工担任产品经理。负责定义项目的实施范围，优先级以及领域知识培训等方面的事务。

李工是研究所的副所长，也是技术专家领域专家。李工表示他的大部分时间都会参与到项目中，来保证项目的正常运转。

再问及还有客户团队其他成员时，聂所表示对李工非常有信心，有什么问题找李工就好，不需要其他干系人的介入来增加项目沟通的复杂程度。于是客户团队正式成立如下。

02丨项目两次变更

项目定位变更

在Sprint 0 阶段，大家开始为项目的正式启动做准备。业务分析师与李工确认了需求方向以及优先级，开始创建用户故事并给团队Grooming。一切准备就绪后，Sprint 1 的计划会议如期召开，我把Sprint 1 需要交付用户故事与开发团队以及客户团队进行了双向确认。在获得双方团队认可后，Sprint 1 就正式开始了，并按照2周一个Sprint的节奏推进。

很快Sprint 1完成了，在Sprint1验收会议上，李工表示很满意。他提出向聂所汇报再确定验收。

第二天，李工带回来聂所长的意见，聂所长提出项目定位需要调整。原因是：前些时候聂所长与相关部门开会的时候，看到相关部门的IT系统，想把相关部分系统集成到本所实施的项目中来。所以本次实施的项目方向从最初设计的“独立单系统”调整为 “多系统的整合”，需要在架构设计上做出相应的调整。所以Sprint 1不给与验收。团队重新估算时间后，开始按照最新需求进行修改，来满足客户需求。

3天之后， Sprint 1重新验收。这次聂所长直接参与到验收会议上。聂所长看了更改后的设计，觉得 “多系统的整合” 应该不属于本次项目目标，而且 “多系统的整合” 会造成项目没有独立特点。要求团队返回到 “独立单系统” 设计方案。

2天之后，开发团队修改完毕，再一次等待所长的验收。这次聂所邀请了她的领导，张局长。并要求我们展示了 “多系统的整合” 以及 “独立单系统” 的设计。张局长表示聂所长所在的部门肩负着企业数字化改造的重任，必须建成统一化数字平台，需求回到 “多系统的整合” 设计。

5天之后，开发团队修改完毕，获得所有干系人的满意，并验收。这样，由于三次项目定位调整，Sprint周期延长一倍的时间。

用户故事变更

在Sprint 2 中，开发团队开始针对“数字展示模块”进行交付。李工对需求很有信心。因为他既是技术专家，又是领域专家。开发团队进行的很顺利，很快团队按照计划交付了任务。

在Sprint 2 的验收的时候。聂所长建议李工邀请研究所内所有研究员参加Sprint的验收会议。

当开发团队讲述Sprint 2 交付的用户故事的时候，我发现很多研究员在始窃窃私语。我开始询问原因，却没有得到回应。我不知道问题出现在了那里。

聂所长示意小于技术员讲一下。小于是一名数字观测技术员。他谈到数据展示的频次太快，使用者在日常检测的时候是每十分钟取一次数据，系统实现的是按照秒来取数据，是想晃瞎他们的眼睛么？但是李工说秒级数据更精确，两个人争论不休。

最后聂所长决定：数字化建设的重点是提高所里日常工作的便捷性，需要保持大家工作模式不变，按照小于的建议修改。接下来，几名研究员也提出一些细节问题。

3天之后，开发团队按照客户意见修改完成，客户很满意，并给与了验收。这样，由于用户故事设计发生调整，Sprint2延长了3天的时间。

03丨需求变更带来了什么？

Sprint 1 和Sprint 2 验收通过了，客户高层对于开发团队的工作很满意。但是通过项目整体燃尽图可以发现，经过两个Sprint 的需求变更，项目整体范围从2840个点，增加到3190个点。

团队交付速率不变的情况，无法在最后一个Sprint燃尽，项目需要延期1.5个Sprint，这意味着项目成本也随之增加。

我把项目当前情况与聂所长进行了说明。她希望我们能够从项目整体把控方面给与专业的改善意见。

由于需求后期变更带来的项目返工，导致项目范围扩大，从而对工期产生影响，最后使得项目费用上扬。

如下图所示的项目管理三角形中范围、时间、成本三个因素之间的互相影响。任何一条边发生变更，都会影响到其他两条边。

而质量处于项目三角形的中心，三条边的任何一条所作的更改都会影响到质量。

那是不是我们要一味的拒绝变更呢？敏捷中如何拥抱变更呢？这里给出的建议是：分层控制，变在早期。引导变更 减少浪费。（这是本篇文章的中心思想，下面我们围绕着这个中心开始讨论）

04丨需求分层

首先我们根据需求粒度，把需求分为3个层次：愿景需求，业务需求，用户需求。在分层治理过程，把变更控制在早期的阶段，使得需求从变化到稳定，从而交付价值。

愿景需求: 从总体上描述了为什么（Why）的问题，组织希望达到什么目标。是客户对将使用的系统所要达成的目标的预期期望。这类需求通常来自与高层，例如项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。随着市场的影响条件的变化而变化。

业务需求：项目中业务（功能）规划，它由愿景需求导向。如果业务需求与愿景需求不符合，那么无须项目包含在项目范围或者作为低优先级来处理。通过不断的分析，确认以及细化，使得客户团队与开发团结队达成共识。“业务需求”处于“愿景需求”和“用户需求”之间，起到承前启后的作用，会随着愿景需求的变化而变化。对于业务需求的确认，需要综合考虑以下因素：

可以根据业务需求与愿景需求的相关性，以及技术可行性来调整范围以及优先级。如下表所示：

用户需求：用户需求是项目（系统）需要实现的具体的功能。“用户需求”是开发团队日常接触最密集的需求级别。在可行性分析以及“愿景需求”，“业务需求确认完成后，所制定的具体功能细节。同时开发团队会根据团队速度来制定“用户需求”的交付计划。是开发团队与客户团队的承诺所在，是需求中稳定的部分。

05丨客户团队分层

我们都知道客户是需求的来源，客户团队直接影响到需求相关的所有活动。管理客户团队是管理需求的必要的部分。

就像需要完整的开发团队一样，也需成立完整的客户团队。必要时需要引导客户建立完整的客户团队，并定义好团队角色的职责。在项目的不同阶段建立与不同客户团队成员建立合作。

根据客户团队的职责，把客户团队分为3个层级：

策略决策： 包含客户高层。例如项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。会根据市场动向，竞争对手情况，制定项目愿景，控制成本，建议工期，并决定项目是否符合验收条件。例如：我要统一宇宙。

业务澄清：产品经理等需求决策人，根据愿景需求，制定需求的优先级，以及决定需求是否包含在项目交付等信息的确定。产品经理说：制造致命武器包含在项目范围并且在第一优先级。

技术支持：需求细节确认人：包括最终用户，测试人员或者相关的IT负责人。关注需求细节的确认，并为开发团队提供必要的需求细节的支持，培训，功能测试以及验收测试等等。需求确认人数说：武器发射密码输入错误3次（不是2次，不是4次，是3次），用户账号被锁。

06丨分层治理，变在早期

在需求的不同层级阶段，通过引入相应的系列敏捷活动，对需求进行分层治理，来实现和引导需求从变到不变的过程。如下图所示：

实现变在早期“愿景需求”，稳在“业务需求”，最后定在“用户需求”。引导需求，变在早期。对于需求的不同层级的敏捷活动，引入对应客户层级，实现客户与需求同步管理。

调整愿景需求（变）

利用定期的需求规划会议来调整“愿景需求”，定义中长期的计划。参与这个会议的人主要是客户团队的“策略决策层”，研究所领导张局长和聂所长。通过对项目影响因素的分析，调整项目定位以及制定项目中长期计划，确定“愿景需求”。

使用项目燃尽图辅助决策。客户“策略决策”层通过读取项目范围与交付速度差距来舍去低优先级需，缩短项目范围与交付速度差距，理智决定项目范围。

开发团队通过不断参与需求规划会议，增进对客户相关市场理解，从而提高开发团队项目实施质量。

同时增加了客户团队与开发团队合作粘性，形成 “One Team” 。大家共同看向远方项目靶向。

确认业务需求（稳）

制定Sprint 规划策略

在Sprint规划中，不止要规划马上要做的Sprint（Sprint N）的交付范围，同时需要规划未来需要做的几个Sprint（Sprint N+）交付范围。

我推荐N+3策略，当然每个项目根据实际情况，可以采用不同的策略。目的是稳定客户需求。实现需求的有效管理。

Three-Amigo会议

Amigo 是西班牙语，好朋友的意思。通过Three-Amigo会议与客户团队的 “业务澄清” 层合作，确认 “业务需求” 。

由于项目的不同角色在理解业务规范方面的差距， 通过Three-Amigo来确保团队中的每个人对于“业务需求”的相同理解和期望。

注：Three-Amigo本身设计是有业务分析师，开发人员，测试人员参与。本项目中，团队做了裁剪，把业务分析师这个角色扩展为业务人员。不止包含业务分析师，也包含了客户相关的业务人员。

锁定用户需求（定）

锁定Sprint周期

选取适当Sprint周期，Sprint需要足够小到适应客户对市场的变化的变动便于调整需求变更，同需要足够长到可以交付价值。当Sprint周期被锁定之后，不得变更。

锁定 Sprint范围

在Sprint正式开始之后，Sprint的范围会被锁定。客户团队认可Sprint的交付目标以及优先级。开发团队需要确定用户故事是否可以完成。在团队进入Sprint之后，Sprint范围不得变更。

根据SprintN+1规划策略，Sprint范围被锁定之后，不得发生变更。

锁定用户故事设计

开发团队需要与客户的“技术支持”层进行紧密合作，澄清用户故事所有细节。在Grooming的时候，双方团队需要澄清所有用户故事细节设计，并根据设计给出相应的估算。用户故事Grooming之后，用户故事的设计被锁定，不得变更。

变更锁定

在实际项目中需求“定”的部分不可避免的会发生变更，我们需要建立变更机制，来拥抱变化，应对变更。

需求变更流程需要包含：变更等级，基于变更等级的变更流程，干系人定义，以及变更要素分析，并且提供变更的应对措施。最后需要可视化变更影响，辅助决策。由于本章节不是本篇文章重点，所以简单陈述，会在以后的相关文章中继续分享。

07丨敏捷就是无休止的变化么-Scrum Master心得

敏捷拥抱变化，那么敏捷就是无休止的变化么， 当然不是。敏捷的快速迭代可以很好的应对快速的市场变化，但是不是混沌的，是在一种弹性规则下。如何找到变与不变的平衡点，避免由于需求变化造成的浪费呢，请看下面大树：

分层治理，变在早期：

拥抱变化，但是并不是一味的变，以及一味的不变。一味的变会造成资源的浪费，最终导致项目的失败。通过分析项目特点，找到变与不变的平衡点，并加以控制和利用，最大化干系人利益，交付最大化价值。进而避免对投资人造成资源浪费以及项目风险。

建立客户团队

客户合作胜于合同谈判。通过加入相应的敏捷活动增加客户的参与度。以开放的方式提高客户交互以及合作粘性。

说到底需求是一个沟通问题，一个项目的成功，依赖很多不同的信息。这些信息来自不同人员。一方面是组织领导者，客户和用户，分析人员，领域专家等，一方面是技术团队。一旦任何一方把持绝对地位，项目都会遭殃。我们需要一个协同的工作方法，让任何方都不占主导地位。

每个企业都有各自的组织架构特点，需要了解企业特点，并尊重企业特点。发挥每个干系人的作用。进行分级处理，做到有效沟通。

制定变更流程

当变更发生时，拥抱变化。通过识别并可视化变更带来的影响，制定应对措施，并获得干系人的认可。通过高度可视化的方式，显示变更带来的影响以辅助决策。