利用 Rational 软件减少开发周期和损耗

受精益软件开发原则的启发，本文将重点介绍各种方法来帮助您发现和消除开发过程中和时间中的浪费，同时加快反馈速度。

精益开发 是一种文化；减少浪费就是该文化的一个结果。减少浪费可以提高操作效率，但是比这更重要的是，它可以缩短开发周期，为客户提供使用价值。更短的开发周期提高了市场的创新、完整性和响应性。它们还为开发团队的学习和不断改进提供了一种有价值的机会。

本文关注的是如何使用针对 DevOps 的 IBM? Rational? 解决方案来如何帮助降低成本和缩短周期。这些工具可以帮助人们让他们的时间更有效率。面对面的交互（比如观察运动中的对象）和合作，一起思考产生问题的根源，这也是精益开发的一个重要方面。

在 Mary Poppendieck 和 Tom Poppendieck 合著的出版物中了解关于 精益开发原则的思想和影响 的更多信息。（请参阅参考资料，以获取这些作者的其他书籍。）

许多人都使用了 IBM DevOps 功能与精益开发原则，成功地减少了浪费。Forrester Consulting 分析了许多使用这些解决方案的 IBM 客户，发现开发人员、测试人员、项目经理通过沟通和协作活动可以节省 30 - 50% 的时间。

团队和组织通常浪费了 40% 或更多的资源。浪费的形式有以下几种：

不必要的开销

不必要的返工

不必要的特性

构建了错误的东西

通常，构建错误的解决方案是因为没有正确地指定需求。在构建错误的解决方案时，企业没有从投资中获得重要的业务价值。在某些情况下，会导致完全忽略某个重要的商业机会。

在思考各种浪费时，您可能会考虑软件的哪些部分是可见的，工作流程如何在系统中工作的，一个团队的工作如何影响另一个团队的工作，坦诚沟通如何促进创新。

如图 1 所示，减少浪费可以让开发团队有更多的时间做卓有成效的工作，并提供以下改进：缩短周期时间，增加设定时间内提供的代码数量。使用这些解决方案和持续交付，IBM Rational 开发团队将周期时间从一年缩短至三个月。

图 1. 精益转型

精益转型可以减少 20% - 50% 的浪费

这些技术可以消除单调乏味的任务，让组织更容易保持作为一个团队和作为一个组织的凝聚力，并提供更友善、更有趣的工作方式。

以下类型的浪费，由 Mary 和 Tom Poppendieck 定义，探讨了一些常见的浪费时间、不创造价值的工作和不必要返工的问题。IBM DevOps 可以帮助减少这些问题，这样人们就可以专注于需要快速高效地提供有效软件的最重要的任务。

等待：

人们花时间等待别人做完一件事，这种等待通常是因为没有明确的团队之间的工作交接。

任务切换和交接：

当人们经常切换任务时，时间会浪费在切换背景和重置环境上。经常留下部分任务没有完成。将一个人指派到多个项目上工作可能会浪费时间。

移动（Motion）：

在必须移动人员和工件时，就会产生时间浪费。一些关键专家和客户是否容易访问？开发人员能否找到测试的结果，而不用从一个办公室走到另一个办公室？相关文档存储在哪里？交接是如何管理的？

额外进程：

不必要的流程、重复的任务和不必要的文书工作可能会浪费时间。这项文书工作会实际向客户提供价值吗？

额外特性：

实现一个不是解决业务问题所必需的解决方案所浪费的时间。

部分完成的工作：

如果用例场景尚未完成，而且没有缺陷，那么该场景拥有少量的价值，或者没有价值。您不可能知道该场景在产品环境之中是否起作用，或者它是否为企业提供了价值。

缺陷：

缺陷会阻止工作的完成。如果有很多缺陷，或者该项目有大量的技术未能达标，就会造成时间浪费。越早发现和修复缺陷，浪费就会越少。

IBM DevOps 是一个用于加速软件创建和交付的持续管道，它包括两个核心工具：

1.Rational solution for Collaborative Lifecycle Management (CLM)：一个针对代码创建管道的平台

2.IBM UrbanCode：一个针对代码交付管道的平台

