互联网研发的「黑暗料理」-「黑暗敏捷」之一

Scrum作为目前互联网公司实施敏捷（Agile）最流行的一种方式，也在不断地被越来越多的实施者们以他们的方式进行“改进、优化”。很多时候，流程方面的裁剪确实是必要的，或许是软件的形式不同、公司的氛围不同，可一些最基本的游戏规则都被更改至面目全非，那还能称之为Scrum吗？

这个系列会分享一些“伪”敏捷的实践，希望能够帮助大家在实施敏捷的过程中避免注入此类的情况。

重申角色的定位

敏捷宣言的创始人之一Ron Jeffries把“伪”敏捷的实践戏称为“Dark Agile”，“黑暗”敏捷，也就是软件开发界的黑暗料理啊。让我们来看看这些实践是如何把敏捷带入深渊的。

Scrum中有三个角色组成了Scrum Team，

• Product Owner
• Scrum Master
• Development Team

实际上真正输出用户价值、商业价值的Development Team，是他们（通常为开发、测试、实施人员）将需求真正转化为产品输出。那么其他两个角色的价值在哪里？

Product Owner

首先是Product Owner（PO），这个角色的名称其实会让人产生一些误解，中文通常翻译为“产品负责人”，其实最终负责产品交付、质量的，还是Development Team。那这个负责人负责什么呢？

Scrum Alliance的Scrum Guide里写道：

The Product Owner is the sole person responsible for managing the Product Backlog.

Product Owner其实是Product Backlog Owner，他负责管理“产品待办列表”。通常来讲，PO作为所有需求方的代表，管理产品要提供的功能，换言之，任何人想要更改需求，都要先通知PO，由PO决定是否更改产品待办列表。

PO还要负责能够清晰地向Development Team解释需求，并且让产品待办列表开放可见。同时负责排列事项的优先级以保证产品价值的交付。

所以如果你身边的PO，或者你自己就是一个PO，检查以下几点，看看是不是已经“黑化”了：

• 给Development Team设置deadline
  Scrum按照Sprint的方式进行迭代式的交付，deadline本身就不应该出现。更何况PO并不应该直接对Development Team进行指挥或者管理。Development Team应该是自组织、自管理的。
• 插任务到Sprint Backlog
  前面说过，PO负责管理Product Backlog，Sprint Backlog不在PO的管理范围之内。决定Sprint要交付的内容的，并不是PO，而是Development Team。PO只负责根据优先级排列Product Backlog。
  而在Sprint过程中插入Task，这种做法非常不可取，不仅会打乱team的节奏，也会让team之前的承诺变得毫无意义。
• Product Backlog混乱
  如果PO无法提供一个清晰可理解的Product Backlog，那也会是开发人员的噩梦。许多PO无法在下一个Sprint开始之前确定任务的优先级，这将直接导致Sprint无法正常开展，更别说交付有价值的内容了。

合格的PO，是一个充分了解产品的“产品代言人”，开发团队能够从PO这里直接或间接得到所有关于产品的问题明确的答案。这样才能让开发团队在“需求无障碍”的环境中火力全开。

Scrum Master

Scrum Master首先得是个Master，也就是中文里的“大师”或者“师傅”，需要精通Scrum，能够帮助Team良好的运行于Scrum的各个过程中。

再来看一下Scrum Guide:

The Scrum Master is a servant-leader for the Scrum Team.

这里有两点需要注意，第一，Scrum Master是一个servant-leader，并不是一个领导者，而更偏向于服务者。第二，Scrum Master服务的对象是Scrum Team，也就是说包括了PO和Development Team。

看看以下几个“黑化”了的Scrum Master:

• 命令下属汇报工作
  Scrum Master并不是任何人的上级，Development Team作为Scrum Master的服务对象，更多的是从Scrum Master那儿获取流程上的建议和帮助，从而提高效率和工作的价值。
• 强行推行政策
  Development Team作为自组织的团队，Scrum Master不应该强行推行自己的政策，这不仅会打击团队的自信心，久而久之也会让团队丧失主动性。
• 按照自己的意愿做出承诺
  还是那句话，做出交付承诺的，应该是Development Team，Scrum Master不应该插手或强迫。

Scrum Master应该提供Scrum流程方面的建议，组织各种会议以及帮助团队形成适合团队的工作模式，保证团队成员对产品的认识都在同一水平上，同时在团队之间消除沟通的隔阂，实现“交流无障碍”。

合格的Scrum Master，是可以“消失”的Scrum Master，当Team完全熟悉Scrum之后，应该可以省略这个角色。

Only members of the Development Team create the Increment

只有Development Team的成员真正创造了产品的增量。

之前也说过，产品的输出来自于Development Team，所以真正的产品负责人，应该就是Development Team本身，每一个成员都应该对自己的输出的质量和数量负责。只要是没有意识到这一点的开发人员，都已经“黑化”了。

Development Team对每个Sprint做出交付增量的承诺，都应该基于自己能力和意愿，而不是基于压力或是诱导。而PO和Scrum Master的存在，可以让团队更加专注于自己的工作，减少流程、需求上的噪音。

Scrum Team的三种角色是完全扁平化的，至少在组织架构方面，Scrum没有上下级的概念。如果你的组织在上面加上了上下级的概念，那就要谨防其带来的额外障碍了。

“黑暗敏捷”让本来很轻的Scrum变得很重，或许是妥协，或许是曲解，都应该尽量避免。