最完整的Scrum敏捷软件开发过程幻灯片课件

1、Scrum敏捷软件开发过程 2 目录 什么是敏捷软件开发 敏捷方法的项目计划敏捷项目管理和传统项目管理为什么使用敏捷 Scrum概述Scrum的角色Scrum实践和工作产品敏捷开发中的估计方法测试驱动开发Scrum应用支持工具和模版一些常见的误解 4 什么是敏捷软件开发 敏捷软件开发是软件项目的一个概念框架 有许多建立在敏捷概念上的方法 如Scrum和ExtremeProgramming XP 与僵化的 重量级的 官僚式的方法形成对照 比如瀑布模型 指纯粹形式的 最大限度地降低短期固定时间的迭代式软件的开发风险 5 敏捷宣言 2001年 人和交互胜过过程和工具 Individualsandinteractionsoverprocessesandtools可以工作的软件胜过完备的文档 Workingsoftwareovercomprehensivedocuments客户协作胜过合同谈判 Customercollaborationovercontractnegotiation随时应对变化胜过遵循计划 Respondingtochangeoverfollowingaplan 6 敏捷过程的限

2、制 敏捷软件开发过程包含过程 原则 工具 和最重要的 人因此诚信是基础没有过程能够对诚信进行有效地约束诚信与否是有效实施敏捷过程的最大限制 7 使用敏捷方法的项目计划 ProductBacklog Features 5213858 32 InitialSizeEstimatesAsStoryPoints Longtermplanning bestguessatthemoment 32SPoffunctionality TeamVelocity8SP Sprint 4SprintsTargetSprintforeachPBLitemset feasibleimplementationOrder SprintBacklog Tasks Sprintful oftop priorityPBLtothenextSprint Moreaccurateestimatesasmanhours Shorttermplanning commitmentbyTeam Maybeconstantlyupdated Scopefrozen newPBLitemstonextSprint 8 敏捷项目管理和传统

3、项目管理 传统项目管理 事先对整个项目进行估计 计划 分析反对变更 变更需要重新估计 重新规划严密的合同来减少风险 如果改变需求要走CR流程 项目作为一个 黑盒子 对客户与供应商的可视性差 产品化和测试阶段是分离的 文档和计划驱动的方法 软件交付时间晚 意识到风险的时间晚 敏捷项目管理 对整个项目做一个粗略的估计 每一次迭代都有详细的计划 鼓励变化 客户价值驱动开发 信任和赋予权力 合约使变更变得简单 增加价值 客户和开发人员之间是紧密的连续的合作关系每次迭代都产生可交付的软件专注于交付软件 第一次迭代就可交付能工作的版本 风险发现的早 9 为什么采用敏捷 预期的收益 采用敏捷方法得当的话 可以 更加透明 随时跟踪项目的状态和进展情况 及早发现问题和风险 快速交付 每次迭代都能交付可运行的软件 最高风险和最高优先级的需求 最优先进行开发 改善应对变更能力 减少大量的重计划 改善项目沟通 更好的客户参与 避免错误的假设 总之 提高了生产率 减少 浪费 不需要的文档 重复工作等 项目的每次迭代都有明确的目标 提高客户满意度 短期内产生成效 按预期交付软件 每次迭代结束产生可以运行的软件 改

4、善员工的满意度 团队精神 减少官僚 能够规划和管理自己的工作 减少 恐慌 稳定的工作量 可持续的步伐 10 敏捷方法何时有效 公司和客户一致认为应当使用敏捷方法 双方都能理解敏捷方法 敏捷方法对需求不完整以及经常变换的项目比较有效 项目可以划分成固定时间间隔的迭代 并且可以冻结正在进行的迭代的范围公司和客户都有能力担当角色尤其是ProductOwner和ScrumMaster 项目的人员结构能够分成6到10人的团队 最好每个工作地点一个小组 团队成员能够以自组织的方式工作 项目的合同允许变更 固定价格的项目可以使用敏捷 但应当尽量避免 最好在按时间和材料付费或者按月付费的项目中进行使用 变更项目的范围不需要高级管理层的批准 11 警告 敏捷开发过程是一个艰苦的过程AgileWorkisHardWork这种状态也许会存在很长时间 不舒服疑惑有挫折感 Scrum概述 13 Scrum概述 1 3 Scrum是管理软件项目的一个轻量级的敏捷方法 名字来源于橄榄球运动中的scrum过程简单 但高度的纪律性依赖迭代和增量的敏捷方法 Scrum是一种工作管理的方法 不仅仅限于软件开发 可以用来管理

5、其它活动 Scrum不包含技术方法或实践 14 Scrum概述 2 3 项目的阶段 项目分成增量的迭代过程 在Scrum中称为迭代任务清单 通常持续2 4周的时间 Sprint的时间是限定好的 不能从外部改变正在进行中的sprint持续时间和范围 每个sprint都可以产生可交付的迭代 即测试过并具备文档的的功能点原则上 当产品开发到一定程度时 如实现了足够的客户价值 项目可以在任何一个sprint后结束 如同任何项目 敏捷的项目有三个主要阶段 产品定义 规划 运行Sprints所需要的准备 规划 技术分析 执行Sprints 执行 在增量时间段内实现需求 产品需求清单 结束 准备最终发布 结束项目 15 Scrum概述 3 3 SprintPlanningMeeting NextSprintGoalSprintBacklogUpdatedProductBacklog DailyScrummeetings WhatdidyoudoyesterdayWhatwillyoudotoday Whatobstaclesareinyourway Source DailyScrum SprintR

