项目管理蓝图第 1 部分：敏捷、Scrum、看板和精益的综合比较

概述

今天在软件开发中使用了许多方法。 您可能听说过诸如瀑布、敏捷、Scrum、看板、精益、极限编程等流行语。

在本文中，我将定义这些术语，讨论它们之间的关系以及它们之间的区别。 前面提到的许多流行语都是基于精益制造的概念，精益制造最初是基于丰田制造系统（TPS），所以我们将首先讨论这个。

精益方法论

精益和精益制造的起源

“精益”一词起源于制造业，它是用来描述基于丰田生产系统 (TPS) 的制造模型，该模型最初由丰田佐吉、丰田喜一郎和大野耐一开发，他们最初是受到亨利福特的启发。 TPS 专注于“彻底消除所有浪费”的理念，并在 1950 年代至 1970 年代彻底改变了制造业。 1990 年，当“改变世界的机器”出版时，TPS 被称为“精益制造”。

TPS 确定了丰田的三大类废物：

• Muda：翻译为“废物”。 丰田确定了七种类型的木达，后来又增加了八种。 这些是：
  • 缺陷：发现和修复缺陷所涉及的努力
  • 生产过剩：生产超过需求
  • 等待：等待下一个生产步骤、中断等。
  • 未使用的人才：能力未充分利用、培训不足等
  • 运输：加工过程中不需要的移动部件或产品
  • 库存：已完成的库存和在制品
  • 运动：移动或行走超出处理所需的范围

  • 过度加工：来自不良工具或产品设计

• Muri：翻译为“覆盖层”。 Muri 通常由 mura 产生，但也可以由 muda 产生。 Muri 表现为故障、旷工、安全问题等。
• Mura：翻译为“不均匀”。 Mura 可以在客户需求的波动、每个产品的处理时间或不同操作员的周期时间的变化中找到。 当 mura 不减少时，会增加 muri 的可能性，因此会增加 muda。 可以通过在供应链中创建开放性、更改产品设计以及为所有操作员创建标准工作来减少 Mura。

TPS 通过应用以下两个核心概念来消除浪费：

• Jidoka：松散地翻译为“带有人情味的自动化”，规定“质量必须在制造过程中建立！” 这意味着当出现问题时，设备会立即停止，从而防止产生不良产品。
• 准时制：只生产“需要的东西、需要的时间和需要的数量”。

随着 TPS 的发展，这些核心支柱和价值观建立在 Jidoka 和 JIT 的概念之上并变得根深蒂固：

• 连续的提高：
  • 挑战：形成长远的愿景，以勇气和创造力迎接挑战，实现梦想
  • Kaizen：持续改进业务运营，始终推动创新和进化，一次消除一个muda
  • 源地现佛：实践现地现佛，追根溯源，寻找事实做出正确决策，凝聚共识，以最快速度实现目标
• 尊重人：
  • 尊重：尊重他人，努力理解对方，承担责任，尽最大努力建立互信
  • 团队合作：激发个人和职业成长，分享发展机会，最大化个人和团队绩效
• Andon：状态或故障的视觉指示器
• Heijunka：表示调平或生产调平
• Hansei：意味着自我反省。 为了提高效率，工人应该挑战当前流程背后的假设，以找到更好的假设。
• 看板：用作控制生产的视觉工具的招牌
• Poka-yoke：也称为防错或防错
• 拉动系统：材料在需要时被拉入工作站
• Seiri：是反映浪费的原则。 Seiri 指示应该删除不必要的内容。 这包括所有最初的七种 TPS 浪费
• 标准化：围绕人体运动组织所有工作，并创建一个没有muda的高效生产序列。 这有助于提高质量、保持稳定的步伐，并允许持续改进。

下图显示了核心概念和核心价值观如何相互关联。

精益管理

丰田产品系统和精益制造随着时间的推移而发展，并应用于包括管理在内的许多领域。

精益管理应用持续改进和尊重人的核心价值观，并将其提炼成一套五项规范的精益原则，这些原则将被重复多次以持续改进和消除浪费：

1. 识别价值：从最终客户的角度按产品系列指定一个价值。
2. 映射价值流：确定每个产品系列的价值流中的所有步骤，尽可能消除那些不创造价值的步骤。
3. 创造流程：让创造价值的步骤紧密地发生，这样产品才能顺利地流向客户。
4. 建立拉动：随着流程的引入，让客户从下一个上游活动中拉取价值。
5. 寻求完美：当价值被指定时，价值流被识别，浪费的步骤被移除，流动和拉动被引入，重新开始这个过程并继续它，直到达到完美的状态，在这种状态下创造完美的价值，没有浪费。

