原创

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

温馨提示:
本文最后更新于 2023年02月16日,已超过 667 天没有更新。若文章内的图片失效(无法正常加载),请留言反馈或直接联系我

 

江湖上软件开发有两个大门派,第一个门派历史和软件一样久,心法是以流程为主轴,正式名名称为瀑布式开发(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 是个易学难精的架构,导入一个月就似模似样入门了,但背后的精神如团队自我组织、持续改善要数个月到数年才能见效。持续学习是必要的。

 

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

正文到此结束
本文目录