项目管理蓝图第 1 部分：敏捷（Agile）、Scrum、Kanban 和 精益（Lean） 的综合分析

概述

今天，软件开发中采用了几种方法。您可能听说过瀑布（Waterfall），敏捷（Agile），Scrum，Kanban，精益（Lean），极限编程等术语。

在本文中，我将定义这些概念，并解释它们如何相互联系和变化。上述许多流行语都是基于精益生产的想法，精益生产建立在丰田制造系统（TPS）的基础上，所以我们将从那里开始。

精益方法

精益生产及其起源

“精益”一词是在制造业中发明的，用于表示基于Sakichi Toyoda、Kiichiro Toyoda和Taiichi Ohno建立的丰田生产系统（TPS）的生产模式，此生产模式是受到亨利福特的影响。TPS 在 1950 年代和 1970 年代通过专注于“彻底消除所有废弃物”的概念来改变生产。当“改变世界的机器”于1990年发布时，TPS被称为“精益生产”。

丰田的TPS识别了三类主要废弃物：

• Muda

  ：“废弃物”是直译。丰田发现了七种形式的muda，后来又添加了第八种。它们如下：

  • 缺陷：

    识别和纠正缺陷所需的时间和精力

  • 生产过剩：

    生产多过于需求

  • 等待：

    等待下一个制造步骤、中断等。

  • 未使用人才：

    人才利用不足、培训不足等

  • 运输：

    加工不需要的产品或移动部件

  • 库存：

    库存已完成和在建工作

  • 动态：

    移动或行走超过处理所需的次数

  • 过度加工：

    由于工具或产品设计不足

• Muri：

  翻译为“负担” Muri通常是Mura的结果，尽管它也可能是Muda的结果。Muri 表现为故障、旷工、安全问题等。

• Mura：

  解释为“不均匀”。Mura在客户需求、每个产品的处理时间或不同操作人员的周期时间方面都存在差异。当Mura不被最小化时，发生Muri和Muda的机会就会增加。通过提高供应链透明度、改进产品设计以及为所有操作员提供统一的工作，Mura可以被减少。

TPS试图通过使用两个关键概念来减少浪费：

• Jidoka：

  “人性化的自动化”一词意味着“质量必须融入生产过程！”这意味着当出现问题时，机器会立即停止，避免生产不合格的产品。

• 准时制（JIT）：

  只生产“需要的东西，在需要的时候，以及所需的数量”。

这些基本支柱和原则随着TPS的发展而建立起来，建立在Jidoka和JIT的思想之上：

• 持续增强：

  • 挑战：

    建立长远眼光，以勇敢和独创性面对问题，以实现愿望

  • Kaizen：

    不断完善公司程序，不断推动创新和进步，一次去除一个Muda

  • Genchi Genbutsu：

    实行Genchi Genbutsu，从源头收集事实，以便做出合理的判断，达成协议，尽快实现我们的目标

• 对别人的尊重：

  • 尊重：

    尊重他人，尽一切努力相互理解，承担责任，尽最大努力培养信任

  • 团队合作：

    鼓励个人和职业发展，分享发展机会，提高个人和团队绩效

• Andon：

  状态或问题的指示

• Heijunka：

  调平是指生产调平

• Hansei：

  意味着自我反省，员工应该质疑当前程序背后的假设，以便开发更好的程序

• Kanban：

  用于视觉调节生产的版面

• Poka-yoke：

  也称为防范错误或避免错误

• 拉动系统（Pull System

  ）：仅在需要时将材料带入工作站

• Seiri：

  是废物反射原理。根据Seiri的说法，不需要的东西应该被删除。这包括TPS最初的所有七种废弃物

• 标准化：

  根据人体运动安排所有任务，并生成无泥浆的制造顺序。这有助于提高质量、一致的速度和持续的进步

精益管理

随着时间的推移，丰田产品系统和精益制造日趋成熟，并在包括管理在内的各个领域实施。

精益管理将持续增强和对别人的尊重的基本概念简化为一套五项规范性的精益原则，这些原则将重复多次以不断改进和消除浪费：