这些原则和精益管理的其他方面在 Womack & Jones 于 1996 年出版了“精益思维”时被正式确定。

精益软件开发

此后，精益已应用于管理、软件开发和其他领域。

在 1980 年代和 1990 年代，软件开发行业正面临危机，因为使用传统瀑布方法执行的项目花费的时间越来越长。 这通常导致在确定业务需求和交付软件解决方案之间存在巨大的滞后。 有时，在某些具有特定要求的行业（例如航空航天业）中，这种滞后以数年甚至数十年的时间来衡量。

在这些多年的时间框架内，需求、系统甚至整个业务都发生了变化。 通常，项目会在中途被取消，或者他们将完成其范围，只是发现他们交付的内容不再满足项目开始时确定的业务需求。

瀑布方法奖励利益相关者在被迫编写合同时考虑所有事情，即使他们可能不确定自己需要什么。 瀑布方法迫使在需求或设计阶段做出决定，而这些决定很难在不改变合同和增加项目成本的情况下改变。 很大比例的软件项目完全失败，或者交付延迟和超出预算，或者未能交付所需的东西。

这种普遍的挫败感导致各种思想领袖试图改进瀑布。 早期的例子包括快速应用程序开发 (RAD)，它专注于通过快速开发原型并与业务合作进一步开发需求来缩短需求和设计阶段，从而减少浪费。 还朝着迭代开发的方向发展，其中完成了一个小项目并在持续迭代中添加了功能。 虽然这些方法有所帮助，但它们并没有解决与瀑布相关的核心问题。

在 1990 年代和 2000 年代初期，几位作者出版了关于将精益原则应用于软件开发的书籍。 Robert Charette 博士于 1993 年发表了《精益软件开发》，并于 2003 年发表了《精益软件开发的 12 条原则》。

Tom 和 Mary Poppendieck 于 2003 年出版了“精益软件开发：敏捷工具包”。这本书详细介绍了精益开发的七项原则，这些原则与精益制造中的七种浪费形式直接相关。 下图列出了两种不同的精益出版物和敏捷（在下一节中讨论）之间的异同。

精益与敏捷的区别

根据 Charette 博士的说法，精益和敏捷之间的主要区别之一是敏捷是自下而上的，而精益是自上而下的。

敏捷框架

敏捷的起源和敏捷宣言

大约在 Charette 和 Poppendiecks 出版他们的书的同时，创建了敏捷框架来帮助解决同样的问题。 2001 年 2 月，一群敏捷先驱在犹他州雪鸟市臭名昭著的雪鸟会议上相遇，试图提出解决方案。

结果就是敏捷宣言，它为一种方法论制定了一套价值观和原则，该方法论试图适应不断变化的需求和客户需求，减少浪费，并使用增量迭代方法更快地交付收益。

敏捷宣言的内容如下：

“我们正在通过开发软件并帮助他人开发更好的方法。 通过这项工作，我们开始重视：

• 个人和交互超过流程和工具
• 工作软件优于综合文档
• 合同谈判中的客户协作
• 响应变化而不是遵循计划

也就是说，虽然右边的物品有价值，但我们更看重左边的物品。”

与宣言中的价值观一致的是敏捷宣言背后的 12 条原则：

“我们遵循以下原则：

1. 我们的首要任务是通过早期和持续交付有价值的软件来满足客户。
2. 欢迎不断变化的需求，即使是在开发的后期。 敏捷流程利用变化来获得客户的竞争优势。
3. 频繁地交付工作软件，从几周到几个月不等，优先考虑更短的时间范围。
4. 业务人员和开发人员必须在整个项目中每天一起工作。
5. 围绕有动力的个人建立项目。 为他们提供所需的环境和支持，并相信他们能够完成工作。
6. 向开发团队和在开发团队内部传达信息的最有效和最有效的方法是面对面交谈。
7. 工作软件是进度的主要衡量标准。 敏捷流程促进可持续发展。
8. 赞助商、开发人员和用户应该能够无限期地保持恒定的步伐。
9. 对卓越技术和良好设计的持续关注提高了敏捷性。
10. 简单——最大化未完成工作量的艺术——是必不可少的。
11. 最好的架构、需求和设计来自自组织团队。
12. 团队会定期反思如何提高效率，然后相应地调整和调整其行为。”

