SCRUM是软件开发的灵丹妙药吗？
SCRUM目前是各大公司普遍采用的软件开发方法，但是软件开发效率和质量依靠的是SCRUM吗？非也！工程模型和开发方法只是工具，如何驾驭这个工具还是依赖人的技能，素养和团队。瀑布模型是理想主义者的模型，它对各个角色提出了较高的要求，所以瀑布模型适用于软件开发各个角色水平都很高，能够很好得完成这个角色赋予的任务的团队，但是这样的团队存在吗？也许只有在神话中才能找到。SCRUM则是基于开发各个角色无法做到完美的前提下，如果通过Lean和迭代来减少浪费，逐步完善软件开发的方式实现软件的最终目标，这可能是SCRUM在实践中得到大家广泛认可的根本原因。但是SCRUM就是灵丹妙药吗？是不是请来讲师在公司培训一周，公司的开发能力和开发质量就能显著提升，公司研发管理就高枕无忧了呢？
首先我们来剖析一下开发实践中常用的对SCRUM的误解和滥用。
“因为我们是Lean的，所以我们不需要设计和文档”。这大概是Developer常用的用来推脱不愿意做的事情的口头禅吧。其实Lean不是不要设计和文档，而是设计和文档本身也是迭代的，通过每一个阶段的设计和文档逐步完善整个的设计和必要的文档。当然Lean的思想不要求像瀑布模型那样繁琐的文档。
“因为我们是Agile的，所以我要自己挑backlog，而且工作量我说多少就是多少”。作者曾经目睹SCRM团队的Sprint planing会议上，几个开发人员用SCRUM扑克进行工时投标，然后工时低的竞标获得该工作项，会议中SCRUM Master记录每一个人的工时估计，平计算平均值。这个SCRUM扑克的初衷是为了让工时估计更准确，但是工时估计准确的前提是开发人员要把这项工作如何进行开发进行深入的分析。所以大家把时间花在出牌报价上，不如一起分析一下到底需要做哪些工作，难点在什么地方，然后一起给一个相对合理的估计。
“Lean就是民主，开发经理不能随便说三道四，指手画脚，否则我就会在retro会议的时候抱怨”。SCRUM受到开发人员的欢迎的一个很大的因素是给人感觉开发人员翻身做主了，他们不需要听从开发经理的指挥，自己决定做什么怎么做。可是软件开发是一个脑力劳动，对于一个功能的理解，实现的复杂度，甚至软件架构设计，都存在很多主观因素在里面。同一个功能点，你可以说不做，不一定用得上，也有人可以说肯定用得上，必须做。同一段代码，可以有人说是过度设计，是浪费和增加软件复杂度，也可以说是为了未来的可扩展性。这个时候就必须有平衡，有取舍，最终就要有人拍板。被否决的一方可能就会认为自己受到了权力的威慑，所以就会在retro会议中进行抱怨，在团队传递负面的情绪。
“Lean就是减少浪费，所以一切文档和测试都可能因为后期设计改动导致浪费，所以先不做吧”。充分的测试时为了发现更多的问题，文档是为了团队内部的交流，这些工作做到恰到好处，并不会浪费时间，反而会节省大家的交流时间。
从瀑布模型开发转为SCRUM的团队最常见的错误就是通过SCRUM的建议流程重复之前的工作模式和工作状态。团队没有领会到SCRUM的灵魂。把瀑布模式的开发计划转换为backlog，daily scrum变成工作汇报和监督的方式，开发测试的流程一切照旧，只是按照SCRUM的工具进行了工作任务的管理和跟踪，仅此而已。
如果以上这些现象出现在了你的开发团队中，这样的SCRUM是无法发挥SCRUM的优势，最大程度发挥每一个人的潜力，实现SCRUM Team的最大效率的。SCRUM能够有效帮助团队提高开发效率最根本基础就是团队每一个人必须是以积极主动的工作态度，通过合作的方式来实现1+1>2 的工作目标，从而达到高效开发的目的。SCRUM开发方法中所有的不必要的工作判定必须是客观的，如果是以偷懒的思维进行判定，其实什么都不做就成了最极致的lean了，而且这个开发团队就会陷入混乱，无序，低效的状态。