Scrum敏捷开发模式讲解课件.ppt

Scrum Master的选择 ? 高效SM的特征 – – – – – 对团队的成功有高度的责任心 良好的人缘、良好的沟通技能 敏感、好的聆听者 积极、乐于助人 技术专家，会更有帮助但非必要 ? 专职SM会有最好的成果 – 如果不能专职，必须有一位成员担当这个角色（相应 降低他的原工作负担） ? 避免让团队行政管理者做 做SM – 因为大家会指望原管理者来作规划，也就很难做到自 我管理 Product Owner ? 负责最大化项目ROI（投资回报） ? 实现手段： – 多方收集意见，充分了解机会和风险； – 确定清晰、一致的愿景及目标，明确为实现最大 商业价值所需做的事情； – 制订一个需求表，按照优先级列出特性和功能； – 积极参加迭代计划和迭代回顾会议，在迭代中为 团队提供支持； – 基于日常观察和学习，持续精炼和优化PB； ? 对PB优先级有最终决策权 Scrum给团队管理者带来哪些变化 ? 第1步：列出管理者过去负责的事项列表 （尽可能列全） ? 第2步：勾掉列表中： – 与Scrum冲突的； – 在Scrum中不必要的； – 对实现团队自我管理有不良影响的； 管理者2.0 ? 第3步：帮助管理者按照以上步骤，梳理一 份新的工作说明； ? 第4步：与管理者的上级和HR沟通，争取 理解和支持； 迭代中不允许变更 ? 禁止变更交付件和交付日期 – 一旦团队作出承诺，就不允许变更交付件 – 如果发生重大变化，PO可以中止当次迭代 – 在迭代中会出现“分解”和“澄清”，但是不允许添加 新工作，或者对现有工作进行“实质变更” ? “变更”vs“澄清” – 如果存在争议，那么将其认定为变更，放到PB 中，下一次迭代再考虑。 – 在我们实际应用中，将较低级别的需求剔除掉。 变更的影响 在迭代期间，如果PO增加只需要少量工作的工 作项，或替换部分工作项，会有什么影响？ 当前迭代 今后的迭代 团队交 PO满 付承诺 意度 项的能 力 团队 对交 付件 的承 诺 PO不 提变 更的 自律 PO写 PB的 规则 团队对 团队遵 其它团 要交付 循其它 队遵循 承诺内 Scrum Scrum 容的关 规则的 规则的 注度 自律性 自律性 PO用户故事 ? 用户故事是写PB的好方法之一； ? 用户故事是简短、明确的功能说明，按照 用户价值和用户需要编写。 迭代计划会议 ? 团队确定在迭代结束时，能完成多少PB ? 对于2周迭代的项目，会议一般花3-4小时 ? 分两部分（同一天内，连续） – 第一部分 （PO召开需求评审会） ：团队评审PO想要的东西， 然后与PO确认“完成”的定义 – 第二部分(团队拆分需求，打扑克牌)：团队决定承诺完成多少， 以及如何实现承诺。 迭代策划——第一部分 ? PO介绍PB中最优先PB项的细节 ? 团队提出问题、建议，就疑问进行确认 ? 协商对PB需要做的修改 – 团队驱动项增加到PB中 – 大粒度项拆分 – 任何其它提炼和优化 ? 团队和PO评审标准的“完成定义”，就所有 修订达成一致 “完成”定义 在迭代结束时，要“完成”的功能， 必须完成以下步骤： 1 开发规格说明书 2 开发规格说明书评审 3 开发完成 4 代码review 5 单元测试完成 6 测试用例完成 7 测试用例评审 8 测试执行报告 9 已提交至测试集成 …… ＃ 缺陷标准： 不允许P1 P2缺陷，P3缺陷小于3个 达到“完成”—不太好的方式 达到“完成”—更好的方式 迭代策划——第二部分 ? 团队开始将PB项分解为工作任务，并且估计需要 的时间 ? 对照团队可用资源，团队承诺本迭代完成量，确 保工作量适当 ? 所有团队成员都参与会议和讨论，无论经验多少 及能力高低 计划纸牌 燃尽图 每日Scrum会议 ? 会议目的： – 保持团队内部协调顺畅，相互之间进展明晰 – 每天暴露困难和障碍，非团队监管 ? 如何开展： – 在Task白板处，每个工作日举行，团队所有成员参加 （开会时间到，不等待其他成员，小组自定义惩罚措施。） – 围成一个圈，面向圆心（而非SM） – 行政管理者最好回避 – 每个人汇报3件事（也可以做一些调整） – 会议中不允许讨论（如果确实必要，简洁一点） 每日Scrum会议 ? Master任务： – 记录并现场解答跟踪问题。 – 更新燃尽图。 ? 团队个人(每个人1-3分钟陈述，讲给团队) – 昨天完成的Task。 – 今天将认领的Task。 – 需要协助解决的问题。 白板 迭代回顾