上述价值观和原则是 Jidoka、JIT、Genchi Genbutsu、Kaizen、Hansei、Heijunka 和减少浪费等精益原则的应用。

应用于软件开发的敏捷原则

敏捷是一个伞式框架，适用于任何应用敏捷价值观和原则的过程。

一些例子是：

• 极限编程
• Scrum
• 看板

Scrum

人渣简史

Scrum 是一个应用由多个人分别发明的敏捷原则的框架，其中一些人签署了敏捷宣言：

• Hirotaka Takeuchi 和 Ikujiro Nonaka 在他们的白皮书“新产品开发游戏”中最初在制造环境中引入了“scrum”一词。 1986 年发表在《哈佛商业评论》上。
• Jeff Sutherland、John Scumniotales 和 Jeff McKenna 于 1993 年在 Easel Corporation 实施了 Scrum。
• Ken Schwaber 在他的公司使用了后来成为 Scrum 的东西，即 1990 年代的高级开发方法。

Schwaber 和 Sutherland 在整个 1990 年代合作开发和改进软件开发环境中的框架，并在各种会议上发表演讲。 Schwaber 与 Mike Beedle 在 2001 年的《Agile Software Development with Scrum》一书中描述了这种方法。

Schwaber 继续创建了两个主要的 Scrum 认证机构：

• Scrum 联盟：创建于 2001 年。设立Certified Scrum认证系列。
• Scrum.org：在 Schwaber 离开 Scrum 联盟后于 2009 年创建。 设置平行的Professional Scrum认证系列。

随着时间的推移，创建了几个框架/认证机构，以解决将 Scrum 框架扩展到更大的团队和项目的问题，因为 Scrum 最初是为小型团队（7 正或负 2 名成员）设计的：

• SAFe：规模化敏捷框架
• LeSS：大规模 Scrum
• Scrum@scale：由 Jeff Sutherland 创建的大规模 Scrum

Scrum 价值观

根据 Scrum 联盟：

Scrum 是一套简单但非常强大的原则和实践，可帮助团队在较短的周期内交付产品，实现快速反馈、持续改进和快速适应变化。

Scrum 是一个规范的、增量的和迭代的框架，用于开发应用敏捷原则的软件。 Scrum 价值观和原则在下面的图表中进行了概述，并且与精益和敏捷的价值观和原则有很大的一致性。

Scrum 概述

工作被划分为称为冲刺的短期迭代，通常为 1-3 周。 这与瀑布的深度规划形成鲜明对比。 为当前 sprint 计划的工作是从称为 Product Backlog（Pull System，Heijunka）的工作项优先级积压的顶部选择的，并且在 sprint 开始后就固定下来。 目标是在每个 sprint 结束时拥有工作软件，从而实现快速反馈。

在 sprint 结束时，团队开会审查已完成的工作、sprint 的进展情况，并计划下一个 sprint。 冲刺长度以及冲刺仪式和节奏对于每个冲刺都是固定的。

冲刺由包含完成冲刺工作所需的所有技能的跨职能团队执行。 日常计划和进度跟踪是使用 Scrum 板和 sprint 燃尽图等视觉工件完成的。

冲刺中的工作是从优先级积压中提取的。 遵循这些方法允许随着时间的推移不断变化的需求，并鼓励来自最终用户的不断反馈。

下面的思维导图概述了 Scum 的一些主要概念，这些概念将在接下来的部分中讨论。

Scrum 角色

Scrum 具有三个角色：

• Scrum Master ：Scrum Master 是 Scrum 团队的仆人领袖。 他们是团队的教练，帮助促进协作、消除障碍、实施和保护 Scrum 流程并保护团队。 这通常意味着他们组织和促进 sprint 仪式，确保产品负责人有适当的优先级和整理的积压工作，确保团队不会被迫过度致力于 sprint，确保范围不会被添加到sprint，确保遵守完成的定义。 他们不向团队成员分配任务（Genchi Genbutsu），也不负责项目的交付
• 产品负责人：产品负责人是负责交付产品的“唯一可拧脖子”。 产品负责人定义他们想要构建的愿景，并将该愿景传达给团队和组织。 产品负责人拥有业务和市场需求，并通过创建和管理产品待办事项来确定所有需要完成的工作的优先级。 他们决定何时发布哪些功能。 他们与团队和其他利益相关者合作，以确保每个人都了解产品待办事项中的项目。 他们在 sprint 演示中接受或拒绝在 sprint 中完成的工作。
• 团队成员：Scrum 团队是一个自组织的跨职能团队，通常由五到七名成员组成。 项目中的每个人都一起工作并互相帮助，而不必局限于不同的角色，如架构师、程序员、设计师或测试员。 每个人一起完成这组工作。 Scrum 团队计划他们可以完成每个 sprint 的工作量并拥有该计划（Genchi Genbutsu）。