这篇文章主要关注如何使用 IBM DevOps 的关键功能来处理这些浪费。以下软件产品解决了 DevOps 工具的创建和交付方面，消除了其中的浪费。关于单个产品的更多信息，请参见 参考资料。

IBM Rational Quality Manager

IBM Rational Requirements Composer

IBM Rational Team Concert

IBM UrbanCode Deploy

IBM UrbanCode Release

您可以参考您最感兴趣的部分，或者按顺序阅读本文。"评估价值链" 和 "缺陷" 部分尤其有用，因为它们介绍了用于分析和思考所有过程的工具，缺陷就是一个例子。

评估浪费和价值链

价值链 是一种技术，可以帮助团队和组织了解任务花费了多长时间和有多少浪费。价值链可以帮助团队了解工作项目何时没有积极发挥作用，通过消除空闲时间，团队可以明显缩短周期时间。

对大多数组织而言，关键价值链是要花多长时间才能融入到生产环境中。图 2 显示了一个得到许多个人或团队通过的想法，直到该想法得到部署。每一个想法都在等待被实现，或者已经采取了某些行动来将这个想法付诸于实现。

图 2. 某个想法得到实现的流程

为了防止浪费，您需要管理和度量工作项目会在队列中呆多久。对于您自己的价值链，可以考虑从只需要更改一行代码的想法开始。要花多长时间才能交付这个想法？

使用价值链来查看组织中的工作的任何方面。通常，以下价值链有明显的浪费：

确保新想法进入开发阶段

确认需求和设计

搜索和查找相关的项目信息

复制和修复缺陷

获取和设置一个测试基础架构

将应用程序部署到测试环境

将应用程序部署到生产环境

除了价值链的长度之外，还需要考虑以下这些测量：

进程效率是通过总体工作量与消耗时间之间的比例来计算的

总周期时间

一些更改（比如自动化某个手动任务）可以减少周期时间，但也有可能会降低效率，因为它们不能减少所有浪费。考虑周期时间和效率的另一种方法是以下公式：

周期时间 = 工作量 + 浪费量

效率 = 工作量 / 周期时间

为了更好地理解这些指标，让我们来看图 3 所示的一个示例，图中显示了一个价值链，在发现该价值链的一个缺陷后，对该缺陷进行了修复。

图 3. 一个有缺陷的价值链的示例

在使用价值链时，测量工作量和浪费量（所耗费的时间减去工作量）是一个很好的实践。在这个示例中，平均需要 4.25 个小时的工作量来修复一个缺陷，但该缺陷耗用了 16.25 个小时的时间，导致了 12 小时的浪费。

通过关注于降低某个价值链上的平均浪费量和工作量（例如，缺陷修复周期、实例或用例场景），您就可以开始让进程变得更加简洁，并向企业或客户更快更多地提供价值。更短的周期可以提供更快的反馈，从而可以帮助您引导项目向意想不到、但有益的方向发展。

您可以配置 IBM DevOps 来计算平均工作项目（实例、缺陷、改进请求、用例场景，等等）在每一个阶段的平均浪费量和工作量。借助这些计算，您可以使用这些测量来推动改进。图 4 显示了一个来自 IBM DevOps 的示例报告，揭示了一些缺陷的耗用时间、工作量、浪费量和效率。

图 4. 缺陷效率报告

传统的衡量进步的主观手段对决策制定而言可能是一个很差的基础。使用 IBM DevOps 测量产品管道（而不是活动管道）提供了一个更诚实的视角，带来了更好的质量反馈和进步。这种报告只是如何衡量您的现有流程的一个示例。这些客观的测量方法可以帮助引导项目提供更多的价值和更可预测的结果。

与等待相关的浪费

许多浪费都可以归因于等待，特别是以下这些常见的等待形式：

等待基础架构

等待应用程序部署

等待其他团队

等待审核完成

前两个等待时间源于将代码从开发环境移动到测试环境，再移动到生产环境。

团队需要花时间等待配置机器和部署软件（部署到测试环境或部署到生产环境），这通常会导致长时间的等待。使用云来实现开发和测试，可以让团队在需要的时候快速配备基础设施，用这些设施来测试他们的应用程序。这种方法可以让等待时间从几天或几周缩短到几分钟。团队可以在开发和测试阶段的更早时间按访问类似生产环境的环境。这种访问可以及早地发现缺陷，最终减少部署风险。

