Scrum敏捷软件开发方法在实践中的改进和应用.docx

?

?

Scrum敏捷软件开发方法在实践中的改进和应用

?

?

论文导读:：简介。正如敏捷宣言所述：个体和交流胜于过程和工具。坚持应用持续集成和测试驱动方法。和测试驱动开发（Test-DrivenDevelopment。

关键词：Scrum，敏捷，持续集成，测试驱动

?

1引言

随着软件行业的发展，基于详尽的需求分析、系统设计和把需求变更作为梦魇的瀑布模式已经逐渐被开发者们所丢弃了，而能够更快地面向市场、更好地响应客户需求变更的敏捷开发模式深得开发者们的青睐。正如敏捷宣言所述：个体和交流胜于过程和工具；可以工作的软件胜于综合的文档；客户协作胜于合同谈判；应对变化胜于遵循计划[1]。敏捷开发模式更重视软件的生产率，且适用于解决需求模糊或快速变更的问题。现今已经有很多种敏捷方法被付诸到实践中了，广为人知的有极限编程（ExtremeProgramming，XP）、Scrum、动态系统开发（DynamicSystemDevelopmentMethod，DSDM）、自适应软件开发（AdaptiveSoftwareDevelopment，ASD）、水晶方法（CrystalClear）、特征驱动开发（Feature-DrivenDevelopment，FDD）和测试驱动开发（Test-DrivenDevelopment，TDD）[2]等。敏捷方法在实践中取得了巨大的成功。很多数据和实例告诉我们，敏捷是提高软件生产率不争的事实。然而过程本身不是敏捷的，但人可以敏捷计算机毕业论文，团队或者组织可以敏捷。如果只是做敏捷而不是敏捷地去做，就会导致敏捷方法应用的失败[3]。在敏捷开发方法实践中需要去体验、分析思考以及进行必要的方法改进，以切实获得采用敏捷方法所带来的最大效益。

2Scrum简介

Scrum是当今被广泛应用的敏捷开发模式之一。它有着自己鲜明的优势：客户成为开发团队的一部分、能够频繁提交可以工作的中间增量产品、可以不断更改项目的需求以适应用户需求的变化、不需制定详尽的不切实际的计划和编写冗长的文档使得团队更加灵活自如，自由地自我组织和自我管理使得团队积极主动、敏捷创新[4]。Scrum也有着区别于其他模式的特质。它拥有特定的成员角色：产品的负责人PO（ProductOwner），Scrum主管SM（ScrumMaster）和团队（Team）（适宜的人数是5到10人）。它拥有独特的实践方式：冲刺（Sprint），计划会议（SprintPlanningMeeting），评审会议（SprintReviewMeeting），回顾会议（SprintRetrospective），每日例会（DailyMeeting），产品订单梳理（ProductBackloggrooming）。它拥有着特殊的工件：产品订单（ProductBacklog），燃尽图（BurnDownChart），完成标准（DefinitionofDone），产品增量（ProductIncrement）[1]。

Scrum开发过程是以Sprint为增量的迭代开发过程，一般一个Sprint适宜的迭代周期是1到4周。Sprint开始时，团队从已按优先级顺序排列好的产品订单中选择适合本团队的项目，与PO澄清需求并生成同样按优先级顺序排列好的Sprint订单，并且保证在本次Sprint结束前做完论文格式范文。每个工作日团队都要收集汇报彼此的任务进程和余下的任务量。Sprint结束时小组展示最终的项目成果，并收集来自团队之外的反馈，用以下一个Sprint的自我提升。图1描述了Scrum的开发流程。

图1Scrum的迭代过程

3Scrum方法在实践中的灵活运用

3.1项目背景

本文的项目背景是某知名通信设备公司研发中心的开发和测试工作。研发团队具有多年Scrum开发经验，团队任务是研发和测试该公司某一产品线上的几个功能模块，其中包括基于底层Linux操作系统和顶层应用层的中间件模块：启动管理和内存文件管理。

3.2Scrum方法的改进

3.2.1改进每日例会的模式

按照Scrum倡导的每日例会形式，每个成员应轮流回答三个经典问题，这使得我们小组的日会在很长一段时间内基本沦为一场激烈的辩论会，而这些讨论往往是徒劳的。对此，我们决定对这种已经背离Scrum宗旨的日会进行改进。改进的主题就是转变角色计算机毕业论文，让项目任务成为会议的主角，因为Sprint订单原本就是对项目任务的细化。于是新的日会改变了模式：仍然由主管主持，所有成员群视白板，但变成了一种问答形式。如图2所示，主管会按优先级顺序遍历项目，针对细化了的每个项目的每个任务提问三个问题：今天花了多少时间、做到了什么程度（日会安排在下班前一小时）？遇到了什么问题？明天怎么解决、继续做多少？相关负责成员回答问题