Scrum 流程、活动和仪式

如上所述，Scrum 有一个明确的流程和一组仪式和活动。 冲刺的流程如下。

冲刺计划：

在 sprint 开始之前，Scrum Master 与 Scrum 团队和产品负责人召开会议，称为 sprint 计划会议，产品负责人确定即将到来的 sprint 的目标，然后团队根据目标计划他们的工作。

这通常通过以下活动完成：

• Sprint容量：团队确定sprint的容量，考虑天数、团队成员数、节假日等。
• 冲刺目标：产品负责人确定冲刺的目标。 根据目标对产品待办事项进行优先排序（即相关故事位于顶部）并进行梳理，这一点至关重要。
• 工作选择：故事或任务从积压的顶部拉到冲刺中，直到达到估计的容量。 随着故事的引入，产品负责人将解释故事并回答团队提出的问题，根据需要更新故事，直到产品负责人和 Scrum 团队对故事有良好、共同的理解。 一旦这个活动完成，团队就有了一个提议的初始冲刺范围。
• 任务分解： Scrum 团队详细讨论每个故事，重点是规划他们将如何完成故事并解决所有验收标准和国防部。 他们将生成完成故事所需的子任务列表。 完成子任务列表后，如有必要，将对故事的估计进行审查和更新。
• Sprint 承诺：一旦所有的故事都被分解并更新了估计，就会审查提议的初始 sprint 范围。 故事可能会从 sprint 中删除并放回待办事项列表中和/或可能会添加其他故事。 一旦完成，只有 Scrum 团队（而不是 Scrum Master 或产品负责人）承诺完成冲刺中的工作，然后冲刺开始。

为 sprint 承诺的工作总量或范围以故事点来衡量。

冲刺执行

在 sprint 期间，团队成员从 sprint 待办事项列表的顶部提取工作项（用户故事、任务等）以进行工作。 不同的团队成员将处理不同的工作项或其子任务。 他们将在适当的时候通过将项目从 Scrum 板上的一列移动到下一列（通常是待办事项 > 进行中 > 测试 > 已完成或其一些变体）来更新项目的状态，直到完成。

使用燃尽图跟踪进度，该图表显示已完成的工作量和以故事点衡量的剩余工作量。 剩余故事点显示在 Y 轴上，剩余时间显示在 X 轴上。 故事完成后，燃尽图会更新。

Scrum Master 每天都专注于：

• 促进每日站立会议以计划一天并审查进度（见下文）
• 确保团队有当天的计划
• 消除障碍
• 保护冲刺范围和团队免受干扰
• 帮助团队维护他们的燃尽图和其他 Scrum 统计数据

每日站立

在 sprint 的每一天开始时，Scrum Master 会与 Scrum 团队和产品负责人进行一次 15 分钟的简短会议，以计划一天并审查 sprint 进度。 这是一个简短的会议，每个人都站在 Scrum Board 前，会议中的每个人在 2 分钟或更短的时间内回答以下问题，参考 sprint board 上的特定项目：

• 你昨天做了什么？
• 你今天打算做什么？
• 有没有阻碍你完成工作的障碍？

这使每个人都可以看到每个人都在做什么，看到正在取得或没有取得什么进展，并确定障碍和/或需要的帮助。

冲刺完成

在计划下一个 sprint 之前，Scrum Master 会促成两个仪式以结束 sprint。

冲刺演示

在 sprint 结束时，Scrum Master 组织了一个 sprint 演示会议，每个完成的故事都在工作软件上向产品所有者和团队的其他成员展示。 如果满足所有接受标准，产品所有者将接受该故事，或者他们将拒绝该故事。 如果一个故事被拒绝，则会发现不足之处，并将故事按优先顺序放回产品待办事项列表中，以便稍后完成或根本不完成。 通常，产品负责人不接受的故事部分会被分解成一个或多个单独的故事，并且原始故事被关闭。

计算每个冲刺完成的故事点总数（速度）并结束冲刺。 速度用于跟踪团队的输出水平，并用于估计功能或发布何时完成。

冲刺回顾

