精益软件开发连载（三）
实践
精益软件开发不规定具体有哪些实践。更重要的是要证明实际的过程定义与原则和价值观是一致的。然而，一些做法是普遍采用。本节简要介绍了其中的一些。
累积工作流图
自2005以来，累积工作流图已成为Team Foundation Server（TFS，微软在Visual Studio中的一个工具软件）报告的标准部分。累积工作流在工作流的每个状态中绘制累积工作项的区域图。它具有丰富的信息，可以用来推导过程中的步骤，以及吞吐率（或“速率”）之间的平均循环时间。不同的软件开发生命周期过程在累积工作流图上产生不同的视觉特征。从业者可以学习识别在该过程中显示的面积图来理解模式的功能。一个真正的精益过程将显示均匀分布的颜色区域，平滑地稳步上升。图片将呈现光滑无锯齿的步骤或可见的颜色块。
在最基本的形式中，累积工作流图用来在工作项的生命周期中使任何工作步骤中工作的质量情况变得可视化。这可以用来检测瓶颈和观察“mrua”（工作流中的变量）。
可视化控制
除了使用累积工作流图，精益软件开发团队使用物理板或电子投射的可视化系统来将工作变得可视化并观察其工作流程。这种可视化帮助团队成员观察进展中的工作积累，使他们看到瓶颈和“Mura”的影响。可视化工作控制也使团队成员变得通过自我组织方式选择和协同工作，而不受计划和具体管理方向或干预的影响。这些可视化的控制通常被称为“卡墙”，或有时（不正确的）称为“看板”。
虚拟看板系统
看板系统是精益生产的一种实践。它使用一个物理卡系统来限定工作进程中任何给定阶段的工作数量。这样的工作进度限定的系统在新的工作开始时创建一个“拉”系统，这个看板表示只有当看板有了空位置时，新的工作可以被“拉”到一个特定的状态和它被排入了工作计划进度中。
在精益软件开发中，看板是虚拟的，通常通过设置工作项类型的工作流中给定步骤的最大数量来跟踪。在一些实现中，电子系统跟踪虚拟看板，并在启动新工作时提供信号。该信号可以是可视化的或以警报的形式，如电子邮件。
虚拟看板系统通常与视觉控制相结合，提供一个可视化虚拟看板系统来显示一个或多个工作项类型的工作流。这种系统通常被称为“看板板”或“电子看板系统”，可视虚拟看板系统可作为Team Foundation服务器的插件，称为可视WIP。这个项目是由瑞典Hakan Forss开发的一个开源系统。
小批量的规模/单一任务工作流
精益软件开发需要工作是小批量的规模，通常被称为“迭代”和“增量”或具有相对独立性的工作项，这些工作项经常被称为“迭代项”或者“增量”。单件工作流程需要一个复杂的配置管理策略，以使得完成的工作可以被交付而未完成的工作不能发布。这通常是在版本控制系统中使用建立分支的策略实现的。一个小部分的工作通常被认为是一批作业，可以由一个小团队的8人或更少的人在不到2周的时间内完成。
小批量和单任务工作流程的完成需要频繁与企业主互动，以补充Backlog或工作队列中的工作任务。他们还需要一种频繁交付的能力。为了使业务人员能够频繁的互动和持续的交付，有必要缩小业务规模和协调成本这两个活动。实现这一点的一个常用方法是使用自动化。
自动化
精益软件开发期望高水平的自动化来使得单间工作流程获得最经济的成本并满足高品质减少缺陷。使用自动化测试、自动化部署和软件工厂的自动化部署的设计模式和创建重复的低变化率的源代码，这些都是司空见惯的精益软件开发过程。
持续改善活动
在介绍精益的文献中，“kaizen”一词是指“持续改善”，而改善事件则是对一个过程或工具进行改变的行为，这一过程或工具有望被改善。精益软件开发过程使用几个不同的活动来产生改善事件。这里列举一些活动。每一个活动的目的是通过关于通过一些刺激性的谈话问题作用于产生不利影响的因素，从而达到能够满足需求。改善工作的本质是我们必须从不同的团队和不同技能的人群中发起关于问题的话题。
每日站会
团队的软件开发人员高达50人，通常会满足前面的可视化控制系统，例如使用一个白板来展示他们正在进行的工作。他们讨论了工作流程的动态变化和影响工作流程的因素。特别关注的是外部工作的困难和问题以及由于缺陷而导致的工作延误。处理问题的过程经常会变成为一个一个的站立会议进行。这导致的结果是，一个较小的组可能会留在会议后继续讨论这个问题，并提出解决方案或过程的变更。接下来的一系列改善活动将遵循这些变更。这些自发的会议在过时的文件表达中通常被称为自发的质量循环。这种自发的会议是真正改善文化的核心。经理在每日站立会议之后鼓励改善活动实施，目的是启动组织更加适应精益思想。
回顾会议
项目团队可以安排定期会议以回顾最近的表现。这些往往是在具体的项目可交付成果完成后或在敏捷软件开发中Sprint增量迭代完成时开展的。回顾会议通常使用一个轶事的方法来思考这样的问题“什么做的好？”“我们会怎么做？”和“我们应该停止做什么？”这通常会产生对一个Sprint Backlog的持续改善的建议。然后，团队可以优先考虑其中一些去实施改善。
业务评审
业务评审通常比业务回顾活动包含的内容广，包括来自整个价值流的表现。这是常见的多达12个部门提出客观的、定量的数据，显示他们收到的需求，并反映他们满足需求的能力。业务回顾通常每月举行。业务评审和业务回顾的主要区别是业务评审包含了一些更广泛的功能，通常跨越项目和其他活动的组合，并使用客观的、定量的数据。因此，在比较中，业务回顾往往是局限于单个项目；涉及团队的分析、开发和测试活动；合同通常一般的内容。
没有一个单一的精益软件开发过程。如果它完全符合精益软件开发的价值观和原则就可以说是精益过程。精益软件开发并没有规定任何具体的实践，但一些活动已经变得常见。精益组织通过工作流和工作流程的可视化，通过了解流程的动态和影响因素（如瓶颈、非即时可用性、可变性和浪费）来鼓励持续改进。
过程改进建议和合理的方式，以减少变异的来源，消除浪费，改善工作流程，提高价值交付或风险管理。因此，在一个不断进化的组织中精益软件开发过程也将不断发展和量身定制。将一个过程的定义从一个组织复制到另一个组织，并期望它在不同的上下文环境中工作是不现实的。也不太可能在几周或几个月内组织以发现所使用的过程与以前观察到的相同。它将永远是不断变化的。
使用精益软件开发过程的组织如果只在这三种形式（“mura，”muri，”和“muda”）中表现出少量的浪费，并且表现出能够通过对风险的有效管理来优化价值传递，这就是精益软件开发模式。追求完美的精益永远像一次旅行一样，没有最终的目的地。真正的精益组织总是在不断寻求进一步的改善。
精益软件开发仍然是一个新兴领域，我们期望它在未来十年内继续发展。