Scrum intro
- 1. Scrum 介绍 王挺 2012 年 12 月 20 日
- 2. 议程 ● 什么是 Scrum ● 概念 ● 角色 ● 过程一览 ● 具体过程 ● Git 的应用
- 4. 概念 ● Sprint – 最小的一个开发周期 – 2-6 周 ● Backlog – 所有故事的集合 – + Bugfix
- 5. 角色 ● Scrum Master – 以 scrum 的利益为核心利益 – 组织 scrum ，保证 scrum 顺利进行 ● 产物负责人 – 以客户利益为核心 – 决定产物需要那些特性 – 决定开发优先级别 – 提供需求细节
- 6. 过程
- 7. 过程一角
- 8. 具体过程 ● Scrum 开始前 – 准备 Backlog ， 写下简短的故事 – 复杂度估计 (1, 2, 3, 5, 8, 13, 21 ...) – 故事价值估计 – 故事优先级排序 – 故事时间估计 – 故事拆分为任务
- 9. 具体过程 ● Scrum 开始前 – 准备 Backlog ， 写下简短的故事 – 故事价值估计 – 复杂度估计 (1, 2, 3, 5, 8, 13, 21 ...) – 故事优先级排序 – 故事时间估计
- 10. 准备 Sprint Backlog ● 必要的字段 – ID – 名称 – 重要程度 – 初始估计 Story point
- 11. 准备 Sprint Backlog ● 垂直方向划分
- 12. 准备 Sprint Backlog ● 用户的角度去描述 – 用户总是试图帮助我 们来理解他们想要的 – 他们的方法常常是错 误的 ● 想要的：挂画 ● 解释的：需要锤子和
- 13. 准备 Sprint Backlog ● 专业导向 – 专业团队应该为客户 提供专业化的咨询
- 14. 具体过程 ● Scrum 开始前 – 准备 Backlog ， 写下简短的故事 – 故事重要性估计 – 复杂度估计 (1, 2, 3, 5, 8, 13, 21 ...) – 故事优先级排序 – 故事时间估计 – 故事拆分为任务
- 15. 故事重要估计 ● 标准 – 对用户的价值 ● 评分 – 0 – 100 – 高 中 低
- 16. 具体过程 ● Scrum 开始前 – 准备 Backlog ， 写下简短的故事 – 故事价值估计 – 复杂度估计 (1, 2, 3, 5, 8, 13, 21 ...) – 故事优先级排序 – 故事时间估计 – 故事拆分为任务
- 17. 计划扑克
- 18. 计划扑克
- 19. 具体过程 ● Scrum 开始前 – 准备 Backlog ， 写下简短的故事 – 复杂度估计 (1, 2, 3, 5, 8, 13, 21 ...) – 故事价值估计 – 故事优先级排序 – 故事时间估计 –
- 20. 产物负责人的权利
- 21. 重要性复杂性的平衡 ● 资源是有限的 ● 欲望是无穷的 ● 代价是不同的
- 22. 具体过程 ● Scrum 开始前 – 准备 Backlog ， 写下简短的故事 – 复杂度估计 (1, 2, 3, 5, 8, 13, 21 ...) – 故事价值估计 – 故事优先级排序 – 故事时间估计 – 故事拆分为任务
- 23. 实际时间 ● 60% 完美人天 – 休假 – 生病 – 纯技术类工作 – Bugfix
- 24. 具体过程 ● Scrum 开始前 – 准备 Backlog ， 写下简短的故事 – 复杂度估计 (1, 2, 3, 5, 8, 13, 21 ...) – 故事价值估计 – 故事优先级排序 – 故事时间估计 – 故事拆分为任务
- 25. 拆分到可以控制的范围 ● 我们天生没法处理复杂的事情 – 难以估计需要的资源 – 难以测试 – 难以设计 ● 看似简单的事情，往往背后有复杂的细节
- 26. 把大象放进冰箱 ● 简版 – 打开冰箱 – 把大象放进去 ● 真实世界 – 什么样的大象
- 27. 越狱 ● 简版 – 把哥哥搞出来 ● 真实世界 – 如何把自己搞进去 – 怎样对付狱警
- 28. 具体过程 ● Scrum 中 – 每日会议 ● 15 分钟 ● 三个问题： 昨天做了什么，今天要做什么，有什么问题 ● 项目透明， 每个人都知道项目的进度，其他人都在做什 么 – DoD
- 29. 每日会议 ● 昨天做了什么 ● 今天要做什么 ● 有什么问题妨碍了我的开发
- 30. 每日会议 ● 15 分钟 ● 所有人都到 ● 交流进度 ● 了解当前问题 ● 任务向右移动
- 31. DoD ● 如何定义做好了 – 单元测试 – 接收测试 – 文档 – 代码规范
- 32. 具体过程 ● sprint 后 – 开发成果演示 ● 邀请客户和有关的人员参加 ● 接受他们的反馈 – 总结优缺点 ● 有哪些妨碍了这个 sprint 的进展 ● velocity 的估计误差调整
- 33. Git 在 Scrum 中的应用 ● 每个故事一个分支 – 建立本地分支 – Push 到 remote – 本地开发 + push ● 一个故事结束后该分支 merge 到开发主分支 – 集成测试
- 34. Scrum 的军规 ● 1/0 – 一个故事只有两种状态：完成 和 未完成 – DoD 如何定义完成 – 只有完全实现的故事才会发布 ● Sprint 中需求稳定 – 产物负责人提供故事的细节但不做修改 – 不添加新的故事
- 35. Scrum 的道
- 36. 一个整体团队
- 37. 客户价值为中心 ● 不是计划中心 ● 以客户价值为中心
- 38. 灵活应对变化 ● 唯一不变的就是变化本身 ● 快速应对变化才是王道 ● 重构而不是不过度设计
- 39. 问题？
- 40. 谢谢！
Editor's Notes
- #2: 感谢末日前一天还能来听 感谢老刘的安排
- #9: Story As as user I want to input my address. High level use case from users point 用户需要的what， 我们提供how 专业的指导而不是简单的实现 估计有大家一同做，由于每个人能力不同，估计会有不同，考虑点也有不同，讨论之后确定一个值 完成的难度会影响优先级别，一个比较有用但是非常难 以实现的，会排在一个没它那么有用，但是很容易实现 的后面 时间的估计是粗略的估计，在开始的几个sprint里这个估计值和实际的会有较大的差异 task 一两天可以完成大小 .
- #10: Story As as user I want to input my address. High level use case from users point 用户需要的 what ， 我们提供 how 专业的指导而不是简单的实现 估计有大家一同做，由于每个人能力不同，估计会有不同，考虑点也有不同，讨论之后确定一个值 完成的难度会影响优先级别，一个比较有用但是非常难 以实现的，会排在一个没它那么有用，但是很容易实现 的后面 时间的估计是粗略的估计，在开始的几个 sprint 里这个估计值和实际的会有较大的差异 task 一两天可以完成大小 .
- #15: Story As as user I want to input my address. High level use case from users point 用户需要的 what ， 我们提供 how 专业的指导而不是简单的实现 估计有大家一同做，由于每个人能力不同，估计会有不同，考虑点也有不同，讨论之后确定一个值 完成的难度会影响优先级别，一个比较有用但是非常难 以实现的，会排在一个没它那么有用，但是很容易实现 的后面 时间的估计是粗略的估计，在开始的几个 sprint 里这个估计值和实际的会有较大的差异 task 一两天可以完成大小 .
- #17: Story As as user I want to input my address. High level use case from users point 用户需要的what， 我们提供how 专业的指导而不是简单的实现 估计有大家一同做，由于每个人能力不同，估计会有不同，考虑点也有不同，讨论之后确定一个值 完成的难度会影响优先级别，一个比较有用但是非常难 以实现的，会排在一个没它那么有用，但是很容易实现 的后面 时间的估计是粗略的估计，在开始的几个sprint里这个估计值和实际的会有较大的差异 task 一两天可以完成大小 .
- #20: Story As as user I want to input my address. High level use case from users point 用户需要的what， 我们提供how 专业的指导而不是简单的实现 估计有大家一同做，由于每个人能力不同，估计会有不同，考虑点也有不同，讨论之后确定一个值 完成的难度会影响优先级别，一个比较有用但是非常难 以实现的，会排在一个没它那么有用，但是很容易实现 的后面 时间的估计是粗略的估计，在开始的几个sprint里这个估计值和实际的会有较大的差异 task 一两天可以完成大小 .
- #23: Story As as user I want to input my address. High level use case from users point 用户需要的what， 我们提供how 专业的指导而不是简单的实现 估计有大家一同做，由于每个人能力不同，估计会有不同，考虑点也有不同，讨论之后确定一个值 完成的难度会影响优先级别，一个比较有用但是非常难 以实现的，会排在一个没它那么有用，但是很容易实现 的后面 时间的估计是粗略的估计，在开始的几个sprint里这个估计值和实际的会有较大的差异 task 一两天可以完成大小 .
- #25: Story As as user I want to input my address. High level use case from users point 用户需要的what， 我们提供how 专业的指导而不是简单的实现 估计有大家一同做，由于每个人能力不同，估计会有不同，考虑点也有不同，讨论之后确定一个值 完成的难度会影响优先级别，一个比较有用但是非常难 以实现的，会排在一个没它那么有用，但是很容易实现 的后面 时间的估计是粗略的估计，在开始的几个sprint里这个估计值和实际的会有较大的差异 task 一两天可以完成大小 .
- #29: 把状态改变的蝉迟辞谤测移动位置
- #30: 把状态改变的蝉迟辞谤测移动位置
- #31: 把状态改变的蝉迟辞谤测移动位置
- #33: 估计误差的原因 Sprint未能完成的原因 好的地方/不好的地方
- #35: 保证在蝉辫谤颈苍迟期间需求需要一个稳定的状态