精益软件开发

由 david J。Anderson.David J.anderson 一个本书，在敏捷管理的课程的作者 :，在 2012 年发布，Kanban: ，[1] 在 2010 年发布，并且，软件工程的敏捷管理： ，[2] 在 2003 年发布。他是于 1997 至 1999 年间，在新加坡创建敏捷软件开发方法，即功能驱动的开发的团队的成员。他创建了 MSF for CMMI process improvement，因此，他合着书已从软件工程研究院的技术说明，“CMMI 和敏捷过程：为何不是接受两个！”他是学习用于社团的创建者 (http://www.leansystemssociety.org)。他是斜率 Kanban University Inc.，该测试的测试的 CEO，并在世界上提供 Kanban 培训的质量标准组织通过网络合作伙伴和他导致一家国际管理、培训咨询公司，david J。anderson & 关联公司。（http://www.agilemanagement.net）帮助技术企业通过更好地管理指令和决策以改善其性能。

2012 年十一月十一月 2011 中，更新。

Anderson 介绍学习软件开发。

应用于

精益，软件开发，项目管理，Team Foundation Server

• Introduction

• 精益和敏捷

• 在敏捷之外的精益

• 定义学习软件开发

• 值

• 原则

• 实践

首选创造术语学习软件开发作为联盟的标题，该联盟于 1992 年 10 月在德国斯图加特由欧盟的 ESPRIT 方案组织。以下年份，Robert “Bob” Charette 在 1993 年单独的建议了“学习软件开发”的概念作为工作浏览的部分在软件项目中管理风险的更好方法术语“精益”回到 1991 年的日期，James Womack、Daniel Jones 和 Daniel Roos 建议，它们的书 已更改世界的计算机：学习生产的情景[3] 视为在用于丰田描述管理方法的英语术语。精益可能适用于软件开发的想法很早就建立了，仅在该术语第一次用于关联制造过程中的趋势和工业工程后的 1 到 2 年创建。

在它们的第 2 本书，发布于 1995 年，Womack and Jones[4] 定义五个内核精益化思维的支柱。这些是：

• 值

• “值流”

• 流

• 拉取

• 完美

这将成为未来十年主要的默认工作定义。通过消除浪费建议、实现完美的实现。在具有 5 支柱时，它是第 5 个支柱，通过浪费的活动的系统标识和其清除来完美实现，真正地用于广泛的用户。精益几乎变为独占方式与浪费清除的做法关联通过二十世纪九十年代后期和二十一世纪早期部分。

精益的 Womack 和Jones 定义没有普遍共享。在丰田的管理原则更加精细。英语中单独的词“浪费”更多地描述了以下三个日语术语：

• Muda –字面意义表示“浪费”，但提示非增值事件

• Mura–含义“不均”，也可解读为“流中的变化”

• Muri –含义“过度负载”或“不合理”

完美不仅可以通过减少非增值活动实现的，还可以通过平缓流和消除过重负载实现。此外，丰田方法基于基本原理方面并通过 20 世纪质量保证的教学有重大的影响和统计进程控制专家如 W。Edwards Deming 也为该模型提供了大量信息。

遗憾的是，“精益”的定义和有关该主题的作者一样多。

精益和敏捷

Bob Charette 受邀请了，但不能参与 2001 年在犹他州雪鸟的会议，创作敏捷软件开发 [5] 的声明。尽管缺少此历史会话，学习软件开发视为对于软件开发的几种敏捷方法之一。Jim Highsmith 专用他 2002 的章节[6] 来采访有关主题的 Bob。然后，Mary & Tom Poppendieck 继续创作一系列 3 本 [7,8,9] 书。在 21 世纪的前几个年份期间，学习原则可用于解释为什么敏捷方法是更好的。精益解释敏捷方法包含了很少“浪费”并因此生成更好的经济结果。学习原则用作“提供者权限”来采用敏捷方法。

在敏捷之外的精益

近年来，学习软件开发确实作为其自己的专业相关，但是不特别敏捷移动的子集。此演变从合成精益产品开发和 Donald G 工作的想法开始。Reinertsen[10,11] 和源自大规模系统工程和 James Sutton 及 Peter Middleton[12] 的书写中非敏捷世界的想法。我还整合了 Eli Goldratt 和 W 的工作。爱德华兹戴明和开发在流中的焦点而不是浪费降低 [13]。根据在 2005 年 Reinertsen 的要求，仅当系统准备处理它，我引入限制正在进行的工作，并且“拉”新工作的 kanban 系统。Alan Shalloway 在他的以 [14] 为主题的 2009 书籍添加了他的在学习软件开发的建议。自 2007 以来，作为软件开发专业进步的新动力而诞生的 Lean 专注于改进流、管理风险和改进（管理）决定。Kanban 在 IT 相关工作中成为了学习方案的主要使能器。显示流中的焦点，而不是浪费消除的焦点，证明持续改进的一种更好的催化剂在知识工作活动中如软件开发。

定义学习软件开发

定义学习软件开发具挑战性，因为没有特定的学习软件开发方法或过程。精益不等同于个人软件进程、V 模型、螺旋模型、EVO、功能驱动的开发、极限编程，Scrum 或测试驱动的开发。如果观察为与学习软件开发移动的值和学习软件开发原则对齐，则软件开发生命周期过程或项目管理过程可以说是“精益”。因此预期后面可以跟、名为学习软件开发的一个简单的配方的那些失望。通过了解 Lean 准则和采用 Lean 的核心价值，您必须使用或定制您自己的软件开发流程。

在学习软件开发中具有思想的若干学校。最大和可导致争论，school 是学习用于社团，包括唐纳德 Reinertsen，吉姆・萨顿、阿伦 Shalloway，bob Charette，mary Poppendeick 和 david J。Anderson.在社团及其信条位置的窗体之前分别进行开发的 mary 和个 Poppendieck 的工作，如克雷格 Larman，Bas，Vodde[15,16]，因此，最近，显示 Coplien[17]工作。本文、通常是学习用于社团视图的委托如使用其信条表示和提供自己的想法聚合和摘要。

值

学习用于社团显示了其信条[18] 在 2012 学习软件&用于会话[19]。这基于发布的设置值的年前。这些值包括：

• 接受人文环境

• 接受复杂 & 不确定性对知识工作是自然的

• 致力于更好的性能结果

• 在启用一种更好的社会学结果时

• 查找、接受和询问大范围内规则的想法

• 基于值的社区增强正更改的速度 & 深度

接受人文环境

通过人类了解工作如执行软件开发。我们方在本质上非常复杂，并且，逻辑思想家时，我们还可以通过我们的情感和一些固有的兽性特征不可能相当的避免指引。设计我们要在其中工作的系统或过程时，必须考虑心理学和神经心理学。还必须满足我们的社会行为。人类天生具有感性、社会性和部族性，而且，我们的行为也会因疲劳和压力产生变化。成功进程将是拥抱的那些并满足人文环境而不是尝试拒绝并假定逻辑，计算机般的那些行为。

接受复杂 & 不确定性对知识工作是自然的

客户行为和市场是不可预知的。通过处理的工作流和工作人员的集合是不可预知的。缺陷和所需的返工是不可预知的。在软件开发中的许多级别具有继承机会或看似随机的行为。在传送时，往往更改项目的目的、目标和范围。某些此不确定性和变化，不过，最初未知，可知的意义上来讲，对其进行研究和分配，并且其风险管理，但是，某些变化事先不能了解且不能足够预期。因此，学习软件开发系统必须能够响应个事件，并且，该系统必须能够适应更改的情况。因此所有精益软件开发进程必须存在于允许（该进程的）适配性的框架内，以展开事件。

致力于更好的性能结果

人类活动，如精益软件开发，应专注于提高经济效益。当它分配两个到业务中的值和客户的优点时，大写的门是可以接受的。公司的管理投资者或所有者需要的投资回报。员工和工作人员为公平的努力执行该工作需要一个公平的支付速率。客户需要在其已提交的优点发送以交换公平的价格支付的一个好的产品或服务。更好的性能结果将包括多个值传递给客户，在较小开销，那么，当管理投资者或所有者以可能的有效方法部署的大写字母时。

启用一种更好的社会学结果

不应牺牲执行工作的线程提供更好的性能结果。创建采用人文环境尊重人并提供尊重人的心理和社会学环境的工作系统的工作场所非常重要。创建一个设备线完成大的工作就是学习软件开发社区的核心价值。

原则

精益软件与系统联合会似乎与加固学习软件开发过程的几个原则达成一致。

• 遵循系统思维与设计方法

• 可以通过构造复杂满足系统的上下文来影响紧急结果

• 尊重方（作为系统的一部分）

• 使用“科学方法”（以促使改进）

• 鼓励领导

• 生成可见性（到工作、工作流和系统操作）

• 缩短流时间

• 减少浪费以提高效率

遵循系统思维与设计方法

这在精益语言中被称为“优化整体”，这暗指需要优化的整个系统（或过程）中的输出，以及我们不应该怀着如魔法般优化整体的希望对部件进行不当优化。大多数从业者认为必然结果为 true，即优化部件（本地优化）会导致不太理想的结果。

学习系统思维和设计方法需要我们考虑外部利益干系人制造的系统的要求，例如客户和这些利益干系人所需的预期结果。我们必须学习要求的本质和比较我们系统传递的功能。要求将包括所谓“值要求，”为其客户愿意支付和“失败要求，”通常为返工或值要求的提供中失败引起的其他要求。需求错误通常有两种形式：对之前交付的价值需求实行返工，以及由于未能提供价值需求而额外提供服务或支持。在软件开发中，需求错误通常是 Bug 修复的请求和客户关心的请求或帮助桌面函数。

系统设计方法需要我们还按预期方式进行处理 (PDSA) 方法来制作过程设计和改进。W.爱德华兹戴明使用过“确定”和“功能”提示我们学习我们的系统行为的自然原理。此系统包括我们的软件开发过程和运行该系统的所有人员。将会有一个可观测的行为前导时间、质量、功能的质量或发送函数（在敏捷语言中称为“速度”）等。这些指标将展示变化，并通过研究变体的表示和传播，我们可以开发我们功能的了解。如果这与要求和客户期望不匹配，则系统将需要重新设计以缩小此差距。

Deming 也介绍功能是由系统设计影响的 95%，因此，只有 5% 由各性能提供帮助。换句话说，可以尊重人员传递不责备它们因为功能的空白比较和重新设计系统启用它们是成功的。

若要了解系统设计，必须科学了解系统功能动态学以及可能受到的影响。开发模型是为了预测系统的动态。当可能有许多模型时，一些常见部分在常见用法中：对经济成本的理解；与客户赋值的产品或服务的生产相关的所谓的事务和协调成本；约束的原则–对瓶颈的理解；并深入了解的原则–变化的学习和识别为系统设计的常见或特定和外部的系统设计。

可以通过构造复杂满足系统的上下文来影响紧急结果

复杂系统具有当迭代运行生成一个紧急结果的开始条件和简单规则。紧急结果很难或不可预知启动的条件。计算机科学实验“实时游戏”是复杂系统的示例。复杂自适应系统具有在其中一些自我意识，并使其考虑其当前规则集的程度的反射内部方法允许来实现预期结果。该复杂满足系统可以选择满足自己–更改为简单规则–缩小当前结果和所需的结果之间的空白。在播放将为复杂满足系统时，生活游戏满足的此类规则可能进行重写。

在软件开发过程中，复杂自适应系统的“简单的规则”构成过程定义的策略。此处的核心原则在于开发软件产品的信念，服务不是一个确定的活动，因此无法适应其本身的已定义过程对不可预见的事件将不会有充足的响应。因此，该进程作为我们的系统思想和设计方法的一部分，必须具有适应性。它适配通过策略接受的修改。

学习软件开发的看板方法通过将该看板拉式系统的策略视为“简单规则”利用此概念，且开始条件是可视的工作和工作流，使用系统动态的理解管理这些流，且该组织使用科学的方法理解、提议和事件进程提高。

尊重人员

该学习开发社区采用 Peter Drucker 的知识工作定义，该定义声明如果工作人员较他们的老板具有有关他们执行的工作的更多知识，则这些工作人员是知识工作者。这创建妥善安排工作人员做出如何工作和如何修改提高执行工作的方式的决策的暗示。因此应遵循辅助进程的语音。辅助进程应授权自行组织来完成工作并实现所需的结果。他们还应授权建议和实施正如“精益语言”称为的流程改进机会或“kaizen 事件”。明确过程策略，以便工作人员了解约束他们的规则是另一种尊重他们的方式。明确定义的规则通过删除担心和勇气的需求建议自律行为。通过授予他们权力和给予他们一系列显示声明的策略来对他们表示尊重可拥有包含尊重人类环境的核心价值。

使用科学方法

查找使用模型，以工作完成方式的动态信息和 Lean 软件开发系统如何运行。观察并研究系统及其功能，然后开发和应用预测其行为的模型。集合处理中的分配数据，并使用该数据了解如何将系统执行并预测它如何更改，更改辅助进程。

精益软件与系统联合会使用统计方法（如统计进程控件图表和针对前导时间和速度的基元数据光谱分析直方图）可以了解系统功能。他们还使用模型，例如：了解瓶颈的约束理论；了解系统设计内部与外部影响的变化的深厚知识系统；以仅执行坐标的任务形式的经济成本分析，在创建客户值产品或服务后进行设置、交付或清除。某些其他方式访问使用，例如实际选项的原则，寻求从金融风险管理应用财务选项理论于实际的决策。

科学方法建议：我们学习；我们假定基于模型的结果；我们扰乱基于该预测的系统；并且我们再次观察查看扰乱是否生成该模型可预知的结果。如果没有，则我们检查我们的数据并重新考虑我们的模型是否准确。使用模型促使过程改进将它移动到了一个科学实践，并将它从基于直觉的迷信活动中提升了。

鼓励领导

领导和管理不同。管理是设计进程、创建、修改和删除策略，做出战略和操作决策、收集资源、提供财务和结构以及传达有关上下文（如战略、目标和所需结果）的信息的活动。领导是有关远景、方法、策略、勇气、创新、判断，提倡和许多特性。领导可以并且应该来自组织内的任何一个。员工领导的小行为将创建改进的联级，这些改进将交付创建 Lean 软件开发流程时所需的更改。

生成可见性

了解工作为不可见。如果看不到内容，则（几乎）不可能管理它。必须生成可见性执行的工作和工作流通过各个的网络、技巧和部门直到完成。必须创建进程设计的可见性。通过查找进程流可视化的方法和通过使用进程显示的策略对于每个人可以看见并考虑。当所有这些内容为可见时，则可能使用科学的方法，因此，有关潜在的改进的对话可以是协作和目标。如果工作和工作流是不可见的，并且，如果进程策略不是显式的，团队过程改进几乎不可能的。

缩短流时间

软件开发专业和学习软件工程的学者以传统方式聚焦于衡量活动中花费在工作上的时间。精益软件开发社区已发现，衡量一些要处理的实际已用日历时间可能更加有用。这通常称为循环时间并由执行活动的边界限定。例如，如某一工作项（如用户情景）正等待分析、设计、开发或测试，并排队准备部署到生产环境中，从“分析”到“部署工作准备就绪”的循环时间会测量该工作项的总运行时间。

专注于工作经过进程所需的时间，在多个方面很重要。所显示的较长循环时间与 Bug 比率中的非线性增长关联。因此，循环时间越短，质量越高。这却不够直观，但在排队或实际无人触及它的同时可能在代码中插入 Bug 看起来十分可笑。传统上，软件工程专业和学习此专业的学者忽略了此空闲时间。但是，实验证据表明，循环时间对初始质量来说很重要。

Alan Shalloway 还讨论了“导致工作”的概念。他的观察为正在执行任务的延隔可以导致该任务花费比已做工作更多的努力。例如，如果找到 bug 并立即修复，可能只需要 20 分钟的时间，但如果对该 bug 进行会审和排队，需要等候数日或数周才能进行修复，那么修复所需的时间可能需要好几个小时。因此，循环时间延迟会“引发”其他工作。因为此工作是可以避免的，在学习术语，必须视为“浪费”。

关注循环时间的第三个原因是业务相关的原因。每个特性、功能或用户情景有一个值。值可能是不确定的，但是，但是，具有值。该值可能会随时间发生变化。随时间更改值的概念可以经济上表示为市场 ELT 函数。在了解工作项的市场 ELT 函数时，即使函数展示传播不确定性模型的值，可能计算“延迟的成本”延迟的成本允许我们在减少循环时间上放置一个值。

一些工作项，市场 ELT 函数在将来不会启动直到已知的日期。例如，需要在美国的 7 月 4 日假期使用的功能在该日期之前没有值。缩短循环时间和能够预测循环时确定某是很有用的。此示例。理想情况下，我们需要启动该工作，以便在需要某项功能的时候“及时”，即于不太早于也不太晚于所要求的日期交付该功能，因为晚交付会导致延迟成本。实时传递确保最佳地使用可用资源。早期交付提示我们可能会处理其他事情并且隐式地产生延迟的机会成本。

由于这三个原因，学习软件开发寻求最小化流时并记录启用有关流时的预测的数据。该目的是最小化来自 Bug 的故障、由于修复 Bug 时的延迟造成过重负载的浪费，并最大化通过避免延迟的成本和延迟的机会成本发送的值。

减少浪费以提高效率

对于每个添加值活动，存在必要的清除和配送活动，但不自行添加值。例如，开发工作软件增量的项目迭代要求计划（安装行为）、环境、可能的版本控制中的代码分支（统称配置管理，也称安装行为）、发行计划和实际发行（配送活动）、对客户进行演示，可能还包括环境拆卸或重新配置（清除活动）。在经济术语中，安装、清除和配送活动是事务成本执行添加值的工作。这些成本（或开销）被视为精益中的浪费。

通信开销的所有窗体可被视为浪费。会见以确定项目状态和向团队成员安排或分配工作，在经济语言中将被视为协作成本。所有协调成本在精益化思维中都浪费。学习软件开发方法查找消除或减少协调成本通过使用团队成员的 colocation，短的面对面会议如 standups 和可视化控件如卡片墙。

学习软件开发中浪费的第三个常用窗体是故障要求。需求错误会造成软件开发系统的负担。需求错误通常会因质量低劣导致负面效果，如返工或产生额外的工作形式。软件开发中故障要求的最常见的窗体是 Bug、产品缺陷和按预定方式使用该软件的故障驱动出的客户支持活动。故障要求的在制百分比通常称为故障加载。针对故障要求的值添加工作百分比是系统效率的衡量。

针对总工作的增值工作的百分比，包括所有非值添加交易记录和协调成本，确定包括添加事务和协调成本的所有个非值，该值确定效率级别。没有事务和协调成本并且没有失败加载的系统将视为 100% 有效。

传统上，西方管理科学告知，可通过增加工作的批处理大小以提高效率。通常，事务和协调成本是固定的，或仅随批处理大小的增加而稍微增加。因此，用批处理工作的效率会更高。此概念称为“节省刻度”。但是，在知识工作问题中，协调成本趋向于随批次大小非线性增加，而事务成本通常表现为线性增长。因此，为提高效率的传统的 20 世纪方法为如软件开发的知识工作问题是不合适的。

对保持批大小以便提高效率时，最好集中减少开销。因此，精益方法高效的原因是降低浪费。学习软件开发方法关注快速、低开销和快速计划方法；低的通信开销；和有效的低开销协调机制，如在 kanban 系统中可视化控件。它们还建议自动化测试和自动化部署，以减少交付的事务成本。最大程度减少环境设置和拆卸成本的现代工具（如现代版本控制系统以及使用虚拟化）也有助于提高小型软件开发批处理的效率。

实践

学习软件开发不规定做法。演示实际过程定义使用准则和值更为重要。但是，许多做法得到广泛采用。本节简要概述其中一些。

累计流程图

累计流程图一直是 2005 年起以来在 Team Foundation Server 中的报告的标准节。累计流程图绘图工作流中的每个状态的累计工作项的一个区域图。它们有丰富的消息，且可用于进程中和吞吐量速率（或“速度”）的步骤之间派生意义生命周期。不同软件开发生命周期过程产生在累积流程图的不同的可视签名。从业者可以学会识别区域关系图中显示的过程中的不正常图案。真正的学习过程将显示顺利稳步上升的均匀分布的颜色区域。图片显得平整光滑，不带交错步骤或可见颜色块。

在最基本的窗体中，累计流程图用于正在进行工作的可视化数量在工作项生命周期中的任何给定步骤。这可用于检测瓶颈并观察“色差”效果（流中的可变性）。

“可视化控件”

除了使用累计流程图外，学习软件开发团队使用电子可视化系统的物理键盘，或投影，可视化工作和观察其流。这样可帮助团队成员观察正在进行的工作累积并使其发现瓶颈和“木拉的效果”。可视控件还允许团队成员自我组织选择工作和一起协作，而无需计划或特定管理方向或干预。这些可视控件通常称为“卡片墙”或有时（不正确）称为“kanban 键盘。”

“虚拟 kanban 系统”

kanban 系统是从精益制造中采用的做法。它使用实际卡片的系统来限制正在进行工作的数量在工作流中的任何给定阶段。此类正在进行的工作绑定系统创建“下拉式”新的工作开始的位置，仅当任意 kanban 清单时新的工作可“被拉”到特定状态，并且工作可以继续到此。

在学习软件开发中，kanban 是虚拟的并通常通过设置给定的步骤的最大数字来跟踪工作项类型的工作流。在某些实现中，在新的系统可以启动时，电子系统保持虚拟 kanban 的记录并提供信号。该信号可见或为警报形式，如电子邮件。

虚拟 Kanban 系统通常与虚拟控件相结合以提供表示一个或多个工作无聊类型的可视虚拟 Kanban 系统。此类系统通常称为“kanban 键盘”或“电子 kanban 系统”。可视虚拟 kanban 系统可用作插件为 Team Foundation Server，调用 Visual WIP[20]。此项目由瑞典的 Hakan Forss 作为开放源开发。

小批量/单个流

学习软件开发工作要求在小批处理中执行，通常称为“迭代”或“增加，”或工作项独立流，称为“单个流”，而不会意外释放未完成的工作，单个工作流需要一个复杂的配置管理方法来启用发送已完成的工作。这通常使用版本控制系统中的分支策略实现。小批量的工作通常视为可由 8 个人的小型团队或小于 2 周内执行的批次。

小批处理和单个流要求与业务所有者频繁交互，以补充积压工作或队列或工作。它们还需要一个功能频繁地释放。若要启用与业务人员的频繁交互和频繁交付，需要缩小交易记录和活动的协同成本。一种常用方法实现此目的是使用自动化。

自动化

学习软件开发需要高级自动化来启用经济上的单个流并鼓励高质量和减少故障要求。使用自动化测试，自动化部署和软件工厂自动化设计模式的部署和源代码重复小变化部分的创建，全都将在学习软件开发过程中常见。

Kaizen 事件

在学习广告中，术语 kaizen 表示“持续改进”，并且 kaizen 事件是更改的操作进程或工具有希望导致改进。

学习软件开发过程使用多种不同的活动来生成 kaizen 事件。这些在此处列出。这些活动中的每个旨在刺激有关负面影响功能的对话，并且，因此，可以根据要求发送。在知识工作中出现的 kaizen 是我们必须引起对话，这些对话有关与具有不同技能的团队不同的跨人员组中问题。

每日站立会议

团队软件开发人员，通常 50，在可视控件系统上通常符合如显示它们的进程内工作的可视化的白板。他们讨论影响工作流的流和因素的动态。特别着重于外部受阻工作和由 Bug 引起的延迟工作。经过一系列站立会议后，过程中存在的问题通常会变得明显。在会议讨论该问题并建议解决方案或更改过程后，结果为可以保留较小的组。kaizen 事件将遵循。这些自发会话在旧宣传资料中通常称为自发质量范围。此类自发会话确实是在 kaizen 区域性中心。管理层将鼓励在日常站立会议后出现 kaizen 事件，以便驱动在组织中精益化的采纳。

追溯

项目团队可安排定期会议，以反映最新绩效。在可交付特定项目完成后或开发的装箱时间增量在 Agile 软件开发中称为迭代或冲刺后，才通常完成这些操作。

通常情况下，追溯会通过询问诸如“运行是否正常？”、“哪些做得不够？”和“我们应停止做什么？”的问题来对反射使用观察性的方法

通常情况下，追溯会对 kaizen 事件生成建议的积压工作。然后，团队可以按优先级排列其中的一些实现。

操作检查

操作检查通常大于追溯并包括整个值流的代表。通常最多 12 个部门来表示目标，显示接收和放映功能来应对异常的能力的请求的定量数据。操作检查通常每月进行一次。操作评审和追溯之间的主要差异是操作评审跨越功能的更宽范围，通常跨越项目和其他方案的组合，并使用目标和定量数据。相比之下，追溯往往作用于单个项目；仅涉及几个团队例如分析、开发和测试；且一般本质上具有观察性。

操作检查引起有关影响在团队之间的性能的动态的讨论。一个团队可能生成了由另一个团队处理的故障要求？故障要求可能是中断性的，并将导致第二个团队错过其提交以及不能按预期交付？操作检查提供机会讨论这些问题并建议更改。操作检查通常生成小型积压工作的潜在看板事件，可对这些事件进行安排和优先级排序，用于未来实现。

没有诸如单个学习软件开发过程的内容。如果它清楚地与值和学习软件开发的原则对齐，则进程可以说是“精益”。学习软件开发不规定任何做法，但是，一些活动已成为通用。学习组织寻找鼓励 kaizen 通过工作流和正在进行的工作的可视化并传递到流和因素的 dynamics 的理解（例如瓶颈、非即时可用性、变化和浪费）影响它。建议并合理化过程改善，以便降低来源的多变性、消除浪费、改善流或提高价值交付或风险管理水平。同样，学习软件开发过程始终对照和单独定制它们相关组织。它是不自然的从一个组织简单复制到另一个并预期它在不同的上下文中工作。也将可能返回组织在几周或几个月的时间来找到用于相同的更早的观察进程。它将始终发展。

使用学习软件开发进程的组织可以被称为学习，如果仅按所有三种格式 (“mura,” “muri,” and “muda”) 展开浪费的少量金额，且可以显示通过有效风险管理优化值传递。精益中的完美实现始终是旅程。没有目标。True Lean 组织始终在寻找进一步的改进。

学习软件开发仍是一个合并的字段，因此，我们可以希望继续在下一个十年中发展。

1. Anderson, David J.，Kanban: 您的技术业务成功的发展更改，2010 年，Blue Hole Press。

2. Anderson, David J., 软件工程的敏捷管理：运用业务结果约束的理论，2003 年，Prentice Hall PTR。

3. Womack，James P，Daniel T。Jones 和 Daniel Roos，已更改世界的计算机：学习生产的情景，2007 更新了版本，2007 年，自由出版社

4. Womack，James P 和 Daniel T。Jones,精益化思维：在 Corporation 中消除浪费和创建财富，第 2 个版本，2003 年，自由出版社

5. beck，Kent et al，敏捷软件开发的宣言，2001 http://www.agilemanifesto.org/

6. Highsmith，James A.，Agile Software Development Ecosystems（敏捷软件开发生态系统），Addison Wesley，2002 年

7. Poppendieck、Mary 和 Tom Poppendieck，精益化软件开发：敏捷的工具包，Addison Wesely，2003

8. Poppendieck、Mary 和 Tom Poppendieck，实现精益化软件开发：从概念到赚钱，出版社，2006

9. Poppendieck、Mary 和 Tom Poppendieck，领导精益化软件开发：结果不是重点，出版社，2009

10. Reinertsen, Donald G.，1997 年，自由出版社，管理工厂的设计

11. Reinertsen, Donald G.，产品开发流程的原则：第二代 Lean 产品开发，Celeritas 发布，2009

12. Sutton、james 和针对 Middleton，学习软件的方法：经理和开发人员，效率按的证书的技术，2005

13. Anderson, David J., 软件工程的敏捷管理：运用业务结果约束的理论，2003 年，Prentice Hall PTR。

14. Shalloway、阿伦和方海狸和 James R。Trott，Lean-Agile Software Development：达到企业灵活性，Addison Wesley，2009

15. Larman、Craig 和 Bas Vodde，精益化和敏捷开发：考虑和大型缩放 Scrum 的组织工具，Addison Wesley Professional，2008 年

16. 将精益化和敏捷开发规模化的做法：使用大规模的 Scrum 进行大型、多站点和离岸产品开发，出版社，2010

17. Coplien，james O。和 Gertrud Bjornvig，学习体系结构：agile software development，Wiley，2010

18. http://leansystemssociety.org/credo/

19. http://lssc12.leanssc.org/

20. http://hakanforss.wordpress.com/2010/11/23/visual-wip-a-kanban-board-for-tfs/