1. 识别价值：

   按产品系列，从最终客户的角度提供价值。

2. 映射价值流：

   确定每个产品系列的价值流中的所有流程，在可行的情况下删除任何不能提供价值的步骤。

3. 创造流程：

   使价值创造阶段按一定的顺序发生，使产品顺利流向买方。

4. 建立拉取：

   允许使用者在引入流时从下一个上游操作中提取价值。

5. 追求完美：

   正如价值所描述的那样，发现价值流，消除浪费的过程，并添加流动和拉动，重复该过程，直到达到完美状态，在这种状态中，价值可以完美的产生而没有被浪费。

当沃马克（Womack ）和琼斯（Jones ）在1996年发布“精益思维”时，他们编纂了这些想法和精益管理的其他部分。

精益软件开发

从那时起，精益就被用于管理、软件开发和其他行业。

软件开发行业在 1980 年代和 1990 年代处于灾难的边缘，因为采用传统瀑布方法的项目需要的时间越来越长。这通常会导致确定业务需求和交付软件解决方案之间存在巨大差距。在具有特殊需求的特定部门，例如飞机工业，这种滞后可能以年或是几十年为单位。

在这多年的时间里，需求、系统甚至整个公司都发生了变化。通常，计划在中途终止或完成其范围时，才发现它们生产的内容不再满足项目一开始时确定的业务要求。

瀑布流程奖励考虑一切的利益相关者，因为他们被迫写一份合同，即使他们不确定自己需要什么。瀑布技术要求在需求或设计阶段中做出判断，这些决定如果不通过修改合同和增加项目成本是很难逆转的。有许多的软件项目是完全失败的，交付延迟和超出预算，或没有达到要求。

由于这种普遍的不满，许多思想领袖试图改善瀑布。快速应用程序开发（RAD）是一个早期的例子，它专注于通过快速构建原型并与企业合作进一步完善需求来缩短需求和设计阶段，从而消除浪费。他们也转向迭代开发，其中完成基本项目并在迭代中添加功能。虽然这些方法是有益的，但它们并没有解决瀑布的根本问题。

几位作家在 1990 年代和 2000 年代初出版了关于将精益概念应用于软件开发的书籍。1993年，Robert Charette博士发布了“精益软件开发”，然后在2003年，他发表了“精益软件开发的12个原则”。

2003年，Tom和Mary Poppendieck发布了“精益软件开发：敏捷工具包”。本书概述了七种精益开发概念，这些概念与精益制造中的七种浪费类型完全对应。

精益和敏捷之间的差异

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

目标

Charette的精益软件开发

1. 1/3 人力
2. 1/3 开发时间
3. 1/3 时间
4. 1/3 投资
5. 1/3 努力适应

敏捷宣言

1. 个人和互动
2. 工作软件
3. 客户协作
4. 应对变化

原则

Charette的精益软件开发

1. 客户满意度
2. 物有所值
3. 客户参与
4. 团队努力
5. 一切都是多变的
6. 领域，而不是单点解决方案
7. 只完成，不构建
8. 80% 立即解决方案
9. 极简主义是必不可少的
10. 需求决定技术
11. 产品增长就是功能增长
12. 注意限制

敏捷宣言

1. 客户满意度
2. 迎接不断变化的需求
3. 频繁的交货周期
4. 利益相关者协作
5. 信任、支持和激励的文化
6. 面对面交流
7. 工作软件是指标
8. 可持续发展
9. 技术卓越
10. 简单化
11. 自组织团队
12. 团队反馈

Poppendieck的精益

1. 消除浪费
2. 放大学习
3. 尽快交付
4. 尽早决定
5. 为团队赋权
6. 在产品中建立完整性
7. 查看整个过程

敏捷框架

敏捷宣言及其起源

敏捷框架是在Charette和Poppendiecks出版他们的书以帮助应对相同挑战的同时设计的。在2001 年 2 月，一群敏捷先驱者聚集在犹他州Snowbird著名的 Snowbird 会议上，试图解决这个问题。

其讨论的结果就是敏捷宣言，它概述了一套信念和原则，该方法使用增量迭代方法来适应不断变化的需求和客户需求，最大限度地减少浪费，并更快地提供收益。

