Scrum为项目执行提供了可靠的、已被证实的基础。但是，在每个项目中，Scrum都必须根据具体需求和环境进行调整，这是项目成败的决定性因素。在这篇文章中，将会介绍如何成功地完成了一个大型的（20人年，超过十万行代码）、分布式（开发人员位于印度和荷兰）Scrum项目，而这个项目曾经在传统开发方式下被废弃过。为了帮助读者顺利运作大规模项目，在这里我也会历数我们的经验教训，包括：项目启动、找到合适的产品负责人、估算的重要性、有效沟通、测试、文档。
测试
我们在项目中做了自动化测试，保证在每个Sprint结尾的时候都可以交付经过测试的软件，不带有回归的bug。即使随着系统扩展，我们还是做到了在8人的Scrum团队中只安排一个测试人员，而且保证了高质量：外部测试团队最多也就是能在每千行代码中发现一个缺陷。
我们的自动化测试包括两部分：单元测试和验收测试。在前者中，我们用的是JUnit，用Clover度量测试覆盖率，我们的目标是服务器端代码的测试覆盖率达到80%。验收测试用FitNesse作自动化。每个完成的用户故事，都会在FitNesse上有一套验收测试。有了庞大的测试套件，就能在Sprint中找到并修复回归的bug。这种做法还有另外一个好处，就是测试人员从一开始就可以积极参与，在用户故事实现之前编写测试用例。
有一个地方让我们苦恼了很久。这个系统有一部分是一个用户界面很复杂的富客户端。对这东西做自动化测试要比对服务端做测试难得多。所以在UI方面的功能我们大部分还是依靠手工操作。随着系统的增长，回顾测试所花的时间就越来越长，更糟的是，外部团队只在这部分系统中会发现回归bug。如果有了自动化测试就能防止这一点。我们由此学到了一点，即便是自动化测试很困难，为它付出些努力，迟早会获得回报，尤其是在项目晚期。
- 产出成果
客户对我们的工作很满意。说点马后炮的话，跟大多数项目一样，功能、时间、预算都会随着项目进度发生变化，所以“按时按预算”完成只是个很模糊的完成标准而已。更为重要的是，我们在项目进程中常常跟客户讨论怎样把项目做好，他们都很满意。不幸的是，因为其他系统中的问题，产品在全国范围内部署的时候出了麻烦。
客户找了外部的审核公司来审核这个软件。他们的结论是：
1.系统的可维护性非常好。
2.源码质量非常高。
在审核公司的报告中，他们说他们从来没有给过一个项目这么多正面评价。
