敏捷开发经典案例背景荷兰铁路可以跻身于世界上使用量最大的铁路系统之列，每天要运送120万乘客。

该部门打造了一套全新的信息系统，为乘客提供更准确的列车信息，减少人为干预。

作为该系统的一部分，我们做了这个PUB发布系统，对所有车站中的信息显示和音频广播做集中控制。

有人之前试过完成这个PUB系统，但是他们当时用的是传统的瀑布方法。

客户把详细的需求文档规范交给了开发商，然后放任自流，等着完整的系统成形交付。

三年之后，这个项目被取消掉了，因为开发商没能开发出一个可以工作的系统来。

然后客户雇佣了我们公司从头做起，我们引入了敏捷开发方式，用上了 Scrum，跟客户紧密协作，开放交流，小步前进。

起步项目开始的时候，我们在第一个sprint开始前安排了一个启动阶段，耗时三周，准备好了sprint中所需的一切。

这个启动阶段由一个项目经理，一个架构师和一个Scrum master参与完成。

选择产品负责人是个很有难度的事情，我们找不到一个人能够有时间、具备领域知识、而且有权利设置需求优先级。

我们提名了两个业务分析师来一起承担产品负责人的职责。

他们能抽出时间来，而且他们从前也参与过构建PUB的工作，所以业务知识很丰富，足以担当起产品负责人的角色，为多组客户充当优秀的代理。

有关优先级的和范围的高级决策，是由客户委任的项目经理负责，但是他时间不够用，对于需求的理解也有所欠缺。

一般情况下大家的配合还可以，但偶尔项目经理也会对（他所缺席的）计划会议上制定的优先级进行调整，于是这个会议就得重新来过。

在理想状态中，对优先级有最终决策权的人应当每次都参加 sprint计划会议。

因为先前有人试着构建过PUB系统，所以有些部分的详细需求文档已经是现成的了。

它们遵守了MIL标准[1]，不过其形式不适于敏捷计划和估算 [2]，因为在敏捷开发中，需求应当被组织成小块的段落，每一块都可以在一个sprint中进行实现、测试和演示，但是现有的文档与此要求不符。

产品负责人也没有多少编写用户故事的经验，为了解决这个问题，Scrum master帮他们弄出了最原始的产品backlog，里面放着一些细粒度的、经过估算的用户故事，供前几个迭代使用。

我们所构建的软件只是某个大型软件系统的一部分，它还包括很多相关的软件系统，那些系统负责显示信息，还要在车站内安装相关显示设备。

我们得保证每件事情都可以按时完成，才能把复杂的系统理顺。

所以需要有一个整体的计划方案。

经历了几次迭代，我们对系统的各个功能都按照自己的最大能力做出估算，这个问题也解决掉了，而且也有了一个比较靠谱的生产率。

于是就可以用发布版本燃尽图来记录和沟通进度了。

这里我们学到的东西就是，即使是信息量很少的情况下，有估算也比没估算好。

扩展到分布式团队项目启动以后，一开始只有7个人，两星期一迭代。

项目从一开始就计划着要用到印度的一些人力，所以从第一个sprint开始就有两个印度开发人员进入了团队。

他们来到客户现场参与开发，用了六周时间熟悉领域知识、用户代表和团队其他成员。

建立团队伊始，就要决定如何协作。

我们跟所有团队成员一起——也包括印度同事——组织了一个“规范和章程”活动。

我们定下来一些实践方式，如怎样做结对、用哪些工具、质量目标、每天的核心工作时间等等。

然后在Wiki上记录下来。

整个团队有了共识，事情就好办多了。

一旦这些共识需要修改，比如在回顾会议上提出改进，这些实践就要在wiki上更新，这样有新人加入的时候，他们看到的总是最新内容。

在前几个迭代里面，团队成功地构建、测试、验证了组成系统核心的用户故事。

这让客户很满意，尤其是跟过去相比，我们的进度更快，而且客户对项目的方向也有掌控权。

几个迭代以后，我们就扩展了项目：印度的开发人员返回本国，然后我们在印度和荷兰都增加了资源，这样变成了两个Scrum团队，每个团队5个开发人员，共享同一个测试人员。

过后又变成了三个团队，一共三个测试人员。

每个团队都既有印度员工，又有荷兰员工。

这种方式让项目保持了很高的生产率和工作质量。

那我们是怎样异地协同工作的呢？首先，我们频繁使用Skype。

我们都有网络摄像头、耳机、麦克风，还有个大屏幕。

所以我们既能一对一开会，也能全体参会。

这些都用的是现成的东西和免费软件。

没多花多少钱，只是用UPS保证断电的时候也能继续开Skype会议，这样提高了印度那边的网络联系能力。

其次，只有在同一个地方的人才做结对。

也就是说印度的人跟印度的人结对，荷兰的人跟荷兰的人结对。

经验告诉我们，不管现在有了哪些工具，结对编程所需的交互协作还是需要两个人坐在一起的。

最后，我们用ScrumWorks记录谁在做什么事情，记录Sprint的进度。

因为我们是分布式团队，所以这个比白板要好得多。

在跟产品负责人讨论产品backlog的时候，ScrumWorks也起了很大作用。

在实施这种分布式模型的时候，我们也战胜了很多困难。

例如，产品负责人不习惯说英语。

按照Scrum的说法，计划会议分成两部分，在第一部分中，产品负责人给团队讲述用户故事，并且设置优先级。

因为这种语言障碍的存在，这一部分的会就只让荷兰团队参加了。

第二部分通常是大家讨论具体任务，做估算。

这部分是跟印度团队一起用Skype来完成的，说的是英语，产品负责人不参加。

我们还多花一些时间来沟通第一部分会议的内容。

Sprint演示也只在荷兰进行。