在 sprint 演示之后但在下一次 sprint 计划会议之前，Scrum Master 促进了一次 sprint 回顾，团队在此回顾刚刚完成的 sprint，并讨论什么进展顺利，什么进展不顺利，以便他们可以持续和渐进地改进流程和质量随时间变化（Kaizen、Hansei）。 有大量的回顾形式或练习可用于帮助团队进行讨论。

生成改进行动项目列表，有时它们会导致项目被添加到产品待办事项中，对 DoD 或团队章程的更改等。

产品积压管理

产品待办事项创建

在计划或执行冲刺之前，产品负责人需要创建产品积压工作。 积压工作通常从产品所有者编写的称为故事的功能开发项目开始，随着时间的推移，还会填充开发或 QA 任务、峰值和缺陷等，可能由团队的任何成员创建。 积压中的所有项目都按优先顺序排列。

积压梳理

一旦创建了初始产品待办事项并确定了优先级，正在进行的待办事项整理流程就会接管。 目标是始终至少对待办事项中的最重要项目进行梳理和估计，以便在冲刺计划会议期间准备好将它们拉入冲刺。 这通常是通过与产品经理和由 Scrum Master 协助的团队定期举行的积压梳理会议来完成的。

在会议开始之前，会向团队发送一份故事列表，以便他们审查和准备培训会议。 在梳理会议上，从验收标准、复杂性、风险、规模、实施策略等方面讨论每个项目。对验收标准和故事的其他细节进行审查和修改，直到团队、产品负责人和 Scrum Master对故事有共同的理解。 在这一点上，故事是使用称为计划扑克的技术以故事点估计的。

故事点估计

故事点是一个使用相对大小的工作单位，将故事与以前的、已知的、易于理解的作品进行比较。 你总是在问“这个故事是更大、更小还是与其他作品大致相同”的问题。

斐波那契量表（1、2、3、5、8、13、21……）是最常用的量表，其中每个增量大约是前一个增量的两倍（即，一个五点故事或多或少是前一个增量的两倍）大如三点故事）。 有时会使用其他尺寸，如 T 恤尺寸（XS、S、M、L、XL）甚至鱼（小鱼、金鱼、鳟鱼、金枪鱼、鲸鱼等）。 任何允许您比较某物相对于另一物大小的比例都可以。

故事点代表团队实施故事的全部努力，包括开发、测试、设计和完成定义所需的其他杂项任务。 该估算考虑了工作量、复杂性和风险。 一旦确定了故事的相对大小，就会分配比例尺上的大小作为估计值。

团队准备故事点估计过程，首先通过选择一个整个团队都理解为参考故事的“最中等”大小的故事来建立估计基线。 还选择了一些更大或更小的附加参考故事。

故事点估计是在梳理会议期间完成的，有时在使用 Planning Poker 进行 sprint 计划期间完成：

1. 每个团队成员/评估员都有一组卡片。
2. 如上所述，一次讨论一个积压项目。
3. 一旦项目被充分讨论，每个估计者私下选择一张卡片来代表他们的估计。
4. 当所有的估价师都做出估价后，他们同时亮出他们的牌。
   • 如果所有估计都匹配，估计者选择另一个积压项目并重复相同的过程。
   • 当估计不同时，估计者讨论该问题以达成共识。

故事点估计的优点是：

• 快速：估计是相对于已经完成的产品积压项目。
• 足够准确：足够准确，可以概述范围、计划未来工作、确定优先级并管理期望。
• 拥抱不确定性：故事点指定了一个未知的时间范围。 从特定的斐波那契式故事点序列中进行选择可以捕捉不确定性。
• 团队运动：涉及每个人（开发人员、设计师、QA、产品经理）。 使用多个视角来确定工作的规模，但只有从事工作的团队成员才能估计
• 衡量团队速度：衡量团队在冲刺中所做的工作量与花费在工作上的时间量。 随着团队的改进，他们将更快地完成相同大小的故事，从而随着时间的推移提高故事点速度。

发布估计和跟踪

故事点估计也使用以下技术在发布计划上下文中使用：

1. 列出所有要调整大小的故事
2. 将它们按从小到大的顺序排列
   • 以第一个和第二个用户故事为例。
   • 决定哪个更大，把更大的放在下面
   • 然后拿下一个并决定它相对于其他两个适合的位置
   • 重复该过程，直到所有故事现在都在列表中（按从小到大的顺序）
3. 调整故事的大小