根据敏捷宣言：

“通过这样做并帮助其他人做到这一点，我们可发现更好的软件生产方法。”这种努力教会了我们重视：

• 人与人之间的互动

  胜过流程和工具

• 工作软件

  胜过大量文档

• 客户参与

  合同谈判
• 通过坚持计划来应对变化

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

12 项敏捷宣言原则与宣言的价值观一致：

“我们坚持以下原则：

1. 我们的首要目标是通过按时和一致地交付有用的软件来满足客户。
2. 接受不断变化的需求，尤其是当它们在开发过程的后期出现时。敏捷方法利用变化来获得客户的竞争优势。
3. 定期交付正常运行的软件，从几周到几个月不等，首选较短的持续时间。
4. 在整个项目中，商人和开发人员必须定期协作。
5. 围绕积极进取的人制定计划。给他们所需的氛围和支持，并相信他们会完成任务。
6. 面对面的沟通是向开发团队和在开发团队内部传输信息的最有效方式。
7. 进展的关键指标是功能软件。敏捷程序促进长期增长。
8. 赞助商、开发商和消费者应该能够永远跟上步伐。
9. 持续关注卓越技术和智能设计可提高敏捷性。
10. 简单性——尽可能少做劳动的技能——是至关重要的。
11. 自组织团队提供最好的架构、要求和设计。
12. 团队思考如何定期变得更加成功，然后适当地调整和修改其行为。”

上面列出的价值观和概念是精益原则的实施，例如Jidoka，JIT，Genchi Genbutsu，Kaizen，Hansei，Heijunka和减少废弃物。

使用敏捷原则进行软件开发

敏捷是一个广泛的框架，包含任何遵循敏捷理想和原则的过程。

以下是几个示例：

• 过度编程
• Scrum
• Kanban

Scrum

Scum 的简史

Scrum是一种实现敏捷概念的方法，由许多人独立开发，其中一些人签署了敏捷宣言：

• Hirotaka Takeuchi和Ikujiro Nonaka在他们的白皮书“新产品开发游戏”中首次在制造环境中使用了“Scrum”一词，该白皮书于1986年发表在哈佛商业评论上。
• Scrum于1993年由Jeff Sutherland，John Scumniotales和Jeff McKenna在Easel Corporation推出。
• 在1990年代，Ken Schwaber的业务，Advanced Development Methods，采用了后来的Scrum。

在整个1990年代，Schwaber和Sutherland在软件开发环境中共同创建和增强框架，并在许多会议上发表演讲。Schwaber与Mike Beedle合作，在2001年出版的《Agile Software Development with Scrum》书中定义了这一过程。

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

• Scrum Alliance：成立于2001年。创建Certified Scrum认证计划。
• Scrum.org：Schwaber于2009年退出Scrum Alliance后，创立了Scrum.org，并设置Professional Scrum认证系列。

由于Scrum最初是为小型团队（7人加减2人）构建的，因此随着时间的推移，开发了许多框架/认证机构来处理Scrum框架对更大团队和项目的可扩展性：

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

Scrum 价值观

Scrum Alliance 声明：

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

Scrum是一种基于敏捷概念的规范性、增量式和迭代式软件开发范式。Scrum价值观和原则会在以下的图表中陈述，它们与精益和敏捷价值观和原则非常相似。

Scrum概述

任务被分散为几个冲刺，冲刺是持续 1-3 周的短时间盒迭代。这与瀑布的精心准备形成了鲜明的对比。当前冲刺的原则是从工作项的优先级订单选择的，并被称为产品待办列表对应（拉动系统，Heijunka），并在冲刺开始后才进行更正。目标是在每个冲刺结束时拥有正常运行的软件，以便可以快速提供反馈。

团队在冲刺结束时聚集在一起，评估已完成的工作，讨论冲刺的进展情况，并计划下一个冲刺。对于每个冲刺，冲刺持续时间以及冲刺仪式和节奏都是预先确定的。

冲刺由跨职能团队执行，该团队由完成冲刺工作所需的人才组成。使用可视化工件如 Scrum 板和冲刺燃尽图跟踪和计划每日进度。

