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

96
是小岸
2018.07.26 16:53 字数 1697

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变得很重,或许是妥协,或许是曲解,都应该尽量避免。

项目管理
Web note ad 1