下面的解决方案为公共或私人环境提供了基础架构即服务或平台即服务：

Codename: BlueMix（一个 IBM 公用的平台即服务）

IBM SoftLayer（一个 IBM 公用的基础架构即服务）

IBM PureApplication System

IBM SmartCloud Orchestrator

浪费的另一个来源是在部署应用程序期间花费的时间。手动部署可能非常耗时。如果专家资源（比如应用服务器管理员或安全专家）被使用，那么这个过程可能会花费额外的时间，因为该团队必须等待另一个团队完成部署。

IBM DevOps 使团队能够自动化部署应用程序，管理哪些东西应该部署到每个环境，并促进环境之间的编码。而不是等待部署，然后可以自动完成部署。例如，一个在线零售商使用 IBM DevOps 将每个部署的时间减少了 95%。

最终我们获得了两项功能：自动部署和云，它们可以显著减少团队花在等待基础架构和部署上的时间。如图 5 所示，在按下一个按钮或代码检查时，提供基础架构，部署应用程序并重新运行测试。如果应用程序获得通过，那么它可以轻松地通过各种测试环境得到晋升，还可以部署到生产环境。

图 5. 部署到云的开发人员

实现这些更改是一个不断发展的过程。一些组织选择加速这个周期的某一部分，或者最初只是为了某些环境而实现这些更改。自动化部署或者使用云，这些使得团队和组织能够显著缩短周期时间，提高他们的创新能力和反应。

浪费的第三个主要来源是团队的失败，他们受他人的影响优先完成了某些工作。通常，没有一个简单的方法让团队或个人了解他们的工作的哪些方面影响到了他人。scrum 方法试图通过关注这些障碍的日常会议解决这个问题。然而，这种方法很难扩展到分布式团队。

IBM DevOps 提供了几个关键特性，用于减少了团队和个人因为等待别人而浪费的时间。如图 6 所示，任务被标记为正被另一个任务阻塞。团队和个人监视了三个任务视图：被阻碍的任务、阻碍别人的任务，以及最近为受阻碍的任务。

图 6. 阻塞任务

该方法极大地提高阻碍其他团队和个人的任务的可见性。可见性是帮助团队通过自我组织来减少等待时间的第一步。如图 7 所示，在一个项目级别上，可以监视某个团队的阻塞任务的数量。在团队的仪表板上提供这种测量方法可以帮助他们了解和调整他们的方法，从而减少这些障碍。

图 7. 团队的阻塞任务

在许多开发场景中，某个任务被阻塞，导致团队无法取得进展。在这种情况下，可以暂停某项任务，释放和存储与该任务相关的所有代码更改。在任务暂停后，开发人员就可以开始处理另一个任务。当最初的任务变得畅通时，开发人员可以恢复原来的工作，合并来自原来任务的更改（如果需要的话）。

开发人员可能有大量暂停的更改或变更集。一个变更集，如图 8 所示，是一个存储库对象，收集了一组相关文件、文件夹和组件修改，以便可以将它们应用于单个操作中的某个流程目标，比如工作区或工作流程。每一个暂停的变更集都代表了未完成工作形式的浪费，但是，只要开发人员仍在正致力于有价值的工作，这种形式的浪费就不值得太多的关注。有时，浪费在短期内是必需的。临时浪费的来源可以采用回顾的方式进行分析。

图 8. 暂停更改的视图

审查工件也可能导致等待浪费，因为作者常常需要等待审查结束才能进行后续操作。追踪人们是否完成了审查通常会浪费很多时间。IBM DevOps 集中和自动完成审查。可以将需要审查的工件（需求、设计、代码和软件资产）以电子方式分配给评论家，而且可以采用一种简单时尚的方式捕获并实现他们的评论。评论家会获得关于评论的自动通知和提醒。如图 9 所示，可以随时查看任何审查状态。这种方法可以减少工件审查过程中的浪费。

图 9. 通过在线评论节省时间

任务切换和交接

任务切换和交接会导致相似类型的浪费。由于任务切换造成的浪费发生在团队成员将部分工作转交给另一个人时（例如，开发人员修复了一个缺陷，并将它转交给测试员，以验证该修改）。任务交接发生在不同任务之间进行切换时。

