精益开发和devops认证_使用DevOps进行精益软件开发

精益发展是一种文化。 减少浪费是结果之一。 清除浪费可以提高运营效率，但更重要的是，它可以缩短开发周期并提高客户价值。 较短的周期可以改善市场中的创新，竞争力和响应能力。 它们还可以为开发团队提供学习和持续改进的宝贵机会。

本文重点介绍针对DevOps的IBM®Rational®解决方案如何帮助减少浪费和缩短周期时间。 这些工具可帮助人们提高工作效率。 面对面的互动（例如观察实际项目并就问题的根本原因进行协作）也是精益开发的重要方面。

丰田总裁表示，精益管理的两个Struts是持续改进和尊重人。

“ [丰田系统]的本质在于，每位员工都有机会以自己的工作方式发现问题，解决问题并进行改进。 ”

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

许多人使用具有精益开发原则的IBM DevOps功能来成功减少浪费。 Forrester Consulting分析了许多使用这些解决方案的IBM客户，发现开发人员，测试人员和项目经理仅通过交流和协作活动就可以节省30％到50％的时间。

团队和组织经常浪费40％或更多的资源。 废物有几种形式：

• 不必要的开销
• 不必要的返工
• 不必要的功能
• 建立错误的事物

通常会构建错误的解决方案，因为没有正确指定需求。 如果构建了错误的解决方案，则企业不会从投资中获得可观的商业价值。 并且，在某些情况下，完全错过了重要的商机。

当您考虑浪费时，请考虑软件的哪些部分可见，工作如何在系统中流动，一个团队的工作如何影响另一个团队以及开放式沟通如何促进创新。

如图1所示，减少浪费使开发团队可以花更多的时间进行生产工作，这种改进减少了周期时间并增加了在指定时间范围内可以交付的代码量。 通过连续交付使用这些解决方案，IBM Rational开发团队将周期时间从一年缩短到三个月。

图1.精益转型

这些技术可以消除无聊的工作，使团队和组织更容易组织起来，并提供一种更友好和有趣的工作方式。

由Mary和Tom Poppendieck定义的以下浪费类型，探讨了浪费时间，无法增加价值的工作以及不必要的返工的常见问题。 IBM DevOps可以帮助最大程度地减少这些问题，从而使人们可以专注于快速有效地交付有效软件所需的最基本任务。

• 等候：
  人们花时间等待别人做某事，通常是因为团队之间没有明确的工作交接。
• 切换和任务切换：
  当人们频繁切换任务时，浪费时间来重新获得上下文感和重置环境。 通常，任务只能部分完成。 指定一个人从事多个项目可能会浪费时间。
• 运动：
  当人和文物必须移动时，浪费时间。 主题专家和客户是否易于访问？ 开发人员是否可以找到测试结果而不必走几步楼梯到另一个办公室？ 相关文件存放在哪里？ 如何管理交接？
• 额外流程：
  不必要的流程，重复的任务和不必要的文书工作可能会浪费时间。 该文书工作是否真的为客户提供了价值？
• 额外功能：
  实施解决业务问题不需要的解决方案会浪费时间。
• 部分完成的工作：
  如果用例场景没有完成并且没有缺陷，那么它几乎没有价值。 无法知道该方案是否在生产环境中有效，或者是否会为业务带来价值。
• 缺陷：
  缺陷会阻止工作完成。 如果存在许多缺陷或项目承担大量技术债务，那会浪费时间。 越早发现并修复缺陷，产生的浪费就越少。

IBM DevOps是用于加速软件创建和交付的连续流水线，包括两个核心工具：

• 协作生命周期管理（CLM）的Rational解决方案：用于代码创建管道的平台
• IBM®UrbanCode：用于代码交付管道的平台

本文重点介绍关键的IBM DevOps功能如何解决这些浪费。 以下软件产品解决了消除浪费的DevOps工具的创建和交付方面。 有关单个产品的更多信息，请参见参考资料 。

