昨天有个做Scrum培训的朋友约我吃早餐，聊起他们最近在思考的一个课题：Scrum Master的职业路径是什么。据说有不少的Scrum Master在向他们咨询这个问题，以至于他们打算开一个线下沙龙来专题讨论了。
我继续发扬着一贯直(jian)接(suan)了(ke)当(bo)的作风，我跟他说：没啥路径。
这是怎么说呢？我觉得要回答这个职业路径的问题，还得回归到软件开发的本质上来。比如一个健康的Scrum团队每天早上会自觉自发地站在一起开晨会，了解互相的进度、依赖和障碍。开完晨会，大家知道了整个团队的状态，该去开发就开发，该互相帮助就结对互相帮助。这是一个自组织团队正常的样子。
“9点半站在一起开晨会”这件很简单的事，也有很多团队做不好。我们经常看见，开个晨会，谁也不想听别人讲什么，每天讲的内容也没啥新意。“昨天我在做这个story，今天我接着做这个story，估计今天也做不完，明天继续做这个story，没什么问题。”人人如此，天天如此，晨会开得还有什么意义？慢慢的就连参加晨会的兴趣也淡了。
这时候领导看见了，说这个团队怎么开个晨会都不成样子，得找个Scrum Master来解决一下。这就是很多组织里Scrum Master创造价值的方式。
然而“晨会开得不成样子”这个问题，解决的办法是曲折的。你不可能通过要求一个团队“自组织起来”而得到一个自组织团队。具体到开个晨会这件事，你也不可能通过要求一个团队“好好开晨会”而让他们开好晨会。你只能想办法去排除那些让他们无法自组织、开不好晨会的障碍。那这个障碍是什么呢？最典型的障碍就是：用户故事拆得太大，一个故事要做一周两周，所以基本上每天晨会说的都是“昨天在做这个故事，今天还在做这个故事”。
然后Scrum Master说了，咱们把故事拆得小一点吧，人家申导上课的时候说了，一个故事最好1~2天能完成开发测试，大一点也不要超过3天，咱们这个故事拆分，还可以改进一下嘛。
然后，他就听见所有人都在反对他：
1、PO说，这故事已经是最小了，没法再拆小了，再拆下去故事都没意义了。
2、开发说，你再拆小也没用啊，我反正都是把整个功能放在一起设计，先做数据库层，再做业务层，最后做接口层，这样一层代码写好就不用再改呀。
3、测试说，你们本来提测就够频繁了，还要拆小，想累死我们吗？能不能把整个功能做完善了再提测呀？
我在《敏捷中国史》里面说了，我们这个行业的关键问题，不是瀑布或敏捷的问题，而是四项基本能力是否具备的问题：需求管理、项目管理、配置管理、质量保障。一个最最简单的晨会，你可能以为它仅仅是一项最基本的项目管理活动，当你真的想解决其中的问题，你就会发现，它其实涉及了需求管理（需求以什么方式拆解和传递）、配置管理（代码以什么方式修改和提交）、质量保障（软件以什么方式测试）的问题。
晨会开不好，不是一个管理问题，而是一个能力问题。团队缺乏软件开发基本能力，晨会只是一个征兆。
尴尬就尴尬在，提出“职业路径”这个问题的Scrum Master，很可能他们也同样缺乏软件开发基本能力。
不服气么？咱们还是学先贤，三省吾身嘛：
1、把需求拆分成又小、又能独立开发独立测试、又有独立价值的用户故事，用开发一看就明白的形式表述出来，我会吗？
2、以端到端“纵切蛋糕”的方式实现功能，在已有的代码上不断添加完善而又不破坏原有功能，我会吗？
3、用自动化测试取代绝大部分手工回归测试，我会吗？
那要是啥也不会，你又有啥立场叫人家好好开晨会呢？
软件开发的四项基本能力当中，项目管理的能力、尤其是项目进度管理的能力，会越来越多地被信息透明化和团队自组织所取代。软件开发专业人士的职业路径，不可避免地要从另外三项基本能力中去找：需求管理、配置管理、质量保障。学两天Scrum Master课程，考一本证书，只能帮你认识到这些能力的重要性，并不能让你神奇地获得这些能力。
那，想帮团队把晨会开好，想有个更光明的职业路径，咋办呢？
嗯……比如说，我只是提个建议哈……
