在过去的三十年里，受敏捷启发的框架，比如Scrum， Kanban、极限编程(XP)和精益敏捷已经主导了软件开发. 虽然他们有共同的血统, 每种方法都提供了管理软件开发项目的不同方法，并且每种方法都有不同的优点和局限性.

在这个项目管理蓝图中，我讨论了精益和 敏捷 从20世纪中期日本的汽车制造业到当今全球软件团队的使用，追溯它们的话语演变和应用实践, 然后仔细检查Scrum和Kanban, 这是当今业界最流行的两种受敏捷启发的框架.

精益思想

“精益”一词是从 丰田生产系统(TPS)这是由丰田章一、丰田喜一郎和大野耐一共同开发的生产模式. 该系统通过专注于消除生产过程中的低效率，从20世纪50年代到70年代彻底改变了制造业. 丰田指出了低效率的三个主要原因:

1. 浪费: 废物(日语中称为废物) 穆达)由于缺陷而产生, 生产过剩, 等待, 运输, 库存, 运动, 过度加工. (现在很多公司都意识到了 未使用的人才 作为第八种废物.)

2. 过重的负担: 上覆岩层(muri)适用于人员和机器，并显示为 倦怠旷工或安全问题. 为了防止muri，丰田将生产活动均匀地分布在装配线上.

3. 不均匀: 不平衡(不均匀)可能是由于客户需求的波动或操作员速度或产品完成时间的变化造成的. 它增加了超载的风险，产生了浪费. 培训工人使用多台机器，以增加灵活性和 预测 需求可以帮助减少不均衡.

消除这些障碍, 丰田将其生产体系建立在一个被称为“准时制”的核心概念之上.这种方法最大限度地减少了生产前的过剩库存. 而不是, 该公司通过所谓的“拉动式系统”在产品完成后补充材料.”

丰田认识到质量控制必须在生产过程中根深蒂固, 需要自动化和人工智能的结合 中的. 丰田设计的机器可以在出现问题时自动停止. 该公司还授权工人在发现违规行为时停止生产.

TPS强调持续改进的必要性, 实地观察, 通过团队合作尊重他人. 丰田的理念和实践在1990年的书中得到进一步推广 改变世界的机器 詹姆斯·P. 丹尼尔·沃马克. 琼斯和丹尼尔·鲁斯，他们引用TPS作为“精益生产”的模型.”

精益发展

精益原则在20世纪90年代开始进入软件开发领域. 当时，该行业迫切需要新的方法. A 斯坦迪什小组1994年的报告 发现不到五分之一的软件项目是不合格的成功. 这些缺陷部分是由于传统的 瀑布式方法, 哪些在多年项目开始时定义了需求，导致软件交付延迟或超出预算. 在某些情况下，交付物过时的原因是 市场变化 那是在一个项目中发生的.

包括瀑布的早期改进 快速应用开发这一概念最初出现在IBM，并随着1991年詹姆斯·马丁(James Martin)著作的出版而传播开来 快速应用开发. 该策略侧重于通过快速成型等技术减少浪费. 软件开发人员也转向增量开发, 在小项目的持续迭代中添加功能. 虽然这些工作方式有所帮助，但它们并不能解决与瀑布开发相关的核心问题.

另一个重大的发展发生在企业管理领域. 1996年，作家詹姆斯. 沃马克和丹尼尔. 琼斯接着说 改变世界的机器 与 精益思想. 这本书概述了……的原则 精益管理, 将持续改进和尊重人的核心精益价值提炼为五个可用于消除浪费和持续改进的规定原则. 这些想法将为……的发展提供信息 精益-敏捷方法 在未来的几十年里.

与此同时, 软件开发人员开始独立开发新的精益方法和框架, 包括Scrum, XP, 水晶, 和自适应软件开发. 这通常源于公司内部为提高效率所做的努力, 但是开发者也开始通过出版物和演示来分享他们的想法.

敏捷方法

2001年2月, 一群软件行业的领导者在雪鸟会面, 犹他州, 为软件开发中的效率问题设计一个解决方案. 的 与会者 包括几位已经推出精益启发方法的人, including Jim Highsmith (Adaptive Software Development); Jeff Sutherland, Ken Schwaber, and Mike Beedle (Scrum); Kent Beck, Ron Jeffries, and Ward Cunningham (XP); and Alistair Cockburn (水晶).

会议的结果是 敏捷软件开发宣言 (通常称为敏捷宣言)，与会者在其中列出了 12条精益原则 用于软件开发. 这些原则强调了适应的重要性 需求变更 以及客户需求, 尽量减少浪费, 并且使用增量方法更快地交付工作软件. 敏捷宣言的核心价值如今已广为人知，但值得重申. 这些价值观优先考虑:

• 个体和相互作用 超过流程和工具.
• 工作软件 超过全面的文档.
• 客户协作 超额合同谈判.
• 应对变化 而不是遵循计划.

2002年，Jim Highsmith在 敏捷软件开发生态系统. 这本书描述了早期的受精益启发的方法，如Scrum和XP，作为实现敏捷软件开发的技术.

