scrum学习

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之间进行修整