• IBM®Rational®质量管理器
• IBM®Rational®Requirements Composer
• IBM®Rational Team Concert™
• IBM®UrbanCode部署
• IBM®UrbanCode版本

您可以参考最感兴趣的部分，或依次阅读本文。 “ 测量价值链 ”和“ 缺陷 ”部分特别有用，因为它们描述了用于分析和思考任何过程的工具，其中以缺陷为例。

衡量浪费和价值链

价值链是一种技术，可以帮助团队和组织了解执行任务需要花费多长时间以及存在多少浪费。 价值链可以帮助团队了解何时未在积极地工作工作产品，并且通过消除空闲时间，团队可以显着减少周期时间。

对于大多数组织而言，关键的价值链是将一个想法付诸生产需要多长时间。 图2显示了一个想法，该想法会经过许多个人或团队，直到被部署为止。 在每个点上，想法都在等待被研究，或者正在采取一些措施将想法付诸实施。

图2.一个想法进入生产流程

为了避免浪费，您需要管理和衡量待处理产品在队列中保留的时间。 对于您自己的价值链，请考虑从只需要更改一行代码的想法开始。 交付需要多长时间？

放心部署

使用IBM Bluemix上的DevOps服务一致地更快地交付高质量软件。 注册免费的Bluemix云试用版 ，然后开始使用 。

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

• 确保将新想法批准用于开发
• 批准需求和设计
• 搜索并找到相关的项目信息
• 复制和修复缺陷
• 获取并建立测试基础架构
• 部署应用程序以测试环境
• 将应用程序部署到生产中

在价值链的整个长度上，请考虑以下措施：

• 以总工作量与经过时间成比例来衡量的过程效率
• 总循环时间

诸如使手动任务自动化的更改可以减少周期时间，但同时也降低了效率，因为它们无法减少任何浪费。 考虑周期时间和效率的另一种方法是以下公式：

周期时间=精力+浪费

效率=工作量/周期时间

为了更好地理解这些指标，请查看图3中显示的与发现缺陷后修复缺陷相关的示例。

图3.缺陷价值链示例

使用价值链时，最好的方法是测量工作量和浪费（经过的时间减去工作量）。 在此示例中，修复缺陷平均需要花费4.25个小时，但是花费了16.25个小时的时间，导致12个小时的浪费。

通过集中精力减少整个价值链上的平均浪费和精力（例如，缺陷修复周期，故事或用例场景），您可以开始使流程变得更加精简，并更快地为您的业务或客户提供更多价值。 。 较短的周期时间可以更快地获得反馈，这可以帮助您将项目引向意想不到但有益的方向。

可以将IBM DevOps配置为计算任何工作产品的每个阶段（故事，缺陷，增强请求，用例场景等）的平均浪费和工作量。 通过这些计算，您可以使用这些度量来推动改进。 图4显示了来自IBM DevOps的示例报告，该报告显示了一些缺陷所花费的时间，精力，浪费和效率。

图4.缺陷效率报告

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

与等待相关的浪费

浪费归因于等待，尤其是以下常见形式：

• 等待基础设施
• 等待应用程序部署
• 等待其他团队
• 等待评论完成

等待时间的头两个来源是关于将代码从开发迁移到测试再生产的过程。

团队配置机器和部署软件（测试或生产）所花费的时间通常是长时间等待的原因。 使用云进行开发和测试可以使团队根据需要快速配置基础架构，以测试其应用程序。 这种方法可以将等待时间从几天和几周减少到几分钟。 在开发和测试阶段，团队可以更早地访问类似于生产的环境。 这种访问可以尽早消除缺陷，并最终降低部署风险。

浪费的另一个来源是在应用程序部署期间花费的时间。 手动部署可能很耗时。 如果使用专家资源，例如应用程序服务器管理员或安全专家，则该过程可能需要花费更多时间，因为团队必须等待另一个团队进行部署。