理想情况下，在一个小型的敏捷项目中，很少进行任务交接，因为团队成员倾向于承担所有项目角色（编写实例、开发代码、测试和执行其他类似任务）。然而，在更大的项目中，或者在很少有全能人才的项目中，任务交接是必需的。

任务交接会引入大量的浪费，原因如下：

由于需要在工具或团队之间重新设置密钥信息而导致的返工

由于团队成员没有意识到等待的东西已经准备就绪而导致的等待时间

缺乏足够的细节

过时的工件

没能成功地将更改传达给团队。

IBM DevOps 有助于通过以下方式减少开发和操作之间的交接浪费：

自动化部署

提供促进环境之间的应用的能力

提供组织和管理大量版本的能力。

这些功能消除了与部署软件相关的手动活动和容易出错的活动，并帮助管理版本，以及最终会显著减少浪费和风险的更改。团队可以更频繁地发布他们的软件，以便可以更早地提供价值，这样团队和组织就可以更快地获得反馈。图 10 显示了如何可视化每个环境中的应用程序版本，这样操作就可以看到要执行的处理，从而简化开发和操作之间的任务交接。

图 10. 显示了每个环境中有哪些应用程序版本的部署管道

借助 IBM DevOps，来自任何团队的团队成员都可以通过 RSS、电子邮件列表或 Web 中的视图来查看信息和关注其他团队中的变化。如图 11 所示，在下面的示例中，此信息可以帮助团队节省时间。

需求团队可以查看他们的哪些需求已经转换成正在运行的或已经测试的代码，如图 11 所示。

设计团队可以跟踪可能会影响他们的不断变化的需求，从而减少设计错误需求方面的精力浪费。

开发团队可以跟踪测试团队报告的新缺陷和不断变化的需求，还可以很轻松地规划实现新需求和修复缺陷的工作。

测试团队可以查看哪些需求已经发生变化，哪些需求已准备好测试，以前中断的哪些测试现在已经准备好重新测试，而且可以很轻松地计划测试活动。

操作团队可以查看构建的状态，查看应用程序可以部署到哪些环境中，在每个构建中有哪些缺陷修复和新特性。

图 11. 需求团队查看哪些需求被转换成正在运行的代码和测试代码

可见的和易于访问的信息可以极大地减少交接过程、额外流程和运动中的浪费，因为团队成员拥有一些他们可以轻而易举地获得的信息，如图 12 所示。他们可以访问这些信息，不必打扰其他团队成员就可以实现状态更新。

图 12. 仪表板显示了来自其他团队的即时更新

项目和后续阶段之间的交接

前面小节关注的是如何在项目之中 降低成本。这一小节将会更多地关注项目、构件及第三方之间 的成本。如下面示例中所示，团队之间的交接可能会造成浪费：

1.一个应用程序从一个开发团队传递到另一个团队（一个部署团队或运营团队），以便完成它的部署

2.一个应用程序被传递到一个拥有少量开发工件的支持团队，这些开发工件包括需求、设计和测试。支持团队必须在可以提供满意的支持之前考虑团队是如何发挥作用的。

3.暂时尚未涉及到的程序需要得到升级，但是有时不能找到原始的需求、设计、测试，甚至代码。

4.一个应用程序拥有特定非功能性需求，该需求可以在公司的任意地方得到解决，但是找到拥有其他需求的应用程序会变得更加困难，而且很难找到用来解决问题的设计和代码。

软件资产管理可以帮助解决这些类型的问题，并降低不能在正确时间找到正确信息的相关成本。资产可以用作存储任意类型的工件、背景和元数据，比如代码、测试脚本、服务定义、引用架构和业务模型。特别需要指出的是，使用 IBM? Rational? Asset Manager，通过帮助人们使用混合的规范类别、标记和文本搜索，可以降低搜索已存在资产所需的时间。该方法使得找到高质量资源，将它们下载到桌面或者开发环境中进行使用变得非常快捷。

