如果你所在的开发团队正在采纳敏捷方法，或者正在考虑向敏捷的方向转变。你可以考虑选择 Scrum 或者其他任何敏捷方法，也可以将它们混合使用。如果你打算从局部开始实践敏捷方法，就可能会与所在的组织格格不入。你或许听说过敏捷方法中有这样一个角色，他的职责是保护团队不受到非敏捷世界的干扰。或者，你所听到的恰恰相反——他是团队不健全的标志，会导致产生我们与他们（Us vs. Them）之间的壁垒，形成局部优化。那么，哪一种观点才是正确的？你应该如何执行ScrumMaster 或者与之等价的角色的职能？
早在2003 年，Scott Ambler 就撰写了一篇文章 Running Interference ，从一开始他就提到：
在理想的世界里，你希望做正确的事情：开发可以工作的软件，它能够以最适当的方式满足利益相关者的需求。你能够与利益相关者紧密合作，创建你认为适用的工件，而不是被迫创建不能增加价值的工件，并且总能在项目开发生命周期里最合适的时间去完成相应的功能。你需要在合适的时间能够找到合适的人员，并有权拒绝别人的“帮助”。换句话说，你能够完全掌控自己的命运。 现在，你可以停止大笑了。
接着，Scott 给出了恳切的建议，以指导如何处理不太好的情形：
如果其他人顽固不化，无法将他们的开发方式转变为更为敏捷的一种，甚至在你竭尽所能地对他们进行培训，与他们沟通之后，他们依旧如此，你该如何应对？答案很简单——将他们排除在外。在美式足球队里，前锋线上总会有那么几个大块头，他们唯一的职责就是确保对方成员不能攻垒到四分卫位置（这会阻止球队向前移动）。在软件开发中，屏蔽者（Blocker）扮演的就是与之相似的角色，虽然不是从身体上，但却从方法和态度上阻止其他团队成员干扰自己的开发人员的进度。 一个屏蔽者需要完成官僚们要求的文档，参加他们的会议，并建立一个假象，让它看起来你的项目团队实际上就是在与其它小组一同工作。这样就能防止因为官僚们对开发人员的干扰而造成的进度延迟，使得开发人员能够“两耳不闻窗外事”地安心工作。官僚们总是打着他们“帮助”了团队的旗号，并以此来证明他们的存在意义。
最近，InfoQ 就这类屏蔽的危险性采访了 Scott：
InfoQ：屏蔽究竟是好，还是坏？ Scott：是的 ;) 正如我写到的那样，它应该并且只能是最后的选择。你应该设法就你正在使用的技术对其他人进行培训，这与了解他们正要完成的内容一样重要。多次的团队会议和讨论可以解决很多问题。如果这些都不奏效，那么你就可能需要采取屏蔽，这很令人遗憾，但却是使你走向成功的唯一策略。
InfoQ：ScrumMaster 应该成为屏蔽者吗？
Scott：团队中的每个人都可以担负屏蔽者的职责。这个角色可以由每个人轮流担任，但通常都是由高级人员 / 负责人担任。
InfoQ：这难道不是创造一个我们与他们壁垒分明的心态吗？你是否同意这种心态通常会阻碍项目的成功通过？
Scott：是的，这样做确实带来很大的风险，可能不是一件好事情。我们需要齐心协力去理解每个小组试图达到的目标。我发现有许多敏捷开发者已经沉沦到为“邪恶官僚”粉饰太平的地步，这通常是因为他们并没有真正理解项目的远大前景。敏捷运动在为开发者提供指导原则方面贡献颇多，但是从另一方面来讲，它加剧了对开发新手的偏见，无视他们的价值。
InfoQ：那么，要用什么方式来代替呢？一个团队应该如何发展，才能够采用敏捷增加其价值，同时还能处理好与采取不同方式做事的其他人之间的关系？
Scott：答案就是明确各个小组的目标。如果你能够现身说法，通过敏捷方式可以达到这些目标，那么通常你就能够继续前行。也许你就会发现他们询问你的内容实际上是有意义的。
这不是第一次就屏蔽者的问题展开讨论。这是一个争论不休的问题，相关内容可以查看我们之前在InfoQ 上讨论的内容 。
因此，如果你在一个非敏捷环境中采用敏捷，你可能需要一个屏蔽者——但必须谨慎。需要注意到“我们”与“他们”之间产生的壁垒，会滋生一种坏气味。要聆听非敏捷者的声音——他们同样在努力地干好工作，并为整个组织作出了贡献。
查看英文原文： Is the ScrumMaster-as-Blocker a Pattern to Follow or a Smell to Avoid?
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论