敏捷开发流程(自己总结)_第1页
敏捷开发流程(自己总结)_第2页
敏捷开发流程(自己总结)_第3页
敏捷开发流程(自己总结)_第4页
敏捷开发流程(自己总结)_第5页
已阅读5页,还剩8页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、-作者xxxx-日期xxxx敏捷开发流程(自己总结)【精品文档】敏捷开发的相关简介敏捷定义 Scrum是一个轻量级的软件开发方法Scrum是一个敏捷开发框架,是一个增量的、迭代的开发过程。在这个框架中,整个开发周期包括若干个小的迭代周期,每个小的迭代周期称为一个Sprint,每个Sprint的建议长度2到4周。在Scrum中,使用产品Backlog来管理产品或项目的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中,Scrum开发团队从产品Backlog中挑选最有价值的需求

2、进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表,我们称它为Sprint backlog 。 在每个迭代结束时,Scrum团队将交付潜在可交付的产品增量。敏捷的原则个体与交互 胜过 过程与工具可以工作的软件 胜过 面面俱到的文档客户协作 胜过 合同谈判响应变化 胜过 遵循计划这四句价值观用语句表达就是:自组织团队与客户紧密协作,通过高度迭代式、增量式的软件开发过程响应变化,并在每次迭代结束时交付经过编码与测试的有价值的软件。 胜过与客户确定合同后在初期制定并遵循基于活动的完整计划,在重型过程和工具指导下,通过完成大量文档进行知识传递,

3、最后交付需求。敏捷宣言12条原则1.最优先的目标是通过尽早地、持续地交付有价值的软件来满足客户。2.欢迎需求变化,甚至在开发后期。敏捷过程控制、利用变化帮助客户取得竞争优势。3.频繁交付可用的软件,间隔从两周到两个月,偏爱更短的时间尺度。4.在整个项目中业务人员和开发人员必须每天在一起工作。5.以积极主动的员工为核心建立项目,给予他们所需的环境和支持,信任他们能够完成工作。6.在开发团队内外传递信息最有效率和效果的方法是面对面的交流。7.可用的软件是进展的主要度量指标。8.敏捷过程提倡可持续发展。发起人、开发者和用户应始终保持稳定的步调。9.简化使必要的工作最小化的艺术是关键。10.持续关注技

4、术上的精益求精和良好的设计以增强敏捷性。11.最好的架构、需求和设计产生于自我组织的团队。12.团队定期地对运作如何更加有效进行反思,并相应地调整、校正自己的行为。敏捷的角色1产品负责人产品负责人(Product Owner)的职责如下: 确定产品的功能。 决定发布的日期和发布内容。 为产品的ROI负责。 根据市场价值确定功能优先级。 每个Sprint,根据需要调整功能和优先级(每个Sprint开始前调整)。 接受或拒绝接受开发团队的工作成果。 2 ScrumMaster作为Team Leader和Product owner紧密地工作在一起,他可以及时地为团队成员提供帮助。他必须: 保证团队资

5、源完全可被利用并且全部是高产出的。 保证各个角色及职责的良好协作。 解决团队开发中的障碍。 做为团队和外部的接口,屏蔽外界对团队成员的干扰。 保证开发过程按计划进行,组织Daily Scrum, Sprint Review and Sprint Planning meetings。3 Team负责产品的开发 一般情况人数在5-9个左右 团队要跨职能(包括开发人员、测试人员、用户界面设计师等) 团队成员需要全职。(有些情况例外,比如数据库管理员) 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。 高度的自组织能力。 向Product Owner演示产品功能。 团队成员构成在spri

6、nt内不允许变化。 团队整体向产品开发负责。敏捷工件1、Product Backlog有优先级的故事列表,并估算故事点产品订单:产品订单(Product Backlog)是整个项目的概要文档,它包含已划分优先等级的、项目要开发的系统或产品的需求清单,包括功能和非功能性需求及其他假设和约束条件。产品负责人和团队主要按业务和依赖性的重要程度划分优先等级,并作出预估。预估值的精确度取决于产品订单中条目的优先级和细致程度,入选下一个冲刺的最高优先等级条目的预估会非常精确。产品的需求清单是动态的,随着产品及其使用环境的变化而变化,并且只要产品存在,它就随之存在。而且,在整个产品生命周期中,管理层不断确定

7、产品需求或对之做出改变,以保证产品适用性、实用性和竞争性。2、Sprint Backlog当前Sprint要完成的任务列表,并估算工时 团队成员自己挑选任务,而不是指派任务 对每一个任务,每天要更新剩余的工作量估算 每个团队成员都可以修改Sprint backlog,增加、删除或者修改任务冲刺订单:冲刺订单是大大细化了的文档,用来界定工作或任务,定义团队在 Story 中的任务清单,这些任务会将当前冲刺选定的产品订单转化为完整的产品功能增量。冲刺订单在冲刺规划会议中形成,其包含的不会被分派,而是由团队成员签名认领他们喜爱的任务。任务被分解为以小时为单位,没有任务可以超过 16 个小时。如果一个