通过使用 IBM Rational Asset Manager 作为所有软件资产的定义库，您就可以直接处理项目和程序层次上的交接中产生的浪费和无效问题。开发团队可以选择上传他们的可部署工件，可以将 IBM DevOps 设置成只下载并部署已经在 Rational Asset Manager 中已获批准的工件。这种方法可以提高控制，减少浪费和降低风险。它为所有项目文档、代码和工件提供了一个门户，这样支持团队就可以在一个地方访问所有开发信息。这使得快速找到开发工件来实现系统维护变得更加轻松。团队就能够快速识别解决类似问题的其他项目，并通过重用他们的解决方案来节省时间。

如图 13（一个可视化浏览图）所示，该图显示了资产之间的关系，该图让您可以更简单、更快地找到相关资产。

图 13. Rational Asset Manager 可视化浏览

任务切换

任务切换中的浪费的一个示例是这样一个情形：一个开发人员完成了函数编码的一部分，然后切换到另一个函数编码。在开始编写新的函数之前，开发人员可能必须浪费一些时间来删除所有原始代码更改。

许多个人生产力的书籍（比如 完成这件事情 和 明天再做它）都强调：多任务并不代表更快。如果您有两份工作要做，完成一份工作后再完成另一份工作要比同时试图完成两份工作要快一些。敏捷开发团队和 Kanban 开发团队都遵循这个原则，以便最大可能得减少同时做的事情的数量。

在一个理想世界中，任务切换是有限的。管理人员和其他资产的方式可以帮助您将浪费降至最低。例如，避免忙得团团转的团队，所以他们涉足到太多不同的任务中。按照顺序操作项目，而不是让个人或者团队同时参加许多项目。

如果需要进行任务切换，那么 CLM 可以帮助您解决这个问题。借助 CLM，可以最大程度地减少由于提高速度而导致的浪费，因为所有工件（业务流程、需求、论坛、评审、注释、测试、设计、编码、规划和涉及的人员）相互之间都是有联系的。这赋予他们一定的背景，并缩短了从一项任务转向另一项任务所需的时间。

CLM 为任务切换提供了有效的支持，因为所有工件都存储在 CLM 储存库中。所有文件更改（不管更改是针对代码、针对设计，还是针对文档）都与某项任务有关联。我们会将那些变更作为变更集进行管理。在该任务上工作的开发人员可以暂停一组变更，如图 14 所示。在开始执行更改之前，一个暂停可以将所有代码都转化为暂停状态。所以，开发人员可以一次性同时处理多项代码更改，在单个工作上只需极小的工作量。显然，按这种方式工作并不是很理想，但是，如果您一直等待，直到一些其他的工件可以进行编辑，那么这种工作方式也向您提供了一种最大程度地减少等待和任务切换中的浪费的方法。

图 14. 利用暂停变更集来节省任务切换时间

移动（Motion）

当人们需要花费时间进行物理上的移动时，就会产生移动浪费。例如，如果一个业务分析员一天需要上下楼梯两三次来会见一些业务专家，那么就会产生移动浪费。在移动浪费与 额外进程 浪费的时间之间，存在较强的联系。当团队成员参加不必要的会议或者只需要他们出席一小段时间的会议时，就会产生移动浪费。这种情况会产生移动浪费和任务切换浪费，因为团队成员在参加会议之后重新转移了注意力。

要减少移动浪费，可以提高工件的可视性，并改进团队成员与涉众之间的协作，通过使用 CLM 将任意类型的开发工件联系到一起，可以实现这种协作。涉众和团队成员可以通过 Web 浏览器来查看这些工件和关于它们的信息。他们可以从自己的桌面访问几乎所有项目，而不是通过参加各个会议来评审工件和信息。这减少了移动浪费，并改进了不同位置之间的人们的协作。

Forrester Consulting 采访了许多 CLM 用户，发现团队因为能够在需要的时候轻松地找到正确的信息而显著减少了浪费。一个客户估计他们节省了以前用于沟通的 70% 左右的时间。

如图 15 所示，因为可以通过浏览器查看项目的所有方面，CLM 可以编辑操作板来查看管理员和涉众想要看到的信息。这促进了业务敏捷性，因为涉众可以在任何他们愿意的时候查看项目。因为可以减少花费在会议之上的时间，这还降低了团队和团队领导的时间浪费。

图 15. 在 Web 浏览器中显示团队进度

