Scrum 的精益化

由 David Starr。 David Starr 是聚焦提高软件开发的专业的 Scrum.org 的首席软件工匠。 他还成立了在线技术社区 ElegantCode.com。

2012 年 7 月

检查 Scrum 框架的内部学习质量与各种方法来帮助 Scrum 团队提高使用精益化思维。

应用于

Team Foundation Server

Overview

Seeing Scrum Through the Lean Lens

Toward Leaner Scrum

Conclusion

有关敏捷软件开发的当前讨论不包含用于计划，监视和执行软件开发事件的三个 Scrum, Lean, 和 Kanban 工具。 这些工具通常由声明 Scrum 框架和精益化思维可以很好地协同工作的一些敏捷开发从业者比较和对比，当其他人将这些工具看作交付软件的根本不同方式。

概述

Scrum 很欢迎；其团队生命使用敏捷的开发方法、使用 [1] 的 92% 报表。 对成功的 Scrum 进行采样使得许多团队能够在基础 Scrum 框架之上使其做法更成熟。 本文检查了使用具有 Kaizen 或持续改进思想的精益与看板技术扩展 Scrum 框架。

Scrum

Scrum 框架由 Ken Schwaber 和 Jeff Sutherland 于 1995 年引入，是团队在迭代和增量交付软件中一起使用的方法。 Scrum 团队将工作组织到称为 Sprints 的时间框中，最后一个月或更早，这每个 Sprint 中都出现了一组完整且正在运行的功能。

简单了解 Scrum 框架，并变得极受软件开发团队和其客户的欢迎。 Scrum 获得将焦点集中在 Sprint 上的跨职能性的和自发组织的团队，以传递工作的 Increment 和潜在的可发布的软件。

Scrum 是在 Scrum Guide 中编篡的，其中有文档 Scrum 的角色、项目和事件。 Scrum 指南由 Scrum 的创建者维护，且该 Scrum 在 Scrum.org 上可联机获取。

精益

精益化思维是处理系统优化的方式关注减少浪费和通过系统提高整个值流。 在最近几年，精益在制造中有一个丰富的历史记录并在软件开发圈中受到欢迎。

在应用软件开发时，精益化思维由以下七个原则体现，首先在该书中发布，“学习软件开发：敏捷的工具包”[2]。

1. 消除浪费

2. 扩大了解

3. 尽可能晚的决定

4. 尽快交付

5. 授权团队

6. 内置完整性

7. 请参见整个部分

应用将这些原则到发送软件产品工作不是结束目标。 并不是告诉某人“执行精益化”；而是让他使用精益化原则来指导其决策和选择将从整体上改进系统的技术。 例如，TDD（测试驱动的开发）这种做法通过在软件创建点检查软件的方法来创建完整的软件，因此，支持在创建过程中构筑完整性的精益原则。

Kanban

精益化思维中的根的一个技术是看板[3]，看板使用正式方法中的精益化思维，重点减少浪费、及时交付和避免给执行工作的人员带来过重负担。 不同于 Scrum，Kanban 不是一个迭代且递增的方法；Kanban 在五个核心活动上生成，而非在迭代上生成。

1. 可视化该工作流

2. 限制正在进行的工作 (WIP)

3. 管理流

4. 明确进程策略

5. 改进协作

使用 Kanban 的不同团队通常具有非常不同的过程。 看板方法是管理进程的简单技术集，然后对其进行有意优化。 就地 Kanban 很容易应用于进程，包括 Scrum。

Scrum 和 Kaizen

一旦工作软件的递增与每个冲刺 (sprint) 一致交付，scrum 团队就可以寻找改善其做法的新方法。 有效 Scrum 的核心是 Kaizen，即持续改进思想的理念。 健康 Scrum 团队在聚焦于 Kaizen 时，几乎会使用无数种做法。 像相对估计、测试先行的开发、生成自动化以及结对编程等工具和技术正好都在 Scrum 团队的主页上。

实现 Scrum 时不仅其他工具、技术和做法工作正常，而且存在在 scrum.org 中描述和管理的Scrum 扩展模型。 Scrum 的扩展模型鼓励进行致意 Scrum 并与框架一起正常工作的记录实践的社区参与。 此写入时，建议专门应用于 scrum 过程中的多个扩展学习工作。

