敏捷实践（二）－荷兰铁路公司的分布式Scrum开发（项目如何启动）
Scrum为项目执行提供了可靠的、已被证实的基础。但是，在每个项目中，Scrum都必须根据具体需求和环境进行调整，这是项目成败的决定性因素。在这篇文章中，我们将会介绍我们如何成功地完成了一个大型的（20人年，超过十万行代码）、分布式（开发人员位于印度和荷兰）Scrum项目，而这个项目曾经在传统开发方式下被废弃过。为了帮助读者顺利运作大规模项目，在这里我也会历数我们的经验教训，包括：项目启动、到合适的产品负责人、估算的重要性、有效沟通、测试、文档。本篇介绍“项目如何启动”
项目开始的时候，我们在第一个sprint开始前安排了一个启动阶段，耗时三周，准备好了sprint中所需的一切。这个启动阶段由一个项目经理，一个架构师和一个Scrum Master
参与完成。
选择产品负责人是个很有难度的事情，我们不到一个人能够有时间、具备领域知识、而且有权利设置需求优先级。我们提名了两个业务分析师来一起承担产品负责人的职责。他们能抽出时间来，而且他们从前也参与过构建PUB的工作，所以业务知识很丰富，足以担当起产品负责人的角，为多组客户充当优秀的代理。有关优先级的和范围的高级决策，是由客户委任的项目经理负责，但是他时间不够用，对于需求的理解也有所欠缺。一般情况下大家的配合还可以，但偶尔项目经理也会对（他所缺席的）计划
下辈子我还记得你
会议上制定的优先级进行调整，于是这个会议就得重新来过。在理想状态中，对优先级有最终决策权的人应当每次都参加 sprint计划会议。
因为先前有人试着构建过PUB系统，所以有些部分的详细需求文档已经是现成的了。它们遵守了MIL标准，不过其形式不适于敏捷计划和估算，因为在敏捷开发中，需求应当被组织成小块的段落，每一块都可以在一个sprint中进行实现、测试和演示，但是现有的文档与此要求不符。产品负责人也没有多少编写用户故事的经验，为了解决这个问题，Scrum Master帮他们弄出了最原始的产品backlog，里面放着一些细粒度的、经过估算的用户故事，供前几个迭代使用。
泰坦尼克号音乐孙菲菲被打事件我们所构建的软件只是某个大型软件系统的一部分，它还包括很多相关的软件系统，那些系统负责显示信息，还要在车站内安装相关显示设备。我们得保证每件事情都可以按时完成，才能把复杂的系统理顺。所以需要有一个整体的计划方案。经历了几次迭代，我们对系统的各个功能都按照自己的最大能力做出估算，这个问题也解决掉了，而且也有了一个比较靠谱的生产率。于是就可以用发布版本燃尽图来记录和沟通进度了。这里我们学到的东西就是，即使是信息量很少的情况下，有估算也比没估算好。
飓风战魂主题曲文章摘自：www.infoq/cn/articles/dutch-railway-scrum
郭晓冬主演的电视剧评论：这是一个典型的大项目开发，Scrum迭代的第一个迭代（迭代0）需要完成以下主要工作：核心
七子之歌歌词
团队建立、需求整体分析、架构整体分析、估算、第一版需求列表和发布计划。在我们的实践中同样有很深的体会，跳过了这一步，后面迭代的效率和风险都有很大问题。大项目的开发，DAD（有纪律的敏捷交付）流程更加适合，这里有介绍：
kan.weibo/con/3530865808556986