落地敏捷典型问题:计划会议中的估算,你纠结吗?

本文探讨了Scrum计划会议中估算的难点,包括时间消耗、准确性问题及必要性争议,并提出了解决方案,如提前准备需求、简化描述、讨论异常处理与非功能性需求、前移风险以及调整团队心态。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

计划会议中的估算,你纠结吗?

 

在Scrum中的计划会议中,估算是较为让人纠结的环节。主要的问题是:1) 花费的时间长;2) 估算不准确 3) 估算是否有必要

 

 

原因是什么?我认为主要是:1) 对需求的理解不到位;2) 每一个需求严格按照planning poker的方式,对于简单的需求和强分工的任务意义不大,但是耽误了时间;3) 设计的风险没有被发现;4) 团队受到“兑现承诺”的压力,一般会“悲观估算”

 

 

如何解决这些问题,我的建议是:

 

①    PO在grooming会议之前提前将需求发出,开发团队是带着问题进行需求讨论,否则刚刚拿到需求,讨论的效果并不好

 

②    需求的描述,不拘泥于用户故事的形式,详细程度由团队的成熟度决定。团队越成熟,在简单的需求描述情况下依然可以把需求讨论清楚,可以简单描述;否则还是详细描述为佳。

 

③    需求和设计的讨论,异常处理、用户使用场景、非功能需求往往是被遗漏和疏忽的地方

 

④    风险前移:复杂的设计还是通过时序图等在白板上进行,不要把设计的风险带到实现中。

 

⑤    PO和团队都要承认“估算是不准确的”,估算的目的是为了帮助团队消除需求和设计的理解风险,并得到哪些需求可能被交付。PO和团队关注的焦点在于“迭代的目标是否被实现”,而不是“团队承诺的需求是否全部被实现”。

 

⑥    忘 掉前面几点,在回顾会议中找到适合自己的做法,持续改进。可能这样的方式最适合:估算和实际校准的成员,估算不需要扑克的方式,直接他估算即可;反之则需 要发现原因,是需求理解还是设计风险,扑克、时序图、活动图、反讲都要用上。也可能另一种方式最适合:放弃估算,根据最后需求完成的情况不断分析问题所 在,然后在迭代过程中加强这些问题的解决…

 

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值