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

Powered by Jekyll and Theme by solid

本站总访问量