精益化思维应用于 scrum 的优点不容置疑。 不足为奇的是，许多 Scrum 从业者已意识到通过将精益化思维应用到其 Scrum 做法中所带来的更高性能和质量。

查看整个 Lean Lens 中的 Scrum

Scrum 框架包括以下角色、项目和事件。 如果您对基本的 scrum 框架不熟悉，请在继续之前阅读 scrum 指南。

角色	Artifact — 项目	事件
产品所有者 Scrum 主管 开发团队	产品积压工作 冲刺 (sprint) 积压工作 递增	冲刺 (sprint) Sprint 计划 日常 Scrum Sprint 预览 Sprint 追溯

Scrum 指南为这些组件如何一起工作设置了四个规则，但是精益化思维提供了一个框架以在将来优化 Scrum 角色的编码、项目和事件。 Scrum 团队选择产品积压工作中的子集，以传递各个 Sprint，并将焦点集中在传递具有相应质量和功能的 Increment 上。 精益化思维可以帮助平滑中的工作流通过冲刺 (sprint) 并减少整个值流的浪费。

Scrum 和斜率工作保持高质量，用于执行的总体工作的成功是必需的。 若要查看进行的精益软件开发和 Scrum 共享的原则，请通过精益化思维简单分析 Scrum 的角色、项目和事件。

事件

冲刺 (sprint) 的异常，是所有其他事件的容器，Scrum 事件实际上仅是会议。 精益化思维通常视会议为浪费并且浪费是反复清除。

这可能导致其中一个包含不必要的 Scrum 事件。 但是，在 Scrum 中的每个事件都经过了仔细设计，以消除将以中断（或临时）方式出现的会议。 执行良好 Scrum 事件较少会议和花费较少的响应时间未计划中断的结果。

每个 scrum 事件旨在检查内容和调整内容。 该检查支持将学习和生成完整性扩大到创建进程的学习原则。 在 scrum 事件支持推迟决策和查看整体的学习原则期间改变计划、要求或其他项目。 下表显示了 Scrum 事件和在每个过程中检查和适宜的事件。

Event	检查	适合的
积压工作梳理	产品积压工作	产品积压工作
Sprint 计划	产品积压工作 以前的递增	Sprint 目标 冲刺 (sprint) 积压工作
日常 Scrum	冲刺 (sprint) 积压工作 冲刺 (sprint) 目标的进度	冲刺 (sprint) 积压工作 每日计划
Sprint 预览	最新增加 最新的冲刺 产品积压工作	产品积压工作 其他长期计划
Sprint 追溯	最新增加 最新的冲刺 Scrum 团队自身 技术实践	Scrum 团队行为 技术实践 在 Scrum 内使用工作管理实践

Artifact — 项目

Scrum 项目被视为简单得不能再简单。 当它们仅包括需要完成该作业的详细信息时，由 Scrum 团队传递的要求、计划，甚至软件非常有用。

产品积压工作

在完美的世界中，不需要创建超出人们只讨论的要求。 请求该软件的人员理想情况下会通过这些的创建从本质上理解，而不需该要求的中间表达。 当在非常小的团队时用客户关系关闭，只会不缩放。 在提供功能之前创建要求是计划必需的。 精益看到要求为库存，在精益化思维中通用浪费并因此需要最小化。

在 Scrum 中，要求在产品积压工作中管理，规定非常少的窗体或结构。 不要求产品挤压工作项为高度详细或完全表示。

在计划工作需要维护产品积压工作和要求时，理想的用法是创建并优化产品积压工作项的一点实际工作开发组。 有效的 scrum 团队避免创建在从不能工作的产品积压工作的要求。

冲刺 (sprint) 积压工作

在完美的世界中，不需要计划。 开发团队可以简单的接受从队列中的下一功能请求，忽略该要求的上下文和成本。 在处理工作的简单模型是非常灵活的时，它不会考虑软件开发在本质上是复杂工作。 即便计划简单且缺乏详细信息，具有重要复杂性的产品开发都能从计划中获益。