完成以后，荷兰团队再写封内部简报，告知印度团队——也包括公司其他人——演示的结果。

事实证明，这个内部简报深受欢迎。

拆出一个只关注架构的团队我们的项目只是整个应用链条中的一部分，必须要跟客户现有的IT基础架构无缝挂接。

虽然我们的产品负责人对核心功能需求非常熟悉，但是在安全、日志、可用性、性能等方面就所知甚少了。

要从客户的组织中了解这些需求难度很大，因为这得跟不同部门中的许多人沟通讨论。

这种调查工作给Scrum的迭代节奏拖了后腿。

为了解决这个问题，我们创建了一个独立团队，他们只关注架构方面的内容。

他们的工作就是弄清楚非功能性需求，好让我们把它们转换成backlog中的用户故事。

我们用“Scrum of Scrum”会议来跟特征团队沟通。

我们都喜欢这种方式，因为特征团队可以全速前进。

而且有些员工也喜欢在“架构团队”中工作。

文档客户要求大量的文档，而且还要符合MIL文档规范。

还要用荷兰语写。

很明显，这项工作只能由荷兰人来干。

而且开发跟测试都不熟悉MIL规范，写用户手册这样的文档也不是他们所擅长的。

所以我们决定雇一个曾经写过MIL文档的技术文案。

开发跟测试可以继续关注于各自职责。

这个做法也很成功，不过我们发现这也要求技术文案和其他团队成员之间也要有大量的沟通交流，这是需要引起注意的，因为开发人员只想“做他们该做的事情”。

需求管理我们的产品负责人是一些业务分析师，他们习惯于用荷兰语写出大量的需求文档。

而在我们的过程中，只要backlog中有用户故事，产品负责人也能在计划会议上做解释，这就足够了。

但是客户又要求有很多文档。

所以我们打算和产品负责人一起把需求翻译成用户故事。

结果就是需求被放在了两个地方：需求文档和 backlog。

当需求发生变化的时候就会导致问题。

我们做了大量的辅导工作，确保产品负责人不仅仅是关注需求文档，也要负责backlog。

有了一行文字表达的用户故事，再加上产品负责人的解释，我们的Scrum团队就可以构建和测试软件了。

不过需求文档对外部的测试团队做测试还是很有价值的，虽然在好些迭代里面，我们很难把实现的用户故事跟需求文档中的某些部分“映射”起来。

回顾从前，我们其实一直都没有一个理想的需求管理过程。

我们只是尽了最大努力，来应对这相互冲突的需求：我们需要用户故事，客户需要详细的需求文档。

测试我们在项目中做了自动化测试，保证在每个Sprint结尾的时候都可以交付经过测试的软件，不带有回归的bug。

即使随着系统扩展，我们还是做到了在8人的Scrum团队中只安排一个测试人员，而且保证了高质量：外部测试团队最多也就是能在每千行代码中发现一个缺陷。

我们的自动化测试包括两部分：单元测试和验收测试。

在前者中，我们用的是JUnit，用Clover度量测试覆盖率，我们的目标是服务器端代码的测试覆盖率达到80%。

验收测试用FitNesse作自动化。

每个完成的用户故事，都会在FitNesse上有一套验收测试。

有了庞大的测试套件，就能在 Sprint中找到并修复回归的bug。

这种做法还有另外一个好处，就是测试人员从一开始就可以积极参与，在用户故事实现之前编写测试用例。

有一个地方让我们苦恼了很久。

这个系统有一部分是一个用户界面很复杂的富客户端。

对这东西做自动化测试要比对服务端做测试难得多。

所以在UI方面的功能我们大部分还是依靠手工操作。

随着系统的增长，回顾测试所花的时间就越来越长，更糟的是，外部团队只在这部分系统中会发现回归bug。

如果有了自动化测试就能防止这一点。

我们由此学到了一点，即便是自动化测试很困难，为它付出些努力，迟早会获得回报，尤其是在项目晚期。

产出成果客户对我们的工作很满意。

说点马后炮的话，跟大多数项目一样，功能、时间、预算都会随着项目进度发生变化，所以“按时按预算”完成只是个很模糊的完成标准而已。

更为重要的是，我们在项目进程中常常跟客户讨论怎样把项目做好，他们都很满意。

不幸的是，因为其他系统中的问题，产品在全国范围内部署的时候出了麻烦。

客户找了外部的审核公司来审核这个软件。

他们的结论是：1.系统的可维护性非常好。

2.源码质量非常高。

在审核公司的报告中，他们说他们从来没有给过一个项目这么多正面评价。

总结下面是我们从这个项目中学到的最重要的几点：1.很难找到一个既有丰富的需求知识、又有权利设置优先级的产品负责人。

所以人们往往都要用几个人一起扮演产品负责人的角色，尤其是在大型项目里面。

2.如果一定要按期完成工作，那就得保证产品backlog的完整，也要做好估算。

对需求而言，即便信息量很小，有估算也比没估算的好。

把估算跟团队生产率合并以后，发布计划就有了必要的信息。

3.Scrum对多个分布式团队很适用。

我们每个Scrum团队都既有荷兰人又有印度人，这很好地发挥了团队精神，让我们注重有效沟通。

在沟通中，利用现成的硬件和免费软件能节省成本。

4.在启动分布式项目的时候，先把大家都聚到同一个地方，让大家对团队实践达成一致，这点效果很好。

5.对于不适合放到Scrum Sprint中的工作（比如寻找关键人员，跟其他客户部门交流），可以让一个单独的团队去做，这样效率更高。

特性团队可以集中精力开发软件。

有一个专职的技术文案也很好，即便这会增加沟通成本。

6.虽然软件开发过程不需要大量的需求文档，但客户可能需要。

不过在Scrum项目中，需求文档代替不了用户故事。