一个真实的敏捷开发案例

一个真实的敏捷开发案例

ID:38989734

大小:21.31 KB

页数:4页

时间:2019-06-23

一个真实的敏捷开发案例_第1页
一个真实的敏捷开发案例_第2页
一个真实的敏捷开发案例_第3页
一个真实的敏捷开发案例_第4页
资源描述:

《一个真实的敏捷开发案例》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、一个真实的敏捷开发案例摘要:Scrum为项目执行提供了可靠的、已被证实的基础。但是,在每个项目中,Scrum都必须根据具体需求和环境进行调整,这是项目成败的决定性因素。在这篇文章中,将会介绍如何成功地完成Scrum为项目执行提供了可靠的、已被证实的基础。但是,在每个项目中,Scrum都必须根据具体需求和环境进行调整,这是项目成败的决定性因素。在这篇文章中,将会介绍如何成功地完成了一个大型的(20人年,超过十万行代码)、分布式(开发人员位于印度和荷兰)Scrum项目,而这个项目曾经在传统开发方式下被废弃过。为了帮助读者顺利运作大规模项目,在这里我也会历数我们的经验教训,包括:项目启动、找到

2、合适的产品负责人、估算的重要性、有效沟通、测试、文档。背景荷兰铁路可以跻身于世界上使用量最大的铁路系统之列,每天要运送120万乘客。该部门打造了一套全新的信息系统,为乘客提供更准确的列车信息,减少人为干预。作为该系统的一部分,我们做了这个PUB发布系统,对所有车站中的信息显示和音频广播做集中控制。有人之前试过完成这个PUB系统,但是他们当时用的是传统的瀑布方法。客户把详细的需求文档规范交给了开发商,然后放任自流,等着完整的系统成形交付。三年之后,这个项目被取消掉了,因为开发商没能开发出一个可以工作的系统来。然后客户雇佣了我们公司从头做起,我们引入了敏捷开发方式,用上了Scrum,跟客户紧

3、密协作,开放交流,小步前进。起步项目开始的时候,我们在第一个sprint开始前安排了一个启动阶段,耗时三周,准备好了sprint中所需的一切。这个启动阶段由一个项目经理,一个架构师和一个Scrum___master参与完成。选择产品负责人是个很有难度的事情,我们找不到一个人能够有时间、具备领域知识、而且有权利设置需求优先级。我们提名了两个业务分析师来一起承担产品负责人的职责。他们能抽出时间来,而且他们从前也参与过构建PUB的工作,所以业务知识很丰富,足以担当起产品负责人的角色,为多组客户充当优秀的代理。有关优先级的和范围的高级决策,是由客户委任的项目经理负责,但是他时间不够用,对于需求的

4、理解也有所欠缺。一般情况下大家的配合还可以,但偶尔项目经理也会对(他所缺席的)计划会议上制定的优先级进行调整,于是这个会议就得重新来过。在理想状态中,对优先级有最终决策权的人应当每次都参加sprint计划会议。因为先前有人试着构建过PUB系统,所以有些部分的详细需求文档已经是现成的了。它们遵守了MIL标准[1],不过其形式不适于敏捷计划和估算[2],因为在敏捷开发中,需求应当被组织成小块的段落,每一块都可以在一个sprint中进行实现、测试和演示,但是现有的文档与此要求不符。产品负责人也没有多少编写用户故事的经验,为了解决这个问题,Scrum___master帮他们弄出了最原始的产品ba

5、cklog,里面放着一些细粒度的、经过估算的用户故事,供前几个迭代使用。我们所构建的软件只是某个大型软件系统的一部分,它还包括很多相关的软件系统,那些系统负责显示信息,还要在车站内安装相关显示设备。我们得保证每件事情都可以按时完成,才能把复杂的系统理顺。所以需要有一个整体的计划方案。经历了几次迭代,我们对系统的各个功能都按照自己的最大能力做出估算,这个问题也解决掉了,而且也有了一个比较靠谱的生产率。于是就可以用发布版本燃尽图来记录和沟通进度了。这里我们学到的东西就是,即使是信息量很少的情况下,有估算也比没估算好。扩展到分布式团队项目启动以后,一开始只有7个人,两星期一迭代。项目从一开始就

6、计划着要用到印度的一些人力,所以从第一个sprint开始就有两个印度开发人员进入了团队。他们来到客户现场参与开发,用了六周时间熟悉领域知识、用户代表和团队其他成员。建立团队伊始,就要决定如何协作。我们跟所有团队成员一起——也包括印度同事——组织了一个“规范和章程”活动。我们定下来一些实践方式,如怎样做结对、用哪些工具、质量目标、每天的核心工作时间等等。然后在Wiki上记录下来。整个团队有了共识,事情就好办多了。一旦这些共识需要修改,比如在回顾会议上提出改进,这些实践就要在wiki上更新,这样有新人加入的时候,他们看到的总是最新内容。在前几个迭代里面,团队成功地构建、测试、验证了组成系统核

7、心的用户故事。这让客户很满意,尤其是跟过去相比,我们的进度更快,而且客户对项目的方向也有掌控权。几个迭代以后,我们就扩展了项目:印度的开发人员返回本国,然后我们在印度和荷兰都增加了资源,这样变成了两个Scrum团队,每个团队5个开发人员,共享同一个测试人员。过后又变成了三个团队,一共三个测试人员。每个团队都既有印度员工,又有荷兰员工。这种方式让项目保持了很高的生产率和工作质量。那我们是怎样异地协同工作的呢?首先,我们频繁使用Skyp

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。