8、任务超过 16 个小时,那么它就应该被进一步分解。每项任务信息将包括其负责人及其在冲刺中任一天时的剩余工作量,且仅团队有权改变其内容。3、发布燃尽图直观反应当前发布剩余的工作量,以Sprint周期数和故事点数为单位。燃尽图(Burndown Chart)是一个公开展示的图表,纵轴代表剩余工作量,横轴代表时间,显示当前冲刺中随时间变化而变化的剩余工作量(可以是未完成的任务数目,或在冲刺订单上未完成的订单项的数目)。剩余工作量趋势线与横轴之间的交集表示在那个时间点最可能的工作完成量。我们可以借助它设想在增加或减少发布功能后项目的情况,我们可能缩短开发时间,或延长开发期限以获得更多功能。它可以展示项

9、目实际进度与计划之间的矛盾。 4、Sprint燃尽图Sprint燃尽图直观的反映了Sprint过程中,剩余的工作量情况,Y轴表示剩余的工作,X轴表示Sprint的时间。随着时间的消耗工作量逐渐减少,在开始的时候,由于估算上的误差或者遗漏工作量有可能呈上升态势。Sprint过程1、Sprint计划会议 团队从产品backlog中挑选他们承诺完成的条目。(做什么) 创建Sprint Backlog (怎么做) 标识具体的任务并为任务做估算 由团队协作完成,而不是ScrumMaster 考虑了高层设计2、Scrum每日站会团队每天进行15分钟的检验和适应的会议称为Scrum每日站会。每日站会上,每个

10、团队成员需要汇报以下三个问题: 从上次会议到现在完成了哪些工作。 下次会议前准备完成什么。 工作中遇到了哪些障碍。 汇报的对象是团队,不是任何一位领导(PO,SM,团队负责人)。汇报的重点在于提出问题,进而解决。每日站会不是进度汇报会议,这个会议是为将产品backlog条目转化成为增量的人(团队)召开的。团队承诺实现Sprint目标和完成产品Backlog条目。每日站会是检验朝向Sprint目标的进程,如果有必要进行后续会议对Sprint中的下一步工作进行调整,目的在在于增加团队实现目标的可能性。这是Scrum经验过程中的重要检验和适应的会议。3、Sprint评审会议Sprint评审会议用来演

11、示在这个Sprint中开发的产品功能给Product Owner.Produc Owner会组织这阶段的会议并且邀请相关的干系人参加。 团队展示Sprint中完成的功能 一般是通过现场演示的方式展现功能和架构 不要太正式 不需要PPT 一般控制在2个小时 团队成员都要参加 可以邀请所有人参加4、Sprint回顾会议Sprint回顾会议上,全体成员讨论有哪些好的做法可以启动,哪些不好的做法不能再继续下去了,哪些好的做法要继续发扬。 团队的定期自我检视,发现什么是好的,什么是不好的。 一般控制在15-30分钟 每个Sprint都要做 全体参加 Scrum Master 产品负责人 团队 可能的客户

12、或其它干系人开发流程阶段参与人事务输出开发调研PO,SM,团队讨论产品需求条目问卷调查分析故事列表工作量估算SM,团队使用估算扑克估算故事点确定故事的依赖关系带估算的故事列表发布计划会议PO,SMPO确定当前发布的时间和应该包含的故事PO向各干系人公开发布规划产品BacklogSprint计划会议SM,团队PO确定最近1-2个Sprint的最优先级故事团队从产品Backlog中的最高优先级故事中挑选承诺完成的条目分解条目成为工作项评估工作项工时(小时为单位)Sprint BacklogSprintSM,团队按Sprint Backlog产出软件产品软件产品必须是潜在可交付的(经过完整测试,可运

13、行,有完整用户文档)潜在可交付的产品增量Sprint评审会议PO,SM,团队团队向PO及相关干系人演示产品增量收集意见,为下一个Sprint作准备 Sprint回顾会议PO,SM,团队对开发流程进行回顾,检查哪些方法是值得保留的,哪些是要废弃的。更好的Scrum流程敏捷的开发流程1首先组建scrum团队(5-9人)2 确定团队成员职责(scrummaster,po,team)3需求设计分析,列出product backlog,格式如下:ID NAME IMP EST HOW TO DEMO NOTES注意事项:DEEPDetailed appropriately(粗细适中):指将当前优先级高的

14、功能模块尽量细化,而相对优先级较低的功能模块,只需要知道大体功能点既可。Estinnated(估算过的):对每个功能点进行估算。Emergent(涌现的):功能模块随着开发的推移是变化的,因此每次迭代完成都要重新调整。Prioritized(排好优先级的):将功能模块根据商业价值进行排序。产品功能模块的优先级最好用(10,20,30计算),方便需求变更,附加功能插入。4 sprint planning-想要什么以及为什么?5 选择部分product backlog(优先级)作为当前sprint的sprint backlog,并创建sprint面板。6 sprint准备会,确定每个人做什么以及怎

15、么做(最好是,自己选择)?确定此次sprint的“可交付物”(也就是完成这次迭代要达到的效果)。并且确定当前sprint哪些功能是必须实现的(must),哪些是应该做的,但若没时间就算了(should),哪些是不太需要,但有更好(could)。7 sprint开发开始,创建sprint的任务版和sprint backlog的燃尽图,并确保每日更新,每日晨会。Sprint任务版:Sprint backlog to do doing done燃尽图:在迭代开发过程中,会发生需求的变更或者功能点的添加,但只要对本次迭代影响不是特别大,就不要对本次迭代发生变更。(记录迭代中的变更)8 迭代完成后需要完成文

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论