项目管理与开发
敏捷开发入门看板｜理解 Scrum 的三个角色·五个事件·三个工件，跑通第一个冲刺
入门｜白板 2 页·任务看板 5 列（4 个父任务、12 个子任务）
入门：不使用专业术语，只要按照白板上的提问和填写示例逐一回答，就能成形。
刚开始学习敏捷开发的人，以及第一次加入 Scrum 团队的人，用这套面向新手的敏捷开发入门模板，理解三个角色、五个事件、三个工件，把第一个冲刺完整地跑一遍。白板上依次是敏捷开发的思路、两周冲刺的五个步骤、三个角色的三个框、三个工件的三个框、五个事件速查表、用 MoSCoW 挑出这次要做的部分（四列），以及 KPT 回顾。任务看板分为产品待办列表、冲刺待办列表、开发中、待评审、已完成五列，认识术语、组织第一个冲刺、开好每日站会、评审与回顾这四个父任务和十二个子任务全部处于未开始。不懂 Scrum 的做法就直接参加，很容易被术语甩在后面；按这块看板从上往下走一遍并跑完一个冲刺，连每日站会上该说什么都会变清楚。这也是敏捷开发怎么做、Scrum 怎么入门的一份具体答案。与已经在运转的团队所用的两周冲刺运营看板不同，这里的主角是术语的理解和第一次的完整体验。
免费注册后，即可从模板市场复制并使用此模板
白板预览
以文字形式阅读白板内容
敏捷开发 入门看板
使用方法：① 读懂敏捷开发的想法 → ② 走一遍两周冲刺的流程 → ③ 确认三个角色和三个工件（看板③〜⑧） → ④ 定下五个事件的时间，并用 MoSCoW 分出这次要做和先不做的（看板⑨⑩） → ⑤ 用 KPT 复盘（看板⑪）
① 什么是敏捷开发（用短周期做出来、给人看、再改）
- 一句话说清 用两周左右的短周期做出能跑的东西，给人看， 收到意见再改。不断重复这个过程。
- 和以前做法的不同 例：不是把所有需求都定完再动手， 而是先定好先做什么，从上往下一点一点做。顺序中途可以改。
- 好在哪里 例：每两周就能看到实物，方向偏了两周内就能发现。 返工只损失一轮。
② 两周冲刺的流程（每日站会每天重复）
- 1. 冲刺规划会议 冲刺的第一天。用⑩的 MoSCoW 挑出两周里要做的东西，做出冲刺待办列表。最长四小时。例：从产品待办列表上面挑三件、合计 13 个故事点。
- 2. 开发（两周） 只做选中的部分。即使来了新的需求，原则上也不放进这个冲刺。例：只推进登录改进的三件（13 点）。
- 3. 每日站会（每天十五分钟） 在第二步的两周里，每天固定时刻十五分钟。各自说昨天做了什么、今天做什么、卡在哪里。与开发并行，每天重复。例：每天早上十点站着开。
- 4. 冲刺评审 最后一天。把能跑的东西给相关人看并收集意见。最长两小时。给人看画面，不是给人看文档。例：实际操作新的登录页面演示。
- 5. 冲刺回顾 评审之后。看的不是做出来的东西，而是做事的方式本身。最长一个半小时。用⑪的 KPT 定下一个动作。例：把“插队需求先由 Scrum Master 接下”作为下次的 Try。
③ 产品负责人
- 决定先做什么的人
- 对产品待办列表的排序负责
- 例：定下“这次先做登录改进”
- 做什么内容拿不准时，就找这个人商量
④ Scrum Master
- 看流程有没有被遵守的人
- 排除卡点，守住每个事件的时间
- 例：先接下插队的需求，再去做协调
- 不是发号施令的角色，也不一定是管理者
⑤ 开发者
- 实际动手做的人，包含设计、实现、测试
- 两周能做多少，由开发者自己估算
- 例：三个人分担冲刺待办列表
- “开发者”不是职位名，而是角色的名字
⑥ 产品待办列表
- 把想做的全部按先做的顺序排成的一张清单
- 越靠上越先做。顺序由产品负责人决定
- 例：登录改进／通知设置／管理后台搜索
- 这张清单没有终点。中途增加也没关系
⑦ 冲刺待办列表
- 只把这两周决定要做的部分挪过来
- 在规划会议上挑选，中途不再添加
- 例：登录改进的三件（合计 13 点）
- 谁负责哪一件，看这里也能知道
⑧ 增量
- 两周结束时做出来的、能跑的东西
- 不满足完成的定义（＝团队事先约好做到哪一步算完成的条件）的东西不算在内
- 例：测试和验证都做完的登录改进
- 冲刺评审上给人看的就是它
⑨ 五个事件速查表
| 做什么 | 谁参加 | 时间参考 | |
|---|---|---|---|
| 冲刺 | 冲刺 装下其余四个事件的、为期两周的箱子。中途不延长期限。 | Scrum 团队全员 （产品负责人·Scrum Master·开发者） | 两周 固定在一个月以内 |
| 规划会议 | 冲刺规划会议 挑出两周里要做什么，做出冲刺待办列表。 | Scrum 团队全员 | 最长四小时 第一天上午 |
| 每日站会 | 每日站会 说昨天做了什么、今天做什么、卡在哪里。 | 开发者 （另外两个角色是听众） | 十五分钟 每天同一时刻、同一地点 |
| 评审 | 冲刺评审 展示能跑的东西并收集意见。看画面，不看文档。 | Scrum 团队＋相关人 （需求方·使用者） | 最长两小时 最后一天 |
| 回顾 | 冲刺回顾 看的不是做出来的东西，而是做事的方式本身。 | Scrum 团队全员 | 最长一个半小时 评审之后 |
⑩ 挑出这两周要做的部分（MoSCoW）
Must（必须）
- 只放没有它冲刺目标就达不成的东西。 例：修复重置密码邮件收不到的缺陷
Should（应该做）
- 重要，但这次去掉也能达成目标的东西。 例：改掉看不懂的报错文案
Could（可以做）
- 放进冲刺，但时间不够时最先去掉的东西。这次没有也能达成目标。 例：更换登录页面的标志图
Won't（这次不做）
- 决定不做的东西。不要删掉，留在产品待办列表（看板⑥）里。 例：通知设置和管理后台搜索放到下一个冲刺以后
⑪ 第一个冲刺的回顾（KPT）
Keep（继续保持）
- 自从把每日站会固定在每天早上十点，所有人都能到齐了
- 卡点当场说出来，半天就解开了
Problem（没做到的）
- 选的 13 个故事点里，有 5 点两周没做完
- 中途插进来的需求没能拒绝，冲刺待办列表越来越鼓
Try（下次要试的）
- 下个冲刺从 8 个故事点开始，有余力再加
- 插队的需求先由 Scrum Master 接下
任务看板内容
产品待办列表 16 项
认识 Scrum 的术语
最先绊住人的是术语。按角色、事件、工件三束来记，开会时就不会跟丢。
写出三个角色
用真实姓名写出产品负责人、Scrum Master、开发者分别是谁。有人兼任就写明兼任。
排出五个事件
把冲刺／冲刺规划会议／每日站会／冲刺评审／冲刺回顾这五个按时间顺序排好，并填上日期和时刻。
确认三个工件
确认产品待办列表、冲刺待办列表、增量分别放在哪里、由谁维护。
组织第一个冲刺
光背术语学不会。要把两周的框定下来，并且只挑出装得进这个框的量。
定好周期和星期
定下开始日、结束日，以及每个事件在星期几的几点。中途不延长期限。
把要做的放进首列
把想做的全部放进产品待办列表这一列，再按先做的顺序排好。顺序由产品负责人决定。
只选两周的量
从上往下，只把两周内做得完的量挪到冲刺待办列表。太多时先用看板⑩的 MoSCoW 定出 Won't（这次不做）并去掉。拿不准就少选一些。
开好每日站会
冲刺进行中每天的运作。不要开成进度汇报会，而是当场把卡点说出来、把堵住的地方疏通。
说昨天和今天
每人用一分钟说昨天做了什么、今天做什么。细的讨论放到站会之后单独谈。
当场说出卡点
卡住的事一定要说出口。解决由 Scrum Master 在站会之后接手推进。
用看板展示进度
把卡片移到开发中、待评审、已完成，让剩下多少一眼就能看见。
评审与回顾
两周的收尾。对做出来的东西的意见，和对做事方式的意见，要分开处理，这是 Scrum 的规矩。
展示能跑的东西
在冲刺评审上给相关人看的不是文档，而是实际能跑的画面，并收集意见。
意见回到待办列表
把收到的意见做成卡片放回产品待办列表这一列，作为下次排序的材料。
用 KPT 定一个 Try
在回顾上重新审视做事的方式，只定一个下个冲刺要试的 Try。
