敏捷需求 变!变!变!

统计150天数据发现:人员变动对敏捷团队没有影响?
2020年5月6日
作者:​巫婆艾 原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心得

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

分层治理,变在早期:

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

建立客户团队

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

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

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

制定变更流程

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

评论关闭了。