在敏捷宣言之后的几年里, 出现了其他框架和方法, 将哲学的价值观和原则付诸实践. Mary和Tom Poppendieck出版了 精益软件开发:敏捷工具包 in 2003. 他们的方法将精益制造中的七种浪费形式作为敏捷软件开发的起点. 2010年，戴维. 安德森, 他是微软的软件工程师, 正式概述Kanban, 另一个精益启发的方法, 在他的书中 Kanban:技术业务的成功进化变革.

今天，两个最突出的敏捷框架是Scrum和Kanban. 我将在下面的部分中讨论这两个框架, 展示他们之间的异同.

Scrum

Scrum已经被证明是最流行的支持敏捷的框架, 87%的受访者使用, 根据 2022 敏捷状态报告. (许多参与者使用了不止一种框架或方法.“scrum”一词起源于橄榄球, 它描述的是球员围绕球的紧密队形. 它是由Hirotaka Takeuchi和Ikujiro Nonaka在一个制造业背景下引入的 1986 《欧博体育app下载》 article. 他们用这个术语来描述将项目推进到“前场”所需的团队合作.”

1993年，当Jeff Sutherland和Easel公司的同事开始实施Scrum过程时，Scrum进入了软件行业. 两年后, Sutherland和Ken Schwaber在一次软件行业会议上发表了一篇关于Scrum开发过程的论文. Schwaber随后与Mike Beedle合作，在他们2002年出版的书中详细介绍了这种方法 使用Scrum进行敏捷软件开发. 同年, Scrum联盟由Schwaber成立, along 与 Mike Cohn and Esther Derby; since then, 它已经成长为世界上最大的敏捷和Scrum认证和专业网络组织.

Scrum概述

Scrum是一个用于软件开发的增量和迭代框架. 它的原则和实践帮助团队在短周期内工作, 能够快速响应反馈和不断变化的需求. 框架是规定性的，具有明确定义的团队结构、工作流、事件和术语.

Scrum涉及自组织、自我管理的团队，通常由5到7个团队成员组成. 其中一个成员被称为 Scrum master:这个仆人式领导者促进协作并执行Scrum流程, 但不负责分配任务或产品交付. 另一个成员， product所有者, 定义团队的愿景, 与其他利益相关者合作, 并最终接受或拒绝团队的工作. Teams are cross-functional; members work together and are not bound to distinct roles like architect, 程序员, 设计师, 或测试人员.

工作发生在被称为sprint的短的、有时间限制的迭代中，通常持续时间为一到四周. sprint关注于在sprint开始之前建立的优先级“产品待办事项列表”中的工作项. 团队的目标是在每个sprint结束时交付可工作的软件，从而实现快速的反馈周期.

Scrum过程

在冲刺开始之前，产品负责人创建一个产品待办事项列表. 待办事项列表通常从称为“用户故事.故事从终端用户的角度定义产品特性. 研究和原型任务被称为“尖峰”，有时需要在团队开始一个故事之前完成. 产品负责人按优先级顺序安排积压的工作.

一旦产品待办事项列表被创建并确定了优先级，正在进行的待办事项列表细化过程就会接管. Scrum团队审查一系列故事和其他任务. 他们与产品负责人和Scrum管理员会面，讨论每个故事的“验收标准”.e.(由产品所有者指定的可测试需求). 他们还评估复杂性、风险、规模、实现策略和其他因素. 一旦参与者对每个故事建立了共同的理解, 他们通过与之前的任务进行比较来估计完成任务所需的工作量, 很容易理解的工作，并分配基于大小的值，称为“故事点.”

正式启动冲刺, Scrum主管负责组织Scrum团队和产品负责人之间的冲刺计划会议. 团队决定其冲刺能力, 基于可用的时间和资源，它可以处理的故事点的数量是多少. 产品负责人展示产品待办事项列表中的项目, 团队讨论每个故事，并分解故事所需的子任务，以实现“完成的定义”(国防部). 他们继续从积压中提取故事，直到达到冲刺能力. 这些故事被安排在一个叫做Scrum板的表格式展示上, 在sprint期间，团队将在哪里跟踪进度. 在回顾了sprint范围之后, Scrum团队(而不是Scrum主管或产品负责人)承诺完成这项工作.e.(“冲刺待办事项”)，然后冲刺开始.

在冲刺期间的每一天的开始 Scrum master 便于简要介绍, 与Scrum团队和产品负责人进行15分钟的会议，以计划和审查进度. 这种简短的会议被称为“每日scrum”.“每个人都简要汇报了前一天的工作, 今天的工作计划, 还有任何障碍. 当团队成员发现障碍时, Scrum管理员将该项目添加到“障碍待办事项列表”中,为团队提供可见性. Scrum管理员负责解决障碍待办事项列表中的问题.

除了维护Scrum板之外，Scrum管理员还通过燃尽图来监控进度. 图表显示了已完成的工作量，用描述点来衡量. 剩下的故事点显示在Y轴上，剩下的时间显示在X轴上. Scrum管理员在团队完成故事时更新sprint燃尽图.

在冲刺结束时, Scrum管理员促成了一个sprint演示会议，团队在会上使用工作软件展示每个完成的故事. 如果满足所有的验收标准，产品负责人将批准故事. 如果一个故事被拒绝, 产品负责人识别不足之处, 故事按照优先级顺序返回到产品待办事项列表中. 经常, 故事中被拒绝的部分被转换成一个单独的故事, 原作是封闭的.

在sprint演示之后, Scrum管理员主持最后的会议，即sprint回顾会议. 团队对sprint进行反思，并评估哪些进展顺利，哪些不顺利. 这个过程生成一个改进行动项的列表, 哪些可能会被添加到产品待办事项列表中，或者导致团队章程的变更.

Scrum的优点和缺点

因为Scrum团队对待办事项进行优先级排序，并在总是产生工作软件的短迭代中工作, Scrum允许客户确定他们喜欢什么(不喜欢什么)，并在产品开发期间请求更改. 流程和管理的间接成本更低，从而导致更快、更便宜的结果.

然而，在某些情况下，Scrum并不是最好的项目管理过程. 组织应该了解这个框架可能产生的问题:

• 透明度: Scrum增加了透明度和问责制. 虽然透明是有利的, 当问题和糟糕的表现暴露出来时，可能会让人感到不舒服, 如果在持续改进的Scrum框架内处理不当，就会导致阻力.
• 团队经验与承诺: 缺乏经验或未承诺的Scrum团队或Scrum管理员可能会因误用Scrum框架而导致严重的问题. 因为团队成员没有 定义角色，所有成员必须具备相关的技术经验. Scrum还受益于来自组织其他部分的承诺.
• 范围蠕变: Scrum的主要优点之一是团队和涉众可以在此过程中调整优先级和范围, 但如果不自律，这也可能是一个缺点. 范围蔓延对于没有确定结束日期的项目来说是一个特别的问题, 因为涉众可能会继续添加工作项.
• 定义不清的工作: 定义和理解不佳的用户故事或任务可能导致返工, 不准确的估计, 范围蠕变. 尽管Scrum优先考虑开发工作软件 文档，产品负责人必须清楚地传达标准和期望.
• 缩放: Scrum最适合小型团队. 大型团队需要一个 不同的方法.

对于需求不确定或预计会变化的项目来说，Scrum是一个很好的框架. 最适合有经验的人, 激励团队, 因为它使他们能够组织工作，评估进展和问题. 随着时间的推移，Scrum团队经常会改进并变得更有效率.

Kanban

Kanban 是专注于可视化的敏捷管理过程吗, 工作流, 限制正在进行的工作. 这个概念直接来自TPS，其中的术语 Kanban (或“招牌”)是指产品和材料上的标签. 当一个丰田工人移除Kanban并把它送到生产线上, 启动了一个新订单.

软件开发人员在David J. 安德森2010年的书 Kanban:技术业务的成功进化变革，其中概述了微软使用的技术. 近年来，它的使用范围迅速扩大. 的 2022年敏捷状态报告 发现56%的敏捷团队使用Kanban, 使其成为继Scrum之后第二流行的方法.

Kanban流程

在软件开发中，Kanban类似于Scrum的一个轻量级且不那么严格的版本. 团队使用Kanban来可视化正在进行的工作. 该板类似于Scrum板，但工作流程并不是在时间限制的sprint中推进的. 而不是, Kanban允许持续的工作流程，但根据团队的能力限制了每次占用每个状态的项目数量. 在现有工作进展之前，团队不能拉出新工作.

因为Kanban团队不需要在sprint中工作, 团队没有按照规定的会议流程进行规划, 产品演示, 回顾, 诸如此类. 持续改进是通过跟踪和分析项目的流动，并在发现问题时进行增量改进来完成的.

Kanban并没有规定团队成员的具体角色 项目经理 经常促进活动，并确保工作项的优先级和清晰的理解. 单个Kanban甚至可以跨团队共享.

下表是Kanban和Scrum的总体比较:

总的来说，Kanban是一种高度适应性的方法，非常适合团队进行增量 产品的改进. 它需要的培训比Scrum少，而且更灵活. Kanban可以与其他框架结合使用，甚至可以 在企业规模上实现.

超越蓝图

根据斯坦迪什集团, 实现敏捷框架和方法的项目大约是 成功的可能性要高出四倍 比那些使用更传统的方法. 用于软件开发的最流行的受敏捷启发的项目管理蓝图在精益制造和TPS中有其历史根源，并在过去三十年中改变了软件行业.

对精益有很好的理解, 敏捷, Scrum, Kanban是项目管理领域的基础，在一个地方解释它们可以在团队和公司扩展使用时进一步持续改进和增长 瀑布，爸爸，安全，及其他 混合的方法.

本文最近进行了全面更新，以纳入最新和最准确的信息. 下面的评论可能早于这些更改.