Scrum 指南将冲刺积压工作定义为为冲刺选定的产品积压工作项的子集，以及传送它们的计划。 冲刺积压工作为该冲刺显示一个项目的工作的库存（浪费），至少每天获取改进。 此日常优化能保证该计划不是承诺，并允许开发团队在最近负责的时刻之前延迟实施决策。

Scrum 团队生成几乎不能满足的要求和计划，以削减其成本。 最小化库存的精益方法允许延迟决策并授权该团队在冲刺 (Sprint) 内进行自行组织。 Scrum 团队的重点不是要求或计划，而是要在各个 Increment 中传送的值。

递增

每个冲刺包括工作软件的至少一个渐进式增加的发运。 产品增量仅为 Scrum 项目，而不通过精益化思维考虑浪费。 尽管如此，产品增量可以在它浪费。 浪费存在未使用功能、缺陷、未完成功能，难以维护的代码或错误分解的设计形式。

高绩效 Scrum 团队严格地消除产品自身的浪费。 通常，通过频繁检查整个冲刺 (Sprint) 过程中的递增和始终保持高质量来实现这一点。 这意思到生成完整性的精益原则的精髓。

Scrum 团队通过在传递 Increment 时牢记 Lean 原则受益。 Scrum 框架本身确保增量打开以供在冲刺审核的检查。 在 Sprint Review 中接收有关 Increment 的反馈是扩大了解的基础。

角色

仔细平衡 Scrum 规定的角色，在其中授权 Scrum 团队并平衡张力。 Scrum 主管、开发团队和产品所有者协作才能成功，需要每个人看到其他方面。 这种协作确保 Scrum 团队成员查看整个 Scrum 系统并通过支持任一角色（而非其他角色）以使次要优化 Scrum 团队的决策透明化。

Scrum，共同创始人 Jeff Sutherland 注：成功的 Lean 实现的基础是从下到上的智能和具有实现管理器的已授权工作人员。 Scrum 的自我组织开发团队体现授权员工 Lean 想法，他们能够促使在该组织中进行学习而不是将其口述给他们。

Scrum 特有的是 Scrum“主管”一角，以下 Scrum“指南”对此进行了介绍：

Scrum 主管负责确保已理解和执行 Scrum。Scrum 主管通过确保 Scrum 团队是否遵循 Scrum 理论、实践和规则实现此操作。Scrum 主管是 Scrum 团队的雇佣主管。Scrum 指南 - 2011 年 10 月

要很好掌握 Scrum 的一个主要技能和活动是简化。 在大多数情况下，Scrum Masters 便于 Scrum 事件。 Scrum 主管是经理，尽管是 Scrum 的采用和遵从，而不是人。

更接近 Scrum

使用“精益化思维”考虑并处理 Scrum 公开的问题常常会生成高返回，而且对于维持 Kaizen 区域性而言，这是一个非常好的方式。 Scrum 团队仍了解如何将 Lean 应用于 Scrum，但是，许多实践都很受欢迎，因为它们证明 Scrum 团队更有效。

具有用于知识工作的许多常见实践和技术，该知识工作直接支持学习原则。 多项技术在下测试与在它们的是只但在scrum团队可能意识到。

遵循肯定不是技术的详尽说明列表，而是简单地示例一些 Scrum 团队如何提高使用公用的技术给实习者学习。 此外，每个方法可以多种方式应用。 此处仅描述了几个精益化技术。 Scrum 团队可能会以与本文档中描述的不同方式来处理以下情景。

正在消除浪费

最基本的精益化做法可能是消除浪费。 精益考虑浪费任何内容不严格要求生产所需的结果。 在软件开发的常见浪费包括:

1. 未使用的代码或功能

2. 导致修改的缺陷

3. 等待某些花费的延迟或时间

4. 从一个人员、团队或业务进程切换到另一个

5. 极详细要求

6. 要求不足

7. 缓慢通信或不良的通信

某些浪费不是那么容易避免且甚至是必需的。 在最严格的定义下，例如，要求文档是浪费的。 表示需求终究不会发送到客户端的索引卡。 因此浪费了索引卡。 要求卡片本身不是产品功能；它表示必须完成创建功能的工作。 要求存在卡片帮助开发人员认真考虑和跟踪其工作。 在大多数团队将此看做必需的做法时，它易于标识为浪费。

