敏捷管理之Scrum扫盲 – 10分钟读懂Scrum与敏捷软件开发入门

江湖上软件开发有两个大门派，第一个门派历史和软件一样久，心法是以流程为主轴，正式名名称为瀑布式开发（Waterfall），最具代表的武功就是 CMMI。另一个门派在1990年代异军突起，心法是以认为主轴，正式名称为敏捷开发（Agile），最知名的武功是 Scrum。（注：Scrum 的原始意思是橄榄球的爭球动作，在软件界沒有翻译成中文，都是直接叫 Scrum）

 两个门派最大的不同在中心思想，用中国的哲学流派来比喻，瀑布式开发是法家，法为主，人为辅，强调「不别亲疏，不殊贵贱，一断于法」。只要规则定下去，照著做就会有好产品，铁打的营盘流水的官，人的因素要尽可能排除以利产出的一致性。

而敏捷开发是道家，人为主，法为辅，主张「道法自然」。道是没有一定的形式，要观察目前的情境，考量人的天性，因势利导，以求功成事遂，百姓皆谓我自然。

总之敏捷软件开发门派更注重在人的层面，请求的是从快速从经验中学习反应和团队的自我管理。

而 Scrum 这套武功之所以比起其他的武功如看板、极限开发（XP）更有名，是因为一般认为比较容易导入或入门。因为 Scrum 里角色和活动定义明确，又不提技术细节，让不懂技术的老板也可以听懂（技术活也是很重要滴，请参考XP）。 很多团队导入 Scrum 就落入了做敏捷，而不是变敏捷的陷阱，如果组织已经在跑敏捷，可以看看这清单确认一下是真敏捷，还是假敏捷 XD。

如果还没导入，恭喜你，可以先考虑 Scrum 会带你上天堂还是地狱，并可参考 Scrum 不包生导入指南，还有破除敏捷=快的迷信。

Scrum 角色

Scrum 只有三种角色，至于其他角色如部门主管在 Scrum 框架外装作看不到不讨论。所有成员都要保持敏捷的精神和态度。

1. Development Team（Dev Team，开发团队）：可以独立完成任务的特种部队，人数5-9人（7+/-2）。大招是我決定该怎么做（How），武器是自我管理和持续改善的能力。每个人都有自己的特长，但依任务需求自行安排工作内容。类似射雕英雄传里全真七子所部的天罡北斗阵，如任一人受敌时，左右会来相救。
2. Product Owner（PO，产品负责人）：：产品的守护者。大招是要做什么我说了算（What），武器是敏锐的市场嗅觉和摆平厉害干系人。如同射雕英雄传里北极星位对天罡北斗阵的影响，当郭靖站到了北极星位就可以驱动全真七子。PO 要决定产品的规则和为产品的成败负责，可以參考一些 PO 常常绊倒的地方。
3. ScrumMaster（SM，无中文名称）：Scrum 功夫的传道者，唯一的大招是影响力，武器是异于常人的信心与耐心。有人觉的他是 Team Lead 或是 PM 的角色。但其实他没人事权不能管人，沒财务权不能编预算，更可怜的是不能决定产品的走向，是个令人摧心的角色。最常见的安排是 PM 直接转 Scrum Master，或是主管自己跳下來兼 Scrum Master，会把 Scrum Master绊倒的地方也不少。

以上三者又统称 Scrum Team 或 Team。

Scrum 物件

Scrum 中常会提到的物件与中文名称。

1. Item（物件）：又称 Story，是 PO 定义的产品产出。Item 大小要讲究，要可以让团队在一般的速率下，可以完成3-5个。太多太繁杂，太少万一没做完就感觉整个 Sprint 一事无成，对团队信心是个打击。
2. Task（工作）：是 Dev Team 针对 Item（不是 PO 也不是 SM 哦），列出完成 Item 所需的工作。工作分配是开发团队自己安排。
3. Product Backlog（产品代办清单）：由 PO 负责整理的产品愿景图，以 Item 为单位，施工顺序由上而下。
4. Sprint Backlog（迭代代办清单）：Dev Team 向 PO 承诺这个 Sprint 会尽力完成的 Item List。以 Task为单位。
5. Potentially Shippable Product Increment（潜在可交付产品增量）：开发团队的产出，简单的说就是 PO 数要上线就可以马上上线的东西才算数。
6. Burndown Chart（燃尽图）：有点类似怪物的血条，看看还剩多少血怪（Sprint Backlog）才死。以 Task 大小为单位。

Scrum活动

Scrum 活动每一个都是有他的目的和时间限制（Time Boxed）。

1. Sprint（迭代/冲刺）：当团队決定要做哪些 Item 后，就著手去冲。Sprint 长度定义在1~4周，但实际上不要多过2周。而且 Sprint 长度应该要保持稳定尽可能不变。这样才容易让团队掌握节奏，也容易预估和比较 Sprint 內的工作量。大原则是 Sprint 內的 Sprint Backlog 不改变（有原则就有例外）。
2. Daily Scrum（每日站立会议）：每天10-15分钟不能超时，目的是让团队咨询同步。一定要站着罚站为了让大家长话短说。
3. Sprint Planning（计划会）：Sprint 开始时，讨论一下这个Sprint 团队可以交付哪些Item。Item 优先顺序 PO 决定，要选多少 Item 由 Dev Team 决定。
4. Product Backlog Refinement / PBR（产品代办清单精炼会议）：PO 跟 Team 一起讨论近期內会开始施工的 Item，主要是从商业和使用者角度切入，尽可能不触及技术细节。
5. Sprint Review（演示会）：Sprint 结束时针对产品的会议，PO邀请利害关系人对产出给意见，是要可用的软件才算产出。不准备Powerpoint或其他简报，单纯就软件操作取得回馈。
6. Sprint Retrospective / Sprint Retro（回顾会）：Sprint Review 后，Scrum Team 成员（Dev Team 或包含 PO），针对这个 Sprint 团队的工作模式讨论改善，并定出下个 Sprint 改善事项。为了创造一个安全的环境，原则上只有团队成员才能参加。

Scrum 是个易学难精的架构，导入一个月就似模似样入门了，但背后的精神如团队自我组织、持续改善要数个月到数年才能见效。持续学习是必要的。

敏捷管理系列内容：点击查看列表