冲刺的工作是从优先的产品待办列表对应提取的。这些策略允许随着时间的推移而改变需求，并促进最终用户的持续输入。

Scrum团队

Scrum有三个功能：

• Scrum 大师：

  Scrum 大师是Scrum团队的仆人式领导者。他们充当团队的教练，促进合作，消除障碍，执行和保护Scrum流程，并保护团队。这通常需要组织和促进冲刺仪式，确保产品所有者有一个适当的优先级和有次序的产品待办列表，确保团队不会被迫过度投入冲刺，确保范围不会添加到冲刺，并确保遵循Definition of Done。他们不将责任赋予团队成员（Genchi Genbutsu），也不对项目完成负责。

• 产品负责人：

  产品负责人是负责产品交付的“单拧颈”。产品负责人定义并向团队和公司传达他们想要开发的愿景。产品所有者负责业务和市场需求，并通过创建和管理产品待办列表来确定需要完成的所有工作的优先级。他们选择何时发布哪些功能。他们与团队和其他利益干系人协作，以确保每个人都知道产品待办列表。在冲刺演示中，他们可批准或拒绝冲刺期间执行的工作。

• 团队成员：

  Scrum团队是一个由五到七人组成的自组织、跨职能的团队。项目中的每个人都相互协作和协助，不限于某些职位，例如架构师、程序员、设计师或测试人员。每个人都共同努力完成一组任务。Scrum团队决定每个冲刺中可以完成多少工作，并拥有计划（Genchi Genbutsu）。

Scrum、活动和仪式的流程

如前所述，Scrum具有定义的流程以及一组仪式和任务。冲刺流程如下所示。

冲刺计划：

在冲刺开始之前，Scrum 大师与Scrum团队和产品负责人一起主持冲刺计划会议，在此期间，产品负责人指定即将到来的冲刺的目标，团队根据目标准备工作。

这通常通过以下活动来实现：

• 冲刺能力：

  冲刺能力由团队确定，同时考虑天数、团队成员、假期等。

• 冲刺目标：

  冲刺目标由产品所有者确定。至关重要的是，根据目标（如相关故事位于顶部）对产品待办列表进行优先级排序和整理。

• 工作选择：

  在达到预期目标之前，情景或任务将从队列顶部被包括到冲刺中。当故事被引入时，产品负责人将描述叙述并回答团队问题，根据需要修改故事，直到产品负责人和Scrum团队对故事有扎实的共享知识。完成此活动后，团队将建议起始冲刺范围。

• 任务分解：

  Scrum团队深入探讨每个故事，专注于如何在满足所有验收标准和DoD的同时完成故事。他们将创建一个完成故事所需的子任务列表。完成子任务列表后，将评估故事估计值，并在需要时进行修改。

• 冲刺承诺：

  一旦所有故事都被分解并进行修改，就会评估建议的第一个冲刺范围。可以从冲刺中删除故事并将其发送到产品待办列表，也可以添加新故事。一旦完成，只有Scrum团队（而不是Scrum 大师或产品所有者）承诺完成冲刺中的工作，然后启动冲刺。

故事点代表着冲刺期间承诺的总工作量或范围。

执行冲刺

在冲刺期间，团队成员处理冲刺待办事项列表中的工作项（用户情景、任务等）。众多工作项或其子任务将由不同的团队成员处理。在适当的时候，他们将通过将项目从一列移动到下一列来更改 Scrum 板上项目的状态（通常是待办事项>正在进行>测试>完成或其任何变动），直到完成。

燃尽图用于监视进度，该图指示在叙述点中执行和剩余的工作量。Y 轴表示剩余的叙事点，而 X 轴表示剩余的时间。故事完成后，燃尽图将被更新。

在日常中，Scrum 大师关注的是：

• 促进每日会议，用于组织一天和监控进度（见下文）
• 确保团队有日常策略
• 消除障碍
• 让冲刺范围和团队远离干扰
• 维护团队的燃尽图和其他 Scrum 信息

每日会议