IBM DevOps使团队能够自动化应用程序的部署，管理部署到每个环境的内容以及在环境之间升级代码。 部署可以自动进行，而不必等待部署。 例如，一家在线零售商通过使用IBM DevOps将每次部署的时间减少了95％。

最终，这两项功能（自动部署和云计算）可以大大减少团队等待基础架构和部署所花费的时间。 如图5所示，当按下按钮或签入代码时，将配置基础架构，部署应用程序，并重新运行测试。 如果应用程序通过，则可以轻松地通过各种测试环境对其进行升级，并可以将其部署到生产环境中。

图5.开发人员部署到云

实施这些更改是一个不断发展的过程。 一些组织选择加速此周期的一部分，或者最初只对某些环境实施更改。 自动化部署或使用云使团队和组织可以显着减少周期时间并提高创新和React能力。

等待浪费的第三个关键原因是团队无法根据工作对他人的影响来确定工作的优先级。 通常，团队或个人无法通过简单的方式来了解其工作的哪些方面会影响其他方面。 Scrum方法试图通过每天召开针对障碍的站立会议来解决这个问题。 但是，这种方法很难扩展到分布式团队。

IBM DevOps提供了几个关键功能，以减少团队和个人等待他人所浪费的时间。 如图6所示，一个任务被标记为被另一个任务阻止。 团队和个人监视任务的三种视图：我阻止的任务，我阻止其他任务的任务以及最近解除阻止的任务。

图6.阻止任务

这种方法极大地提高了阻止其他团队和个人的任务的可见性。 可见性是帮助团队自我组织以减少等待时间的第一步。 如图7所示，在程序或项目级别，可以监视拥有团队的阻止任务的数量。 在团队的仪表板上进行此度量可以帮助他们学习和调整方法，以最小化这些障碍。

图7.按团队阻塞任务

在许多开发情况下，正在处理的任务被阻止并且无法取得进展。 在这种情况下，可以暂停任务，以便展开和存储与该任务有关的所有代码更改。 任务挂起后，开发人员可以处理其他任务。 当原始任务变得畅通无阻时，如果需要，开发人员可以恢复原始工作并合并原始任务的更改。

开发人员可能有大量的暂停更改或更改集 。 如图8所示，变更集是一个存储库对象，它收集文件，文件夹和组件修改的相关组，以便可以在单个操作中将它们应用于流目标，例如工作空间或流。 每个暂停的变更集都以未完成的工作形式表示浪费，但是，只要开发人员正在从事有价值的工作，那么这种浪费形式就不用担心了。 有时，短期内需要浪费。 可以回顾性地分析临时废物的来源。

图8.待更改视图

评审工件也可能导致等待浪费，因为作者通常必须等待评审完成才能继续。 通常，浪费大量时间来追踪人员以完成评论。 IBM DevOps集中并自动执行评论。 可以通过电子方式将审阅的工件（需求，设计，代码和软件资产）分配给审阅者，并可以以简单的方式捕获并实施其注释。 审阅者会收到通知并自动提醒他们。 如图9所示，可以随时查看任何评论的状态。 这种方法可以消除对工件进行审查的过程中的浪费。

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

交接和任务切换

越区切换和任务切换会造成类似的浪费。 当一个团队成员将一件工作移交给另一个工作时（例如，开发人员修复缺陷并将其移交给测试人员以验证修复），就会发生移交 。 Ť 问切换是不同的任务之间，当一个人的开关。

理想情况下，在小型敏捷项目中，交接最少，因为团队成员倾向于承担所有项目角色（编写故事，开发代码，测试以及其他类似任务）。 但是，在较大的项目或具有多技能的个人很少的项目上，需要进行移交。 由于以下几个原因，移交会带来大量的浪费：

• 由于需要在工具或团队之间更新信息密钥而导致的返工
• 团队成员未意识到已准备就绪而导致的等待时间
• 缺乏足够的细节
• 过时的文物
• 尚未成功传达给团队的变更。

