Scrum 为项目执行提供了可靠的、已被证实的基础。但是,在每个项目中,Scrum
都必须根据具体需求和环境进行调整,这是项目成败的决定性因素。在这篇文章中,将会
介绍如何成功地完成了一个大型的(20 人年,超过十万行代码)、分布式(开发人员位于
印度和荷兰)Scrum 项目,而这个 项目曾经在传统开发方式下被废弃过 。为了帮助读者
顺利运作大规模项目,在这里我也会历数我们的经验教训,包括:项目启动、找到合适的
产品负责人、估算的重要性、有效沟通、测试、文档。
背景
荷兰铁路可以跻身于世界上使用量最大的铁路系统之列,每天要运送 120 万乘客。该
部门打造了一套全新的信息系统,为乘客提供更准确的列车信息,减少人为干预。作为该
系统的一部分,我们做了这个 PUB 发布系统,对所有车站中的信息显示和音频广播做集中
控制。
有人之前试过完成这个 PUB 系统,但是他们当时用的是传统的瀑布方法。客户把详细
的需求文档规范交给了开发商,然后放任自流,等着完整的系统成形交 付。三年之后,这
个项目被取消掉了,因为开发商没能开发出一个可以工作的系统来。然后客户雇佣了我们
公司从头做起,我们引入了敏捷开发方式,用上了 Scrum,跟客户紧密协作,开放交流,
小步前进。
起步
项目开始的时候,我们在第一个 sprint 开始前安排了一个启动阶段,耗时三周,准备
好了 sprint 中所需的一切。这个启动阶段由一个项目经理,一个架构师和一个 Scrum___
master 参与完成。
选择产品负责人是个很有难度的事情,我们找不到一个人能够有时间、具备领域知识、
而且有权利设置需求优先级。我们提名了两个业务分析师来一起承担产 品负责人的职责。
他们能抽出时间来,而且他们从前也参与过构建 PUB 的工作,所以业务知识很丰富,足以
担当起产品负责人的角色,为多组客户充当优秀的代 理。有关优先级的和范围的高级决策,
是由客户委任的项目经理负责,但是他时间不够用,对于需求的理解也有所欠缺。一般情
况下大家的配合还可以,但偶尔项目 经理也会对(他所缺席的)计划会议上制定的优先级
进行调整,于是这个会议就得重新来过。在理想状态中,对优先级有最终决策权的人应当
每次都参加 sprint 计划会议。
因为先前有人试着构建过 PUB 系统,所以有些部分的详细需求文档已经是现成的了。
它们遵守了 MIL 标准[1],不过其形式不适于敏捷计划和估算 [2],因为在敏捷开发中,需
求应当被组织成小块的段落,每一块都可以在一个 sprint 中进行实现、测试和演示,但是
现有的文档与此要求不符。产品负责 人也没有多少编写用户故事的经验,为了解决这个问
题,Scrum___ master 帮他们弄出了最原始的产品 backlog,里面放着一些细粒度的、
经过估算的用户故事,供前几个迭代使用。
我们所构建的软件只是某个大型软件系统的一部分,它还包括很多相关的软件系统,
那些系统负责显示信息,还要在车站内安装相关显示设备。我们得保证每 件事情都可以按