通过浏览器访问这些数据可以减少花费在状态会议上的时间。在一些项目中，这些时间可以降至一半，因为团队可以只关注状态报告的黄色（注意）和红色（警告）区域。在过渡阶段，新的工作方式可能会让人感到有点不舒服，因为数据提供了一个真实的进度视图！对团队进度的访问可以改进决策制定的质量，并减少收集数据上花费的时间，因为状态更新是由 CLM 自动化的。

额外进程

额外进程是不会向用户提供价值的多余进程。例如：生成没人阅读的文档，更新计划，手动收集指标和进度信息，组织没人响应的评审，以及其他类似的不必要任务。使用前面描述的价值链分析或类似的技术，在上下文中评估每个进程步骤，了解其重要性。

确定进程是否向客户提供了价值，或者是否延误了客户获得价值的时间。

手动部署进程就是进程浪费的一个很好的示例。有人编写很长的、详细的和完整的文档，描述如何部署应用程序，还编写了一些随后手动执行的指令，以便将每个应用程序部署到测试环境或生产环境。在某些情况下，组织会执行双重部署，以确保正确遵循指令。IBM DevOps 提供了一个图形化的进程编辑器简化了应用程序部署，如图 16 所示，以便创建自动化部署。IBM DevOps 包括数百个现成的步骤。这些功能有助于减少构建或部署过程中造成的缺陷，显著降低失败部署的风险。

图 16. IBM UrbanCode 部署进程

还可以配置 CLM 来制定一个组织的进程，有一个函数可以在整个过程中为团队提供无缝引导。有时工具很难理解一个进程，但是，与不遵循进程相比，CLM 更容易遵循进程。例如，如果一个团队决定，他们需要在其单元测试中检测 70% 的代码覆盖率，如果代码覆盖率不符合这个标准，那么 CLM 可以禁止代码交付。

如果团队想以某种方式进行工作，或者发现进程的某些元素没有为他们工作，CLM 还为团队在覆盖进程方面提供了灵活性。在前面的示例中，某个团队可能决定他们想要某些组件的更高层次的覆盖率，或者他们想要有选择地强制执行代码覆盖率要求。

CLM 支持一个需求定义方法，该方法侧重于 等待定义特性 的细节，直到实现了它们所在的迭代。CLM 还支持编写客户测试，将这作为详细的需求定义的一种替代。

可以改进整个生命周期中的自动化的其他 IBM? Rational? 工具可以消除目前手动执行的进程。消除手动进程可以让实现更小更频繁的发布、持续集成、集成测试、测试虚拟化和自动化测试变得更容易。这些实践还可以减少浪费，因为它们能够缩短周期时间，还可以更频繁地接收反馈。可以通过查看价值链来评估整个进程的上下文中的自动化改进。

让团队使用他们的回顾性调查来分析进程并确定可以更改哪些地方来实现不断改进，这是一个很好的实践。通过在所有任务中收集数据，并提供分析数据的能力，CLM 有助于确定是否存在不增加价值的进程或任务。

额外特性

使用以下方法来减少额外特性：

建立一个经营理念存储库，将这些理念融入到一个适应性的、迭代的规划方法中。首先实现一些重要的理念。

开始一个清晰的愿景。

在反馈的基础上积极引导功能设计。

允许改进解决方案。

积极地、尽早地融入一系列的利益相关者中间，经常频繁地进行过程矫正，以便产生更好的结果。

鼓励利益相关者进行合作，汇集不断移动的目标。

使用视觉表示和基于场景的需求定义，而不是使用大型文本文档，如图 18 所示。

延缓具体的规格，直到实施冲刺为止。

经营理念存储库特别适用于以下组织：任何给定的商业理念都可能跨许多系统或应用程序进行实现的组织。如图 17 所示，CLM 使得企业围绕一组高级营销理念进行合作成为可能，这样企业就可以优先考虑这些理念，为它们管理审批流程，并最终提交它们，以便开发这些理念。在这个理念得到开发后，企业可以查看许多团队的进度，了解该理念的状态。这种方法可以帮助企业专注于代表最好的投资的理念，减少用于开发的使用物品的数量。它还有助于确保不开发不必要的特性。企业有很大的灵活性来应对市场环境变化，从生产环境中的现有理念中寻求反馈。