一个版本中所有故事的故事估计与团队的速度相结合，将允许您估计发布何时完成并跟踪其进度。 这通常显示在发布燃尽图中。

Scrum 工件和术语

• 产品待办事项：给定产品的所有工作项的待办事项列表，其中可以包括功能（故事）、技术任务、峰值和缺陷
• 发布燃尽图：用于显示发布级别的进度并使用 Sprint Velocity 预测发布何时完成的图形图表。 完成的故事点显示在 Y 轴上，冲刺显示在 X 轴上。
• Sprint Backlog：在给定的 sprint 中要完成的所有工作项的 backlog 列表。 sprint backlog 的内容在 sprint 计划会议上达成一致。
• Scrum Board：一个表格样式的板，用于跟踪为 sprint 承诺的工作进度。 状态显示在顶部的垂直列中，工作项在每个状态之间移动，直到完成。 Scrum 板在 sprint 计划会议期间填充，并在 sprint 结束时重置。
• Sprint Burndown：一个图形图表，显示在 sprint 长度内以故事点衡量的已完成工作量和剩余工作量。 剩余故事点显示在 Y 轴上，剩余时间显示在 X 轴上。
• 冲刺速度： Scrum 团队在冲刺中完成的故事点数。
• 障碍积压： Scrum Master 需要解决的障碍列表，以便团队可以继续工作。 当团队成员被阻止时，他们会将一个项目添加到障碍积压中，以向团队和 Scrum Master 提供可见性。
• 史诗：史诗是由多个相关用户故事组成的大量工作。
• 用户故事：用户故事是从最终用户的角度对软件功能的描述。 用户故事描述了用户的类型、他们想要什么以及为什么。 用户故事有助于创建对需求的简化描述，并包括验收标准。 用户故事由产品所有者创建和维护。
• 任务：任务是由 Scrum Master 或团队成员输入的一项工作，可能与用户故事直接或间接相关。 它们通常是技术性的，将包括验收标准。
• 尖峰：尖峰是一种特殊类型的任务，当您需要研究、原型和/或架构师时，您可以决定如何实施或估计用户故事。
• 子任务：子任务是作为完成用户故事或任务的实施步骤输入的任务。 它们通常由团队在 sprint 计划会议期间输入。
• 故事点估计：基于斐波那契尺度（1、2、3、5、8、13、21……）的相对规模估计尺度
• 验收标准：包含在每个故事中的特定故事、可测试项目的列表，在产品所有者接受故事完成之前必须完成这些项目。
• 完成的定义 (DoD)：在任何故事被认为完成之前必须完成的常见步骤或标准的列表。 团队同意这一点并将其记录下来，这样就不必在每个故事中都列出它。

Scrum 的优缺点

Scrum 的主要优势是应用敏捷价值观和原则以及精益概念，例如 Seiri、Jidoka、Just-in-Time、Kaizen、Genchi Genbutsu、Heijunka、Pull System 和 Iterations。 应用这些原则可以让项目团队获得持续的反馈，快速适应不断变化的需求和不确定性，减少浪费，提高可见性和透明度，并争取持续改进。 通过始终关注产品待办事项中最重要的项目，并且只在始终产生工作软件的短迭代中工作，Scrum 更加以客户为中心，并允许客户查看他们喜欢（和不喜欢）的内容并根据需要进行更改。 流程和管理方面的间接成本更小，从而导致更快、更便宜的结果。

Scrum 是一种很好的方法，适用于需求不明确和/或预期会改变的项目。 这适用于大多数项目。 Scrum 也非常适合经验丰富、积极进取的团队，因为它允许团队自己组织工作，并为进度和问题提供可见性、透明度和问责制。 所有这些都将导致团队随着时间的推移而改进并变得更有效率。

Scrum 确实有一些缺点，在某些情况下并不是最好的方法：

• 透明度： Scrum 增加了透明度和问责制，这既是优点也是缺点，因为团队内外的问题和表现不佳会暴露出来。 如果在持续改进的 Scrum 框架内处理不当，这可能会让人不舒服，并且可能会导致阻力。
• 团队经验和承诺：缺乏经验和/或未承诺的 Scrum 团队或 Scrum Master 可能会因误用 Scrum 方法而导致严重的问题。 Scrum 团队中没有明确的角色，因为每个人都做所有事情，因此需要具有技术经验的敬业团队成员来遵循 Scrum 流程并随着时间的推移进行改进。 如果组织的其他部分抵制 Scrum，这也可能是非常有害的。
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

看板

什么是看板？

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

看板与 Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.