《Scrum敏捷软件开发过程.ppt》由会员分享，可在线阅读，更多相关《Scrum敏捷软件开发过程.ppt（85页珍藏版）》请在金锄头文库上搜索。
1、Copyright 2008 TietoEnator CorporationScrum敏捷软件开发过程2008-12-03Jinghua Li Quality Manager TietoEnator Corporation T 变更需要重新估计、重新规划严密的合同来减少风险 , 如果改变需求要走 CR 流程.项目作为一个“黑盒子” ，对客户与供应商的可 视性差.产品化和测试阶 段是分离的.文档和计划驱动 的方法.软件交付时间 晚, 意识到风险 的时间 晚.敏捷项目管理:对整个项目做一个粗略的估计,每一次迭代都有 详细 的计划.鼓励变化, 客户价值驱动 开发.信任和赋予权力;合约使变更变得简单
2、，增加价 值.客户和开发人员之间是紧密的连续 的合作关系每次迭代都产生可交付的软件专注于交付软件.第一次迭代就可交付能工作的版本，风险发现 的 早. 8Copyright 2008 TietoEnator Corporation为什么采用敏捷? 预期的收益 采用敏捷方法得当的话，可以：更加透明; 随时跟踪项目的状态和进展情况，及早发现问题 和风险 .快速交付, 每次迭代都能交付可运行的软件.最高风险和最高优先级的需求，最优先进行开发.改善应对变 更能力, 减少大量的重计划.改善项目沟通.更好的客户参与, 避免错误的假设.总之:提高了生产率; 减少“浪费” （不需要的文档，重复工作等） ，项目的
3、每次迭代都有明确的目 标.提高客户满意度; 短期内产生成效, 按预期交付软件, 每次迭代结束产生可以运行的软件.改善员工的满意度; 团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌” ，稳定 的工作量（可持续的步伐）. 9Copyright 2008 TietoEnator Corporation敏捷方法何时有效？公司和客户一致认为应 当使用敏捷方法，双方都能理解敏捷方法.敏捷方法对需求不完整以及经常变换 的项目比较有效.项目可以划分成固定时间间 隔的迭代, 并且可以冻结 正在进行的迭代的范围公司和客户都有能力担当角色尤其是Product Owner 和 Scrum Master.项目
4、的人员结 构能够分成6到10人的团队 ，最好每个工作地点一个小组.团队 成员能够以自组织 的方式工作. 项目的合同允许变 更.固定价格的项目可以使用敏捷，但应当尽量避免。最好在按时间和材料付费或者按月付费的项目中进行使用、变更项目的范围不需要高级管理层的批准.10Copyright 2008 TietoEnator Corporation警告！敏捷开发过 程是一个艰苦的过程Agile Work is Hard Work这种状态也许会存在很长时间 ！不舒服疑惑有挫折感11Copyright 2008 TietoEnator CorporationScrum 概述Copyright 2008 Ti
5、etoEnator CorporationScrum 概述(1/3)Scrum是管理软件项目的一个轻量级的敏捷方法, 名字来源于橄榄球运动中的scrum 过程简单 ，但高度的纪律性依赖迭代和增量的敏捷方法.Scrum 是一种工作管理的方法，不仅仅 限于软件开发，可以用来管理其它活动.Scrum 不包含技术方法或实践.13Copyright 2008 TietoEnator CorporationScrum 概述 (2/3) 项目的阶段项目分成增量的迭代过程，在Scrum中称为迭代任务清单, 通常持续2-4周的时间 .Sprint 的时间是限定好的; 不能从外部改变正在进行中的sprint持续时
6、间 和范围.每个sprint都可以产生可交付的迭代, 即测试过 并具备文档的的功能点原则上, 当产品开发到一定程度时，如实现了足够的客户价值，项目可以在任何一个sprint 后结束,.如同任何项目，敏捷的项目有三个主要阶段 :产品定义 (规划); 运行Sprints 所需要的准备、规划、技术分析.执行Sprints (执行): 在增量时间段内实现 需求 (产品需求清单).结束: 准备最终发布，结束项目14Copyright 2008 TietoEnator CorporationScrum 概述 (3/3)Sprint Planning Meeting: Next Sprint Goal Sp
7、rint Backlog Updated Product BacklogDaily Scrum meetings : What did you do yesterday What will you do today? What obstacles are in your way?Source: http:/ ScrumSprint RetrospectiveShippable Product Increment15Copyright 2008 TietoEnator CorporationScrum角色、实践和工作产品Copyright 2008 TietoEnator Corporation
8、Scrum中的三种角色Product Owner- 产品所有者个人：代表所有的干系人Scrum Master: 个人：负责指导过程的执行Scrum Team Scrum团队 :承诺完成工作，向干系人交付产品价值17Copyright 2008 TietoEnator CorporationScrum 角色 Scrum 团队Scrum 团队 是Scrum的中心角色， 产品交付要依靠团队 .Scrum 团队 自我组织 、自我管理Scrum 团队 是职能交叉的， 包含产品交付的所有角色:开发人员、测试 人员、build managers, 文档编写, 界面设计 人员.Scrum 团队 中的角色是不分
9、等级的; 不应当出现“我是开发人员我不作测试 ”.团队按照最有利于项目的原则来分担责任 (如组件的所有权等 ).敏捷是建立在信任和授权的基础上，因此团队 是自发组织 的，组员选择 自己的任 务，而不是别人强制加以分配的.另一方面，Scrum团队 有交付的责任，他们需要能够自我激励和对工作目标进 行承 诺.团队 最佳规模： 6-10 人18Copyright 2008 TietoEnator CorporationScrum 角色 Scrum 团队主要职责参与迭代任务清单的创建执行为干系人创造价值的工作根据团队的承诺完成所需的各项任务将工作中的各项障碍迅速与Scrum Master 进行沟通全面
10、参与所有的各项会议更新任务状态自发选择 任务标识任务的完成标识发现 的新的任务与其它团队共同进行工作19Copyright 2008 TietoEnator CorporationScrum 角色 Scrum MasterScrum Master不是一个管理者，而是一个教练和推动者 - Scrum团队 是一种自发的 组织 ，是自我管理的.Scrum Master的角色通常由项目组的成员担当，组长 或者项目经理。Scrum Master 应当是项目中的成员.主要职责 :评价过程的健康状况加强过程消除障碍促进过程改进支持团队开发Scrum Master 的主要工作是做决策、消除障碍，保证团队 能顺
11、利交付产品20Copyright 2008 TietoEnator CorporationScrum 角色 Scrum MasterScrum Master 还有如下责任与其它角色配合.训练团队 ，提高生产率.培训产品所有者和干系人，确保Scrum流程的执行确保一切工作按照既定的规范来运行.规划并进行必要的改进.推动会议的召开.维护障碍列表维护Scrum过程改进列表优秀的 Scrum Master 应当是专注的,、有决心的、有领导 才能.21Copyright 2008 TietoEnator CorporationScrum 角色 Product Owner产品所有者代表投资方的利益，确保交
12、付的产品与期望的一致 （提供更好的投资回 报).Product Owner决定产品具有哪些功能.Product Owners的主要责任是创建和维护产 品需求清单, 即管理项目的范围.Product Owner不断的把产品需求清单按优先级进行排序 ，使得最重要的功能能优先实现.对于团队来说，只有一个需求集。所有的需求申请都归口到Product Owner管理商业价值（投资回报）Product Owner 还有如下责任:计划项目的发布，什么时间、向什么人等.对每次Sprint的结果进行评审和批准22Copyright 2008 TietoEnator CorporationScrum 角色 Pro
13、duct Owner参与Scrum会议迭代计划会议团队进 展跟踪会议迭代评审和回顾会议能够随时回答团队 工作中产生的各项和产品/业务 相关的问题Product Owner 的角色一般由客户担当，作为服务提供商的公司无法设定优先级.23Copyright 2008 TietoEnator CorporationScrum 角色 客户与管理层客户和管理的角色是可选的，需要时才设立客户:是产品的最终用户 通过 Product Owner来设定对产品的期望把当前的业务传 达给项目.管理层:公司高级管理层,代表公司在项目中的利益.通过Product Owner来传达公司的利益和优先级（prioritie
14、s ）24Copyright 2008 TietoEnator Corporation产品需求清单 Product Backlog (1/4) 概论基本上，产品需求清单是为了实现产 品的功能所需要的工作的列表，包括:功能方面的需求; 功能点.非功能方面的需求, 如性能改进.要修改的Bug; 上一版本的已知错误.新技术, 如支持新的操作系统或者平台.问题; 日后的不确定项, 如新的功能.产品需求清单是不断完善的.Product Owner 在项目进行过程中可以随时更新：增加、删除、修改功能，变更优先级等.下一次迭代中要包含较高优先级的需求.产品需求清单也可称为User Stories (用例)
15、，因为它们能够给产 品的用户带 来价值 .在一次迭代中要能够实现产 品需求清单，如果不能全部实现 要进行分解. 25Copyright 2008 TietoEnator Corporation产品需求清单 (2/4) 构成Product Owner负责创 建最初的产品需求清单，一开始是不完整的.最初的清单应当包含足够的需求.清单应当包含多少需求, 取决于定价模型 (black-box, 更多的计划时间).产品需求清单来源于:客户; 标书, 需求规格说明等.Scrum团队的想法; 增强型新功能等.现有产品的迭代增量; 已知错误, 技术问题 等.比较好的做法是Product Owner 、Scrum团队 、客户/管理以及其它相关方（如相关 的Scrum团队 ）举行一次或者多次研讨会Scrum Master 或者 Product Owner 来促成会议的召开，必须要有人来做.要有效率、要围绕主题、 沟通良好 、避免不同的假设，承诺并且共通合作，确定优先级.26Copyright 2008 TietoEnator Corporation产品需求清单 (3/4) 估计Scrum团队对产 品需求清单的每一项的规模提供初步的估计，通常采用事件点作为 单位Story Points (模糊的).也可采用人天或者人小时作为单位，但容易混淆： a) 实
