第1章　为什么敏捷转型难（但值得）

许多软件开发公司都在极力地向敏捷转型。但他们的努力无可厚非。相对于传统的开发团队，成功的敏捷团队可以开发出更高质量的软件产品，可以更快以更低的成本满足用户的需求。再说，谁又不愿意变得敏捷呢？它听上去就是那么简单。这就好像在说一个人不应该太苗条，不应该太富有，抑或是不应该太敏捷。然而，抛开这些时髦的词汇和炒作，有些公司正从中看到非常显著的好处。这些公司正在通过实施像Scrum这样的敏捷过程郑重其事地转向敏捷。

他们亲眼目睹生产力的显著提升和成本的降低；他们可以更好地将产品推向市场并获得很高的客户满意度；他们正在体验更透明的开发过程，从而获得更高的预测能力。对他们来说，完全失控、永远无法完成的项目已经成为历史。

Salesforce.com就是受益于Scrum的公司之一。它于1999年在旧金山的一个公寓里成立。它是真正经历过稻糠（.com）时代的成功案例之一。2006年，拥有2000名员工和超过4.5亿美元营业额的Salesforce.com注意到，他们的产品发布周期由曾经一年四个版本缩减到了一年一个版本。客户得到的更少，但需要等待的时间却更长。必须有所行动了！于是，公司决定向Scrum转型。在第一年的转型过程中，他们发布的功能点比上一年多了94%，每个开发人员比往年多交付38%的功能点；和前一年相比（2008），他们向客户多交付了500%的商业价值。在接下来的两年中，他们的收入翻了两倍多，超过10个亿。结合这样的结果，如此多的企业已经向Scrum转型或正在尝试向Scrum转型也就不足为奇了。

我之所以说“尝试”，是因为向Scrum或者其他敏捷方法转型是困难的。比许多企业预期的困难得多。获得敏捷带来的所有回报而必须进行的变革是意义深远的，这些变革不仅要求开发人员也要求企业中其他的成员进行大量的付出。工程实践的改变只是一方面，观念的改变却是完全不同的另外一个方面。本书的目的不仅仅是介绍如何很好地向敏捷转型，也是介绍如何获得长久的成功。

我亲自见证过几个失败的敏捷实施案例，这些失败本应该是可以预防的。第一个例子，一个公司花了100多万美元在敏捷转型上面。他们请来外部的培训师和教练，同时雇佣5个员工组成“敏捷办公室”为新的Scrum团队提供建议和帮助。他们最终失败是因为他们认为实施Scrum仅限于开发团队。发起敏捷转型的管理层认为，只给开发人员提供培训和支持就足够了。他们没有考虑到Scrum对销售人员、销售部门甚至是财务部门的工作带来的影响。如果这些地方没有改变，组织惰性会把整个公司重新带回到原点。

因为完全不同的其他原因，Josef在他的公司使用Scrum并最后以失败告终。Josef是一个刚刚被提拔上来的新的项目经理。因为Scrum非常符合他天生的管理风格，Josef立刻对它产生了巨大的兴趣。他轻松说服团队（他们在不到一个月以前都是他的同级伙伴）在新的项目中尝试Scrum。这个项目取得了极大的成功，得到了团队的一致称赞，Josef也赢得了管理一个更大项目的机会。Josef向他的新团队介绍了Scrum，他们中大多数人都愿意尝试新的方式。尽管在项目中的这些人很乐意使用Scrum，但是他们的部门经理却开始变得紧张起来，因为Scrum有可能会影响他们的仕途。于是Josef的好运到头了。这些部门经理，特别是质量管理（QA）的总监和数据库开发部的总监，联合起来以Scrum不适合他们公司这么复杂而重要的项目这一理由，说服了分管工程方面的副总。

Caroline的遭遇要稍微好点儿。她是一个海量数据管理公司的副总裁，负责公司的开发管理。她的部门有200多个开发人员。当她在一个Scrum项目中看到好处之后，她兴奋地在整个事业部中发起了实施Scrum的倡议。他们给所有的员工都进行培训和指导。几个月之后，所有的团队都可以在每两周的Sprint结束时递交出可以工作的软件。这是一个巨大的进步。然而，一年后我再次拜访这个公司的时候，他们再也没有取得任何更多的进展。不可否认，团队与在他们实施Scrum之前相比可以更快地生产出更高质量的软件，但是她的公司只获得本该获得的回报的很小部分而已。Caroline的公司忽视了持续改进是向Scrum转型的重要组成部分。

很震惊，对吗？这些向Scrum转型的失败案例都有好的初衷，然而，好的初衷并不能阻止他们走向失败。但是，请别担心。尽管向Scrum转型也许很困难，但只要使用正确的方法，它是完全能够成功的。在第1章中，我们一起来看一看为什么向任何一个敏捷开发过程（包括Scrum）转型都特别困难。我们将详细列举出一些挑战，正是这些挑战阻碍了这些公司成功地向敏捷转型。更重要的是要明白一点：为什么转型为敏捷公司带来的好处多于相应的付出。