CSPO是什么？CSM是什么？Scrum Master和产品负责人可以取代或合二为一吗？

tonyit

CSPO是什么？CSM是什么？Scrum Master和产品负责人可以取代或合二为一吗？
CSPO即: Certified Scrum Product Owner(产品负责人认证)，CSM即: Certified Scrum Master(CSM认证Scrum Master)很多小团队或组织想将产品负责人与Scrum Master合二为一。这么做可取吗？有谁做过这事儿吗？还有其他方式么？Mike Cohn（《Agile Estimating and Planning》的作者）认为，Scrum Master：负责确保一个Scrum团队保持Scrum的价值观和实践。通过阻止团队在一个Spring中承诺过多的任务来保护团队。Scrum Master组织daily scrum并负责清除在这些会议上反映出来的那些障碍。一般来说，Scrum Master这个角色由项目经理或团队技术主管担任，但并不限于此。另外，Scrum Master应确保团队行为正确。而产品负责人：（一般来说，他来自于市场或内部开发中的一个关键用户）排定Product Backlog中任务（items）的优先级。Scrum团队查看这个排定好优先级的Product Backlog，并从最高优先级开始选择一系列的任务（items），并承诺可以在一个Sprint中完成它们。这些任务（items） 就成了Sprint Backlog。 作为这一承诺（完成这个Sprint Backlog上的所有任务）的回报，产品负责人承诺他不会再向这个Sprint中加入新的需求。需求是可以改变的（而且鼓励改变需求），但必须在 Sprint之外。团队一旦开始一个Sprint，接下来的工作就只是完成这个Sprint的目标啦。
正如Matt Gelbwaks 指出的那样，产品负责人负责业务概念与想法（例如backlog），而Scrum Master负责执行与质量，所以产品负责人想要更多的Feature，但Scrum Master更关注于及时完成Sprint。Tomek Wlodarek解释道，不同的出发点只是问题的一半。另一半问题是对时间的承诺：“我在某个真实企业环境下学到了一点：即一个SM是一个5到6人团队中的全职角色，而在这样的团队中，PO角色可能只是60%到100%。”
Dan Rawsthorne写道：我干过这事，我一个人负责PO，SM以及架构师三个角色。为了让我的团队自组织，有时候，我会站在团队面前，说：“一方面，作为……另一方面，作为……那我做什么呢？”事实证明这样可行，但是非常困难，我再也不想身处这样的环境，也不希望任何人再尝试了。
Tom Mellor也曾经看人这样干过，而且这个人很有才能，现在是个全职教练。
Steve Eichert对此事执乐观态度：“假如一个人能不混淆且适合两个角色的话就可以做这事儿。而且如果必要，这么做也无所谓”。然而他仍推荐将两个角色分开。
Ken Schwaber 也在一个CSM课上说过，在找到适当的受过训练的PO之前，有经验的Scrum Master可以先代理PO的角色。
成为有效率的产品负责人
在一个新项目中第一次做产品负责人时，什么是必须要做的，并且需要花费多少时间？”尽管有些产品负责人已参加过Scrum介绍会议，仍然需要确认一下具体责任。必需的时间承诺和上司的支持问题是关键。帮助产品负责人入门是我们的基本职责。在大多数团体中，产品负责人要么经常被时间捆绑，要么没有意识到自己的责任，或者不确信怎样最好地实现新角色过渡。令人遗憾的是，许多更像是商业赞助者的Scrum项目产品负责人，他们只是在Sprint计划和评审会议上短暂停留一下，或者和团队参加现场客户互动较频繁一些，却把指导团队的责任丢给了ScrumMaster。
产品负责人不是代理
很多时候，产品经理们选择不去做产品负责人（PO, Product Owner）。他们谋划着由一个业务分析员或者产品分析员去“代理”产品负责人。当然，也是因为大部分关于产品负责人的书籍和培训都把他或者她当成是scrum团队的一个附属物：他们要做的只不过是写写用户故事和玩玩计划扑克，要按照INVEST原则而已。所有的这些关于产品负责人的定义都是从开发者的角度来的。
Scrum并没有定义如何使用产品backlog，或者是产品负责人应该做什么。而且，我也确实 认识有人没有用Scrum却在很好的写着用户故事来优化他们的产品管理工作。他们成为了很好的业务分析员，或者需求工程师。将产品负责人的职责授权出去会进一步增加开发团队与客户之间的距离。我对Scrum Master的期望是他们能缩短这个距离。Scrum Master可以去教会业务如何行使PO的角色来做到敏捷。Scrum Master能帮助PO去理解如何抓住机会，去优化价值，如何与团队合作。PO无论如何也不会因为要去做需求开发而变成业务分析员。Scrum一直由（软件）开发领域来促进。我想这是为什么我们只会从我们的角度来看待PO的角色。我们能做点什么改进吗？我们从来没有在他们的角度来看过，对一个产品负责，考虑开发团队如何与PO协作来帮助PO把工作做得更好。
产品经理们和客户已经开始明白了。他们已经明白我们需要他们来帮我们把我们的工作做好。他们开始逃跑，只留下一个没有实质意义的PO的职位，叫产品负责人或者业务分析员。当然，这会直接修复瀑布的作法，使得在开发者和负责产品及其使用的人之间加入了一个中间人。产品负责人也不能是Scrum Master。他们都有各自不同的兴趣和习惯。改变他们的习惯是很难的。改变他们来让他们同时从两个角度看问题是不可能的。他们首先要学会用新的方法来把工作做得敏捷。
我们将会引入一个新的课程，纯粹关注在如何让一个产品经理变得敏捷，来解决这个问题。他或者她可以使用Scrum或者是其它任何一个使用迭代式增量技术的方法，但是关键是要敏捷，价值驱动，并且看重机会-而不是仅仅坐在那里写用户故事。

来源于IASN·爱朔科技http://www.iasn.com.cn/page/jbkc/ http://www.iasn.com.cn/page/CSPO/