在某些浪费是必需的时，许多可以减少、优化或者甚至移除。 在软件开发值流的某些浪费，例如签入代码的太长等待，轻松地识别并已清除。 软件开发团队中找到的其他浪费（如在开发可能开始前创建要求高的文档）作为区域性并需要大量时间和精力才能发生根本性的改变。

方案

Scrum 已有六个月。 开发团队使用每个两周的冲刺和所有测量的质量指示器明确趋势生成软件的可用递增。

精益方法

Scrum 主管满足讨论指导其团队变得具有更高的工作效率和质量。 scrum 主管建议避免精益化思维规定的浪费。 同意尝试该想法，scrum 主管查找浪费的示例并将其分类到两个列表，即可立即消除的和那些要求用时间来管理的列表。

第一个列表包含要由 Scrum Masters 本身或开发团队清除的浪费，并不需要权限或等待。 其他标记为“浪费积压工作”并标识所有同意标识的浪费，但将花费很长时间才能更改。 两个列表的示例如下所示:

立即处理	浪费积压工作
这些版本都必须明确因此维护的生成计算机手动执行。 网站打包是一个手动 ZIP 过程。 自动化此 开发人员都使用一个共享开发数据库，并更改数据频繁地中断开发流。 移动到每个开发人员的专用开发数据库所在的模型。 测试未编写，直到功能存在。 鼓励并指导适用于测试专家的测试先行实践。	在为所有功能编码之前创建的 UML 模型。 对相同开发团队的成员遵循在小，临时讨论的办公室之间的办公室格式会影响的通信。 尽可能引入安装程序，以便部署操作中不是手动的。 Bug 跟踪报告系统中的许多字段都是必需的，但是极少使用。 用在创建数据的事件可以通过使其可选来保存。

使用这些列表武装，Scrum 主管为立即提高使用可操作的建议处理它们单个的 Scrum 团队。 虽然 scrum 主管指导其团队为更高的质量级别，scrum 团队的自我组织性质要求团队对值更改并为发布他们创建一个计划。

冲刺追溯是提高共享思想的专门论坛，并用于获取支持进行执行。 有效冲刺追溯通常导致发布改进的计划，支持 Kaizen 区域性。 消除或提高了积压工作跟踪的浪费可能需要在 scrum 团队之外的工作。 这是其工作包括提高 Scrum 的使用以及在组织内鼓励灵活性的 Scrum 管理者的职责。

限制正在进行的工作

方案

有五个成员的开发团队使用 scrum 12 周，完成与混合结果的三四周内冲刺 (sprint)。 当生成的增量在实现 Scrum 前面过程中创建的软件具有更高质量时，似乎完成较少工作和开发团队成员不一起协作仍然有用。 日常 Scrum 提供团队的每个人都在其任务的隔离的工作个日常提醒，不过，这种情况不会改进。

在冲刺计划期间，开发团队创建要求工作的“执行”列表提供为冲刺选择的每个产品积压工作项。 在冲刺 (sprint) 计划期间，此方法创建冲刺 (sprint) 积压工作以及在冲刺 (sprint) 中用于跟踪开发团队的进度的机制。

开发团队在开发团队工作区域使用在墙上的可见任务板跟踪其在冲刺中的进度。 在最后一个冲刺期间，Scrum 主管在日常 Scrum 之前每天为委员会照相。 以下显示 一些照片。

1 天	4 天
9 天	14 天
17 天	20 天

Scrum 主管与开发团队共享了这些图片。 某些功能易于清单，例如：

• 与开发团队中的成员相比，定期进行的任务更多。

• 第二天，开发人员将功能 C 的所有任务都送入“正在进行中”状态，并将其留在该状态直到冲刺 (Sprint) 结束。

• 功能 B 直到冲刺 (sprint) 结束才开始处理，且尚未完成。

• 功能 C 在冲刺 (sprint) 过程中开始处理，但尚未完成。 工作项功能 C 的开发人员由缺少帮助失败时，不熟悉问题。 尽管在她会感谢一些帮助的日常 scrum 的她的细微提示，但从未具体化，因为其他团队成员聚焦于他们自己的工作和不负责功能 C。

