听说山寨也有品质之分,有 A 货, A+ ,还有种叫‘一比一’:就是样式、剪裁、面料等等外观完全与真品一摸一样。传说有人拿用过的一比一 LV 包包到 LV 店里去换真货, LV 店员带上眼镜仔细看来看去:“这位女士,不好意思,您的 LV 是我们还没到货的新款 … ”。而就笔者看来,开发经理就像是山寨 Scrum Master 中的‘一比一’。
找出其中差别还真是不容易,笔者仔细鉴别了下,发现 Scrum Master 与传统的开发经理的确有如下相同之处:
1) 制定项目交付计划
2) 分派组员任务
3) 组织各种会议,如每日例会等
4) 任务审核
5) 解决组员纠纷,处理影响项目进度的异常状况
6) 项目进度分析、报告
除了这么多相同的功能,还有 Master 这个好听的名字,就笔者观察下来开发经理愿意承担 Scrum Master 的职责还有些深层原因:有更多项目控制权的 Scrum Master 可能顶替他的位置,或是把他架空。同时,很多公司最后放弃了 Scrum ,或者只是部分接纳了 Scrum ,背后的原因往往就是归结于此。
此外,也有下面主要不同:
1) Scrum Master 应该是具备充足的 Scrum 与敏捷知识和经验的,不是一两次培训就可以成为 Scrum Master 的。
2) Scrum Master 应该对需求和项目细节有相当的理解。 Scrum Master 需要在项目进行中对任务状态、进度做出即时的评估,并且时常与 Product Owner 交流任务优先级,参与 Story 的修订,必要时候对任务进行重新评估。传统的开发经理并不一定有能力或精力做出如此细致的决定。
3) Scrum Master 并不参与组员人事上的管理,但传统的开发经理需要。组员薪资、考核等权利的丧失也会导致 Scrum Master 变成名义上的 Master ,在实际开展工作的时候组员不能给与足够的配合。组员会说,反正我不完成任务你也没权利开除我或是给出不佳的考核。尤其是在开发经理不给与 Scrum Master 足够支持的时候,这种状况尤为明显。
虽说这是一比一的山寨,可毕竟用久了就能发现和真的间的差距。 Scrum Manager 也存在如下缺陷:
1) 开发经理因为欠缺足够的 Agile/Scrum 的知识,往往会把一个 Scrum 团队变得形式化、表面化、教条化。比如,我们经常看到开发经理主持的 Scrum 每日 stand-up meeting 会像下面这样:组员们都跟站岗似的,然后每个人轮流发言。大家也都按照模式来汇报状况,“昨天我做了。。。今天我要做。。。没有 impediment ”。大家发言结束,开发经理总结陈词,问有没有问题?组员同口齐声“没有问题!”。听起来老像是:同志们好;为人民服务。开发经理露出了久违的灿烂笑容,依稀可见那被中华牌儿香烟熏陶的牙齿:“很好。老总昨天来观摩我们的 Scrum 例会,看到大家站的整齐,发言一致,又看到大家都进展顺利,没有任何问题,他很高兴!我们要再接再厉。”于是例会整齐划一的在规定时间内结束。看来都做得很好,除了项目最后又延迟了。
2) 开发经理没有足够的开发、需求等项目知识。笔者还是见过很多开发经理有很过硬的技术功底和敏锐的技术洞察力,再加上超过 130 的智商,他们有着快速的学习能力,对技术和功能的细节可以准确无误的介入,及时的跟踪并给出正确指引。相信大家也都见过达不到上述水准的开发经理,比起承认存在的不足,他们会更愿意说:我虽然没有 J2EE 相关经验,但我做过多年 Unit C/C++ 复杂应用程序;我虽然没做过电子商务项目,但我以前有过多年银行系统经验 … 笔者首先承认无论是 C/C++ 或是其他项目经验是会对新技术或是新需求的理解有很大帮助,但能够较快的掌握新知识并不意味着就能够成为合格的 Scrum Master 。笔者就见过在项目初期无法把握一些功能点,或者是无法做出合理的技术选择,在 Spring1 、 2 还过得去,但到了后期就造成了灾难性的后果的。
总的来说,开发经理担任 Scrum Master 一职是比较推荐的做法。相比前几篇文章所描述的几种类型,开发经理有着更强的沟通能力、组织能力以及人事管理权,也会让项目成功的机会大大提升。不过因为技术和需求的欠缺,如果在团队中设立一名专业架构师和需求分析人员则会大大弥补上述不足。
可能你会问了,这几篇看下来,光是说三道四,说别人的倒是容易,到底有没有真正合格的 Scrum Master ? 欢迎关注下篇“其实你也能做专业 Scrum Master ”。