图 17. 经营理念的两两比较

如图 18 所示，直观表示和基于场景的需求定义理解某个需求带来的价值变得更容易。

图 18. 可视场景帮助理解

其他一些方法也可以用来减少额外特性，将焦点从遵守完整的需求规范切换到只选择交付为企业提供重要价值的需求。需要特别指出的是，从需求到交付的更短周期意味着额外的功能根本不太可能实现。

CLM 支持以多种形式定义特性，从用户事例或用例、故事板、用户界面草图、流程图、文本、图像，甚至是音频或视频。利益相关者不仅可以发现最近有什么新内容，什么内容更改过，它们还可以发现与外部和内部工件相关的广泛需求。例如，用户事例是如何看屏幕混合的？使用广泛的可视技术极大地提高了成功的可能性。可视化让人们理解某个需求如何影响日常工作变得更容易。

如前面提到过的那样，单个的储存库能够被所有相关的利益相关者查看，可以搜索存储库来查找与每个个人相关的内容，这使得变得人们找到与他们相关的内容变得更加容易。指示板、标记和过滤器鼓励从大量的利益相关者进行积极参与。这种参与是没有价值的（尤其在从业务部门和客户角度考虑时），因为这些利益相关者可以提供早期反馈。

借助 CLM，可以轻松地将特性集成到敏捷开发计划中。这些计划演示了可执行代码来首先实现最重要的特性。

CLM 中提供的透明性、协作和上下文可以帮助团队理解特性。而这种理解又可以提高决策制定的质量。优先级从遵循移动至规格，以确认来自大量利益相关者的特性的价值，并使得实现关键特性变得更轻松。

部分完成的工作

部分完成的工作是对尚未实现特性所付出的努力。使用瀑布开发方法将会产生大量部分完成的工作，因为大量的时间会花在编写需求、开发和编码上。这会导致没有可用的工作软件，直到周期的晚期才会改变这种情况。这就是团队和组织会转向使用迭代方法的主要原因，这样他们可以更快地完成工作，并考虑部署它们，以便在不久之后让它们发挥作用。

就算您使用的是迭代性方法，但是部分完成的工作所造成的浪费仍然值得您考虑。在一个迭代过程之中，应该关注轮流完成每一个实例（或有限的实例集），团队应该一次尽可能少地处理实例。这种方法会最大可能地减少部分完成的工作，这意味着某些完成的代码会在迭代或者冲刺阶段进行交付。如果团队的工作会在所有实例之间扩展，那么现在就进行测试可能会在开发周期的晚期阶段带来风险，而团队在该迭代中可能不会交付任何新的功能，因为缺陷会在晚期被发现，而且没有时间修复这些缺陷了。

CLM 可以在以下几个方面发挥作用：

如图 19 所示，借助 CLM 敏捷规划任务板，您可以很容易地查看部分完成的工作。

图 19. 显示部分完成工作的敏捷规划任务板

为了最大程度地减少部分完成的工作，CLM 可以帮助团队安排大量的开发人员来处理相同区域的代码。在这种协作方法中，每个开发人员都有一个沙箱，这意味着代码可以独立开发，不会干扰其他人。如果需要的话，开发人员可以相互交付代码，这样他们就可以在其他人的工作的基础上完成自己的构建，而不用与整个团队进行共享。这种灵活性支持亲密的协作，以减少项目中的部分完成工作。

缺陷

缺陷会造成两种浪费：修复缺陷产生的浪费，以及软件不能正常发挥作用而产生的浪费。通过提高需求的质量，IBM DevOps 有助于降低缺陷的产生率。它还有助于减少解决缺陷所需的时间，这样就可以尽可能少地产生浪费。搜索、修复和解决缺陷的过程又叫做缺陷价值链。通常，这会产生大量的成本，因为它需要若干个团队或组织进行亲密无间的协作。

IBM DevOps 通过提升缺陷价值链的效率来支持精益软件开发。对于敏捷团队来说，这一点很重要，因为他们不应该声明拥有重大缺陷的实例点（实例点 是估算用户实例复杂性的混合单元）。缺陷意味着代码尚未完成，仍在进行中，在精益软件开发之中，人们不愿意看到这种状态。缺陷必须在一个冲刺阶段中快速被找到和解决。对于确保软件开发期间技术能力达标来说，有效的缺陷解决过程十分关键。

