扫码阅读
手机扫码阅读
多团队如何评估故事点(译)
459 2024-02-22
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:多团队如何评估故事点(译)
文章来源:
Bruce Talk
扫码关注公众号
规模化敏捷中的多团队评估挑战
当组织扩展敏捷实践到多个团队时,协调和评估工作的复杂性会增加。团队必须进行评估和计划,并跟踪进度,以便产品负责人可以优先排序工作并与利益相关者沟通。多团队环境的挑战包括处理不同技能水平的团队、在不涉及所有人的情况下进行准确评估,以及在不确定最终执行团队的情况下预先评估。
常见的评估错误
组织在多团队评估中常犯的两个错误包括:
- 选择一小部分人进行评估,结果可能不反映所有团队的能力,导致评估结果过于乐观,从而破坏客户信任和工作关系。
- 将用户故事点等同于具体的小时数,这会消除故事点的主要好处,即评估不依赖于执行工作的个体,导致管理层错误比较不同团队的速度。
多团队项目的有效评估方法
针对包含多团队的项目,有效的评估方法是建立一个所有团队都认可的共同基准评估,用于评估和跟踪共享目标的进度。
让正确的人参与
建立跨多个团队的共同基准评估的最佳方法是将每个团队的代表聚集在一起,数量取决于团队的规模和数量。团队应选择最能进行评估的人员,考虑代表的技能组合。
评估多种类型的待办事项
代表团队通过玩计划扑克等活动进行评估,最好是面对面,但也可以虚拟进行。这些代表不会评估整个待办列表,而只估计10-20个能代表工作多样性的项目。
避免每个人都对所有事项精通
并非每位评估者都需要理解待办事项列表中的每一项。选择代表广泛产品范围的项目,并且多数参与者能够参与评估是关键。这样,通过代表团队达成一致的基准评估使各团队能够统一地进行评估。
译者的观点
相对估算如故事点估算具有易于达成共识的优势,应避免将其转换为绝对估算(如具体小时数)。基准评估应覆盖多种类型的用户故事以便于快速估算。多团队环境下,全员参与会议效率低下,选择团队代表进行评估是一种更高效的方法。
想要了解更多内容?
查看原文:多团队如何评估故事点(译)
文章来源:
Bruce Talk
扫码关注公众号
Bruce Talk的其他文章
暴露阻碍还是让他“顺利”的流动
是什么原因让我们害怕工作流程中的阻碍?暴露它还是让它“顺利”的流动下去?哪个对我们更有价值?
玩一场用户故事的Cosplay
我们如何确定团队成员对需求已经理解一致?每个人看到Design之后想法就能一致吗?只有产品做完才能确定是否是客户想要的吗?
用户故事信息过多或过少带来的问题
用户故事信息过多或过少对团队来说都不合适。Just Enough \x26amp; Just In Time。
用户故事拆分案例分享——SPIDR实践
关于Mick Cohn的SPIDR拆分法实例分享。
重新理解“软件工程”
说了也听了这么多年“软件工程”,我们真的知道“软件工程”要解决的东西吗?
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线