IBM DevOps通过以下方式帮助减少开发和运营之间的切换浪费：

• 自动化部署，
• 提供在环境之间促进应用程序的功能
• 提供组织和管理大规模发布的功能。

这些功能消除了与部署软件有关的手动操作和易于出错的活动，它们有助于管理发行版，变更的治理，最终显着减少浪费和风险。 团队可以更频繁地发布其软件，以便它可以更早地交付价值，从而使团队和组织可以更快地获得反馈。 图10显示了如何可视化每个环境中的应用程序版本，以便操作可以看到即将发生的事情，并可以简化开发和操作之间的切换。

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

使用IBM DevOps，来自任何团队的团队成员都可以通过RSS，电子邮件列表或Web中的viewlet查看信息并关注其他团队中的更改。 如图11和以下示例所示，此信息可以帮助团队节省时间。

• 需求团队可以看到他们的哪些需求已变成正在运行的，经过测试的代码，如图11所示。
• 设计团队可以跟踪可能影响他们的不断变化的需求，从而减少浪费在设计错误需求上的工作。
• 开发团队可以跟踪测试团队报告的新缺陷以及不断变化的需求，并且可以轻松地计划工作以实施新需求并修复缺陷。
• 测试团队可以查看哪些需求已更改，哪些故事可以进行测试，哪些先前已损坏的测试现在可以进行重新测试，并且可以轻松地计划测试活动。
• 操作团队可以查看构建的状态，将应用程序部署到的环境以及每个构建中的哪些缺陷修复和新功能。

图11.需求团队视图需求变成了正在运行的代码和测试

可见且易于访问的信息可以极大地减少在切换，额外的流程和动作上浪费的时间，因为团队成员可以轻松获得所需的信息，如图12所示。他们无需访问即可访问信息。打扰其他团队成员以获取状态更新。

图12.仪表盘显示其他团队的即时更新

在项目和后续阶段之间进行移交

上一节的重点是如何在项目内减少浪费。 本节重点关注项目，部门和第三方之间的浪费。 如下例所示，团队之间的交接可能是浪费的：

• 应用程序从开发团队传递到另一个团队（部署或运营团队）以进行部署
• 一个应用程序被过渡到一个没有足够的开发工件（例如需求，设计和测试）的支持团队。 支持团队必须弄清楚应用程序如何工作，然后才能提供令人满意的支持。
• 一段时间未使用过的应用程序需要升级，但是原始的要求，设计，测试，有时甚至是代码也无法找到。
• 一个应用程序具有某些非功能性需求，这些需求已在组织中的其他地方得到解决，但是很难找到其他具有这些需求的应用程序，或者很难从那里找到用于解决这些需求的设计和代码。

软件资产管理可以帮助解决这类问题，并减少与在正确的时间找不到正确的信息有关的浪费。 资产可以用来存储任何有用的工件。 他们的背景； 元数据，例如代码，测试脚本，服务定义，参考体系结构和业务模型。 特别是，使用IBM®Rational®Asset Manager可以通过帮助人们使用正式分类，标记和文本搜索的组合来减少查找现有资产所需的时间。 这种方法可以非常快速地找到高质量的资产，并将其下载到桌面或开发环境中以供使用。

通过将Rational Asset Manager用作所有软件资产的权威库，您可以开始直接解决在项目和程序级别上交接中发生的许多浪费和低效率。 开发团队可以选择将其可部署的工件上传到其中，并且可以将IBM DevOps设置为仅下载和部署已在Rational Asset Manager中批准的工件。 这种方法改善了控制并减少了浪费和风险。 它还为所有项目文档，代码和工件提供了一个门户，以便支持团队可以在一个地方访问所有开​​发信息。 这使快速查找维护中系统的开发工件变得容易。 团队能够快速确定解决了类似问题的其他项目，并重用其解决方案以节省时间。

如图13所示，直观的浏览图显示了资产之间的关系，使查找相关资产变得更加简单快捷。