Scrum 大师在每个冲刺日开始时与Scrum团队和产品负责人进行15分钟的快速会议，以计划这一天并评估冲刺进度。这是一个简短的会议，每个人都站在Scrum板前，在2分钟或更短的时间内回答以下问题，这些问题根据冲刺板上的特定项目：

• 您前一天做了什么？
• 您今天有什么计划？
• 有什么阻止您完成工作吗？

这让每个人都清楚了解大家在做什么，取得了多少进展或没有取得多少进展，并确定所需的障碍和/或支持。

完成冲刺

在计划下一个冲刺之前，Scrum 大师组织了两个仪式来完成冲刺。

冲刺演示

在冲刺结束时，Scrum 大师进行冲刺演示会议，其中每个完成的故事都呈现给产品所有者和团队的其他成员。如果满足所有验收标准，则产品所有者将批准或拒绝该故事。如果故事被拒绝，则会指出缺点，并将故事按优先级顺序重新添加到产品待办列表工作中，以便稍后完成或删除。产品负责人不接受的叙述部分通常被分成其他故事，而原始故事是固定不变的。

计算每个冲刺完成的故事点总数（速度）后，冲刺将结束。速度用于监视团队的输出级别，并预测功能或发布何时完成。

冲刺审查

Scrum 大师在冲刺演示之后并在下一次冲刺计划会议之前促进冲刺回顾，其中团队将反思以前的冲刺，并讨论哪些进展顺利，哪些进展不顺利，以便他们可以随着时间的推移持续和逐步改进流程和质量（Kaizen，Hansei）。有几种回顾方法和活动可用于帮助团队进行对话。

可以创建改进操作项列表，这可能会导致额外事项被添加到产品待办列表工作、修改 DoD 或团队章程或其他结果。

产品待办列表的管理

产品待办列表开发

产品所有者必须先创建产品待办列表，然后才能计划或执行冲刺。产品待办列表通常从产品所有者编写的称为故事的功能开始，并逐渐填充团队任何成员可能添加的开发或质量保证任务、峰值和缺陷等。产品待办列表按优先级顺序进行组织。

整理产品待办列表

在生成第一个产品待办列表并确定优先级后，持续的产品待办列表整理过程将启动。目标是整理和估计产品待办列表的主要项目，以便在冲刺计划会议期间将它们带入冲刺。这通常是通过Scrum 大师与产品经理和团队频繁协调的待办事项梳理会议来实现的。

在会议之前向团队提供叙述列表，以便他们可以评估和准备梳理会议。梳理会议会根据批准标准、复杂性、风险、规模、实施计划等考虑每个项目。验收标准和其他叙述元素将会被审查和修改，直到团队、产品负责人和 Scrum 大师都同意叙述。然后使用称为规划扑克的过程在叙述点中添加情节。

叙述点计算

叙述点是一种劳动量，它使用相对大小将叙述与先前建立和易于理解的工作项目进行比较。您不断地问自己，“这个叙述是更大、更小，还是和另一件作品差不多？”

斐波那契量表（The Fibonacci scale）（1，2，3，5，8，13，21…）是最常用的量表，每个增量大约是前一个的两倍（如一个五点的叙述或多或少是三点叙述的两倍）。如使用其他量表，例如 T 恤尺寸（XS、S、M、L、XL）甚至鱼（鲦鱼、金鱼、鳟鱼、金枪鱼、鲸鱼等）。任何使您能够将一个对象的大小与另一个对象的大小进行比较的比例就足够了。

叙述点表示整个团队执行叙述的工作，包括编程、测试、设计以及满足完成定义所需的任何其他活动。该估计考虑了工作量、复杂性和风险。确定叙述的相对大小后，将分配刻度上的大小作为估计值。

团队首先通过选择整个团队都知道作为参考叙述的“最中等”大小来创建估计基线，从而为估计叙述点的过程做好准备。还有一些大大小小的参考叙述可以被挑选出来。

使用规划扑克，在梳理过程中估计叙述点，偶尔可在冲刺计划期间估计：

