领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
产品负责人如何参与规划扑克游戏？
作者 Dan Puckett 译者 郑柯 发布于 2010年8月10日
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?
译者 郑柯 InfoQ中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。
没有回复
关注此讨论 回复