图13. Rational Asset Manager可视浏览

任务切换

任务切换产生的浪费的一个例子是，开发人员已部分完成对一个功能的编码，然后切换到另一个功能。 在开始使用新功能之前，开发人员可能不得不浪费时间删除所有原始代码更改。

许多个人生产力书籍（例如《完成事情》和《明天做起来》 ）都强调多任务处理并不快。 如果您有两个工作要做，那么先做一个然后再做另一个要快得多，而不是尝试同时做两个。 敏捷和看板开发团队遵循此原则，以最大程度地减少同时处理的故事数量。

在理想的世界中，任务切换是有限的。 人员和其他资源的管理方式可以帮助最大程度地减少任务切换带来的浪费。 例如，避免团队投入过多，以免需要处理太多不同的任务。 按顺序进行项目，而不是同时向个人或团队加载许多项目。

如果需要切换任务，CLM可以提供帮助。 使用CLM，由于将所有工件（业务流程，需求，讨论论坛，评论，评论，测试，设计，代码，计划甚至人员）链接在一起并相互关联，因此可以将因加速而造成的浪费最小化。 这种安排建立在上下文中，并缩短了从一项任务切换到另一项任务所需的时间。

CLM为任务切换提供了出色的支持，因为所有工件都存储在CLM存储库中。 所有文件更改（代码更改，设计更改或文档更改）都与任务相关联。 更改作为更改集进行管理。 如图14所示，从事该任务的开发人员能够暂停一组更改。暂停将所有代码恢复为开始更改之前的状态。 因此，开发人员可以一次并行运行许多代码更改，而只需花费很少的精力就可以开始执行任何单个任务。 显然，以这种方式工作并不是理想的选择，但是如果您不得不一直等到其他工件可用并准备好进行编辑时，则暂停功能提供了一种使等待和任务切换浪费最小的方法。

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

运动

当人们花时间在身体上移动时，就会产生运动浪费。 例如，当业务分析员每天必须走两次楼梯才能见到业务专家时，就会产生运动浪费。 运动浪费和额外过程中浪费的时间密切相关。 当团队成员参加不需要或仅需要短时间出席的会议时，就会产生运动浪费。 这种情况会导致动作浪费和任务切换浪费，因为团队成员必须在会议后重新获得焦点。

为了减少动作浪费，通过使用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支持一种需求定义方法，该方法侧重于等待详细定义功能 ，直到实现它们的迭代为止。 它还支持编写客户测试，以代替详细的需求定义。

在整个生命周期中改进自动化的其他IBM®Rational®工具可以删除当前手动执行的流程。 删除手动流程可以更轻松地实施更小，更频繁的发行版，持续集成，集成测试，测试虚拟化和自动化测试。 这些做法还可以减少浪费，因为它们可以缩短周期时间，并且可以更频繁地接收反馈。 通过查看价值链来评估整个过程中的自动化改进。

对于团队来说，使用回顾来分析流程并确定可以进行哪些更改以不断改进是一种很好的做法。 CLM通过收集所有任务的数据并提供分析数据的能力来确定是否存在没有增值的流程或任务来提供帮助。

额外功能

使用以下方法来减少额外的功能：

• 建立业务构想存储库，以引入自适应和迭代的规划方法。 首先实施重要思想。
• 从清晰的愿景开始。
• 根据反馈积极引导功能设计。
• 允许解决方案发展。
• 尽早积极地使一系列利益相关者参与进来，并且经常进行频繁的课程纠正以取得更好的结果。
• 鼓励利益相关者在不断变化的目标上进行协作和融合。
• 使用视觉表示和基于场景的需求定义，而不是大型文本文档，如图18所示。
• 将详细的规范延迟到实施的冲刺为止。

