Scrum精讲概念.ppt

剩余小时数 燃烧图 燃尽图 燃尽图 Sprint评审会议 在Sprint结束时召开，会议时间控制在两小时以内 开发团队展示这个Sprint中完成的功能，不需要PPT，一般是已经完成的功能DEMO 客户、管理层、Product Owner以及其它开发人员都可以参加 主要是对项目开发的进度通过对实际已完成产品功能的审核进行控制，由产品负责人断定实际所发两点的功能是否与既定的Sprint目标一致， Sprint评审会议 Sprint回顾会议 Sprint结束后，时间在1-3个小时 回顾刚结束的Sprint，对其进行总结和反思，审视和适应的能力是Scrum的基础，在Sprint回顾会议期间，项目团队会分析Sprint中的成功经验和所遇到的阻碍， 产品负责人、Scrum团队和Scrum Master参加 迭代回顾 迭代回顾 ? 迭代回顾的目的：产品检查和适应 ? 参与者：团队、PO、SM、各职能组leader、其 他涉众； ? 参考方式： – 演示产品，验证迭代期内的承诺完成内容。相关人员一起讨 论产品与“完成标准”的偏差。 – 团队向PO提出产品相关议题，或迭代中碰到的问题（例如： 在后续迭代中需要解决的技术问题） – PO向团队提出产品相关议题，或迭代中碰到的问题（例如： 市场变化、用户新需求等） ? ? ? ? 迭代总结 ? 迭代总结的目的：团队工作方式检查和自适应 ? 参考方式： – 每次迭代回顾后召开，1-2小时 – 团队、SM参加 – 管理者和PO应参加，但只部分时间参与，团队需要内部交 谈时间 – 通常会邀请一位中立人员来担当会议协调人 – 讨论四个主题 哪些做得好 那些需要改善（不太好的） 需要在以后尝试的事情（今后迭代中改善） 要上报的问题（向管理者） 度 好的： ? 团队感到在实现目标时比以前 更加聚焦、清晰 ? 团队使用燃烧图后，对迭代进 展有更清晰的了解 ? 每日Scrum会议改善了团队在 迭代中的沟通 ? 迭代回顾涌现出不少好的想法 今后要开始做的： ? 估计不要太乐观，现实一些 ? 关注开发和测试之间的协作 ? 换一家餐饮服务公司 待改善： ? 在既定时间内，我们没有完成 承诺的内容 ? 估计偏差较大 ? 没有考虑清楚任务相关性 ? 开发和测试之间的协作不太好 ? 茶歇时间的食品很糟糕 上报问题： ? 网络非常不稳定，影响了工作进 ? 需要测试驱动开发培训 Backlog 积压的待处理事务 Sprint 本意“冲刺”，指迭代周期，通常2-4周为一个周期 迭代总结 目录 ? Scrum概览 ? Scrum中的角色和关键原则 ? Scrum流程：策划、执行跟踪、回顾 ? 几个应用主题（发布周期、度量、大团队） Scrum 中的发布周期 Scrum发布周期 ? 两种常见方法： ? 多次迭代发布： ? 每次迭代发布： 多次迭代发布——方法之一 发布前SPRINT 顶层设计和架构调 研，开发环境安装 最终稳定和发布 准备 多次迭代发布——方法之一 在项目接近结束 时，缩短迭代 期，以更快地检 查/适应 简介： Scrum和度量 Scrum和度量 ? Scrum不会阻止你跟踪或测量你所实施的开发过 程； ? 测量的记录和汇报可能需要花费资源 – 如果确实需要消耗团队资源，应该让这些消耗在任务 时间估计时明确出来，或作为一个PB或SB项 常用度量 ? 进度差异对比 – 用实际速度比较估计速度； ? 工作量差异对比 – 任务汇总成本（跟踪本身的工作量，及可能引发的问 题和数据作弊）； – 实际消耗时间 vs 预计消耗时间； ? 挣得值（已实现的软件的商业价值） – 商业价值燃烧图 简介：Scrum自适应 -如何应用于不同规模组织 Scrum自适应 ~ 50人规模 （分析师、设计师、开发、测试、文档等） Scrum自适应 方法1：多团队共用一份PB 方法2：多团队按照独立PB工作 Scrum自适应 Scrum自适应 迭代期间 每天/每周2-3次 协调、相关性管理、问题暴露 目录 ? Scrum概览 ? Scrum中的角色和关键原则 ? Scrum流程：策划、执行跟踪、回顾 ? 几个应用主题（发布周期、度量、大团队） QA * 1 2 3 4 6 7 Product Backlog 优先 级 浏览时钟 搜索某种时 钟 注册帐户 将时钟放入 购物篮 说明 当用户想购买时钟而不确定型号时，我希望能浏览Clockazon 在售的时钟，按照(a)时钟类型和(b)价格范围进行过滤。 在用户查找某款时钟时，我希望能进行不限格式的文本搜索， 按照短语