scrum学习
产品backlog
让产品backlog停留在业务层次上。
产品负责人编写
包括这样一些字段
ID——统一标识符
Name（名称）——简短的、描述性的故事
Importance（重要性）
Initial estimate（初始估算） 由开发团队评估
How to demo（如何做演示）
Notes（注解）
准备sprint计划
sprint 计划会议是Scrum中最重要的活动
在sprint计划会议之前，要确保产品backlog的井然有序。
产品backlog必须存在
只能有一个产品backlog和一个产品负责人（对于一个产品而言）。
所有重要的backlog条目都已经根据重要性被评过分，不同的重要程度对应不同的分数
Sprint计划会议非常关键，应该算是Scrum中最重要的活动。举办Sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心
Sprint计划会议会产生一些实实在在的成果
sprint目标。
.. 团队成员名单（以及他们的投入程度，如果不是100%的话）。
.. sprint backlog（即sprint中包括的故事列表）。
.. 确定好sprint演示日期。
.. 确定好时间地点，供举行每日scrum会议。
产品负责人必须参加
范围（scope）和重要性（importance）由产品负责人设置。估算（estimate）由团队设置
会议内容
会议启动以后，产品负责人一般会先概括一下希望在这个sprint中达成的目标，还有他认为最重要的故事。
接下来，团队从最重要的故事开始逐一讨论每个故事，一一估算时间。在这个过程中，他们会针对范围提出些重要问题：“‘删除用户’这个故事，需不需要遍历这个用户所有尚未执行的事务，把它们统统取消？”有时答复会让他们感到惊讶，促使他们调整估算。
学会按照时间盒安排工作
sprint应该多长才好
时间短就好。公司会因此而变得“敏捷”
但是，时间长的sprint也不错
最喜欢的长度：三个星期
sprint目标
你可以在一个wiki页面（或其他东西）上列出所有团队的sprint目标，然后把它们放到一个显著位置上，保证公司所有人（不只是顶级管理层）知道公司在干什么，目的又是什么
我们为何使用索引卡
故事拆分成任务
时间估算
我们不会让任务拆分出现在产品backlog中
定义“完成”
估算是一项团队活动——通常每个成员都会参与所有故事的估算
要求每个人都对故事做估算
注意——我们在实践TDD（测试驱动开发），所以几乎每个故事的第一个任务都是“编写一个失败的测试”，而最后一个任务是“重构”
Bug跟踪系统 vs. 产品 backlog
让别人了解我们的sprint
我们怎样编写sprint backlog
应该在sprint 计划会议之后，第一次每日例会之前完成
贴在墙上的任务板
任务板警示标记
嘿，该怎样进行跟踪呢？
布置团队房间
让产品负责人无路可走
》每日例会
一般我们都是开站立会议
要尽力让整个团队参与到保持sprint backlog及时更新的工作中来
我们执行这个的难点
老板不了解，并且未必支持
我们的紧急任务太多，很多人经常有突发的support工作
开发工作很难定量化，经常会有新的东西需要补充
很难使大家全力以赴的做开发，因为经常有突发事件，比如autotest停下来了，6楼出问题了，amc出问题了，客户出问题了
主动性，不是所有员工都那么主动
有同事会有支持其他项目，容易推脱到其他项目上
Sprint演示
为什么我们坚持所有的sprint都结束于演示
Sprint演示检查列表
处理“无法演示”的工作
回顾
潜在的主题都是一样的：“我们怎样才能在下个sprint中做的更好
。把sprint回顾结果贴在团队房间的墙上
sprints之间进行修整