商业想法的存储库特别适合可能在多个系统或应用程序中实现任何给定商业想法的组织。 如图17所示，CLM使业务可以围绕一组高级业务构想进行协作，对其进行优先级排序，管理它们的批准流程并最终将其提交给开发人员。 在构思完成之后，企业可以查看多个团队的进度以了解构思的状态。 这种方法有助于企业专注于代表最佳投资的构想，并最大程度地减少致力于开发的项目数量。 它有助于确保不开发不需要的功能。 该企业保留了很大的灵活性，以响应不断变化的市场状况并从生产中的现有想法中寻求反馈。

图17.商业想法的成对比较

如图18所示，可视化表示和基于场景的需求定义使您更容易理解需求带来的价值。

图18.视觉场景有助于理解

The other approaches to help reduce extra features shift the focus from complying with a complete requirement specification to choosing to deliver only requirements that offer significant value to the business. In particular, the shorter cycle from requirements to delivery means that extra features are less likely to be implemented at all.

CLM supports defining features in many forms, from user stories or use cases, storyboards, UI sketches, process diagrams, text, images, and even audio or video. Not only can stakeholders find what's new and changed recently, they can also discover the wider context of the requirements in terms of links to both internal and external artifacts. For example, they can see the screen mock-ups for a particular user story. Using a range of visual techniques improves success. The visualizations are easier for people to understand how a requirement affects their daily work.

As described earlier , a single repository that can seen by all relevant stakeholders and that can be searched to find content relevant to each individual makes it easier for people to find and comment on what's relevant to them. Dashboards, tagging, and filters encourage active involvement from a broad range of stakeholders. This involvement, especially from business departments and clients, is invaluable because these stakeholders can provide early feedback.

With CLM, features can be easily fed into agile development plans. The plans demonstrate executable code to implement the most important features first and early.

The transparency, collaboration, and context available in CLM help teams to understand the features. This understanding improves the quality of decision making. The priority moves from conforming to the specification to validating with stakeholders the true value of the features and implementing the key features early.

Partially completed work

Waste from partially completed work is the amount of effort invested in features that are not yet implemented. Using the waterfall development approach leads to a significant amount of partially completed work, because early in the process, much time is spent writing requirements, developing, and coding. No working software exists until late in the cycle. This limitation is the primary reason that teams and organizations move to an iterative approach, so that they can finish features quicker and potentially deploy them to start delivering value sooner.

Even if you are using an iterative approach, waste from partially completed work is still important to consider. Within an iteration, the focus should be on finishing each story (or a limited set of stories) in turn, with the team working on as few stories as possible at one time. This approach minimizes partially completed work and means that some completed code is delivered within the iteration or sprint. If the team's work is spread across all of the stories, testing might be left until very late in the iteration cycle and the team might not deliver any new functionality in that iteration because the defects are discovered late, with little time to fix them.

CLM can help in a couple of ways:

• As shown in Figure 19, with the CLM agile planning taskboard you can easily see the partially finished work.

Figure 19. Agile planning taskboard shows partially completed work

• To minimize partially finished work, CLM can help teams have a greater number of developers working in the same area of code. In this collaborative approach, each developer gets a sandbox to develop code in isolation, without disrupting others. Developers can deliver code to each other if required, so that they can build on each other's work without sharing with the whole team. This flexibility fosters close collaboration to reduce the partially finished work within a project.

Defects

Defects cause two kinds of waste: the waste in repairing the defect and the waste caused by the software not working correctly. IBM DevOps helps reduce the creation of defects by improving the quality of requirements. It also helps to reduce the time taken to resolve defects so that they cause as little waste as possible. The process of finding, fixing, and resolving defects is known as the defect value chain . Often, significant waste occurs resolving defects because several teams or organizations are required to collaborate closely.

IBM DevOps supports lean development by improving the efficiency of the defect value chain. For agile teams story points (the scrum unit of measurement to estimate complexity of user stories) must not be claimed if there are outstanding defects. Defects imply that the code isn't finished and is still counted as work in progress, a state that is undesirable in lean development. Defects must be found and resolved quickly within a sprint. An efficient defect resolution process is a key to preventing an accumulation of technical debt during software development.

