ScrumMaster宣言认为:Scrum Master是全职工作

标签: scrummaster 宣言 scrum | 发表时间:2012-01-11 16:00 | 作者:
出处:http://news.cnblogs.com/

在敏捷团队中,Scrum Master 应该是全职角色,还是兼职角色?这几个月,有关于此的讨论在社区中十分热闹。

Scrum Alliance Global Gathering:London 2011会议上, Paul Goddard 作了题为“ Scrum Master-角色还是工作?”的演讲,他分享了自己的研究成果:

75% 的 Scrum Master 在自己担任 Scrum Master 的团队中,专门奉献的时间少于一半。

45% 的 Scrum Master 要支持 2 个或以上 Scrum 团队。

88% 的 Scrum Master 承担的职责不仅限于 Scrum Master。

该演讲最后的成果汇聚为 Scrum Master 宣言。宣言开篇表明了起草者们的立场:

我们相信:Scrum Master 应该是一个全职的职位,一个 Scrum 团队中只能有一个人担任。

宣言接下来列出了 12 条 Scrum Master 的简要核心原则:

  1. 专职的交付改进者
  2. 促进持续改进
  3. 帮助持续改进
  4. 授权教练交付
  5. 给予团队营养
  6. 以光明正大的方式帮助团队
  7. 承诺完成卓越工作
  8. 提供善解人意和传播福音式的指导
  9. 长时间保持热情
  10. 帮助团队
  11. 先认识再改善
  12. 具备敏捷的驱动力

Paul Goddard 在自己的 Agilify 博客上说明了起早该宣言的起因:

⋯⋯当我在指导新的 Scrum Master 时,我在培训班利马发现一个趋势。我会问:Scrum Master 在 Scrum 团队中是全职工作么?”绝大多数人回答:“不是。”我担心:这些 Scrum Master 可能已经丧失了让自己的团队(和组织)真正拥抱 Scrum 的机会,他们没有看到 Scrum Master 在 Scrum 团队中应由专人担任。这个趋势随时间不断明显,促使我要提交一个针对该话题的演讲⋯⋯

Scrum 的创立者之一 Jeff Sutherland 在 2010 撰写的 Scrum 手册中,这样说 Scrum Master:

Scrum 会让很多与团队和产品负责人的效率有关的障碍和威胁显现出来,有一个全情投入的 Scrum Master 积极工作以解决这些问题,这一点很重要⋯⋯

Scrum 团队应该有专人担任全职的 Scrum Master,虽然比较小的团队可以由某一名团队成员承担该角色(那么就要减少此人承担的日常工作量)。

scrumdevelopment Yahoo!讨论组最近的一个讨论中,Jeff 继续强调:Scrum Master 应该是全职角色,尽管他们可以从 backlog 中拉取任务。:

Scrum Master(或其他任何团队成员)不承诺完成特定的 backlog 工作条目。团队作为整体,会预计自己完成的工作。如果 Scrum Master 有时间,他可以从 sprint backlog 中提取任务。对于史上第一个 Scrum Master——John Scrmniotales,80% 的情况下都是设计。我作为他的上司和首席工程师,我会协助卸掉他所有的障碍。在我的上家公司中,规则是这样的:任何一次每日例会上,如果团队看到 Scrum Master 没有花费足够的时间来就移除障碍,团队就会把 Scrum Master 承担的 backlog 工作接手过来。

在自己的 Agile Making Progress 博客中, John Piekos 分享了自己的体会,当时他的组织从瀑布切换到了 Scrum:

虽然我们“接受了培训”,也“阅读了文献”,其中反复强调 Scrum Master 和产品负责人都是全职工作,我们没有完全相信。我们过去工作方式的“固定记忆”,让我们在诸多角色和职责之间来回切换,我们过去习惯了这样工作。然而,在我们的敏捷起航项目中,我们很快就确信:Scrum 的角色不能是兼职的。Scrum 比瀑布式开发要来得更为紧张。

Marcle Baumann 在 最近的一篇博客中,对于更有经验的团队,他提出了不太一样的看法:

我同意宣言作者的话:在与全新 Scrum 团队和刚接触敏捷和 Scrum 工作方式的成员一起工作时,Scrum Master 应该是全职角色。但是我相信:一个 Scrum Master 可以支持多个有经验的 Scrum 团队。

Wayne Grant 从软件开发人员的角度出发,也提出了 不一样的观点

理想状况下,我认为 Scrum Master 应该花费大部分时间做 Scrum Master。但是,我自己的经验说明:如果我和团队成员做同样的工作,就能成为更有效的 Scrum Master,因为我可以分享经验给他们。这不一定是大量的开发工作,甚至也许能让 Scrum Master 与团队成员结对完成工作。