• 在冲刺 (Sprint) 规划阶段，功能以优先级顺序置于冲刺积压工作中，令产品所有者非常失望的是，功能 B 并未在冲刺过程中完成，而它的顺序在提供的其他功能之前。

• 多个功能立即正在进行，导致非常代码的不同部分同时更改所有。 在冲刺期间，那么，当开发人员不知道影响了彼此的代码时，这导致了多个生成失败和重做。

所有这些观察点在多种事情上一次返回到开发团队的工作实践。 在任务和尝试之间切换注意侧重于许多项目同时生成感觉开发团队的成员重载和严重影响由 Sprint 积压工作。 相应地，每个团队成员集中于器工作并作为个人而不是团队的成员。

精益方法

在冲刺追溯期间，Scrum 主管解释了限制 WIP 的想法到决定尝试该技术的开发团队。 开发团队决定实现三个设计的新规以减少下一个冲刺中发 WIP：

1. 在冲刺 (sprint) 积压工作中的功能按从上到下的顺序实现。

2. 一次进行的项目不可以超过 3 个。 如果第四个项目正在进行，团队将暂停当前工作，确定系统为何存在瓶颈。

Scrum 主管在下一个冲刺中再次拍图片。 下面呈现了几张照片。

2 天	8 天
12 天	20 天

在冲刺追溯期间，执行以下有关此最新冲刺期间如何更改内容的观察的开发团队中再次共享照片：

1. 开发团队成员在较复杂的项一起工作。 虽然选项在有关如何完成工作上有时不同，解决差异并团队取得了整体快速进度。

2. 开发团队成员开始了解他们此前未关注的产品功能。 每个为整体产品报告集体所有权的感觉。 根据仅集中在其了解的功能的个人之前的实践，这形成了鲜明的对比。

3. 立即显着减少了协调更改的复杂代码中的许多不同的区域上方。 事实上，非常因此，开发团队的工作效率特别是增加而增加。

4. 虽然功能 E 未在冲刺 (sprint) 中完成，发送的所有功能有比函数 E 较高优先级。 即使没有此低优先级功能，产品所有者是高兴和决定将递增传递到客户端。

尽管在冲刺 (sprint) 计划期间创建冲刺 (sprint) 积压工作限制为冲刺 (sprint) 选择的工作批量大小，进一步限制的 WIP 在冲刺 (sprint) 中可能导致更快的吞吐量和更高的效率。 在冲刺 (sprint) 过程中限制 WIP 还可以提高协作并降低技术专家的工作得不到其他人的理解的风险。

减少等待时间

大量时间是花费在等待在软件开发中发生的内容。 很容易在开发团队中大仙此种形式的浪费。 冲刺 (sprint) 期间，新的 Scrum 团队发现自己在等待很多东西，包括：

• 执行某项操作的权限

• 完成较长处理

• 从另一个团队或个人的提交

• 要运行的测试或要完成的验证

• 访问所需资源

• 团队以外人员的协作

错误等待的 Scrum 团队的效率比时间客户差，并且业务花费正在等待的软件来集成、打包和附带。 此问题随着开发组织的规模的增大而严重。 多个开发人员或团队添加到项目时，集成工作到单个产品的成本增加。

内置于 Scrum 的最长的等待时间是冲刺。 是所有 Scrum 事件的容器，冲刺持续时间的唯一要求是它是一个月或小于一个月。 这将用于等待软件的工作增量的事件限制为不超过一个月。 大多数 scrum 团队会以更高的频率交付工作递增。

方案

有六个 scrum 团队处理大型并复杂的软件产品的公司。 每个 scrum 团队重点关注特定功能区和通过主要产品积压工作协调工作。 Sprint 为三周并包括集成的所有开发团队工作。

以前，冲刺 (sprint) 时间为两周，但是随着产品增加，创建冲刺的复杂程度也增大。 已添加需要更多时间集成工作的新 scrum 团队，因此，冲刺 (sprint) 的长度增加以容纳集成活动。

三周获知口语为“集成周”。 新功能的集成到主代码行在此期间是主要活动。 集成团队已建立具有每个开发组代表的每个集成周。 它们直接集成活动的工作。

