Scrum时间估算 - 团队规模[关闭]

作者: 哎？小查查
发布时间: 2025-02-07 12:16:35 (21天前)
转自：

4 条回复

0#
回复此人
部落用户 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 据我所知和理解，你不估计 功夫 在Scrum中。你估计的 用户故事相互关联的复杂性和所包含的功能 </强> 。 在此之后，你估计 故事点 而不是男人的日子。该 燃尽图 显示您团队的进度。随着时间的推移，你会得到相当准确 团队速度 这基本上可以告诉你团队完成了多少故事点 每个冲刺 。 使用此团队速度作为基础来决定是否为任何给定的sprint提交另一个用户故事，或者它是否可能过多。 </DIV>

编辑
1#
回复此人
妖邪 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 在这里加五美分， 复杂 积压项目不由个别团队成员评判。 首先，积压项目很可能涉及多个团队成员，可以分解为较小的任务，如“实施UI”，“运行测试”或“更改数据库架构”。因此，John，Brian以及Mary（测试工程师）都会参与其中。因此，你需要估计“复杂性，努力，风险和温和的常识” 的 整队 </强> ，不仅仅是约翰或布莱恩。 约翰，作为一个高级家伙，可能会说它是复杂的2，而布莱恩（一个大三）可以说它是5，玛丽会注意到很多回归，因为数据库架构的变化，并给它8.最后在Scrum来了的 整个团队的承诺 </强> 冲刺。因此，作为Scrum Master，您需要协助John，Brian和Mary达成协议，这就是计划扑克等工具登上舞台的地方。 </DIV>

编辑
2#
回复此人
v-star*위위 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 它不应该只是复杂性，而是包括复杂性，努力，风险和温和的常识。 我认为你开始以错误的方式进行估算，这与Scrum，Kanban或XP无关。您是按每个人估算的，应该基于每个故事实际完成。考虑整个功能，然后估计故事，而不是单个成员的努力。 按人日/小时估算一直受到批评，因为它不涉及技能组测量。比如，一个具有复杂性5的特征可以在一天内由高级工程师完成，但是对于新的木匠或经验较少的成员需要2天。因此，您不能仅考虑复杂性来衡量故事规模和冲刺承诺。 许多人仅使用复杂性来估计故事，然后根据小时来确定子任务，这也存在缺陷，这是由于实际估计中的重复工作。最重要的是，始终要记住，估计总是一个估计，而规划扑克只能帮助您找到它，但它不是最终的估算技术。 </DIV>

编辑

登录后才能参与评论