例如，在丰田公司，人们并不是仅仅为快速修复缺陷而努力，而是理解问题产生的根源，这样就可以避免将来产生同样的错误。在其著名的 “停止生产线” 实践中，当发现一个缺陷时，可以立即停止整个生产线来修复它。该实践的目标是减少后续工作的工作量。在软件开发过程中，如果构建终止了，那么就应该快速尽全力修复缺陷。

后来他们发现，缺陷成本高于修复成本。上下文切换需要额外的资源，如果后来发现缺陷，则必须重复额外的进程，这些都会带来额外的成本。为了及早发现缺陷，减少与缺陷相关的浪费，必须尽早在生命周期的早期进行测试，这种实践被称为左移测试。

因为集成测试通常是很难自动化，而且设置的复杂性完全取决于应用程序，所以集成测试往往不了了之。IBM DevOps 服务虚拟化功能能够轻松快速地虚拟化应用程序服务。依赖于这些服务的任何应用程序或组件都可以很容易地针对虚拟服务进行测试。使用虚拟化服务需要做更少的工作来确保测试状态下的程序能够正确工作和集成。在与 IBM DevOps 持续交付能力结合使用时，这个功能变得更强大，因为早期的环境可以使用虚拟化服务，并使用真正的服务逐步取代它们，因为系统在各种测试环境中进行测试的过程中不断进步。例如，Forrester Consulting 报道一家大型欧洲银行，他们的项目交付能力在三年内增加了 100%（从每年完成 40 个项目扩大到了 80 个项目），因为他们使用了 IBM DevOps 测试虚拟化和集成测试功能。

如图 20 所示，CLM 自动化了不同团队之间的切换。通过减少手动切换中的等待浪费，这种自动化在整个流程效率中带来了极大的改进。

图 20. Rational Quality Manager 和 IBM Rational Team Concert 中的缺陷工作流

使用 CLM，在测试员报告一项缺陷时，信息就会出现在开发人员接受工作的 IDE 框中。假设这是可以得到立即修复的重大缺陷，那么开发人员可以暂停单个操作中的所有并发工作，加载发现缺陷的基线，然后开始修复缺陷。当缺陷得到修复时，开发人员可以重返以前的工作，精确地回到以前停止的位置。在修复和构建代码之后，IBM DevOps 会自动将修复的代码部署到一个新环境中，测试员会注意到部署修复的地方，以及哪些测试可以重新运行。这种方法意味着该团队可以快速解决缺陷。此外，等待和任务切换可以得到极大的降低。

图 21 显示了一个假想的手动缺陷修复周期的示例。

在这个示例中，修复一个缺陷需要 16.25 个小时，但其中的 12 小时（近 75% 的运行时间）是浪费的时间。浪费的时间明显增加了修复缺陷所需的时间。在将这个示例扩展到通常出现在某个项目中的许多缺陷时，可以会导致在修复代码和向客户提供一个有效系统时产生极大的延迟。

图 22 显示了在使用 CLM 来改进协作时的相同修复周期。

AltText:

在我们使用 CLM 的示例中，修复一个缺陷的工作量从 4.75 个小时降低到了 3.25 个小时，而浪费量从 12 个小时降低至不超过 2 个小时。更为重要的是，修复一个缺陷现在只需要不到半天的时间，这意味着在一个为时两周的冲刺阶段中，可以更快地完成缺陷周期。对于让技术一直处于控制之中，并产生潜在可部署的高质量软件，这一点非常关键。

如果缺陷不在暂停进程中，那么由于开发人员的人为重启操作，每项缺陷的任务切换会产生更多的浪费。在这些情况下，可以小批次地在短周期内处理缺陷。精益软件开发为处理这种情况而整合了暂时需要的浪费。

结束语

本文介绍了 IBM DevOps 帮助团队变得更精益、更智能的各种方法。IBM DevOps 可以帮助团队：

消除浪费并自动化手动流程，这样就可以更有效地交付软件，缩短周期时间。

更有效地引导进程，帮助它们了解最终目的，从而测量、监控和不断改进软件交付。