为了防止浪费，您需要管理和度量从一个想法到项目交付会在队列中呆多久。对于您自己的价值流，可以考虑从只需要更改一行代码的想法开始。要花多长时间才能交付这个想法？
使用价值流来查看组织中的工作的任何方面。通常，以下价值流有明显的浪费：
确保新想法进入开发阶段
确认需求和设计
搜索和查找相关的项目信息
复制和修复缺陷
获取和设置一个测试基础架构
将应用程序部署到测试环境
将应用程序部署到生产环境
除了价值流的长度之外，还需要考虑以下这些测量：
进程效率是通过总体工作量与消耗时间之间的比例来计算的
总周期时间
一些更改（比如自动化某个手动任务）可以减少周期时间，但也有可能会降低效率，因为它们不能减少所有浪费。考虑周期时间和效率的另一种方法是以下公式：
周期时间 = 工作量 + 浪费量
效率 = 工作量 / 周期时间
为了更好地理解这些指标，让我们来看下图所示的一个示例，图中显示了一个价值流，在发现该价值流的一个缺陷后，对该缺陷进行了修复。
在使用价值流时，测量工作量和浪费量（所耗费的时间减去工作量）是一个很好的实践。在这个示例中，平均需要 4.25 个小时的工作量来修复一个缺陷，但该缺陷耗用了 16.25 个小时的时间，导致了 12 小时的浪费。
通过关注于降低某个价值流上的平均浪费量和工作量（例如，缺陷修复周期、实例或用例场景），您就可以开始让进程变得更加简洁，并向企业或客户更快更多地提供价值。更短的周期可以提供更快的反馈，从而可以帮助您引导项目向意想不到、但有益的方向发展。
如何正确地画出当前软件项目团队的价值流图？
关于等待的浪费
许多浪费都可以归因于等待，特别是以下这些常见的等待形式：
等待基础架构
等待应用程序部署
等待其他团队/任务
等待审查完成
前两个等待时间源于将代码从开发环境移动到测试环境，再移动到生产环境。
等待基础架构
团队需要花时间等待配置机器和部署软件（部署到测试环境或部署到生产环境），这通常会导致长时间的等待。使用云来实现开发和测试，可以让团队在需要的时候快速配备基础设施，用这些设施来测试他们的应用程序。这种方法可以让等待时间从几天或几周缩短到几分钟。团队可以在开发和测试阶段的更早时间按访问类似生产环境的环境。这种访问可以及早地发现缺陷，最终减少部署风险。
等待应用程序部署
浪费的另一个来源是在部署应用程序期间花费的时间。手动部署可能非常耗时。如果专家资源（比如应用服务器管理员或安全专家）被使用，那么这个过程可能会花费额外的时间，因为该团队必须等待另一个团队完成部署。
DevOps 使团队能够自动化部署应用程序，管理哪些东西应该部署到每个环境，并促进环境之间的编码。而不是等待部署，然后可以自动完成部署。
最终我们获得了两项功能：自动部署和云，它们可以显著减少团队花在等待基础架构和部署上的时间。在按下一个按钮或代码检查时，提供基础架构，部署应用程序并重新运行测试。如果应用程序获得通过，那么它可以轻松地通过各种测试环境得到晋升，还可以部署到生产环境。
实现这些更改是一个不断发展的过程。一些组织选择加速这个周期的某一部分，或者最初只是为了某些环境而实现这些更改。自动化部署或者使用云，这些使得团队和组织能够显著缩短周期时间，提高他们的创新能力和反应。
等待其他团队/任务
浪费的第三个主要来源是团队的失败，他们受他人的影响优先完成了某些工作。通常，没有一个简单的方法让团队或个人了解他们的工作的哪些方面影响到了他人。scrum 方法试图通过关注这些障碍的日常会议解决这个问题。部分任务管理工具通过DashBoard提高其他团队和个人任务的可见性。
在许多开发场景中，某个任务被阻塞，导致团队无法取得进展。在这种情况下，可以暂停某项任务，释放和存储与该任务相关的所有代码更改。在任务暂停后，开发人员就可以开始处理另一个任务。当最初的任务变得畅通时，开发人员可以恢复原来的工作，合并来自原来任务的更改（如果需要的话）。
开发人员可能有大量暂停的更改或变更集。一个变更集，是一个存储库对象，收集了一组相关文档、组件变更，以便可以将它们应用于单个操作中的某个流程目标，比如工作区或工作流程。每一个暂停的变更集都代表了未完成工作形式的浪费，但是，只要开发人员仍在正致力于有价值的工作，这种形式的浪费就不值得太多的关注。有时，浪费在短期内是必需的。临时浪费的来源可以采用回顾的方式进行分析。
等待审核完成
审查工件也可能导致等待浪费，因为作者常常需要等待审查结束才能进行后续操作。追踪人们是否完成了审查通常会浪费很多时间。通过第三方工具提供集中和自动完成审查，可以将需要审查的工件（需求、设计、代码和软件资产）以电子方式分配给审查者，而且可以采用一种简单的方式获得并实现他们的审查。审查者和被审查者会获得关于评论的自动通知和提醒。团队成员可以随时查看任何审查状态。这种方法可以减少工件审查过程中的浪费。