1. 每个团队成员/估算员都会得到一副牌。
2. 如前所述，一次处理一个产品待办列表。
3. 在对主题进行彻底审查后，团队成员/估算员都会选择一张卡片来私下象征他们的估计。
4. 当所有团队成员/估算员完成估计后，他们会同时公开他们的卡片。
   • 如果所有估计都一致，团队成员/估算员将转到下一个产品待办列表并继续该过程。
   • 当估计不一致时，团队成员/估算员会辩论该主题以达成协议。

以下是估计叙述点的好处：

• 快速：

  估算基于以前完成的产品待办列表。

• 足够准确：

  足够精确以提供高层次的概述、规划未来工作、确定优先级和管理期望

• 拥抱不确定性：

  叙述点表示一个未定义的时间跨度。选择类似斐波那契的叙事点序列可以捕获歧义。

• 团队运动：

  每个人都参与其中（开发人员，设计师，质量保证，产品经理）。使用多个视图来估计工作量，但只有执行工作的团队成员才能这样做。

• 估计团队速度：

  量化团队在冲刺中完成的工作量与执行任务所花费的时间。随着团队的发展，他们将更快地完成类似大小的叙述，从而随着时间的推移产生更快的叙述点速度。

估计和跟踪发布时间

在发布规划环境中，还可以使用以下技术来估计叙述点：

1. 列出所有需要调整大小的文章
2. 从小到大对它们进行排序
   • 考虑第一和第二篇用户文章
   • 选择较大的并将其放在下面
   • 然后选择下一个并找出与前两个匹配的位置
   • 重复该过程，直到所有叙述都添加到列表中（按从小到大的顺序）
3. 调整文章大小

将发布所有叙述的叙述估计值与团队的速度相结合时，可以预测发布何时完成并观察其进度。这通常显示在发布燃尽图中。

Scrum 工件和术语

• 产品待办列表：

  特定产品的所有工作项的目录，包括功能（情景）、技术任务、峰值和故障。

• 发布燃尽：

  用于指示发布进度并使用 Sprint 速度预测发布何时完成的图形图表。Y 轴表示已完成的叙述点，而 X 轴表示冲刺。

• 冲刺待办列表：

  冲刺期间要完成的所有工作待办列表。在冲刺计划会议期间，将决定冲刺待办列表。

• Scrum 板：

  记录冲刺工作进度的表格式板。状态显示在顶部的垂直列中，工作项在每个状态之间移动，直到完成。Scrum 板在冲刺计划会议上会被填满，并在每个冲刺结束时重置。

• 冲刺燃尽：

  表示在整个冲刺过程中执行和剩余的工作量的图形。Y 轴表示剩余的叙事点，而 X 轴表示剩余的时间。

• 冲刺速度：

  Scrum团队在冲刺中完成的叙述数量。

• 障碍列表：

  Scrum 大师必须处理的障碍列表，以便团队继续工作。当团队成员受阻时，他们会将一个项目提交到障碍队列中，以使团队和Scrum 大师意识到。

• 叙事诗：

  叙事诗是由许多链接的用户故事组成的大量作品。

• 用户叙述：

  用户叙述是从最终用户的角度编写的软件功能描述。用户叙述概述了他们想要什么以及他们想要它的原因。用户叙述简化了需求陈述并包含接受标准。产品所有者负责创建和维护用户叙述。

• 任务：

  任务是由Scrum 大师或团队成员输入的工作项，可能直接或间接地与用户叙述相关联。它们通常是技术性的，包括批准标准。

• 峰值：

  峰值是一种活动，当您需要在决定如何执行或估计用户叙述之前进行调查、原型和/或架构时使用。

• 子任务：

  子任务是作为完成用户叙述或任务过程中的阶段添加的任务。它们通常由团队在冲刺计划会议上输入。

• 故事点估计：

  基于斐波那契的相对大小估计量表（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 大师误用Scrum技术，那可能会导致重大困难。因为Scrum团队中没有定义的角色，每个人都负责所有事情，所以遵循Scrum流程并随着时间的推移进行改进需要具有技术技能的敬业团队成员。如果公司的其他部门对Scrum持怀疑态度，那也可能是相当有害的。

