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