前些日子看到bob大叔的一篇新文，是关于scrum的。翻译之余，笔者也正巧这些日子项目中用到SCRUM，工作中也接触了不少自诩是SCRUM MASTER的高端人士，其中也不乏有被成为Scrum Master的，接触下来颇有感触，借此文，表达下笔者的看法。
自《敏捷软件开发》一书出版以来，事隔多年，其间Bob大叔也出过不少如“Clean Code”之类的经典之作，但在敏捷上少有言论发表。故此，以为bob大叔早已经告别了前沿的敏捷战线，一心扑在自己经营的公司，还有栽培小bob上。不想“Scrum/Agile Failings”一文在各技术刊物上一发表，还是引起了广泛的关注，而且文章边辟入理，丝毫没有"out"。
bob大叔这次走的可是七宗罪路线，一开章，笔锋就直指scrum的几大致命要害。从笔者过去6年多敏捷还有最近2年多scrum的经验来看，虽然感觉个别观点有过分挑剔之嫌，不过大体来说，还是赞同的。
笔者还是先感谢国家，让笔者有机会在多家美国软件巨头公司都有就职的经历，就职期间也有机会看到了很多不同风格的项目管理方式。Scrum的提出确实带来了先进的思维。可惜的是，也正像是Bob大叔所指出的，从笔者所见的众多Scrum Master来看，他们很少有真正符合Scrum规范的。结合笔者过去经历来看，比起传说中的Scrum Master，他们更像是下面的一些山寨版本：
1） Scrum Administrator山寨 Scrum Master。笔者就切身遇到过。好端端一个技术过硬的好手儿，非要被提拔为Scrum Master。他自己其实也是相当拧巴的，估计也是冲着这个Master，才勉强接下。几天轰轰烈烈之后，慢慢儿的Scrum就成了走过场：开Scrum晨会；记录成员进度；记录疑难事项；填各种表格；邮件汇报；反正是能记得都记记，不记白不记…。话说是技术好手可不见得是个好admin，这位菜鸟admin经常就会因为填错表格而被challenge。每周还得参加如Scrum Of Scrum之类的繁琐会议，客户在美国，自然也是搞得晚上茶饭不宁的。日日加班儿，大家还都抱怨他的RP。没想忙到最后团队还是完成不了指标。笔者心想：还真是替他捏把汗，倒是没听说过技术+Admin组合的Scrum Master有好果子的，一般都是冲上去头一个成了炮灰。技术+Admin类型失败原因往往可以归结于下：
a) 过于纠结于技术，忘记了进度。本例中的Scrum Master，自身有很好的design功底，就是过分崇拜design，导致每次开会都指责团队成员的设计问题，而忘记了是否完成需求。最后，错误的把团队风气引导为重设计、轻需求。错误理解的需求导致了设计的偏向，并没有达到原有设计的目的。同时，错误的实现需求也使产出无法通过客户的Sprint验收。
b) Scrum Master忙于录入表格，错误地认为团队汇报的就是真实的数据，结果在Sprint验收前夕才发现数据与实际完成工作的差距。本例中的Scrum Master其实RP还不错，信任、尊重别人。不过定期检查实际进度、持续集成并不是对团队成员的不尊重，本例中的团队成员也都是诚实汇报的。那问题出在哪里呢？在笔者肤浅的看来，团队成员认为的“完成”与实际的“完成”很可能有出入，就像本例中团队成员认为他们完成了需求，但实际上他们错误理解了需求。就笔者过去的经验来看，最佳的应对之法还是XP提到的持续集成。
2） 就像是Bob大叔所谈的，Scrum Master变成了‘Project Manager’。<待续>