爱华网价值流图的存在有两个目的：帮助公司找到并结束无用的活动。找到问题并创建一个更有效率的过程并不容易；就算是那些顶尖的公司也可以变得更有效率， 存在改进的空间。但是对公司进行实质性的改变以消除那些没有效率不高的活动，并不是那么容易的。相对而言，识别 无效率活动就容易多了，但是将这些无效率的活动终结就另当别论了。价值流图在增强公司竞争力的同时，还能产生一些需要 的更改。但是首先要指出的是，什么是价值流图，以及怎样去制作这样一个价值流图。接下来的例子和概念，基于一个范例，那就是对软件工程机构应用一个价值流 图，但是这些概念可以应用于广泛的环境之中。
怎 样去制作一个价值流图
有一个简单的例子可以演示怎样制作一个价值流图。一个特定的团队会面临许多交流上的难题，他们不得不与公司以外的团队合作，并就怎样对一项重要的项目协作 达成一致的意见。协议需要在工作开始之前就到位。图 1 显示了他们将会面对的价值流图以描述当前的状况。
图 1. 获得协议（不用出差）
这个基本的价值流图由以下几个不同的元素组成：
一个机构内的过程或者活动被认为是潜在无效率的。它可以是一个简单或者复杂的过程或活动。选择一个您相信是有意义或者重要的过程或者障 碍。 这个过程或者活动被分解为若干个组成的任务。 识别任务之间的关系。 估计完成每一项任务所需要的平均时间。这个估计并不需要多么的精确。如果任务有时需要 3 个小时，有时需要 7 个小时，有时又需要 4 个小时，那么平均起来我们估计需要 5 个小时来完成这项工作。 识别过程中任务之间的平均等待时间。同样，这时的估计并不需要多么的精确，因为在很多情况下，精确的估计并不是需要的，甚至有时是不可能 的。 估计总的工作时间，逃逸的时间，浪费的时间以及效率。 是否有任务得到了重复执行，包括了重复的平均次数（或者上例中的循环）。 可选的：可以创建一个“如果这样做会怎样”的选择（第二个这样的图片，有时也叫做“未来状态”价值流图）。如果进行了一处或者多处的变 更，那么像总工作时间、消耗时间、浪费的时间以及效率这样的未来状态将会发生什么变化？
您应该确保您的价值流图以 真实的客户 来开始和结尾。在其他所有目标之上，我们一直努力为购买和使用我们服务的客户提供更好的服务。价值流图帮助我们考虑，“在向客户交付价值的过程存在什么障 碍？” 同样，当这个交付过程涉及到多个团队的话，价值流图应该包含有助于交付客户价值的所有步骤。通常，在这些机构性的界限处会有很多无效率的活动。
超出这个基本的范例，让我们考虑一下创建价值流图所涉及到的一些基本元素。如果我们的目标是识别和终结一些无效率的过程或者活动，第一步是识别一种或者多 种无效率活动的来源。识别需要处理的最重要机构性问题是很难的。我们应该追寻什么目标呢？对于初始者，考虑一下在您公司中可能存在的以下反模式，因为它们 提供了一些线索，帮助您识别需要创建什么价值流图（采取至 Paul Gibson 所识别的反模式）。在背景中，您应该可以看到改进的稳定迹象了： 委 托，授权，委托，授权 。
在表面上，经常使用的查询在公司表现的方式并不是显而易见的。但是就算是一个电子邮件收信信箱也可以是一个查询。如果一个团队的领导将电子邮件当作 提示参加代码评审会的通知，会怎么样？如果一条信息在构建完成之后只是有选择地发给某一个人，而不是将其公开，又会怎么样？如果一位员工需要等无限长的时 间，以等待管理员通过一条 ID 生成的请求，又会发生什么情况？查询是无处不在的，而电子邮件积压可能是可以归类为查询的唯一反模式。
图 2. 查询
您可以通过查看查询中的最小时间项，以及查询中处理一个项目所需要的平均时间，来访问任意查询的效果。如果查询偶尔会变成零，那么它可能只是 在处理变化中的工作负荷。但是，如果查询从来没有变为零，那么可能的效果是延迟 每一个 通过的项目。因此，举个例子，如果您一天处理一个项目，最小查询数是 20，那么其效果就是将每一个项目延迟到 20 天。
积压 非常类似于查询，但是其名字可能有助于您去获得它的实质。一般来说，需求积压应该决不超过在软件的两个版本中可以完成的工作量。如果您的产品或者项目有需 求的积压，它需要一百年的时间去完成，那么积压就过多了。那么对剩余部分的积压将会如何处理呢？那就是将其删除掉。如果它很重要，那么涉众就会告诉您，您 可以对其做一些权衡。
Mary 和 Tom Poppendieck 提供了一个更加精巧和更加简单的方式，去处理大型的需求积压。接下来的四步概括在他们的第二本书，《执行简短的软件开发》（见于 Resources）：
开始时可以询问，“该查询中有多少部分从来没有使用到？”，删除那些从来没有从中获益的查询。老实的说吧，只管点击删除键就行了。 所以，这种锻炼究竟摆脱了多少项目？一半？现在考虑一下剩余的项目，并对它们做一个 Pareto 分析。关键的项目比率会达到 5。不重要项目的比率将会占到 1。现在将它们全部删除，除了那些 4s 和 5s 的项目。尽情地点删除吧。不要担心：如果这些项目突然变重要了，那么它们会回来的。 现在考虑一下剩余的项目，并估计它们代表了多少天，月或者年。您是否有其他的事情添加至更加重要的列表？将它们记在心里，在不久的未来您 是否有能力完成列表上剩余项目的工作？如果没有，您是否需要添加额外的功能 ？ 如果您的列表仍然是不切实际的冗长，那么它可能会在其他的方面发挥作用，这些方面超出了做些什么以及不做什么的有效决定。例如，一个冗长 的列表可能会反映不适当的注意或者引起过多的请求。将这样的一个列表分解为两个列表，一个发挥外部的作用，另外一个尽量地保持简短。
图 3. 不需要的评审循环
积压的另一个关键例子是缺陷积压问题。在一个质量把关严格的软件工程项目中，质量确实是不能牺牲的原则性问题。但是如果您的缺陷积压是庞大 的，那么将它们全部修复是不是合适的呢？有了这些很大的缺陷积压，除了浪费时间去管理这些积压，很有可能您不会看到什么是重要的。如果您做了一些极端的操 作，比如删除缺陷日志，而且理解 并不是单个缺陷 可以通过迭代的界限？这是否是明智的，可能的，又或者可行的？尽管如此，积压需要得到识别，要么删除要么进行最小化地压缩。当积压存在时，它们必须是需要 的并可管理的。
一周一次的状态会议，一月一次的管理检查点，以及一年四次的操作评审，都是软件开发工作流程的典型部分。会议会为其他的评审会议做好准备，而列表可 以完美地显示出来。回到前面的步骤以识别公司日历中其他的会议安排。这些会议中有哪些是确实需要的？哪些是瓶颈？如果需要批准的话（这本身就是有一个问 题），批准过程是不是可以异步地进行？是否有可能缩减循环时间，这样等待时间就得到了降低？记住如果一月一次的评审/决策会议需要重复劳动以及其他的评审 循环，那么其结果就是将决策延迟一个月，就算只需要一个小时的工作也是这样。
而且，如果决定需要会议的话，您可以考虑一下会议的有效性问题。该会议是否有明确的目的？是否需要一个促进器？行为与结果是否明确？进展是不 是一直都很明显？
简单的日常会议，可能有助于创建一个节奏，促进发展并识别软件工程项目上存在的问题。当我们向团队引入一个 15 分钟的每日简单会议时，只是当他们愿意付出一定的代价后，我们才会让他们去这样做，叫做：从会议中可以取消中间的哪两个小时，可以让每周一次每次 1.25 个小时的会议安排变得最有效率？通常来说，对于一个公司来说，最糟糕的事情莫过于 增加 会议的频率与时间，而不去考虑什么会议可以删除或者得到显著的缩减。另外，我们坚持认为这些日常的会议以不超过 15 个小时为时间上限。
软件支持公司通过有意集成回馈的过程来进行操作。其逻辑部分如下所示 ：
任何人可以接听电话。教会员工一些沟通上的技巧，以处理像许可证确认这样的事情，确认接触信息，培训他们以回答一些基本的问题，并向客户 指出一些知识基础与其他的资源。向访问分配一个优先权或者安全性。给联系留言分类。 有些团队有能力更强的工程师，通过优先级和安全性来处理这些访问。
一个访问者所感到最高兴的事情，就是资源的有效利用了。是不是技术越是高明的工程师，就越能够向客户传递他们的价值（在本例中是问题的解决方 案）？例如，如果有软件开发员和测试员支持偶尔的访问，他们是否愿意去适应需要以处理软件中存在的普通问题 ？
该反模式的点并不仅限于联系留言。更广泛地说，访问来自公司的什么部分，以及它们是如何处理的？回馈代表了一系列的查询机理。
因为本文主要关注的是软件工程团队对价值流图的应用，所以我们还要强调一下如果我们雇佣了专业的软件工程师，那么我们就要像专业性的那样去对待他 们。如果在批准过程中有任何的问题，都可以向他们请教。一般来说，适当的检查与平衡是有效的，但是有两个例子可能会带来一些含有冗繁批准过程的潜在性问 题。
图 4. 多种赞同
想象一下有一家公司愿意雇用来自另一个国家的工程师。处于简便性的考虑，假设这个外国的工程师来自于巴西，而公司计划的批准人位于美国。试想一下巴西的团 队也许需要通过以下的一些步骤 ：
巴西籍的工程师会面试各个候选人并从中选出最佳的人选。 巴西籍工程师的管理员必须批准。 巴西籍工程师的中层管理员也必须批准。 巴西国家层次的管理人员必须批准。 巴西的人力资源与财政部门必须批准。 美国方面的人力资源与财政部门必须批准。 技术性管理批准（至少在一个层次上）可能也需要在美国发生。
意料之中的是，完成这样一个过程需要大约一年多的时间。这个过程中没有批准者会提供任何的实际添加价值。为什么不给巴西的团队一个清晰的预算 方案以及职工总数目标呢，并让它们来管理这个过程呢？
另一个例子可能会更加有用。假设有一个软件产品并不是纯粹作为一个私人的产品出售，而是作为一个大型方案的一部分出售，这个方案中含有许多可能会转移的部 件。如果您必须做一个结构性上的决策时将会发生什么事呢？考虑一下图 5 所示的简化演示。
图 5. 结构性决策
假设您是以为正在处理 产品 A 的结构师。您所在的团队想要产品 A 与产品 B、C、D、E、F 与 G 一起使用。很有可能产品 F 与 G 由公司的其他部分创建，而产品 F 和 G 可能仍然由另一个公司创建。还有一种可能，就是产品 G 对公司的收益流非常重要。
您有两个基本的选择是关于怎样做结构性决策的。可能每个季度，公司会召开一次会议，去决定公司内部各个组成部分相互之间合作的方式。但是，这 种方法的关键问题，在于这种很少召开的会议意味着产品 A 可能需要等待相当长的时间，以作出决策决定怎样构建该产品。可能这会使传递高质量短时间的产品 A 变得十分困难。
在实践中，我们还发现了另外一个十分实用的选项。如果我们将产品 A 上的结构当作一个智能的工程师，并鼓励该工程师基于最佳决定来作出决策，然后与整个团队的成员一起就关键路径的结构性问题作出决策，这种乐观的估计，意味 着 95% 的时间，结构师都进行了合适的处理。当他们不能合适地处理时，剩余的 5% 又发生什么情况呢？我们发现当需要对结构作出一些更改时，对于这个 5% 所需要的重复工作，为了提高总体的速度是十分划算的。您还需要注意到，95% 的成功率要比那些等待批准的团队要高。
“持续性集成”的理由，对于许多简洁且敏捷的软件工程来说是一个咒语，因为将大量的代码集成到一起，是一项十分具有挑战性的工作。开发中代码就位的 时间越长，集成的难度就越大。
图 6. 由并发活动所造成的瓶颈
再一次使用如图 6 所示的流程图，如果产品 A 是在这样一种环境下生产出来的，构建没有频繁的发生，而产品内的构件或者模块只会不定期地集成起来，那么情况就糟透了。但是想象一下另外一种情况，也就是 与大型方案中的其他产品集成会被“延迟”。不可避免的问题在过程的晚期不会得到恢复，而质量问题则会恢复。
除了对产品 A 所做的持续性集成工作，以及方案中的每一个产品，那么就需要大型方案的频繁构建。
将测试延缓到开发过程的末尾代价总是很高昂的。缺陷投入与缺陷导入之间的时间越长，那么校正缺陷所花的时间就越长。这就是为什么一些操作，比如有意 义的单元测试、测试驱动的开发、编程、代码评审及检查、测试自动化以及等等此类，会在简单和敏捷开发过程中得到强调的原因，以消除无效率的活动。
如果您的价值流图揭示了长期测试的“循环”，那么就能保证其中无效率内容的存在了。那么您可以做些什么，以确保功能性的客户系统测试会在整个 开发迭代期间运行了 ？
就算团队为系统测试保留了很长或者晚期的时间，那么在价值流图中区分花在实际测试与花在代码修复上的时间就非常的重要了。例如，对于一个能够 在一周左右完成所有测试工作的大型测试机构来说，假设代码确实是稳定的。如果您拥有一个 13 周的系统测试周期，那么大部分的时间，究竟是应该花在缺陷修复上面，还是花在测试并致力于缺陷的早期清除上面，才能显著地降低系统测试周期与总体的周期时 间？
与之类似，长期测试周期可能会是开发进程的总体子优化的症状。如果它们确实存在的话，那么是否需要机构的分析以考虑一下如何在能最大化总体流 程，而不是提高公司生成未测试代码的能力？
通常来说，团队会考虑创建涉及到内部结构性流程的价值流图。理想条件下，在价值流的开始和结束时候，都应该识别一下真正的外部性客户。
例如，可能您的团队会评审一个价值流图，以理解实施一个外部客户源的新需求需要多长的时间。通常来说，团队会认为该价值流的末端就是产品或者 项目传递的时间。实际上，价值流末端应该识别需要什么，以得到在产品环境中实施的产品或者项目，在这个环境中相同的客户会从原始的需求中得到真正的价值。 如果您创建一个基于网络的程序，一旦您对代码作出了更改，可能会是您的客户参与到产品中去。与之相反，如果您对 IT 商店生产不过紧缩包裹型 的代码，那么就应该好好地考虑一下部署问题。在这种情况下，在传递以后就会发生整个系列的活动了，它实际上是价值流的一部分，可以当作无效率活动的一部 分，并通过变更活动在循环中完成的方式来作为优化的候选对象。
创建价值流图主要有三个原因：客观性，清晰性以及说服力。
情绪与意见在价值流图中都占有一席之地。但是关于需要更改的潜在性机构过程和活动的问题-这正是价值流图所追寻的-最好得到冷静的处理。让我 们考虑一下在这篇文章开始部分使用的价值流图的基本范例。假设您走入一个决策者的办公室并说，“下一次我们需要签一个协议时，如果我们去他们的办公室，那 么就可以更好地节约成本，并能使我们的客户更加满意。”对于一个决策者来说，提供一个默认的回应会更加容易：“此时并不批准出差”。
如果，呈现的是一个简单的价值流图，那么将会做相同的操作，但是问题会更加清晰，而客户的潜在节省与可能的收益就不会这样一目了然了。如果您 还想创建第二个价值流图-未来状态价值流图-这将会把该协议带入我们的视角：“进行旅行，将会花费我们 1,200 美元去完成这项协议，并且可以在两天之内完成。没有旅行，我们将会花费 13,500 美元（基于职工总人数或者其他的成本），大概需要一个半月的时间去完成”。这是不是让您的协议左右摇摆不定？尽管结果可能仍然是一样的（这就是说，旅行没 有得到批准），但是如果旅行得到批准的话，就可以实现费用节省了。不是就决定进行辩论或者反思，您就可以为一些适当的例外情况提供验证了。
最后一个例子可能也十分有用：客户的请求是如何处理的。查看图 7 中所示的下拉图。
图 7. 价值流图，执行一项客户请求
图 7 的大图。
检查一下工作流程。本例中含有一系列的点。首先，它并不是理想的。如果使用Examine the flow here for a moment. A number of points stand out in this example. First of all, it's not pretty. If it were converted into a crystal clear graphic by using Microsoftt® Visio® 或者其他的一些工具，将其转化为一个清晰的条形图，那么它的内容将会发生变化吗？并不是这样。价值流图越容易创建，您的公司就会越频繁地使用它。考虑一下 该价值流图的一些特性，您就可以很快得出一些结论了：
这个特定团队使用的总体开发方法，看起来基本上是一个无效率的开发活动。 尽管图中只包含了等待时间，以及并没有与这些任务相联系的时间，还是会有一些问题会与工作时间无关。产生那些与任务相关的工作时间，您从 任务本身并不会看出有低效率的存在。有一些任务（例如“开发/记录/测试”）将需要得到进一步的分解以确保其中没有含有无效率的地方。 这里有很多的批准循环，它们都是有价值的吗 ？ 这里没有一个循环，可能是因为图是一个简化而已。这就是说，这些批准的循环多久重复一次？它可能是其他一些无效率活动的来源。 从积极的 方面来说，这个特定的过程以用户开始，以用户结束是我们所愿意看到的。正如我们考虑到的那样，通常情况下有一些团队认为，在以其他一些方式传递他们的软件 或者完成工作之后，他们就完成了他们的任务。但是，客户仍然需要将他们得到的软件应用到具体的环境中去，有时这种环境是十分复杂的。
关于价值流图还有其他很多方面可以介绍，但是基本上，关键的问题在于每一个关注的人都可以后退几步，并考虑一下特性请求的流程。然后就可以相 对容易地建议应该处理较严重的无效率问题，正如在第一个例子中所阐述的那样。然后，与之类似，首先应该处理什么及为什么要处理就变得一目了然了。
价值流图帮助我们给公司带来一些改进，过程及方法上进行升级，而更重要的是，生产质量更高的软件。价值流图可以帮助识别公司中存在的一些缺乏效率的地方并 将其终止。通过学习本文中所介绍的内容，您的公司就可以找到对客户而言，更高效率及更高质量的软件产品了。
