What’s the Scrum Master Role in a REAL world

Scrum Master

“掐指一算”,使用Scrum作为开发团队的敏捷方法已经有3年多了。我也从没名份到有名份当了3年的Scrum Master。这几年里,我一直在探索最适合我们团队的敏捷开发的方式。在使用Scrum框架的大前提下,寻找适合当前项目和团队的最佳实践。在这个过程中,我们一直努力遵循Scrum的流程和规范。但就我自身而言,其实一直有个问题在实践过程中不断的收到挑战。那就是:Scrum Master,到底应该做什么?

有人可能会觉得很可笑。因为这是一个有着“标准答案”的问题。任何一本讲述Scrum方法的书都会列有Scrum里面那些角色的定义和工作职责。我真的很佩服想出那些定义的人。他们能让一段文字那么的充实但又几乎没有任何实际的指导作用。

我目前是2个开发团队的Scrum Master。我同时也是其中一个团队的Engineering Lead。我能明显和清晰的感觉到,同为Scrum Master,我在这2个团队中所起到的作用是不一样的。我所提供的帮助,也会被以不同的程度吸收。哪个团队的Scrum运行的更好,整体开发效率更高呢?就是我是他们Engineering Lead的那个团队。

在Scrum里有个很神奇的概念——团队是自治的。什么是自治,就是自我管理、自我约束、自我发展、自我提升。很可惜,这是一个乌托邦式的玩意儿。上哪里去找这么个团队?我相信99%的IT公司都没有这样的团队。在传统的企业架构里,一个开发团队总会由一个Engineering Manager/Lead来负责。团队成员向他汇报。但在项目上,团队又是对Project Manager负责。Engineering Manager一般负责人员的调配、资源的保障和团队的发展。但不可忽视的是,Engineering Manager对团队在项目开发中的影响力。而这种影响力,正是Scrum Master在帮助团队更好的完成项目的过程中所需要的。如果一个Scrum Master没有这种影响力,或者有限的影响力被其他力量所抵消,那他在Scrum Master这个角色上一定做的不会成功。

我向来觉得,在传统的企业架构中,Engineering Manager才是最合适当Scrum Master的人。对外,他能起到保护团队的作用,同时由于他在企业中的地位,往往也更容易争取到团队所需要的资源。对内,他有足够的影响力,能够在紧急的情况下做出大家都愿意服从的决定。我曾经写过一篇《在传统组织结构的公司里,谁适合当ScrumMaster》,里面也提到了上述内容。

那么在这种情况下,这个Scrum Master应该做些什么呢?我今天读到的这篇文章很好的解答了这个问题:

  1. 团队管理
    1. 提高团队生产力
    2. 移除开发过程中的障碍
    3. 团队成员的绩效考核
    4. 解决成员、项目间的冲突
  2. 流程管理
    1. 推动各个Scrum会议
    2. 对流程了然于心,能够随时提供指导
    3. 团队与外部的接口
    4. 提高团队对任务(PBI)的计划和预测的能力
    5. 在现有的流程上,持续的优化和改进
  3. 项目管理
    1. 支持Product Owner
    2. 组织结构的转型
    3. 传播消息

可见,一个合格的Scrum Master,除了需要熟知Scrum的流程规范,应该同时具备Engineering Manager和Project Manager的能力。也只有这样的“三者兼备”,才能最大程度的发挥Scrum Master的作用。让其不仅仅是个组织会议的人,更是一个能够确保项目按时按质交付的人。

这个活,不好干啊!

程序员,你当的了吗?

程序员

在我读大学的年代,计算机专业火的不行。那时候从那个专业(包括其他相关专业,比如物理和电子)毕业出来的学生,很大的比例都当上了“程序员”。而很多公司会给它一个更加响亮的名字——软件工程师。多么有份儿的职位名称啊。尤其是里面的“工程师”更是给这个份工作平添了个又大又亮的光环。

当然,这都是别人眼里看到的。我们自己(由此可见,我也是其中一员),却管它叫“码农”。为啥?工程师多好听啊,为啥不叫。没办法,不是不想,是不够资格。软件工程师,你以为那么好当的啊!

我的老板前几天送了我一本书,《高效能程序员的修炼》。它的副标题说明了一切:软件开发远不只是写代码那么简单……

高效能程序员的修炼

