如何看待ScrumMaster的屏蔽（Blocking）职责
我在阅读Ken Schwaber所著的《Agile Project Management with Scrum》一书，就对ScrumMaster的其中一个职责抱有怀疑的态度。Scrum要求ScrumMaster保证开发人员在一个Sprint（冲刺）过程中，不受到其他无关人员尤其是上司们的干扰。真的能做到这一点吗？即使ScrumMaster通过有效地与Product Owner沟通，确定了Product Backlog；然后我们开启了一个Sprint，并确认了Sprint Backlog；然而，根据客户的需求，一旦需求发生变更，我们还能保证Sprint不受到这一变更的影响吗？
或者，前提是我们有一个高级的、经验丰富的权威Product Owner，我们或许可以尽量避免需求发生的变更，但在软件开发过程中，变更总是不可避免的。特别是在国内客户普遍不了解软件开发的前提下，我们往往需要引导客户提出需求，而不是客户为我们提出明确无误的需求。难道敏捷不是能够灵活应对变化的吗？但问题在于，在组织中总存在不了解敏捷思想的上司们，在Scott Ambler看来，这些上司都是一帮“官僚（bureaucracy）”，他们只在乎客户提出的Deadline，而不会去理会软件开发的基本真理。何况，客户总是对的，难道不是这样吗？
或许有一些方式可以让ScrumMaster作为一个合格的“牧羊犬”。例如，他必须不厌其烦地为团队外的其他人阐述敏捷的思想，以及敏捷方法的原则与过程，此时他是培训师或者布道者。他还需要不停地应付“官僚”们要求召开的繁琐会议，并淹没在文档的海洋中，因为过程管理中必须提交的文档而疲于奔命，此时，他是高明的协调者，玩小球的杂耍高手。ScrumMaster为自己的团队成员建立了高度屏蔽的环境，使得他们能够“两耳不闻窗外事”的安心工作。
然而一个普遍争议是，如此的屏蔽职责会导致在公司内产生壁垒分明的两个阵营。一个阵营是疯狂的敏捷粉丝，另一个阵营则是抱着传统不放的卫道士。这会否在公司和团队中滋生矛盾情绪，甚至会导致公司建立的企业文化轰然倒塌？那么，作为公司的领导者而言，如果不能处理好两者之间的矛盾，就不得不壮士扼腕，以牺牲小部分人的代价换来整体的发展，就像《集结号》中的团长所做的那样。
我曾经在公司的一个项目中似是而非的应用了Scrum的某些方法。例如站立会议，例如类似于Sprint的迭代周期。当我将开发团队分为几个小组的时候，我们同时在为选择何种开发方式而犯难。小组的Leader总是要坚持自己熟知的方式，例如FDD或者RUP。作为项目经理的我，选择了貌似妥协的折中办法。我让每个小组的Leader自己选择自己的方式，唯一要求两点：
1、按照时间表完成规定任务；
2、每日必须参加Team Leader的站立会议。
我保护了他们自己的一种选择，这或许是一种变相的屏蔽。我不知道这种方法是否妥当，但最后我却成功了。因而我在想，如果一个公司并没有完全建立敏捷环境，除了不遗余力地推行与培训敏捷，让他们选择各自的方法或许是个不错的选择。但前提条件是必须将他们分为不同的组，最关键的是不要表现出对某一个小组的偏爱，而是以事实的结果来说服团队成员。此外，一个要点是保证各个小组，特别是小组负责人之间的交流。交流是消除误解的最好方法。
在敏捷开发中，采用屏蔽方式确实是无奈之举，它存在风险，也会滋生两个阵营的矛盾，但如果处理妥当，通过团队会议与定期的交流，可以在很大程度上消除屏蔽给组织带来的负面影响。此时，我们需要担任Blocker（屏蔽者，其实我更愿意用阻挡者，就像橄榄球运动中的大个子前锋所做的那样）的ScrumMaster必须有非常强的控制力。
如果让我投票，我会持保留意见的为Scrum中的“屏蔽”方式投赞成票。
参考：
1、Ken Schwaber《Agile Project Management with Scrum》
2、Amr Elssamadisy《Is the ScrumMaster-as-Blocker a Pattern to Follow or a Smell to Avoid?》[中文版：“ScrumMaster充当屏蔽者”是值得遵循的模式，还是应该避免的坏味道？]
3、Geoffrey Wiseman《Blocking: Useful? Dangerous? Ethical?》
或者，前提是我们有一个高级的、经验丰富的权威Product Owner，我们或许可以尽量避免需求发生的变更，但在软件开发过程中，变更总是不可避免的。特别是在国内客户普遍不了解软件开发的前提下，我们往往需要引导客户提出需求，而不是客户为我们提出明确无误的需求。难道敏捷不是能够灵活应对变化的吗？但问题在于，在组织中总存在不了解敏捷思想的上司们，在Scott Ambler看来，这些上司都是一帮“官僚（bureaucracy）”，他们只在乎客户提出的Deadline，而不会去理会软件开发的基本真理。何况，客户总是对的，难道不是这样吗？
或许有一些方式可以让ScrumMaster作为一个合格的“牧羊犬”。例如，他必须不厌其烦地为团队外的其他人阐述敏捷的思想，以及敏捷方法的原则与过程，此时他是培训师或者布道者。他还需要不停地应付“官僚”们要求召开的繁琐会议，并淹没在文档的海洋中，因为过程管理中必须提交的文档而疲于奔命，此时，他是高明的协调者，玩小球的杂耍高手。ScrumMaster为自己的团队成员建立了高度屏蔽的环境，使得他们能够“两耳不闻窗外事”的安心工作。
然而一个普遍争议是，如此的屏蔽职责会导致在公司内产生壁垒分明的两个阵营。一个阵营是疯狂的敏捷粉丝，另一个阵营则是抱着传统不放的卫道士。这会否在公司和团队中滋生矛盾情绪，甚至会导致公司建立的企业文化轰然倒塌？那么，作为公司的领导者而言，如果不能处理好两者之间的矛盾，就不得不壮士扼腕，以牺牲小部分人的代价换来整体的发展，就像《集结号》中的团长所做的那样。
我曾经在公司的一个项目中似是而非的应用了Scrum的某些方法。例如站立会议，例如类似于Sprint的迭代周期。当我将开发团队分为几个小组的时候，我们同时在为选择何种开发方式而犯难。小组的Leader总是要坚持自己熟知的方式，例如FDD或者RUP。作为项目经理的我，选择了貌似妥协的折中办法。我让每个小组的Leader自己选择自己的方式，唯一要求两点：
1、按照时间表完成规定任务；
2、每日必须参加Team Leader的站立会议。
我保护了他们自己的一种选择，这或许是一种变相的屏蔽。我不知道这种方法是否妥当，但最后我却成功了。因而我在想，如果一个公司并没有完全建立敏捷环境，除了不遗余力地推行与培训敏捷，让他们选择各自的方法或许是个不错的选择。但前提条件是必须将他们分为不同的组，最关键的是不要表现出对某一个小组的偏爱，而是以事实的结果来说服团队成员。此外，一个要点是保证各个小组，特别是小组负责人之间的交流。交流是消除误解的最好方法。
在敏捷开发中，采用屏蔽方式确实是无奈之举，它存在风险，也会滋生两个阵营的矛盾，但如果处理妥当，通过团队会议与定期的交流，可以在很大程度上消除屏蔽给组织带来的负面影响。此时，我们需要担任Blocker（屏蔽者，其实我更愿意用阻挡者，就像橄榄球运动中的大个子前锋所做的那样）的ScrumMaster必须有非常强的控制力。
如果让我投票，我会持保留意见的为Scrum中的“屏蔽”方式投赞成票。
参考：
1、Ken Schwaber《Agile Project Management with Scrum》
2、Amr Elssamadisy《Is the ScrumMaster-as-Blocker a Pattern to Follow or a Smell to Avoid?》[中文版：“ScrumMaster充当屏蔽者”是值得遵循的模式，还是应该避免的坏味道？]
3、Geoffrey Wiseman《Blocking: Useful? Dangerous? Ethical?》