在集成周期间，团队集成不接受新功能，尽管他们请求为地址集成问题做出小的更改。 为响应集成团队的需要，这将导致在集成周内一系列临时代码更改。

下图在冲刺期间显示了典型的配置管理。 开发团队在每个冲刺开始创建其开发分支。 他们在第二周结束时合并其代码。 在第 3 星期中，开发团队根据需要服务集成团队的请求。

在冲刺 (sprint) 期间必须集成时，六个 Scrum 团队容量的 1/3 到当前使用完成集成。 与此同时，很多团队容量在冲刺外的活动花费。 注意上述示例中团队 5 在集成周期间没有任何工作。

增加集成周的成本是必须通常切换上下文的 Scrum 团队的中断流。 某些团队在尝试的分支和分叉的代码行保持生产力在如，增大的总体复杂过程中私有推翻需要的透明度好制定决策。

精益方法

团队的 Scrum 主管满足讨论选项。 一位 Scrum 管理者提及到她的团队在每个冲刺 (Sprint) 的前两周期间在限制 WIP 方面取得了极大成功。 Scrum 主管观察如果每个团队一次性将 WIP 限制到一个函数，可能将其工作潜在集成为每个完成的函数。

如果在所有开发团队中使用了此做法，则没有团队会等到第二周结束再集成他们的工作。 而不是等待集成新功能，每个团队现在可考虑集成到 Done1 定义部分的主代码行对于每个函数有效。

定义执行是开发组的 Scrum 的概念内容达成协议绑定适用于为 Sprint 选择的每个产品积压工作项以考虑该产品积压工作项“完成”。 有关定义执行的更多信息，请参见 MSDN 文章 完成和撤消。

在下冲刺追溯期间，那么，当每个函数完成，开发团队同意尝试集成它们的工作。 他们建立并提交以下新规则：

1. 每个开发团队一次限制 WIP 到一个函数。

2. 函数未完成，直到它在主代码行集成。

3. 在开始新功能工作之前，开发团队将使用主行的全新副本更新它们的代码行。

产生的活动会出现在下图中：

新规则已导致团队在功能传递中体验平滑流。 因为没有集成星期，不再需要开发团队空闲并在冲刺的三周内破坏。

在冲刺期间集成更改所花费的时间较最初要高，但是当持续集成模型变得更加熟悉时，每个开发团队的效率增加了。 随着时间的推移，功能随着每个冲刺 (sprint) 的增加而增加了。

由于对函数现在意味着功能集成到主代码行，功能是否实际完成不再有任何问题。 定义现在执行包括集成到每个单独功能的主代码。 集成失败的风险已显著降低。

最后，减少开发团队因集成代码而必须等待的时间的决定提高了开发团队的整体生产力，并使得对“集成周”的需要过时。 因此 Scrum 团队可能返回到较短的冲刺 (sprint)，以使产品所有者根据需要装运更多。

延迟承诺

延迟承诺是表示为学习软件开发的值的原学习原则之一。 此原则通常被描述为“等到最后负责时间为止”做出决策。

对某一操作的进程过早地承诺做出的决策没有任何价值，因此继续进行思考。 为什么不等待，直到必须作出决定时，因此，将知道有关问题的最可能信息？ 这限制做出错误决策的风险并且允许更多用于选择或到图面的操作路径的时间。

方案

在冲刺计划期间，开发团队为如何实现为冲刺选择的 PBIs 创建详细计划。 通常计划会在冲刺 (sprint) 期间更改，因为已了解了更多的信息。 在工作不太明确时他们才会注意到计划更改更多。 了解浪费的未使用要求，团队希望避免此计划返工。

提交到放弃其他选项的操作需要的一个。 这通常会使那些注意放弃想法的承诺。 可能有多种方式实现给定功能，但当已选择操作的进程后，开发人员可以停止考虑其他方法解决问题和创新的潜在拒绝。

精益方法

开发团队决定允许在冲刺积压工作中定义的较大和较小项。 实际上，他们决定产品积压工作项可能接受冲刺(sprint)不带详细计划。