At Toyota, for example, people are coached to understand the root causes of problems so that the fixes can prevent future weaknesses from building up. In their famous "Stop the Line" practice, when a defect is discovered, the whole production line can be stopped to fix it then and there. This practice is aimed at reducing additional work downstream. In software development, if the build breaks, every effort should be made to fix it quickly.

Defects cost more to fix, the later they are discovered. The additional cost comes from the extra resources required for context switching and the extra processes that must be repeated if a defect is found late. To find defects earlier and to reduce the waste associated with them, it becomes necessary to test earlier and earlier in the lifecycle, a practice known as left-shift testing .

Integration testing, because it is typically difficult to automate, is often left undone because of the complexity of setting up all dependent applications. IBM DevOps service virtualization capability makes it possible for application services to be virtualized easily and quickly. Any application or component that depends on these services can be easily tested against the virtualized services instead. Using virtualized services requires much less effort to ensure that the application under test will work correctly and integrate. This capability becomes even more powerful when combined with IBM DevOps continuous delivery capability, because early environments can use virtualized services and progressively replace them with the real services as the system under test progresses through the various test environments. For example Forrester Consulting reported on a large European bank that increased their project delivery capacity by 100 percent over three years (scaling from 40 to 80 projects completed annually) as a result of using IBM DevOps test virtualization and integration testing capabilities.

As shown in Figure 20, CLM automates the handoff between the different teams. This automation creates a significant improvement in the overall process efficiency by reducing waiting waste during a manual handoff.

Figure 20. Defect workflow with Rational Quality Manager and IBM Rational Team Concert

In CLM, when the tester reports a defect, that information appears in the developer's IDE inbox of incoming work. Assuming that this is an important defect that can be fixed immediately, the developer can then suspend all current work in a single action, load the baseline in which the defect is found, and work on fixing the defect. When the defect is fixed, the developer can resume the previous work, picking up exactly where he or she left off. After the code has been fixed and built, IBM DevOps automatically deploys the fixed code to a new environment, and the tester is notified where the fix is deployed and which tests can be rerun. This approach means that teams can resolve defects very quickly. In particular, waiting and task switching can be significantly reduced.

Figure 21 shows a hypothetical example of a manual defect fix cycle.

Figure 21. Manual defect fix cycle

In this example, a defect takes 16.25 hours to fix, but 12 hours (nearly 75 percent of the elapsed time) of time is waste. The wasted time significantly increases the time that it takes to fix defects. When this example is scaled across the number of defects normally seen in a project, it can result in significant delays to fixing code and getting a working system delivered to the customer.

Figure 22 shows the same fix cycle when CLM is used to improve the collaboration.

Figure 22. Automated defect fix cycle with CLM

AltText:

In our example using CLM, the effort to fix a defect is reduced from 4.75 hours to 3.25, and the waste is reduced from 12 hours to less than 2 hours. More importantly, it now takes only a little over half a day to fix a defect, which means that within a two-week sprint, it's possible to close defects quite quickly. This time-savings helps keep the technical debt under control and produces high-quality software that is potentially deployable.

If the defect is not impeding progress, it might be argued that task switching for each defect generates more waste because of intellectual restart time for developers. In these cases, defects can be dealt with in small batches and short cycles. Lean development incorporates temporary necessary waste for just such situations.

摘要

This article explores various ways that IBM DevOps can help teams become leaner and smarter. IBM DevOps helps teams:

• Remove waste and automate manual processes so that software can be delivered more efficiently, and with reduced cycle times.
• More effectively steer the process by helping them to look at the end-to-end picture, to measure and monitor, and to continuously improve their software delivery.

Leave a comment to share how you apply these ideas in your own organization.

翻译自: https://www.ibm.com/developerworks/rational/library/leaner-software-development-with-the-aid-of-collaborative-lifecycle-management/index.html