想当程序员吗?想做软件开发吗?嗯,单单会写几行代码是远远不够的。(话说我们也真的很苦逼。会写代码已经很不容易了,这还不够。还要学那么多“乱七八糟”的其他东西才能配得上这个职位。)

翻开书,天哪,要学的还真不少呢。从心理学到团队管理,从人员招聘到用户体验,从团队协作到市场营销,从系统安全到代码测试,我们甚至还要去关心坐什么样的椅子,用多大的显示器。我只是想当个程序员啊。容易么!

不过话说回来,人总是要发展的。你愿意写一辈子Hello World吗?只有丰富了自己的经验,开拓了自己的视野,不但从代码的角度,更要从用户的角度去最求产品的完美,才能让自己得到升华,让自己的代码变成艺术。网络上有句话:我们不是程序猿,我们是有追求的艺术工匠。

单单知道if…else…是不够的。单打独斗,闭门造车似的软件开发在当下这个时代已经不再可行。程序员需要知道如何与人沟通,包括其他程序员,包括自己的上下级,甚至包括客户。倾听别人的声音,获取别人的反馈,赢得别人的支持和信任。这样的程序员才能开发出这个时代所需要并且喜欢的产品。

这本书一共有12个章节。它们从不从角度阐述了一个“高效能”的程序员所应该具有的素质。在我看来,那就是:沟通、分析、写代码。

(大家可以看到,我把“写代码”排到了最后)

沟通

大多数程序员其实都挺宅的。尤其是中国的程序员。他不善于表达,让他写一行注释来说明这个函数的功能比让他写100行代码来实现这个函数都难。想让程序员做个PPT来介绍他做的那些功能,天哪,我在做梦吧!

正如前面所说,当今我们已经不可能单靠一个人来完成一个项目了。我们依赖的是一个团队。团队就是由人组成的。人就是需要沟通和交流的。而那些人,正是“程序员”。如果我们无法准确快速的让别人知道自己在想什么,知道自己要什么的话,事情往往就会因此受阻。效率会因此降低,成本则会上升。

拥有良好的沟通能力,就是程序员迈向“高效能”的第一步。

分析

这里说的分析,包括对需求的分析、对市场的分析、对优先级的分析以及对自己的分析。

想要开发出一款软件,并且希望它能被大众接受(甚至喜欢),需要精确的知道它应该具有什么样的功能,使用怎样的交互,面对的客户群是谁,以及何时发布最为妥当。这些都需要有着出色的分析能力来给出答案。不可否认,在当前这个“术业有专攻”的时代,这些事情会被不同的人(产品经理,市场人员,项目经理等)去完成,而程序员只被要求做具体的功能实现。但这并不代表程序员只能守着自己那一亩三分地。程序员需要用他独特的敏锐的嗅觉去帮助其他人来完成他们的工作,确保产品万无一失的成功发布。

程序员很忙的。一天要写好多好多代码,还要做各种各样的分析。还时不时的有些有关无关的会议要参加,有些有关无关的人要伺候。先做哪个,后做哪个,哪个是要自己做的,哪个不适合自己做的,都需要想清楚,安排好。一股脑的来者不拒,笑脸相迎只会给自己带来很多麻烦。

拥有出色的分析能力,是程序员迈向“高效能”的第二步。

写代码

程序员不会写代码,那还叫程序员吗?不过这里的“写代码”可不是一个“Hello World”那么简单。你需要知道怎么写出优雅漂亮的代码以及使用灵活安全的架构。去看看作者推荐的《代码大全(第二版)》吧。它能告诉你一切和“写代码”有关的事情。

有了前两步做垫底,如果你再会写代码的话,那恭喜,你就是个“高效能”的程序员了。

书中最后问到:程序员,你幸福吗?其实程序员是很苦逼的。遇到问题可能会折腾到三更半夜,辛辛苦苦写的功能用户却不买账,好不容易产品发布了却被一些小人抢了功劳。但程序员也是很容易感受到幸福的。因为软件开发过程中,幸福感来的太容易了。单元测试跑通了,幸福。干掉了一堆BUG,幸福。写了个NB的不行的算法,那幸福死了。如果能得到同事的认可,那简直要幸福到天上去了。

把自己修炼成一个“高效能”的程序员吧,让幸福感再放大一倍。