Sprint Planning
会议名称
冲刺计划会议 (Sprint Planning Meeting)
会议举行时间
冲刺周期开始当天的早上 (可以取代当日站会)
会议时间
每周工作量伴随 1 小时的冲刺计划会议, 如果团队每两周冲刺一次, 冲刺计划会议就应该是 2 小时长
会议参与人
Product Owner,Scrum Master, 全体项目成员, 请 Master 在合适时间主动发出会议邀请
目标
让开发团队了解开发任务, 分析与预估用户故事难易度, 并决定接下来冲刺要完成的工作项
Scrum Master 分享桌面, 将上次冲刺回顾会议制定出来的改善项目与整个团队过一遍, 确保团队在这一次冲刺当中改进了上次列出来的改善项
Product Owner 分享桌面, 从 Backlog 中第一个任务开始跟团队简易介绍任务内容, 介绍完毕后留 60 秒的时间让团队开放讨论为了实现这个用户故事需要设立多少子任务, 然后给 10 秒钟的时间让团队成员给出故事点预估 (需包含 Agile Poker 教程)
在两个小时内尽可能多的预估任务
Scrum Master 分享桌面, 设置新的 Sprint, 根据团队的平均速度 (Velocity), 将等同 120% 团队速度的任务从最高优先级, 按照一定比例, 在用户故事都已完善并且有验收条件的前提之下, 开始拖拉到冲刺 Backlog 当中, 并用一句话简单描述冲刺目标, 确保团队成员都认同目标后, 开始冲刺.
120% 原则
例如团队的平均速度是 60 点, 我们会在冲刺中安排 72 点的工作量, 这是为了避免团队提早做完冲刺中的任务而发生无事可做的窘境.
任务分配 Backlog 中的任务一般可以分成三种类别,
技术债 (Technical Debt): 为了加速开发流程, 工程师往往会在应采取最佳方案时做了妥协, 采用了短期内可以加速开发流程的作法, 但长远来看会成为迟早要填的坑, 这种东西就叫技术债. 常见的技术债诸如 "缺乏文档","缺乏测试方案","没有按照标准流程做事情","因为项目时程紧张所以很多没做但应该做的事情","需求本身没有考虑技术实现问题而挖的坑" 等等, 这都是团队为了填坑自己给自己建的任务, 因为一开始方便, 后来迟早要还的观念, 才称之为 "债".
故障 (Bugs): 由终端用户或是 QA 工程师在测试过程当中发现的 Bug, 会以故障的形式记录在 Backlog 中, 等待开发团队安排时间完成的任务.
新功能 (New Features): 由 Product Owner 直接安插进 Product Backlog 的用户故事, 一般都是新功能需求, 这些新功能需求直接对客户输出了价值, 是三种任务当中客户最想要的.
一般建议在每一次的冲刺当中, 我们应该安排 7 成任务实现新功能, 3 成任务修复 Bug 与填坑.
来源: http://www.jianshu.com/p/857ab724347c