我做直播scrum master的心得

前言

  1. 因为最近需要把直播的事情放在一边,专心折腾查询优化的事。所以写一下心得供后续的master参考,可以看出哪些地方是我做得不足的或者是需要修改的。
  2. 具体的scrum流程可以看一下网上的资料,后续可能公司也会有相应的培训流程。在这里就不再介绍了。
  3. 以下只是介绍我在担当scrum master时的一些感受,目前有不少问题的或者执行得不到位,所以建议只是参考一下。另外具体如何实施也与公司情况和当前的团队状态有关,有一些具体做事的方法可能和scrum规定的流程是相反的。

一、我的原则

1. 让大家在现有的资源情况下尽可能干得爽。

1.1 现有的资源我看到如下:

  1. 公司能提供出来的team人力资源,例如有几个全职,有多少实习生,这些人力是否还需要兼顾别的事情。我们团队之前有过不少实习同事,不过后来转化为全职同事的只有一个。

  2. 组外公共团队的参与程度,目前我们的外部团队会有UI和测试(UI和设计资源在我司是由PM去争取的,而测试资源是开发自己去联系的);

  3. 全公司范围内的技术资源(例如博客,技术专家),例如视频中心的开发同事,对于视频编解码还是非常有经验的,可以请教。

  4. 公司的基础设施(例如推送系统、存储平台)

  5. manager或者leader的指导。这点放在资源最后,其实是最重要的资源。一个有经验的manager的指导会对团队产生很大的积极影响,避免走弯路,或者推动别的资源的分配例如增加测试人员。所以对于有manager来参加会议的情况,需要尽可能的把信息传达到位,以便manager利用自己之前项目的经验和当前了解的信息,对后续的项目发展情况作出判断。

1.2 怎么算干得爽:

1.2.1 认可与尊重:尊重每一个技术开发的工作。

首先是不浪费开发时间。在需求方面,需要仔细评估功能点,因为这些功能点定下来后,可能就是好几个小时或者几天的人力,干点优先级更高的事企不是更好。这个需求接还是不接,是临时做做还是后续都会长期优化或者使用。还好我们团队的pm在这方面做得挺好,目前在我看来没有太多的浪费或者调整的功能。这一点在很多团队会成为问题最严重的一点,包括之前我在云图书的项目中,开发与pm虽然整体目标一致,但功能开发点存在很大的分歧。如何处理好这些问题至关重要。这种情况是每个master一定会遇到的。需要做出权衡。

在个人任务方面,让开发者自己有更多的主动权。例如任务选择以及估时。如果是很不靠谱的随便忽悠的估时,完全不相关的任务,那maseter需要参与进来及时调整。但更多的时候,我们需要相信team内的同事是积极的推动项目朝着目标方面前进的。所以pm提出来的任务,master一般不直接参与估时。之前我们的做法是整个团队决定开发时间,但由于团队太小,并且具体的开发模块别人可能不了解(例如让服务端给window客户端估时),所以在后来,就采取了个人自己估时的做法。因为我感觉这种方式,可以让开发人员更自由一些。后续可以团队再自行讨论采取怎么样的开发方式。

1.2.2 薪酬福利
scrum master不是manager,更不是老板。没法在薪酬福利进行配置。而团队参与人员,是不可能绕开这个问题的。很可能在关键时候,核心开发人员出现离职情况导致项目被delay或者直接死掉。目前我在这块做得很不足也没有办法做好,也只能在平时也就是多安排一些TB。这个问题作为master我是尽量避免涉及的,我也不想参与解决。而出现相关的问题,我只能用1.2.4的观点来看待。

1.2.3 技术进步
如果在这个团队工作了一年,但没有技术成长,浪费一年的时间其实损失是非常大的。每一个开发人员自己都会盘算,在这一段时间学到了啥,进步了多少。如果得不到满意的答案,那肯定会对团队失望。所以作为master还是需要考虑每个人的发展的。 这一点master可以做一些引导的事。例如联系会议或者专家资源,促进技术分享,调研更加适合的技术并运用在项目中。

1.2.4 开放的环境
我在当scrum master时,心里会一直记着这么一点:每个人都是非常聪明的,不要把他人当作是傻子,也不能把他人当作是圣人。每个人都会有优点和良好的品德,每个人也都会有自己的隋性和私心。很多时候,大家遇到不爽的事都会选择沉默。我提议了每周的回顾会议,让大家能吐槽团队内部的问题和不足。例如我们的指标不明确,不能衡量一个人的工作到底为团队或者公司做出了多大的贡献。这个确实是我们之前没有做好的,所以目前也在推动指标明确的事。

另外开放的环境还有一层意思,就是团队的成员组织是开放的。团队成员能通过公司的安排聚在一起算是缘份。如果确实干得不爽并且也没有别的办法可以改变,那么我认为选择离开团队也是非常正常的选择。与其浪费时间不能全心投入,反而不如选择更感兴趣的事进步更快。这一点可能确实不应该是scrum master需要考虑的事,但是由于master需要对项目进度负责,所以需要保证在出现人员变动的情况下,项目还能持续的运转。

2. 线上问题能担当。

遇到线上故障,很可能判断是什么问题就需要投入时间。那这个技术调研的时间一定也是scrum master需要关注的。而问题如何尽快解决、如何向用户以及pm和运营同事作交代、如何避免后续再次出现问题,都需要scrum master来跟进。这也是为什么通常来说,master一般是由资历比较老,对项目非常熟悉的人来担当的原因。

scrum master在平时就需要投入更多的时间去处理跟开发技能无关的事,并且这些事有可能会被纯技术开发认为是无用的,我也非常尊重这样的选择。但有失也有得,很可能经过一段时间的工作,沟通能力、对业务的理解能力、危机处理能力这些软实力会大大增加。所以是否承担这个责任,还是看自己的取舍了。


3. sprint的输入与输出

输入:
1. 人力
2. backlog(项目整体的所有的需求,会有优先级,我们的backlog放在sprint目录下
新的任务需求一般来说是加入到backlog中来的。目前我们的backlog处于做不动的状态,里面的功能要么没法有固定的产出导致开发人员不敢做,要么大家都认为不重要。所以目前我处于不管需求的状态。例如windows的客户端开发,我由于不懂,所以更尊重开发同事自己的选择。但更多的时候他们都接了pm的活,这个是我的失职。建议后续的master在这方面能进行修改。

输出:
1. 更好用的产品。
1. 比没有做这个sprint之前技术有所进步的开发同事。

中间涉及的一些流程:

  1. sprint总结和启动会。需要有邮件出来给manager和class team.
  2. 每日立会。(有时会忘记,有时会成员不齐)
  3. jira上的任务跟进
  4. 每周四下午的scrum master事务报告
  5. 第周五的技术分享和吐槽会

我在做master的过程中,学到了很多非技术相关的工作内容,终身受益。 愿你成为一个优秀的scrum master!

comments powered by Disqus