ScrumMaster 或者迭代经理在敏捷团队里面是一个关键角色,而且,对于 ScrumMaster,选择与哪个组织合作或者与哪个团队共事是非常重要的——在考虑是否接受一个新项目的时候,很重要的是创造一个取得成功的环境。
敏捷宣言强调个体胜过流程,而ScrumMaster 的很大一部分职责就是创建团队氛围,让人们互相合作,有效地交付可工作的软件。
Scrum 官方网站把 ScrumMaster 的职责定义为
ScrumMaster 负责在团队中正确、完整地贯彻 Scrum 流程。虽然在实施开始的时候必须做一些折衷,而且因为实施环境的限制不得不放弃某些实践,但是 ScrumMaster 在脑海中始终要铭记实施完整的 Scrum 所带来的好处和价值,渐进地推动团队和组织走向完美状态。
ScrumMaster 特别要对以下工作负责: - 清除挡在客户和开发工作之间的拦路虎,客户从而可以直接驱动开发。
- 教导客户如何最大化 ROI,以及通过 Scrum 实现他们的目标。
- 通过激发创造性与推动授权来提升开发团队的成员
- 以任何可能的方式提升开发团队的开发效率
- 改进工程实践和工具,使得每次功能性上的改进都能得以交付
因为角色的关键性,所以有两点很重要:首先,确保在团队里面担任 ScrumMaser 角色的人必须名至实归;其次、确保团队的环境氛围有助于取得成功。博客 Scrumology 的作者 David J Bland 为有可能成为 ScrumMaster 的人提供了一个列表,包含 10 个问题,供他们在考虑换个团队或者项目的时候参考:
- 你们的迭代周期是多长?——理想状况下应该是 2 周,但如果有理由显示这个周期太短了,这是个积极的信号。但是,如果答案是长达几个月,你就要小心了,因为这绝对不可能敏捷。
- 你们的团队有多少人,怎么构成?——小型的、跨功能的团队非常重要。如果对方倾向于使用大量开发人员,而且各自职能严格划分,你就要小心了。此外,团队是分布式开发,还是坐在一起,这你也应该弄清楚。
- 你们的 Product Owner 能及时回答问题吗?——找不着人的 Product Owner 会严重破坏敏捷团队。这可能就是为什么 ScrumMaster 职位空缺的原因了!
- 你们引入了持续集成吗?——如果部署程序还是依赖于繁琐的批处理流程,是很难坚持敏捷原则的。努力限止他们对现有工具的继续使用,不要让他们逃避这个问题。
- 你们使用测试驱动开发或者测试驱动设计吗?——理由跟上面的 CI(持续集成)一样,TDD 是敏捷与否的另一项指标。再一次,努力找出他们在现有流程下选用的工具集,在不同的技术栈下这会有所区别。
- 你们怎样记录用户故事?——这个问题没有最佳答案,但对方应该就任务板或者项目管理软件中记录的功能简单讲一下。如果碰见过长的软件需求规范或者功能规范,就应该亮起一盏红灯了。
- 你们使用哪些衡量指标来跟踪进度?——故事点数或者小时数应该就足够了。我会注意他们(估计故事点数)的斐波那契数范围是否已经到了极致。比较实际和预估的故事点数可以把会谈带向有趣的方面。试着判断团队成员是否使用了实际故事点数。
- 你们的团队多长时间碰面?——如果 ScrumMaster 的工作做好了,答案应该是每天!对于分布在不同时区的分布式团队,这可能颇具挑战。
- 你们的敏捷实施有上层支持吗?——我曾在没有上层支持的情况下实践过草根式的敏捷,得到的经验就是:在不知道全局的情况下,我绝对不会贸然开工。如果老板宣称甚至 CxO 们 [译注 1:指 CEO/CTO/CFO…等以 C 开头的职务] 也接受过 CSM/CPO 培训,这对我来说是一个很大的有利因素。
- ScrumMaster 还有什么其他职责?——根据组织不同,这会有所差别,但这个问题还是有必要问的,特别是如果那些职责丝毫不能引起你的兴趣。最好是现在就弄清楚它们。
Johanna Rothman 、 Steve Smith 、 George Dinwiddie ,以及 Aye Conference 的其他主办者给面谈双方提供了一个清单,就面谈和评估提供了一些很有益的提示:
面谈提示:
- 尽可能使用开放性问题
- 尽可能使用描述行为的问题来得到真实的例子
- 使用元问题提问“然后呢”,从针对技术人员的战术问题转向询问单独的、与管理相关的战略性问题
面谈陷阱:
- 不要问领导的问题,比如“你的经理是个蠢材吗?”你永远不可能得到一个诚实的回答,而且问题本身也暴露出你的忠心度、诚实度和可信度。一个问题就会让你减分不少。
- 避免询问对方的主观观点,比如“你喜欢你现在做的事情吗?”相反,把问题改成“这里什么对你是有效的?”以及“哪些东西妨碍了你完成自己的工作?”
除此之外,试图弄清底细的 ScrumMaster 还会遇上什么陷阱,又该如何避免呢?在这里留下你的经验分享吧。
评论