标签：bsp 调整 并且 紧急 业务 主题 删除 都对 统一
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之间进行修整
标签：bsp 调整 并且 紧急 业务 主题 删除 都对 统一
原文地址：http://www.cnblogs.com/cutepig/p/7046012.html