• 范围蔓延：

  由于利益相关者能够为范围做出贡献，因此存在范围蔓延的威胁，尤其是在没有设定结束日期的情况下。Scrum的主要好处之一是能够修改范围和优先级，但是如果不采用纪律，它也可能是个缺点。

• 定义不明确的工作：

  重复工作、错误的估计和范围蔓延都可能是由于定义和理解不充分的用户叙述或活动造成的。尽管Scrum优先考虑功能软件而不是文档，但产品所有者必须清楚他们想要什么，并能够在对话和用户叙述中有效地传达它。

• 扩展：

  在大型团队中采用Scrum范式很困难，因为Scrum是为较小的团队而设计的。

Kanban

Kanban到底是什么？

Kanban是一个更轻量级的过程，它包含许多精益和敏捷特征，以及Scrum价值观和原则的子集，但还是有一些关键的区别。Kanban强调可见性、流动性和减少正在进行的工作。

Kanban是一个日语单词，意思是“招牌”或“广告牌”。丰田生产线工人使用Kanban（物理板）来表示其生产过程不同阶段的额外产能。这是使用软件中的Kanban完成的，与Scrum板非常相似。其中包括待办事项的产品待办列表，以及工作项的每个可能状态的垂直列。工作项从一个状态转移到另一个状态的方式与Scrum完成的方式相同;但是，对于Kanban，正在进行的工作数量严格限制为每个状态中的最大项目数，并且具体取决于团队容量。在当前工作转移到流程的下一阶段之前，不能接受新工作。Scrum通过调节为冲刺计划的工作量来间接限制正在进行的工作。

Kanban中没有定义的迭代或冲刺;相反，工作项从一个阶段拖动到下一个阶段。因此，Kanban永远不会刷新。这也意味着一些Scrum仪式没有被使用。Kanban团队通常每天都有会议，尽管它们不是必需的。由于没有定期安排的冲刺计划会议、冲刺演示或冲刺回顾，因此该过程更加简化。这些仪式中的一些行动可能是非正式的，也可能不是非正式的。通过记录和评估对象从一种状态到另一种状态的移动，并根据发现的问题实施持续的增量更改，可以实现持续改进。

与Scrum不同，Kanban不分配角色。所需的唯一职能是团队成员;然而，通常会有一个项目经理来监督团队和产品待办列表。一个Kanban通常就足够于服务许多基于功能的角色和/或团队，这些角色和/或团队只处理具有特定状态的项目。例如，开发团队可以将内容从“待办事项”移动到“进行中”，然后再移动到“测试”，而测试团队将在“测试”中测试项目，然后将其移动到“完成”。

仍然需要许多产品待办列表管理操作（例如确定工作项的优先级和整理工作项），以确保完全理解特定工作项并准备好进行处理;但是，估计工作项是可选的。

Scrum与Kanban

Scrum

• 有时间限制的冲刺
• 冲刺的仪式和责任已经建立
• 专注于快速完成一组工作
• 冲刺速度
• 可预测性是重点
• 限制在冲刺中正在进行的工作并且根据冲刺策略依次分配
• 已分配职责（Scrum 大师、产品负责人、团队成员）
• Scrum 板以一个单一的多功能团队为中心
• 只允许更改产品待办列表，并且在冲刺期间不允许更改
• 需要更多的培训。非常适合需要重大调整的团队

Kanban

• 持续供应
• 减少程序和开销，专注于快速完成特定的事情
• 测量循环时间，重点是高效流动
• 个别商品的在制品有限
• 检索单个工作项
• 没有预定义的角色
• Kanban可以围绕单个跨职能团队或许多专业团队构建
• 随时可能发生变化 – >更具适应性
• 需要的培训更少。这对于只需要增量更改的团队来说是理想的选择

总结

在本文中，我们介绍了一些最突出的软件开发方法。您现在应该对精益、敏捷、Scrum 和Kanban以及它们在 TPS 和精益生产中的历史前身有了扎实的了解。在本系列的下一部分，我们将继续评估和比较不同的软件开发技术，例如瀑布、JTBD 和 SAFe（以及其他扩展框架），以及混合方法，以便您可以在这里集中参考所有这些方法。