Scrum中的
在Scrum中有三个角色:产品负责人,团队和ScrumMaster。他们在一起被称为Scrum团队。
产品负责人负责最大化投资回报(ROI,return on investment),通过确定产品特性,把它们翻
译成一个有优先级的列表,为下一个Sprint决定在这个列表中哪些应当优先级最高,并且不断地重新
调整优先级和梳理这个列表。对于商业产品而言,产品负责人对产品的赢亏负责。对于内部应用的
情况,从非(可以产生收入的)商业产品的角度来讲产品负责人不为ROI负责,但从选择每个Sprint
具有最高价值事项的角度来讲他们仍为最大化投资回报负责。在实践中,“价值”的含意很模糊,优
先级的制定可能会受希望让关键客户满意、保持与战略目标一致、解决风险、改进以及其他因素的
影响。在有些情况下,产品负责人与客户是同一个人。这在内部应用时很常见。有时,客户可能是
带着不同需求的几百万人,在这种情况下,产品负责人与很多产品开发组织中的产品经理或者产品
市场经理类似。然而,产品负责人与传统的产品经理有些不同,因为产品负责人积极地并经常地与
团队互动,重点放在与所有的利益相关人一起工作并且评审每个Sprint的结果,而不是把开发相关的
决定交由项目经理来代理。值得注意的是,在Scrum中,有一个人,且只有一个人做产品负责人并拥
有其最终的权力。他对工作所产生的价值负责。然而这个人却不一定必须独自工作。
团队(也叫开发团队)建造产品负责人所指定的产品,例如应用程序或者网站。Scrum中的团队
是“跨职能”的,它包含了每个Sprint为了交付潜在可交付的产品所需的所有专业能力,并且它是“自组
织”(自管理)的,被给予很高程度的自治和责任。由团队来决定在某个Sprint中要完成多少(从产
品负责人给出的集合中的)事项,以及怎样才能最好地达到这个目的。
团队中的每个成员都只是“团队成员”。请注意在采用Scrum的团体中没有任何固定的专业头衔。
不会有业务分析员,没有数据管理员,没有架构师,没有团队组长,没有交互/用户体验设计师,也
没有程序员,他们在每个Sprint中以任何恰当的方式一起工作来达到他们为自己设置的目标。
因为只有“团队成员”,这种团队不只是跨职能的而且还会表现出“多重学习”的特点。每个人当
然都有特长,但仍继续学习其他专长。每个人都会有主要的、次要的甚至是第三位的技能,并准备
好“到工作所需要的地方去”。每个人都可能承担自己并不熟悉领域的任务来帮助完成一个事项。例
如,一个主要技能是交互设计的人可能以自动化测试为次要技能。以技术文档写作为主要技能的人
可能同时帮助做分析和编程。
Scrum中的团队由七个人左右(加上或减去两个人)组成,对于一个软件产品来讲团队可能包含
具有分析、开发、测试、接口设计、数据库设计、架构、文档等等技能的人。团队开发产品,并且
向产品负责人提供如何把产品做得更出色的想法。在Scrum中,当所有成员在Sprint中都百分之百地
投身于同一个产品的工作时,产量和效率最高。团队避免了在多个产品或项目之间的多任务,从而
避免了分散注意力和工作内容切换的高代价消耗。稳定的团队会具有更高的生产率,因此要避免改
变团队成员。有很多人组成的产品开发团体要被组织成多个团队,每一个都关注于产品的不同特
性,紧密合作,共同努力。由于一个团队往往要做所有完成以用户为中心的特性所需的工作(计
划、分析、编程和测试),这样的团队也被称为“特性团队”。
ScrumMaster帮助产品开发团体学习并应用Scrum来达成商业价值。ScrumMaster会做任何力所能
及的事情来帮助团队、产品负责人和组织取得成功。ScrumMaster不是团队成员的经理,也不是项目
经理、团队带头人或者团队的代表。相反,ScrumMaster为团队服务。他帮助移除阻碍,保护团队免
受外部干扰,并且帮助团队采用现代的开发实践。他教育、培养并指导产品负责人、团队以及组织
中其他的人来提高他们使用Scrum的技巧。ScrumMaster是教练和导师。ScrumMaster确保每个人(包
括产品负责人和管理者)理解Scrum中的原则和实践,并且他们帮助带领组织完成敏捷开发要取得成
功所需的那些通常都很困难的改变。因为Scrum使得影响团队和产品负责人有效性的很多阻碍和风险
都变得可见了,由专注的ScrumMaster全身心地帮助解决这些问题就非常重要,否则团队或者产品负
责人会发现很难取得成功。ScrumMaster应该是专门全职的,然而,小一点的团队可能由其中一个团
队成员扮演这个角色(这样做时他们只能肩负较轻的日常工作量)。出色的ScrumMaster可能来自于
任何背景或专业:工程、设计、测试、产品管理、项目管理或者质量管理。
ScrumMaster和产品负责人不可以是同一个人,因为他们的关注点太过不同,合并这两个角色通
常导致困惑和冲突。合并这两个角色的一个常见的不幸结果是产品负责人进行微观管理,这与Scrum
所要求的自管理团队相冲突。与传统的管理者不同,ScrumMaster不会告诉别人要做什么或者分配任
务,他们推进流程,为团队的自组织和管理提供支持。如果ScrumMaster以前在管理团队的岗位上工
作,那么要在Scrum上取得成功,他需要很大程度上改变与团队互动的心态和思考方法。