scrum不能解决问题，解决问题靠开发团队自己

出色的团队最重要的是有良好素质的团队，这些素质包括进取心、责任心、良好的习惯、热情，其次才是技术、流程

scrum提供了一套实践方法，帮助软件团队养成良好的习惯

scrum原理 ：

---

1.目标驱动，在统一的软件交付目标下组织团队

2.依靠团队的智慧做项目评估、计划乃至设计、开发、测试（？）

3.抓住项目的最基本开发属性：周期+质量

周期用T表示，质量用B表示（bug数目量化），scrum有助于T*B 尽量小，

scrum的角色和职责

---

1.产品负责人(product owner)，定义开发目标、需要实现的features和优先级

2.scrum master，保证团队高效而不受打扰的工作，优化工作条件、过程

3.团队(team)，自组织的完成项目开发,使用一切可行手段保证进度和质量

外围有user,customer,Management

scrum过程：

---

前期：产品负责人整理业务需求，形成product backlog库

执行：以sprint为单位进行迭代完成sprint backlog，每日例会+issues，sprint结束时交付可运行的产品

后期：sprint完成后通过sprint回顾发现问题和改进点，制定下个sprint要引入的新的实践?

scrum的精髓：

---

以上过程也没什么特别的，和UP的迭代几乎一样。

精髓在于“检查并适应”，在三个角色、三种仪式（sprint计划、sprint回顾、每日例会）、三种制品（backlog、sprint backlog、燃尽图）的基础上，可以根据公司和项目情况，因地制宜的引入任何有利于缩短开发周期、提高产品质量的实践。

具体细节：

sprint前： 产品负责人收集需求，形成backlog，backlog以统一格式定义，重要的属性有：名称、重要性、估算时间、简单描述、如何演示等，详细的需求可以在其他需求文档中定义。产品负责人可以通过任何渠道、方式获取和确认需求。

sprint启动会议： 一个sprint周期为两周，一次sprint会议约一个下午，参与人员为3个角色都参加，scrum master主持会议。会议内容详细沟通产品负责人选定的重要性高的产品backlog细节，确保团队对需求的理解无误。团队根据需求理解将backlog拆分成任务，并给出每个backlog的估算时间，产品负责人和团队根据sprint内可用的人天和backlog的时间估算，选定需要排入本次sprint的backlog，scrum master和团队分派任务，制定sprint计划。

sprint中： 整理一面任务墙，将sprint内的backlog和任务按照未开始、进行中、已完成等状态进行归类（任务单位以小于等于1天为宜），同时展示sprint的燃尽图

scrum master每天早上固定时间组织团队的每日例会 （站立会议，控制时间为10-15分钟），确认每个成员前一天完成的工作、当天要进行的工作、工作中碰到的问题、并更新任务墙。任何需求变更都进行实时评估，超过规划人天的backlog视情况进行拆分或者推迟其他重要性低的backlog。任何完成的backlog都需要演示给产品负责人和QA后才能提交测试。

sprint后：

scrum master召集、组织sprint回顾会议。回顾会议以头脑风暴的方式review sprint过程和结果，发现和列举存在的问题，与会人员投票决定需要在下个sprint中解决1-3个问题，探讨解决方案，确定实践方式。

scrum精神

1.团队目标终于岗位职责

2.团队工作优于独立作战

3.高效沟通强于标准化的文档

4.高能动性、自组织的团队胜于角色划分清晰的流水线

5.务实的解决问题的方法好于经典理论

6.快速实践、快速反馈、持续优化

我们怎样编写产品Backlog

其他人也可以添加backlog条目，但重要性必须由产品负责人决定

迭代开发基本需求：

1：迭代要有固定时长（时间盒），不能超过六个星期。

2：在每一次迭代的结尾，代码都必须经过OA的测试，能够正常工作。

Nokia的Scrum标准：

1：Scrum团队必须要有产品负责任，而且团队都清楚这个人是谁。

2： 产品负责人必须要有产品Backlog，其中包括团队对他进行的估算。

3：团队必须要有燃尽图，而且要了解他们自己的生产率。

4：在一个Sprint中，外人不能干预团队的工作。

产品backlog 包括

backlog：需求、故事、特性组成的列表，按重要性排序，包含了客户想要的东西，用客户的术语加以排序

如何让产品backlog停留在业务层次上：

