敏捷项目管理之需求管理

作者:叶朝萍

背景

在近几年比较火的敏捷开发大背景下,我们的项目团队的需求管理,也一直在探寻着敏捷开发的轻量化管理的原则,并且由于我们团队采用了Feature team 的团队运作模式,所以版本的需求都是由各个FT 自己独立管理的方式,理想状态是,各FT 自己管理需求,自己去做质量管理,自己评估把控进度和最后版本的顺利发布。而现实往往和理想之间,总会存在差距。下面就来谈谈,咱们浏览器项目需求管理那些事 ~

需求管理1.0 时代 --- FT 自管理+excel 规划表

我们知道,敏捷价值观中有一个是关于文档的,认为:

这个原则本身是一种比较好的价值观,认为在开发过程中,有可用的软件好过详尽的文档描述,来引导团队快速迭代做出可用的软件。我们的项目需求管理1.0 时代,就是用excel 列表的方式来轻量化去管理需求,通过项目群来同步版本需求规划。

这种方式,确实简化了需求的定义,对团队来说是一种比较轻量的管理方式,但实际应用后,我们发现没有了需求文档的详细说明,和集中的需求设计交互管理,我们的版本需求质量也就也会受到一定的影响,因为没有文档,可能有些需求会被反复更改,导致需求变更增多,变更的增加也造成版本管理出现一些问题:版本需求不可控,质量影响、版本延期等。

  • 首先,是版本延期由于需求大多是一句话需求,没有明确的交互或详细描述,产品经理的想法也会不断变化,而开发的理解也会有所不同,这样就造成额外的劳动量。使得开发无法按期完成需求,而造成版本的延期。
  • 其次,需求变更多

由于版本延期,已经开发好的FT又会觉得与其等待别的FT,不如自己也加入到需求新增的大军中,继续开发,这样互相影响,从而导致本一再延期,整个项目的周期也被不断拉长。

  • 需求的沟通、维护成本加大1、需求描述就是一句话,大大增加了开发难度和测试难度,可想而知,沟通成本加大。 2、 需求靠excel维护,更新和同步都是需要收集人及时更新excel并要同步到相关人员,维护成本高。
  • 版本质量不可控

因为需求不明确,版本需求的新增或变更也难以控制,导致缺陷量也比较多,版本稳定需要更长的周期。面对遇到的问题,我们进行了总结和改进,开始了需求管理的2.0时代。

项目需求管理2.0时代 --- TAPD集中管理+需求评审

1、 需求的工具化管理:变excel的人工维护,为TAPD集中管理方式,每条需求的TAPD单上有明确的交互设计,解决需求的维护和沟通成本。

2、需求评审机制:设立产品版本规划管理委员会。建立需求评审机制,由这个专门的需求决策者来对每个版本规划的需求质量和范围进行评审确认。这样在版本开发前就确认各FT的需求是否可以上这个版本,确保版本需求可控。

这样运作一段时间,基本解决了人工维护的成本和需求不明确的沟通成本问题,延期和变更有一定改善,但是延期和需求变更仍然存在,版本仍会有较大的发布延期情况,需求变更率也非常高,版本整体波动较大。

针对问题,我们继续进行相关的总结分析,发现主要原因还是需求的质量控制不够:虽然我们的需求在迭代开始前,有了评审的机制,但实际开发的过程中,由于需求本身复杂度、技术方案选择,或者开发时间的评估不足等,仍然会导致我们的需求开发有一定的可能会出现延期的情况。而且由于当时评审的仅仅是需求的设计文档或交互稿,有时候做出来后产品或老大可能会觉得和预期不一样,仍然会存在变更的可能性。

针对这些问题和总结的原因,我们继续寻找更好的需求管理模式。

需求管理3.0时代 --- TAPD集中管理+合流评审

经过不断的总结和根因分析,我们的需求管理方式又做了如下调整:

1、 针对需求评估不足或者变更引起的延期,我们的需求仍是采用TAPD工具管理的方式,但这里的管理会有所变化,这里的需求评审由FT内自己评审完成,同时要求FT内必须要要完成内部的需求评审,这个需求的把关由FT自己负责。而评审的完成时间必须是在版本规划的第0周内完成。