当更多了解时，开发团队等待以后创建详细计划。 对于它们来说，当实际开始工作或工作正在进行时，这意味着将冲刺 (sprint) 积压工作项分割为小部分。 这在实际需要之前延迟详细计划，并允许该团队更改更接近工作的实现的想法。 它还确保使用最佳可能计划而不是执行可能不再有效的计划。

这将在接近实现该功能时更好地了解实现选项。 在冲刺中实现以前有的功能期间，开发团队已了解有关该产品的更过信息，并具有如果需要调查的允许时间。

可视化工作流

在看板方法的第一步需要由团队使用的可视化实际工作流。 这意识到精益的“参看整体”原则并需要显示实际工作流，而非业务过程文档或某些其他已有的模型规定的理想化版本。 有用的可视化表示实际进行的操作。

一旦存在工作可视化，工作就可以在其中进行跟踪。 典型阶段封闭的示例模型或瀑布、开发过程在如下所示的进度中几个特征中显示。

Scrum 团队多年来使用工作流可视化来查看 Sprint 的工作。 Scrum 开发团队中工作流可视化的最常见的形式是 Scrum“任务板”或简单“Scrum 板”。 此可视化通常比上述所示的模型更简单，并且可能与以下模型类似。

工作流可视化的典型窗体在很大程度上将受到跨功能开发团队的 Scrum 规定影响。 跨功能开发团队的焦点是 Scrum 框架的定义特征。 它在每个冲刺 (sprint) 中需要交付可用软件完整递增的跨功能团队具有所有功能。 团队成员同时执行软件开发的许多事件。

一旦他们一起实现一个功能，跨功能团队可能执行所有内容的一点。 这与其中专家一次侧重处理某活动所有事项的计划驱动模型不同。 此外，跨功能团队成员所处的专业领域可能不同，但是，任何团队成员都定期处理所有交付该软件所需的活动，无论这种活动是否属于个人的专业领域范畴。 跨功能软件开发团队可能会超过私有的专家团队。

方案

开发团队交付可用软件的增加，但团队成员无法很好地协作。 编码方处理隔离的问题在传递代码到必须通过验证使用在冲刺结束的测试人员之前。

在测试冲刺 (sprint) 结束时剩余的事件极少，因此开发团队有时跳过这一步并在回归测试未完成时提供增量。 缺陷在早期找到具有功能回归测试以允许完成的生产中被找到。

精益方法

Scrum 主管与开发团队一起使用，用于对每个冲刺中引发的实际工作流建模。 即使团队在日常 scrum 使用典型的 scrum 键盘，它很快变得显而易见实际工作流是阶段封闭的过程。 团队生成以下模型反映其实际工作流：

Scrum 主管帮助团队了解通过以跨功能的方式工作获得的效率中的潜在增量。 虽然半信半疑，团队成员同意尝试改进其工作流使其更为跨功能性。

开发团队保留可视化完整，并将其用于在冲刺中监视工作，但是同意查找折叠阶段的每个机会。 即团队查找两个阶段可以合并到一个的可能性，从而取代提交用的协作。 他们每次通过有意更改开发团队内的个人合作方式进行此操作。 在每个冲刺追溯，它们修改模型反映团队进行的增强功能。

首先，Arnie 和 Kyle 同意在合并设计和编码阶段方面展开合作。 他们尝试多种方法来提高协作，之后了解更改为以下内容的工作流：

在实现引起以下更改的代码之前，此开发团队很快了解到创建功能回归测试已失败。

接下来的几个月里，开发团队将寻找机会减少交付管道中的阶段数。 团队更改区域性为专家的实际上共享其知识和个间距成功帮助工作流。 当多个协作发生，启动考虑“专用全科的”团队成员。

作为在团队增加的协作，因此，执行有关创建软件和团队成员彼此的职责见解的集合知识。 这种协作在冲刺 (sprint) 期间会自然折叠工作阶段，并在冲刺 (sprint) 过程中出现的工作流的更简单的可视化中反映出来。 开发团队现在是跨职能部门的，并如下所示相应地查看其实际的工作流。

在消除进度阶段的团队迭代反射处理阶段最终导致首先规定的工作流 Scrum，正在进行中的单个开发阶段。 这显示了完全优化看板最终将其自身显示为传统 Scrum 板。

内置完整性