“给Events表添加索引” 应该 被 “提高后台系统中搜索事件的响应速度” 代替

添加索引只是一种解决方案，而且还未必能真正解决问题，回归到问题的原始出发点，这个可以用《你的灯亮着吗》来指导

backlog条目

标识符（ID），

名称（name），

重要性（Importance），这个故事有多重要 如：10或150 分数越高越重要

初始估算（Initial estimate）， 工作量估算（把3个人关在一起，大约需要4天时间）

如何做演示（How to demo）， （先这样做，然后那样做，就应该得到…的结果）

注释（Notes）

如：

格外的故事字段

Track（类别）

Components（组件）

Requestor（请求者）

我们怎样准备Springt计划

1：产品Backlog必须存在

2：只能有高一产品Backlog和一个产品负责人（对于一个产品而言）

3：所有重要的Backlog条目都已经根据重要性被评分过，不同的重要程度对应不同的分数。

注意：产品负责任之外的人也可以向产品Backlog中添加故事，但是他们不能说这个故事有多重要，这是产品负责任独有的权利，他们不能添加时间估算，这是开发团队独有的权利。

Springt计划会议

1：sprint目标

2：团队成员名单

3：sprint backlog 故事列表。

4：确定好sprint演示日期。

5：确定好时间地点，供举行每日scrum会议。

6：产品负责人必须参加？（

scope（范围）和重要性（importance）由产品负责人设置

estimate（估算）有团队设置 ）

7：用本能反应来估算工作时间（如： 兄弟在三天能完成故事A吗？）

8：sprint会议开始前需要定一个大致的时间计划，

9：每个sprint的目标要有一个概要的描述，

10：团队成员名单以及每个人的投入程度，

一个sprint包含多少故事由团队决定，而不是产品负责人或其他人，产品负责人只能通过修改故事范围、优先级来让团队选择哪些故事进入sprint，
定义完成：放入测试环境可以测试
时间估算：团队所有成员对故事进行估算，包括测试人员、开发人员，集合大家的估算确定最终确定
故事力求在1-5人天完成
故事拆分成任务，故事是可以交付的，任务是不可交付的
技术故事：需要完成但又是不可交付的东西，比如安装持续集成服务器，编写系统设计概览。
技术故事不由产品负责人管理，如果产品负责人可以对技术故事的优先级进行评估为什么都交给他呢？
bug: 如果开发完的功能被测试出bug，bug用jira进行了管理，也有优先级，建议将bug当做是sprint backlog的一部分，按照优先级进行评估是否进入sprint，

5.怎样让别人了解我们的sprint

我们要让整个公司了解我们在做些什么，这件事情至关重要。否则其他人就会发出抱怨，甚或对我们的工作做出臆断。

使用sprint信息页，将sprint列举出来，将sprint信息放到wiki上，邮件通知到家

6.怎样编写sprint backlog

一块白板，记录没开始的故事，今天开始的故事，这个sprint完成的故事。故事用白纸，任务用黄色贴纸，

燃尽图：横坐标是日期（去掉非工作日），竖坐标是工作量，story point，可以用人*时表示，

7.怎样布置团队房间

让团队坐在一起，

8.怎样进行每日例会

团队每个人自觉更新sprint backlog的状态，

9.怎样进行sprint演示

所有sprint都结束于演示

快速演示，演示我们实现了什么而不是我们怎么实现的，

10.怎样做sprint回顾

这是改进的最佳时机，

你不需要在回顾会议上得到什么好点子，在家中的浴盆里就能做得到！

轮流发言，scrum master最后总结

哪些做法可以保持，哪些做法可以改进，具体改进的想法，

11.sprints之间的休整片刻，

在启动新的 sprint 之前，每个人都应该至少度过一个不需要考虑 sprint 的夜晚。更好的是sprint结束在周五，这样就一个周末，最好结束在周四，周五大家搞一个LAB Day，（lab day也是要准备的。。）

12.如何制定发布计划，处理固定价格的合同

13.我们怎样组合使用 Scrum和 XP

Scrum 注重的是管理和组织实践，而XP 关注的是实际的编程实践。

CI：把这一切搭建起来需要大量工作，但付出的每一分钟都物有所值。

14.怎样做测试

把测试人员加入到Scrum团队中，测试人员就是验收先生，