- Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum在英语里是橄榄球运动中争球的意思，强调迅速，自我管理和可适应性。 虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。
- 产品经理
- 项目经理
- 开发人员
- 测试人员
- 需求不明确？
- 需求变得太快？
- 开发速度赶不上提需求的速度？
- 实现功能需要太长时间？
- 进度停滞不前？
- 修BUG多于开发新功能？
- 团队缺乏沟通？
- 不清楚项目进度？
- 不清楚同伴进度？
- 分工不清？
- 适应变化
- 快速迭代
- 沟通高效
- 执行高效
- 目的明确
- 快速迭代(周期一般为2~4个星期)
- 适应变化
- 量化开发
- 估算需求的投入量
- 估算团队生产率
- 自我管理
- 进度跟踪
- 每一个人知道谁负责什么，以及什么时候完成。
- 透明直观
- 所有参与者都了解并认同Scrum。
- 每位参与者都在项目中积极主动，自我管理。
- 不会有人同时参与两个项目。
- Sprint
- Backlog
- 看板 or 故事板
- 故事
- Scrum扑克
- 燃烬图
- 自我组织，自我管理
- 沟通至上
- 注重实践
跨职能/多角色的小团队，人数一般为3~9人。
- Scrum Master：是Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队移除实施中的障碍。通常由项目经理扮演。
- 产品负责人：确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间等等。通常由产品经理扮演。
- 开发
- 设计
- 测试
backlog从根本上来说，就是一个由需求或特性组成的列表，并按重要性的级别进行了排序。 列表每一行成为故事(story)，也可称为一个backlog条目。
制定产品功能需求等。
- 产品负责人（主要负责Product Backlog的编写）
- 其他人（提意见）（并非指项目团队内的其他人）
- 只存在一个Product Backlog。
- 只存在一个产品负责人。
- 让故事停留在业务层次上。也就是说，每个backlog条目应该着眼于业务功能，而非具体技术实现。
- 产品负责人之外的人也可以向 Product Backlog 中添加故事，但是他们不能说这个故事有多重要，这是产品负责人独有的权利。他们也不能添加时间估算，这是开发团队独有的权利。
- 产品负责人应当理解每个故事的含义(通常故事都是由他来编写的，但是有的时候其他人也会添加一些请求，产品负责人对它们划分先后次序)。他不需要知道每个故事具体是如何实现的，但必须知道为什么这个故事会放在这里。
- 产品负责人只需要关注业务目标，开发团队指出如何解决问题。
故事一般包含以下几个内容/字段：
- ID：即统一标识符，自增长的数字，以供索引。
- Name：简短的描述性的名称。
- Importance：重要程度。数值越高越重要。但这只是相对的概念，比如对于重要程度为1的故事来说，2和100的重要程度是一样的。目的只是为了排序。
- Initial estimate：团队的初步估算，与其他功能相比，完成该故事所需的工作量。单位以point计数，相当于投入的人/月或人/天。估值不需要保证绝对无误。(Sprint计划会议中填写)
- Demo：大略描述这个故事应该如何在 Sprint演示会议 上进行示范，本质就是一个简单的测试。(Sprint计划会议中填写)
- Notes：注解。相关信息、解释说明和对其它资料的引用等等。一般都非常简短。(也可在Sprint计划会议中填写)
还可以添加其他内容/字段，如：
- Category：故事属于什么分类下。
- Bug tracking ID：如果你有个bug跟踪系统，那么了解一下故事与bug之间的直接联系就会对你很有帮助。
因环境而定。
- 已排序的Product Backlog。
- 为了让团队获得足够的信息，能够在几个星期内不受干扰地工作。
- 确立本次Sprint的完成目标，指明奋斗方向。
- 确立本次Sprint的参与成员名单。（每次Sprint可以人员不一样，但是Sprint进行中时最好不要有人员调动）
- 确立Sprint 演示日期，即确定此次Sprint时间长度。（一般为2~4周，具体可根据团队生产率计算）
- 从Product Backlog中梳理出Sprint Backlog。
- 确立每日站立会议的时间及地点。（非常重要）
- 团队成员名单
- Sprint 目标
- Sprint Backlog
- Sprint 演示日期
- 每日站立会议的时间及地点
- 项目团队所有人（默认包括产品负责人）
时间较长。一般为2~5个小时。
Sprint 计划会议:13:00 – 17:00 (每小时休息 10 分钟)
按照参考时间表，具体时间划分与讨论内容如下：
13:00 – 13:30：产品负责人对 sprint 目标进行总体介绍,概括产品 backlog。定下演示的时间地点。
13:30 – 15:00：团队估算时间,在必要的情况下拆分Product Backlog里的条目。评估通过Scrum扑克来进行。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的 backlog 条目都要填写“如何演示”。
15:10 – 15:30：团队选择要放入 Sprint Backlog 中的故事。计算生产率,用作核查工作安排的基础。
15:30 – 15:40：为每日站立会议安排固定的时间地点(如果和上次不同的话)。
15:40 – 17:00：将故事拆分成具体的任务，加到Sprint Backlog中，并关联对应的故事。
这个日程绝不是强制执行的。根据会议进程的需要,可以对各个阶段的子进程时间安排进行调整。
- 促进交流
- 明确/解决问题
- 团队成员
固定在短时间，如半小时或十五分钟以内。
- 昨天完成了哪些工作？
- 今天准备做什么？
- 当前遇到了什么问题/阻碍？
- 让其他人可以了解你的团队在做些什么。
- 团队的成果得到认可。提高团队积极性。
- 演示可以吸引相关干系人的注意,并得到重要反馈。
- 演示迫使团队真正得完成工作。
- 团队成员
- 用户
- 其他可能对项目感兴趣的人
演示时间很短，十几分钟。交流时间可长。
每一个Sprint完成后，都会举行一次Sprint回顾会议。
- 回顾过去，展望将来。
- 去糟粕，取精华。
- 促进团队交流。
- 会议记录
- 用于下次Sprint的建议
- 团队所有成员。
根据要讨论的内容范围,设定时间为1~4个小时。
- Scrum Master向大家展示Sprint Backlog,在团队的帮助下对Sprint做总结。包括重要事件和决策等。
- 轮流发言。每个人都有机会在不被人打断的情况下讲出自己的想法,他认为什么是好的,哪些可以做的更好,哪些需要在下个 sprint 中改变。
- 我们对预估生产率和实际生产率进行比较。如果差异比较大的话,我们会分析原因。
- 快结束的时候,Scrum Master 对具体建议进行总结,得出下个Sprint需要改进的地方。
这又是一个很长的话题……
- 不能恪守教条，实践才是硬道理。
- 团队和项目场景的不同，决定了Scrum实施方式的不同。所以没有通用的最佳Scrum实践，只有多多实践，走出适用自己的道路。
- Scrum需要每个人的积极配合参与，否则效率还不如传统迭代开发。
- 敏捷并不只是“快速开发，快速交付”，更重要的是“快速响应，快速调整”。
- Trello
- Teambition
《硝烟中的Scrum和XP - 我们如何实施Scrum》，作者: Henrik Kniberg，出版社: infoQ
Mark.