这个变化将需求的评估充分放权给FT内部完成,你需要根据火车版本的周期,来评估和规划,版本周期内可以完成的需求,而不是所有的需求都想挤上同一趟火车。

2、 我们将产品管理委员会对需求的评审时间,延后到合流阶段,建立了合流评审的机制。这样做的好处是,当开发到合流阶段时,需求功能已经基本完成并可以使用了,这样给到老大进行评审时就比较直观,这样再评审后的既定时间内稍作修改基本就可以达成需求的预期,也减少了合流后的需求变更带来的质量风险。同时,对需求的变更管理也进行了规范,需求的重大变更或新增均需要有充分的理由给到GM审批,通过才能合入。

经过一段时间的运作,我们来看下实际的效果:

(1) 版本从延期不可控 到 逐步可控 再到基本无延期;

(2)需求变更逐步改善,变更率下降了到67%;

(3)质量逐步提升,千行缺陷率也下降明显;

大大降低了项目的时间和人力成本,同时也为产品需求的快速上市提供了保障。

当然,敏捷项目需求管理的方法,我们仍在不断总结和迭代优化中,希望大家也一起来多探讨更好的管理模式,期待更优的需求管理4.0 时代的到来!

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏何彬彬的专栏

经典网络还是VPC,开发者作何选择?

近两天,关于公有云经典网络(基础网络)与私有网络(VPC)的讨论引发技术圈极大关注,事件起因于有开发者将数据库限制在内网访问,但由于安全组设置的原因,阿里云邻居...

3K0
来自专栏人称T客

那些年,我们一起误解的公有云

编译 T客汇 Felix 每个公司都有不同的要求,因此云解决方案的种类越来越多,比如:私有云、公有云、混合云和多重云,这些方案每个都各自具有自己独特的管理和服务...

3355
来自专栏PPV课数据科学社区

测测你的数据管理处于什么段位?

营销技术、新工具和流程的不断演变,营销自动化的兴起,已迫使许多商家学习智能化数据管理。了解数据管理的细微差别,不但有利于改善发件人信誉风险、低响应...

3488
来自专栏程丽萍的专栏

易企秀为什么选择腾讯云CDN?

“易企秀”致力于为中小企业提供移动场景营销平台,经常会碰到突发带宽问题。如何保证易企秀所有的企业客户的终端用户能够在带宽突发时段仍然保持流畅稳定的访问体验,并取...

5750
来自专栏WeTest质量开放平台团队的专栏

锤子发布会,天知道服务器都经历了什么!

对于任何的活动,产品来说,服务器往往是最后一关,也是必须要过的一关,对于众多企业来说,为了不要让自己的汗水白流,为了让自己的产品顺利发布,一定要在上线之前对自己...

1064
来自专栏云加头条

王琰:万物智联,腾讯云 IoT 边缘计算揭秘

本文整理自腾讯云加速产品总监王琰在2018腾讯云云+未来峰会上的分享,介绍了腾讯云如何助力加速物联网+,提供低门槛的一站式开发管理平台。

6367
来自专栏程序你好

敏捷团队需要考虑的六个行为

敏捷团队的成员与其他团队的成员不同吗?是的,没有。是的,因为我们在敏捷团队中看到的一些行为比非敏捷团队的行为更明显。不,因为我们在谈论人!

582
来自专栏云计算D1net

反面教材:别让这三种做法毁了你的云部署

如果大家希望自己的云部署方案能够切实起效,请务必规避以下三种常见错误。绝大多数企业实际上并不具备有效发挥私有或者公有云资源优势的必要经验或者人才储备,因此整个实...

3519
来自专栏腾讯大讲堂的专栏

腾讯游戏背后的运维服务

随着大数据、云计算时代的到来,传统运维工作早已不能满足业务对用户体验和效率的要求,游戏运维更是如此。在腾讯,游戏运维除了需要负责日常发布、变更、故障、迁移等基础...

23810
来自专栏云计算D1net

云公司成败 系于用户体验效果

打造一个云平台非常容易,但是做的非常成功的却少之又少。James Urquhart分享了AWS、Cloud Foundry以及其他一些公司在用户体验和生态系统上...

2923

扫码关注云+社区