Scrum Development 邮件列表中最近有一个讨论, Tri Nguye 提出问题:产品负责人是否应该参与规划扑克游戏?有大概的结论么?正如 Ron Jeffries 明确指出的:
他们应该在场么?是的,说明他们的意思。 他们应该估算么?不,除非他们准备参与编码工作。
也就是说,在规划扑克游戏中,产品负责人应该负责澄清每个用户故事的完成条件,比如:应该包括哪些功能,不要哪些功能,要达到哪些标准等等等等。但是产品负责人不应该帮助团队估算达成这些条件需要多少工作量。以规划扑克形式表示的量化工作量估算,必须由开发团队独立完成。
不让产品负责人提供估算的原因很简单。开发团队成员需要做出承诺,承诺接下来的 sprint 中要完成哪些功能。如果产品负责人可以为这个承诺施加过多影响,团队就无法真正将该承诺视如己出,因此失去很多 Scrum 中自组织所带来的力量。
然而有一种特殊情况,产品负责人可能需要提供自己的工作量估算。 Dan Rawsthorne 指出:
记住:产品负责人是一个角色,是一个人。人可以扮演其他角色,而且在这些角色中,人可能要进行工作量估算。
如果产品负责人也是一个开发人员,实际上,他可能就要在规划扑克过程中提供估算了。考虑到产品负责人角色所占用的时间,其实很少有产品负责人有时间从事开发工作。
产品负责人在估算过程中是不是必须完全沉默?也不一定。规划扑克是一种有用的工具,可以检查在产品负责人和开发团队之间的沟通误差,一旦发现沟通误差,就必须马上纠正。Henrik Kniberg 在他的《硝烟中的 Scrume 和 XP》一书中给出如下例子:
团队和产品负责人对于 sprint 计划非常满意,准备结束会议。这时 Scrum Master 说到:“稍等,这个名为‘添加用户’的故事还没有估算。咱们来看看吧!”经过几轮规划扑克活动之后,团队同意分配 20 个故事点数。此时产品负责人站了起来,怒道:“什么?!”经过几分钟热烈的讨论,发现团队错误理解了“增加用户”的范围,他们以为这需要‘一个很好的 web 图形用户界面来添加、移除、删除、搜索用户’;然而产品负责人只想要”通过 SQL 直接操作数据库,手动添加用户“。他们重新估算了以下,最后同意 5 个故事点数。
在这个例子中,规划扑克起到了交叉检查的作用,防止对于用户故事范围的错误理解。
查看英文原文: How Should a Product Owner Participate in a Planning Poker Session?
评论