Lasse Koskela 精确地 总结了上述意见

我们需要有全职的 Scrum Master,因为我们需要他们善于完成自己的工作,好的 Scrum Master 能提升我们的工作效率。同时,我们需要兼职 Scrum Master,因为他们的技术贡献能提升我们的工作效率。

很明显,对于 Scrum Master,敏捷和 Scrum 新人、以及现有社区的不同成员之间存在不同理解。Scrum Master 应该是全职工作,还是要依赖于团队成员的经验呢?

查看英文原文: Is the ScrumMaster a Full Time Role? Yes, According to the ScrumMaster Manifesto

本文链接



相关 [scrummaster 宣言 scrum] 推荐:

ScrumMaster宣言认为:Scrum Master是全职工作

- - 博客园_新闻
在敏捷团队中,Scrum Master 应该是全职角色,还是兼职角色. 这几个月,有关于此的讨论在社区中十分热闹. 在 Scrum Alliance Global Gathering:London 2011会议上, Paul Goddard 作了题为“ Scrum Master-角色还是工作.

Scrum联盟将改革ScrumMaster认证

- - InfoQ cn
参加两天认证课程并通过一个所有人都能过(换句话说,不可能挂掉)的考试,你就可以获得 Scrum联盟颁发的 ScrumMaster认证(CSM). 但2012年,这项考试流程将进行改革,几家欢喜几家愁,不再是所有人都能通过了. 同时最晚在2013年元月,Scrum联盟还将推出一套新的专业发展单元(Professional Development Unit, PDUs)来完善他们的认证系统.

Scrum的故事

- Philip - 《程序员》杂志官网
2001年2月,17位敏捷先驱齐聚犹他雪鸟度假村,起草《敏捷宣言》的时候,Scrum只是众多方法中不太起眼的一个. 十年之后,Scrum却成为最流行的敏捷方法,几乎成为敏捷的代名词. 本文来介绍下Scrum的两位创始人——Jeff Sutherland与Ken Schwaber. 大家可能不会想到,Jeff Sutherland的第一份工作居然是美国空军战斗机飞行员,还曾于1967年获得了“壮志凌云”称号,完成过100次飞越北部越南的作战任务.

scrum经验

- - CSDN博客研发管理推荐文章
Scrum是基于过程控制理论的经验方法,倡导自组织团队;其运行框架核心是迭代增量型并行开发,也是“适应性”的软件开发方法. Scrum提供了高度可视化的用于管理软件开发复杂性管理的敏捷项目管理的实践框架或敏捷过程,可以用于对现存软件工程实践的包装,提高软件生产率,改善沟通和合作的方法,使人们协作并注重业务目标.

Trello中的Scrum

- - IT瘾-infoq
Trello的用户数量近期超越了1000万的大关,它正迅速成为各色敏捷团队中流行的工具. 它的简洁及在Web、移动端优秀的体验,使它从众多更复杂的解决方案中脱颖而出,赢得了更多的团队. 因为Trello完全不在意用户如何使用,所以导致用户在用它进行Scrum过程最佳实践时产生一些困惑. 去年,我就如何使用Trello及对Scrum和Kanban过程进行管理与很多人进行了交流,同时,我还翻遍了网上所有关于使用Trello管理敏捷过程的文章.

用Scrum的方式实施Scrum

- - CSDN博客研发管理推荐文章
       用Scrum的方式实施Scrum就是说组织利用Scrum的流程来实现组织的转型. 要成功实施Scrum,必须在组织内进行两项主要改变:首先,软件开发人员必须被派到小团队中,还需要教会他们如何使用Scrum进行软件开发;其次,移除所有有碍于优化创新和软件交付的障碍,这些障碍会随着Scrum的使用逐渐显现.

Scrum 实施经验

- bluesnail - 新浪UED
Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发. Scrum在英语的意思是橄榄球里的争球. 虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法:Scrum of Scrums. Scrum定义了许多角色,根据猪和鸡的笑话分为两组,猪和鸡:.

Scrum中的QA(一)

- - ITeye博客
来自“Priyanka Hasija”的经验,她认为QA在Scrum中要做到:. ① 不仅仅是完成test case,还可以作为Product Owner的代理,完成Acceptance test,在PO没有时间的时候代替PO和团队沟通,甚至通过质疑各种假设等方式帮助PO明确需求. QA在复杂的用户场景和异常流程方面更有感觉,这些可以帮助开发人员做估算时不仅仅考量“happy path”.