项目经理和Scrum Master
我的图书馆
项目经理和Scrum Master
在博客上，大家对于Scrum Master和项目经理这两个角色依旧争论不休，许多评论员清晰地指出两者的不同，并表示两者不可并存，更不适合合二为一。
在Scrumalliance站点上发布了名为《》的博文，他提到：
与大众的认识相反，Scrum Master和项目经理这两个角色是完全不同的，也不应该混为一谈。当越来越多的公司向敏捷转变，许多人却仅仅是随波逐流，对他们将要从事的工作并没有足够的认识和理解。尤其是大家对敏捷中的一些角色妄加臆测，总梦想着瀑布实践中的角色也会一锅端地“动迁”过去？然而，Scrum Master并不承担任何传统项目经理的职责。
他进一步谈到：
传统意义上来说，项目经理扮演的是领导者、决策者、计划者的角色，他要管理项目和团队，是负责达成项目商业目标的人。Scrum Master更侧重于教练和引导者，是设立在项目和客户之间的角色。Scrum Master不管理实际工作的团队；反而，他会协助产品负责人，辅导团队，确保项目遵循Scrum流程。Scrum Master只负责Scrum流程能够正确、持续的实施，发挥出它的最大效用。
针对“”这一问题，PM Stack Exchange站点上有一系列的讨论。
Scrum在协助团队识别要做什么和告诉他们怎么做之间划了分水岭。试图让一个人一肩挑将会造成很多矛盾。遇到棘手的情况，比如你是去商谈软件功能，还是要帮助团队成长，你该如何抉择而达成一致呢？Scrum Master是个引导者，一旦要他/她负责这个项目的成败，还顾得上去引导吗？
提供了下面的图表来区分各种角色：
（点击图片放大）
尽管有那么多关于两个角色无法并存的忠告和共识，许多招聘者和雇主依然要招这样的——究竟为什么呢？
查看英文原文：
TA的最新馆藏
喜欢该文的人也喜欢注册 | 登录
我们用技术创新改变传统金融
产品经理就业特训营，专门为大学生和准备转型做产品的人量身定制，60天线下培训，包就业！
如何跟踪项目进展，了解团队生产率，分析千行代码缺陷率等，相信对于一个PM来说，PV, EV, SV, CV, Defect Density等这些概念都是烂熟于胸的，然而对于Scrum的PM，面临的困境是，项目开始的时候，要开发的产品没有明确的需求和时间轴，手头拿到的只是一个High Level的Product Backlog，PM甚至不知道6个月后这个Backlog会不会面目全非。显然，传统的管理方式是很难让人客观了解项目的进展并评价项目。为了客观评价一个Scrum团队的承载力和效率，点融黑帮今天给大家提供几个容易上手的度量标准和追踪的方法，简单快速帮助大家评价和管理一个Scrum团队。
Velocity （已经完成的故事点！）
好吧，我们说的是在一个Sprint中已经彻底完成的故事点，没有Defect，不是部分完成的，而是真正的已经把User Stories转化为已经生产运行的软件的大小（点数）。
什么？已经被解决的Defect算不算，你觉得你去4S店买了辆车发现雨刮器噪音太大，结果人家帮你修好了问你要修理费，你会给吗？ 只有真正完成并交付使用的功能才被记录成为某个Sprint的Velocity，它代表的是一个Scrum团队真正的速率。
哦，对了，正规的项目交付中，我们还分为已完成的Velocity和被接受的Velocity，前者是团队的认知，而后者是PO的认知，如果两个值不一样，恭喜你，你有了一个Impediment。此外，请注意，我们计量的单位是故事点，而不是人天，工作小时或者其他什么，若干个Sprint的ramp up以后，我们希望Velocity和股票一样涨涨涨！
下一个Sprint的承载力（这个单位是人天！）
如果你不知道在下一个Sprint你有多少人能有多少时间为你的项目工作，那你自己就是一个Impediment，从趋势角度来说，我们希望看到的是一个稳定的承载力，任何不稳定的变化，即便是承载力的上升，也未必对团队的速率和质量有好处。
如果一个团队成员有20%投入在你的项目上，是否应当叠加他的人力呢，我的答案是否，试想你每天要花人力到处去找他，找到他也不一定能持续性的解决问题，天知道到底是加强团队承载力还是削弱，这些人有时候也许能解决大问题，但如果我是你，我会在管理成本和Impediment里都记上一笔。和Velocity不同的是，有时候我们并不喜欢这个值涨涨涨，我们更喜欢看到稳定的趋势，否则，你需要正视这个Impediment。
下一个Sprint的承载力（这回说的是故事点啦！）
如果你跑了5个Sprints，发现Velocity渐渐稳定在50左右，这时候，你就可以根据50故事点这个数字作为你团队交付能力的一个重要参照，也可以成为你未来项目走向和预判的一个重要数据支撑。
在Sprint Planning Meeting上，你的团队成员会承诺在下一个Sprint中完成多少个Story Points，如果累计的数字和50相差甚远，你最好问问团队，哪里出了问题。记录每个Sprint Planning中得出的预估完成故事点的数量，将他们和Velocity表对比，你就知道哪里出了什么问题。
Sprint中的范围蔓延 （你最好问问你的PO!）
你需要了解每个Sprint中增加/减少的Story Point，甚至是增加/减少的Story，我们希望这样的变化趋于0，但我们可以接受一定范围内的增加，但当这种趋势越来越不可控的时候，你最好问问你的PO，因为他看起来是你团队最大的Impediment。
分析问题，解决问题 (二八法则！)
如果你信奉二八法则，你可以试试帕累托分析来分析问题和解决问题，找到你的defect，通过鱼骨图找到造成问题的原因并记录下来，你会很快发现你80%的defect是由20%的原因造成的，解决了20%的Root cause，80%的问题将迎刃而解，是不是很酷。
Sprint的成功或失败 （直面成功或者失败！）
每个Sprint都应该有一个准确的结果定义，成功或者失败，不存在接近成功或者有些失败。你可以定义成功的标准，按时交付，按质交付，成本的控制，但重要的不是定义成功或者失败的指标，重要的是给团队一个Sprint结束后的准确评价，如果一个Sprint获得了失败的结果，那么每个团队成员在评审会议中都应该找到解决办法，期望下一次可以获得成功。让你的团队产生对成功的渴望，追逐每一个Sprint的完美交付，如果你没有这么想，那么你就是那个Impediment。
这些指标和分析给谁看，给Senior Management Team？不不不，他们只想知道你的项目是不是红色，即便是橙色预警，他们也默认你的团队可以自行解决。这些信息应该给到你的Scrum团队，让他们知道发生了什么，是否存在问题，发生问题的原因是什么，最终帮助解决问题，快速成长和提高。 当然，如果你的团队缺乏足够的自我约束力，足够的工作积极性，你最好检讨下是不是面试环节出了问题 lol。
本文由点融黑帮 @Richie Zhang 原创投稿，并经人人都是产品经理编辑。未经许可，禁止转载。
如果觉得写的不错，欢迎打赏支持
收藏已收藏 | 30赞已赞 | 5
我们用技术创新改变传统金融
产品经理群运营交流群求职招聘群
Axure交流群
PM要学点技术
关注微信公众号
10个回答15人关注
0个回答0人关注
8个回答27人关注
11个回答10人关注
9个回答81人关注
14个回答21人关注有关敏捷开发的一些面试问题，希望对应聘Scrum Master或者项目经理的朋友有所帮助
有关敏捷开发的一些面试问题，希望对应聘Scrum Master或者项目经理的朋友有所帮助
如果你面试的是Scrum Master或者项目经理职位，且在你的简历里面标注你熟悉某某敏捷开发方法，请准备好以下几个问题来展示你已经理解并掌握了这种敏捷方法：
1. 敏捷开发（测试）方法与其他开发（测试）方法的主要区别是什么？
2. 敏捷方法可以适用到除软件开发和软件测试的项目或工程中去吗？ 哪种项目你认为比较适合敏捷方法？
3. 请介绍一下敏捷开发的特点，越多越好，特别是那些与其他方法不同的特点。
4. 你是什么时候开始使用敏捷方法的？请描述一下项目的概况及采用敏捷方法所带来的优势和问题。
5. 如果有一个简单的测试项目，Beta版本的，请介绍一下你如何使用敏捷方法进行测试？ 你会如何选择敏捷团队的成员？
&&&主编推荐
H3C认证Java认证Oracle认证
基础英语软考英语项目管理英语职场英语
.NETPowerBuilderWeb开发游戏开发Perl
二级模拟试题一级模拟试题一级考试经验四级考试资料
软件测试软件外包系统分析与建模敏捷开发
法律法规历年试题软考英语网络管理员系统架构设计师信息系统监理师
高级通信工程师考试大纲设备环境综合能力
路由技术网络存储无线网络网络设备
CPMP考试prince2认证项目范围管理项目配置管理项目管理案例项目经理项目干系人管理
职称考试题目
招生信息考研政治
网络安全安全设置工具使用手机安全
生物识别传感器物联网传输层物联网前沿技术物联网案例分析
Java核心技术J2ME教程
Linux系统管理Linux编程Linux安全AIX教程
Windows系统管理Windows教程Windows网络管理Windows故障
数据库开发Sybase数据库Informix数据库
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&　　在敏捷团队中，Scrum Master 应该是全职角色，还是兼职角色？这几个月，有关于此的讨论在社区中十分热闹。
　　在 会议上， 作了题为&&的演讲，他分享了自己的研究成果：
75% 的 Scrum Master 在自己担任 Scrum Master 的团队中，专门奉献的时间少于一半。
45% 的 Scrum Master 要支持 2 个或以上 Scrum 团队。
88% 的 Scrum Master 承担的职责不仅限于 Scrum Master。
　　该演讲最后的成果汇聚为 。宣言开篇表明了起草者们的立场：
我们相信：Scrum Master 应该是一个全职的职位，一个 Scrum 团队中只能有一个人担任。
　　宣言接下来列出了 12 条 Scrum Master 的简要核心原则：
专职的交付改进者
促进持续改进
帮助持续改进
授权教练交付
给予团队营养
以光明正大的方式帮助团队
承诺完成卓越工作
提供善解人意和传播福音式的指导
长时间保持热情
先认识再改善
具备敏捷的驱动力
　　Paul Goddard 在自己的 Agilify 博客上说明了起早该宣言的起因：
??当我在指导新的 Scrum Master 时，我在培训班利马发现一个趋势。我会问：Scrum Master 在 Scrum 团队中是全职工作么？&绝大多数人回答：&不是。&我担心：这些 Scrum Master 可能已经丧失了让自己的团队（和组织）真正拥抱 Scrum 的机会，他们没有看到 Scrum Master 在 Scrum 团队中应由专人担任。这个趋势随时间不断明显，促使我要提交一个针对该话题的演讲??
　　Scrum 的创立者之一
在 2010 撰写的 中，这样说 Scrum Master：
Scrum 会让很多与团队和产品负责人的效率有关的障碍和威胁显现出来，有一个全情投入的 Scrum Master 积极工作以解决这些问题，这一点很重要??
Scrum 团队应该有专人担任全职的 Scrum Master，虽然比较小的团队可以由某一名团队成员承担该角色（那么就要减少此人承担的日常工作量）。
　　最近的一个讨论中，Jeff 继续强调：Scrum Master 应该是全职角色，尽管他们可以从 backlog 中拉取任务。：
Scrum Master（或其他任何团队成员）不承诺完成特定的 backlog 工作条目。团队作为整体，会预计自己完成的工作。如果 Scrum Master 有时间，他可以从 sprint backlog 中提取任务。对于史上第一个 Scrum Master&&John Scrmniotales，80% 的情况下都是设计。我作为他的上司和首席工程师，我会协助卸掉他所有的障碍。在我的上家公司中，规则是这样的：任何一次每日例会上，如果团队看到 Scrum Master 没有花费足够的时间来就移除障碍，团队就会把 Scrum Master 承担的 backlog 工作接手过来。
　　在自己的 中， 分享了自己的体会，当时他的组织从瀑布切换到了 Scrum：
虽然我们&接受了培训&，也&阅读了文献&，其中反复强调 Scrum Master 和产品负责人都是全职工作，我们没有完全相信。我们过去工作方式的&固定记忆&，让我们在诸多角色和职责之间来回切换，我们过去习惯了这样工作。然而，在我们的敏捷起航项目中，我们很快就确信：Scrum 的角色不能是兼职的。Scrum 比瀑布式开发要来得更为紧张。
　　Marcle Baumann 在中，对于更有经验的团队，他提出了不太一样的看法：
我同意宣言作者的话：在与全新 Scrum 团队和刚接触敏捷和 Scrum 工作方式的成员一起工作时，Scrum Master 应该是全职角色。但是我相信：一个 Scrum Master 可以支持多个有经验的 Scrum 团队。
　　Wayne Grant 从软件开发人员的角度出发，也提出了：
理想状况下，我认为 Scrum Master 应该花费大部分时间做 Scrum Master。但是，我自己的经验说明：如果我和团队成员做同样的工作，就能成为更有效的 Scrum Master，因为我可以分享经验给他们。这不一定是大量的开发工作，甚至也许能让 Scrum Master 与团队成员结对完成工作。
　　 精确地：
我们需要有全职的 Scrum Master，因为我们需要他们善于完成自己的工作，好的 Scrum Master 能提升我们的工作效率。同时，我们需要兼职 Scrum Master，因为他们的技术贡献能提升我们的工作效率。
　　很明显，对于 Scrum Master，敏捷和 Scrum 新人、以及现有社区的不同成员之间存在不同理解。Scrum Master 应该是全职工作，还是要依赖于团队成员的经验呢？
　　查看英文原文：