需求如何管理

需求如何管理

传统的项目往往产品从业务方处获取需求,然后产品独自构思prd,邮件给开发和测试。测试组织需求评审,制定排期。开发开始写代码,然后提交测试,提交bug、解决bug,最后开发来上线。

这个看似完整的过程存在哪些问题?

1.产品拿到的需求真的是业务方想要的吗?这么实现可以带来什么样的效果?对系统性能有无影响?

2.开发按照产品意淫的prd就可以戴着耳机,闷头写代码了吗?如果有分歧就只是prd描述的不够准确?开发可以通过这一纸文档了解业务的根本目的吗?

3.若出现bug,要不就是代码的问题,要不就是测试用例评审不够细致?测试用例评审后就可以涵盖所有测试用例?

敏捷团队里,把项目拆分成若干个用户故事。进入迭代内的每个用户故事的需求是产品、开发、测试通过沟通而达成一致的,而不是通过prd来传递的。拿到需求后,多问几个为什么,往往能感知一些需求背后的隐情,预测可能存在的需求变化。在开始开发前,就把代码实现的步骤(表结构、接口定义)完成,尽可能避免可能存在的分歧。

发生变化时,Scrum master和产品经理紧急召集开发、测试一起分析需求变更的原因及应对策略,我们以开放的心态来迎接良性的变更。通讯基本靠喊,不要等待咚咚的回复,不要吝啬宣讲的机会,我们都是一个战壕的兄弟,一荣俱荣,一损俱损。我们的目的只有一个,快速有效的解决问题。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值