敏捷思维和Scrum，哪个是第一位?

　　大多数决定走向敏捷开发的公司最终都使用Scrum作为敏捷开发的方法。他们认为在他们大部分的团队里面使用Scrum就能够给他们带来作为一个敏捷开发公司的所有好处，但是这样往往会导致一个令人失望的结局。最主要的问题是这些公司应该考虑一些其他的方式。在开始Scrum之前，必须确定的是他们愿意采取敏捷的思维方式。你可以采用Scrum，但是首先你必须是敏捷的。

　　Scrum是否应该解决我们的问题?

　　在我之前柏林的工作中，我们的团队有一个稳定的流程但是很少有自主权，我们依赖不同的团队，因此我们的能力被限制。所以我们认为Scrum可以使我们变得敏捷，相应的问题也会消失。

　　于是我们逐渐开始Scrum并开始每天开一次Scrum会议。紧接着，我们决定将我们的迭代周期设置为两周，也就是说每两周我们就应该有一个新发布。于是问题来了，对于其他团队的依赖性导致我们的Scrum变得一团糟。除了我们在冲刺结束的2-3天前准备好我们的软件外，QA团队并没有足够的时间来审核我们的发布，TechOps团队也没有足够的时间来部署。以至于我们仍然是每45天甚至更久才发布一个版本。Scrum给我们带来的唯一一个改变就是增加了一系列的会议，很快这些会议也就失去了他们该有的意义。

　　这使得我们的发布缩短至每20-30天一次，仍然远长于我们最初制定的两周一次迭代。公司发展的很快也有了很多新的项目，但是没有新的TechOps工程师，所以他们没有足够的时间去处理每个人的每件事情。

　　波兰的救援!

　　就是在这期间，我们项目的领导从阿姆斯特丹调到了波兰，新的管理者已经有几年的Scrum经验，他们知道为了改进我们的效率，我们需要避免对其他团队的依赖。

　　我们新的团队成员已经从开发到部署负责他们的产品一年多的时间了，在此之前，他们跟我们遇到过同样的问题。他们有一个很棒的解决方案：将项目迁移到AWS上。于是他们准备了一个很详细的预算，描述了迁移到AWS所需的费用并展示给了管理者。当他们看到这将会将我们的运维成本减少到一半的时候就欣然同意了这个方案。于是，在波兰团队的帮助下，我们能够在脱离对TechOps团队依赖的情况下同等程度的完成我们的工作。最终，在决定开始Scrum之后的四个月时，终于实现了每两周一个发布的目标。

　　结语

　　如果你想变得敏捷，只采用类似Scrum这样的开发框架是不够的，你必须改变思维方式，并且管理者也必须改变追求“万无一失”的观念。公司必须承担让团队变得跨领域且更自主所带来风险。如果在管理者和员工之间没有这样的信任，那么想实现敏捷开发就会变得更复杂。

　　我们很幸运有一个思维开放的管理团队，让我们负责整个开发过程也愿为此承担风险。如果你也同样幸运，不要再等了，赶快全面负责你的项目吧，你不会为这个决定后悔的。

　　敏捷思维和Scrum哪个是第一位?当然是敏捷思维啦。