ScrumMaster项目面谈诀窍

ScrumMaster或者迭代经理在敏捷团队里面是一个关键角色，而且，对于ScrumMaster，选择与哪个组织合作或者与哪个团队共事是非常重要的——在考虑是否接受一个新项目的时候，很重要的是创造一个取得成功的环境。

敏捷宣言强调个体胜过流程，而ScrumMaster的很大一部分职责就是创建团队氛围，让人们互相合作，有效地交付可工作的软件。

Scrum官方网站把ScrumMaster的职责定义为

ScrumMaster负责在团队中正确、完整地贯彻Scrum流程。虽然在实施开始的时候必须做一些折衷，而且因为实施环境的限制不得不放弃某些实践，但是ScrumMaster在脑海中始终要铭记实施完整的Scrum所带来的好处和价值，渐进地推动团队和组织走向完美状态。

ScrumMaster特别要对以下工作负责：

• 清除挡在客户和开发工作之间的拦路虎，客户从而可以直接驱动开发。
• 教导客户如何最大化ROI，以及通过Scrum实现他们的目标。
• 通过激发创造性与推动授权来提升开发团队的成员
• 以任何可能的方式提升开发团队的开发效率
• 改进工程实践和工具，使得每次功能性上的改进都能得以交付

因为角色的关键性，所以有两点很重要：首先，确保在团队里面担任ScrumMaser角色的人必须名至实归；其次、确保团队的环境氛围有助于取得成功。博客Scrumology的作者David J Bland为有可能成为ScrumMaster的人提供了一个列表，包含10个问题，供他们在考虑换个团队或者项目的时候参考：

1. 你们的迭代周期是多长？——理想状况下应该是2周，但如果有理由显示这个周期太短了，这是个积极的信号。但是，如果答案是长达几个月，你就要小心了，因为这绝对不可能敏捷。

2. 你们的团队有多少人，怎么构成？——小型的、跨功能的团队非常重要。如果对方倾向于使用大量开发人员，而且各自职能严格划分，你就要小心了。此外，团队是分布式开发，还是坐在一起，这你也应该弄清楚。

3. 你们的Product Owner能及时回答问题吗？——找不着人的Product Owner会严重破坏敏捷团队。这可能就是为什么ScrumMaster职位空缺的原因了！

4. 你们引入了持续集成吗？——如果部署程序还是依赖于繁琐的批处理流程，是很难坚持敏捷原则的。努力限止他们对现有工具的继续使用，不要让他们逃避这个问题。

5. 你们使用测试驱动开发或者测试驱动设计吗？——理由跟上面的CI（持续集成）一样，TDD是敏捷与否的另一项指标。再一次，努力找出他们在现有流程下选用的工具集，在不同的技术栈下这会有所区别。

6. 你们怎样记录用户故事？——这个问题没有最佳答案，但对方应该就任务板或者项目管理软件中记录的功能简单讲一下。如果碰见过长的软件需求规范或者功能规范，就应该亮起一盏红灯了。

7. 你们使用哪些衡量指标来跟踪进度？——故事点数或者小时数应该就足够了。我会注意他们（估计故事点数）的斐波那契数范围是否已经到了极致。比较实际和预估的故事点数可以把会谈带向有趣的方面。试着判断团队成员是否使用了实际故事点数。

8. 你们的团队多长时间碰面？——如果ScrumMaster的工作做好了，答案应该是每天！对于分布在不同时区的分布式团队，这可能颇具挑战。

9. 你们的敏捷实施有上层支持吗？——我曾在没有上层支持的情况下实践过草根式的敏捷，得到的经验就是：在不知道全局的情况下，我绝对不会贸然开工。如果老板宣称甚至CxO们[译注1：指CEO/CTO/CFO...等以C开头的职务]也接受过CSM/CPO培训，这对我来说是一个很大的有利因素。

10. ScrumMaster还有什么其他职责？——根据组织不同，这会有所差别，但这个问题还是有必要问的，特别是如果那些职责丝毫不能引起你的兴趣。最好是现在就弄清楚它们。

Johanna Rothman、Steve Smith、George Dinwiddie，以及Aye Conference的其他主办者给面谈双方提供了一个清单，就面谈和评估提供了一些很有益的提示：

面谈提示：

• 尽可能使用开放性问题
• 尽可能使用描述行为的问题来得到真实的例子
• 使用元问题提问“然后呢”，从针对技术人员的战术问题转向询问单独的、与管理相关的战略性问题

面谈陷阱：

• 不要问领导的问题，比如“你的经理是个蠢材吗？”你永远不可能得到一个诚实的回答，而且问题本身也暴露出你的忠心度、诚实度和可信度。一个问题就会让你减分不少。
• 避免询问对方的主观观点，比如“你喜欢你现在做的事情吗？”相反，把问题改成“这里什么对你是有效的？”以及“哪些东西妨碍了你完成自己的工作？”

除此之外，试图弄清底细的ScrumMaster还会遇上什么陷阱，又该如何避免呢？在这里留下你的经验分享吧。