许多软件技术着重于将集成内置与创建进程中。 创建时，软件设计模式，测试先行的开发 (tdd) 技术、重构并对编程所有查找增加软件的质量。 使用增强创建过程早期质量的技术确保了团队不依赖事实后质量检查以“测试创建过程后面部分的质量”。

方案

开发团队试行了测试先行开发技术并成功使用由开发人员在开发期间创建的单元测试中验收条件的 Given/When/Then 表达式。

给定/时间/条件验收标准格式
给定 <某种初始上下文> 当 <some action occurs> 时 然后 <this is the result>

团队拥有良好、可读的单元测试套件，其开发人员取决于使用自动测试工具频繁引导其设计和测试该代码。

虽然此方法在单元测试级别是有效的，开发团队的测试的专家仍使用 Microsoft Word 文档创建功能测试的验收条件。 在编码功能并完成后，将手动验证它们。 由于这些测试不会运行，直到编码方视为函数完成，缺陷的一个重要数被测试专家找到。 这在冲刺 (sprint) 内导致返工，并且有时会导致在冲刺 (sprint) 审查之前未完成的功能。

精益方法

在冲刺 (sprint) 追溯时讨论验收条件工作流，开发团队决定尝试以下操作：

1. 测试的专家将创建不作为 Microsoft Word 文档的验收条件，但作为不具有内部实现的失败的自动化测试。

2. 新的自动测试将在每天 5 AM 和 3 PM 运行，生成测试通过的报表和故障。 新创建的测试总是失败。

3. 当代码方选择新的功能来工作时，他们通过实现存根验收测试的功能开始。

4. 测试可能由代码编写者改进，但与创建它的测试的专家协作，因此保留了测试的原始用途。

5. 该测试通过前，该功能未完成。

6. 所有测试必须在冲刺 (sprint) 之前测试通过。

使用此方法的若干冲刺 (sprint) 之后，减缩缺陷和返工。 开发团队监视每天自动测试运行两次更新的报告，并发现测试的成功和失败可以显示为趋势。 团队创建使用每个自动的测试运行获取更新的报告。 报表显示验收测试通过和失败结果，其趋势跨两周冲刺的课程。 图形如下所示。

开发团队发现在其日常 Scrum 查看此报表可以发现比在典型燃尽图中更多的值。 Scrum 主管确认此新关系图可作为冲刺积压工作中的关键部分。

Scrum 指南指出冲刺积压工作为冲刺的所选产品积压工作项的集，以及传送它们的计划。 对于此开发团队，该计划自验收测试失败后开始构建，完成进度通过分析测试的成功和失败数量趋势进行跟踪。 使用在冲刺积压工作的任务，测试可以添加，删除或在冲刺中修改。 给定测试的创建通常会通过多达几天的时间导致相应功能的实现。

现在根据功能回归的要求和机制使用实际的自动测试以为这测试是要求。 这还允许将冲刺 (sprint) 的工作视为通过自动测试的进度。 此测试先行开发技术重新定义团队考虑使用 Scrum 的方式，并使要求验证来注入到创建过程本身，从而生成产品的完整性。

极为流行的 Scrum 框架的许多方面都支持精益化原则。 由于 Scrum 团队逐渐成熟和改进，因此通常在迭代和增量开发中为查找多个值查找精益化思维的有效工具。

在特定技术可能存在时，在维护正常软件开发团队中持续关注改进是非常重要的。 Scrum 框架的灵活性足以提供如在看板中找到的那些精益提高方法。 查看整个“精益化思维”的 Len 的 Scrum 常导致更好的质量，更高的效率和更新的浪费。

出于优化 scrum 团队的实现可能很棘手。 在查找方法改进时，不要完全让 enemy 足够好。 与交付客户重视的高质量工作软件相比，Scrum 的完美显得不那么重要，因此焦点应首先放在能够真正改善产品的方面。

引用

1. West, D. (2011). “XXXXX”。 Forrester Research（福雷斯特研究公司）

2. Poppendieck, M. P。 (2003). 学习软件开发：敏捷工具包。 Addison-Wesley Professional。

3. Anderson, D. (2010). Kanban - 您的技术业务成功的发展更改。 蓝色漏洞按。