敏捷项目管理之需求管理

作者:叶朝萍

背景

在近几年比较火的敏捷开发大背景下,我们的项目团队的需求管理,也一直在探寻着敏捷开发的轻量化管理的原则,并且由于我们团队采用了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 条评论
登录 后参与评论

相关文章

来自专栏架构师之路

架构师到底该不该写代码

周末InfoQ-StuQ直播,主持和听众提问的简版实录,快消时代,精简到1分钟可以读完(原文有10000字)。 提问:沈老师是从什么时候开始写文章的? 我从大学...

3498
来自专栏张善友的专栏

DevOps是云计算时代的开发与运营

DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA...

1875
来自专栏Golang语言社区

微服务架构崛起 能否成为下一代云计算?

复杂度可控、灵活可扩展与独立部署 IT架构一直从all in one到近两年热门的微服务架构,技术不断进步,微服务架构模式(Microservice Arch...

2675
来自专栏企鹅号快讯

Java程序员如何提高自己的编程能力

编程对于一部分人来说是一项工作,但对于真正喜欢编程的人来说,不仅仅是一种知识,更重要的是一门手艺。其实大部分人学习编程都希望自己的工作生活变得更好。既然明白了编...

3049
来自专栏开源项目

每日一博 | 如何为开源项目做出自己的贡献

摘要 讲讲我对如何为开源项目做出自己贡献的一些理解。 我是开源软件的使用者,另一方面也是开源项目作者,所以想结合自己项目的实践来说说我对《如何为开源项目做出自己...

32410
来自专栏Kiba518

架构师的御人之道

一个团队的成员有很多人,其中包括项目经理,架构师,组长,组员等等其他人员。就纯开发而言,编写代码的人员只有架构师和组长、组员三个角色。要完成架构,就要利用好三种...

723
来自专栏ThoughtWorks

敏捷中的QA

作者 林冰玉 说到QA,通常指的是质量保证(Quality Assurance)工程师,但我更喜欢定义敏捷中的QA为质量分析师(Quality Analyst...

3207
来自专栏软件测试经验与教训

测试人员职业发展

3144
来自专栏Android 研究

PMI-ACP 敏捷项目管理2——敏捷12原则

在软件项目或者其他类型的有高变更比率的项目而言,严格的变更管理流程会带来很多问题。相比而言,敏捷项目管理允许变更的发生,比如极限变成(XP)提倡"拥抱变化"。敏...

823
来自专栏Kiba518

另一个角度的架构师

ADMEMS矩阵,明确介绍了架构师需要思考的问题,而在这个矩阵中,做完一个架构师最需要了解的什么呢?技术?业务?都不是,最需要了解的是你的领导,其次是你的团队成...

702

扫码关注云+社区