6、etrospective ShippableProductIncrement Scrum角色 实践和工作产品 17 Scrum中的三种角色 ProductOwner 产品所有者个人 代表所有的干系人ScrumMaster 个人 负责指导过程的执行ScrumTeam Scrum团队 承诺完成工作 向干系人交付产品价值 18 Scrum角色 Scrum团队 Scrum团队是Scrum的中心角色 产品交付要依靠团队 Scrum团队自我组织 自我管理Scrum团队是职能交叉的 包含产品交付的所有角色 开发人员 测试人员 buildmanagers 文档编写 界面设计人员 Scrum团队中的角色是不分等级的 不应当出现 我是开发人员我不作测试 团队按照最有利于项目的原则来分担责任 如组件的所有权等 敏捷是建立在信任和授权的基础上 因此团队是自发组织的 组员选择自己的任务 而不是别人强制加以分配的 另一方面 Scrum团队有交付的责任 他们需要能够自我激励和对工作目标进行承诺 团队最佳规模 6 10人 19 Scrum角色 Scrum团队 主要职责参与迭代任务清单的创建执行为干系人创造价值的工作根

7、据团队的承诺完成所需的各项任务将工作中的各项障碍迅速与ScrumMaster进行沟通全面参与所有的各项会议更新任务状态自发选择任务标识任务的完成标识发现的新的任务与其它团队共同进行工作 20 Scrum角色 ScrumMaster ScrumMaster不是一个管理者 而是一个教练和推动者 Scrum团队是一种自发的组织 是自我管理的 ScrumMaster的角色通常由项目组的成员担当 组长或者项目经理 ScrumMaster应当是项目中的成员 主要职责 评价过程的健康状况加强过程消除障碍促进过程改进支持团队开发ScrumMaster的主要工作是做决策 消除障碍 保证团队能顺利交付产品 21 Scrum角色 ScrumMaster ScrumMaster还有如下责任与其它角色配合 训练团队 提高生产率 培训产品所有者和干系人 确保Scrum流程的执行确保一切工作按照既定的规范来运行 规划并进行必要的改进 推动会议的召开 维护障碍列表维护Scrum过程改进列表优秀的ScrumMaster应当是专注的 有决心的 有领导才能 22 Scrum角色 ProductOwner 产品所有者代表投资

8、方的利益 确保交付的产品与期望的一致 提供更好的投资回报 ProductOwner决定产品具有哪些功能 ProductOwner s的主要责任是创建和维护产品需求清单 即管理项目的范围 ProductOwner不断的把产品需求清单按优先级进行排序 使得最重要的功能能优先实现 对于团队来说 只有一个需求集 所有的需求申请都归口到ProductOwner管理商业价值 投资回报 ProductOwner还有如下责任 计划项目的发布 什么时间 向什么人等 对每次Sprint的结果进行评审和批准 23 Scrum角色 ProductOwner 参与Scrum会议迭代计划会议团队进展跟踪会议迭代评审和回顾会议能够随时回答团队工作中产生的各项和产品 业务相关的问题ProductOwner的角色一般由客户担当 作为服务提供商的公司无法设定优先级 24 Scrum角色 客户与管理层 客户和管理的角色是可选的 需要时才设立客户 是产品的最终用户通过ProductOwner来设定对产品的期望把当前的业务传达给项目 管理层 公司高级管理层 代表公司在项目中的利益 通过ProductOwner来传达公司的利益和

9、优先级 priorities 25 产品需求清单ProductBacklog 1 4 概论 基本上 产品需求清单是为了实现产品的功能所需要的工作的列表 包括 功能方面的需求 功能点 非功能方面的需求 如性能改进 要修改的Bug 上一版本的已知错误 新技术 如支持新的操作系统或者平台 问题 日后的不确定项 如新的功能 产品需求清单是不断完善的 ProductOwner在项目进行过程中可以随时更新 增加 删除 修改功能 变更优先级等 下一次迭代中要包含较高优先级的需求 产品需求清单也可称为UserStories 用例 因为它们能够给产品的用户带来价值 在一次迭代中要能够实现产品需求清单 如果不能全部实现要进行分解 26 产品需求清单 2 4 构成 ProductOwner负责创建最初的产品需求清单 一开始是不完整的 最初的清单应当包含足够的需求 清单应当包含多少需求 取决于定价模型 black box 更多的计划时间 产品需求清单来源于 客户 标书 需求规格说明等 Scrum团队的想法 增强型新功能等 现有产品的迭代增量 已知错误 技术问题等 比较好的做法是ProductOwner Scr

10、um团队 客户 管理以及其它相关方 如相关的Scrum团队 举行一次或者多次研讨会ScrumMaster或者ProductOwner来促成会议的召开 必须要有人来做 要有效率 要围绕主题 沟通良好 避免不同的假设 承诺并且共通合作 确定优先级 27 产品需求清单 3 4 估计 Scrum团队对产品需求清单的每一项的规模提供初步的估计 通常采用事件点作为单位StoryPoints 模糊的 也可采用人天或者人小时作为单位 但容易混淆 a 实际的规模b 时间的单位 精确的估计值可以在Sprint规划时给出 当前阶段没有足够的信息 规模的相对值才有意义 这个估计值有助于确定优先级 所需时间 团队速度 产品规模 28 产品需求清单 4 4 优先级 优先级是产品需求清单中的主要问题 优先级不但反映了客户的价值也反映了风险 产品所有者 PO设定优先级 清单中的每一项的优先级是唯一的 但可以对它们进行分类优先级可以在项目的任何时候进行更改 如新的重要的功能可以直接给较高的优先级 确定优先级考虑 价值风险依赖关系 29 产品需求清单 示例 Priority ID likeinanyrequirement

《最完整的Scrum敏捷软件开发过程幻灯片课件》由会员youn****329分享，可在线阅读，更多相关《最完整的Scrum敏捷软件开发过程幻灯片课件》请在金锄头文库上搜索。