软件开发中的精益思想解读︱精益软件开发

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

我们关注的是如何使用精益化思想帮助团队降低成本和缩短周期&＃xff0c;可以让团队成员的工作更有效率。

一般来讲&＃xff0c;团队和组织通常浪费了 40% 或更多的资源。浪费的形式有以下几种&＃xff1a;

不必要的开销

不必要的返工

不必要的特性

构建了错误的东西

不必要的流程

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

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

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

等待&＃xff1a;

人们花时间等待别人做完一件事&＃xff0c;这种等待通常是因为没有明确的团队之间的工作交接。以及工作进度和流程管控的不合理&＃xff0c;导致人力资源的浪费。

任务切换和交接&＃xff1a;

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

移动&＃xff1a;

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

额外进程&＃xff1a;

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

额外特性&＃xff1a;

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

部分完成的工作&＃xff1a;

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

缺陷&＃xff1a;

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

如何在团队工作中尽可能的减少浪费&＃xff0c;让开发团队有更多的时间做卓有成效的工作&＃xff1f;

价值流图的存在有两个目的&＃xff1a;帮助公司找到并结束无用的活动。找到问题并创建一个更有效率的过程并不容易&＃xff1b;就算是那些顶尖的公司也可以变得更有效率&＃xff0c;存在改进的空间。但是对公司进行实质性的改变以消除那些没有效率不高的活动&＃xff0c;并不是那么容易的。相对而言&＃xff0c;识别无效率活动就容易多了&＃xff0c;但是将这些无效率的活动终结就另当别论了。价值流图在增强公司竞争力的同时&＃xff0c;还能产生一些需要的更改。但是首先&＃xff0c;您得尝试描绘项目的价值流图。

评估浪费和价值流

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

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

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

使用价值流来查看组织中的工作的任何方面。通常&＃xff0c;以下价值流有明显的浪费&＃xff1a;

确保新想法进入开发阶段

确认需求和设计

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

复制和修复缺陷

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

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

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

除了价值流的长度之外&＃xff0c;还需要考虑以下这些测量&＃xff1a;

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

总周期时间

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

周期时间 &＃61; 工作量 &＃43; 浪费量

效率 &＃61; 工作量 / 周期时间

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

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

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

如何正确地画出当前软件项目团队的价值流图&＃xff1f;

关于等待的浪费

许多浪费都可以归因于等待&＃xff0c;特别是以下这些常见的等待形式&＃xff1a;

等待基础架构

等待应用程序部署

等待其他团队/任务

等待审查完成

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

等待基础架构

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

等待应用程序部署

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

DevOps 使团队能够自动化部署应用程序&＃xff0c;管理哪些东西应该部署到每个环境&＃xff0c;并促进环境之间的编码。而不是等待部署&＃xff0c;然后可以自动完成部署。

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

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

等待其他团队/任务

浪费的第三个主要来源是团队的失败&＃xff0c;他们受他人的影响优先完成了某些工作。通常&＃xff0c;没有一个简单的方法让团队或个人了解他们的工作的哪些方面影响到了他人。scrum 方法试图通过关注这些障碍的日常会议解决这个问题。部分任务管理工具通过DashBoard提高其他团队和个人任务的可见性。

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

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

等待审核完成

审查工件也可能导致等待浪费&＃xff0c;因为作者常常需要等待审查结束才能进行后续操作。追踪人们是否完成了审查通常会浪费很多时间。通过第三方工具提供集中和自动完成审查&＃xff0c;可以将需要审查的工件&＃xff08;需求、设计、代码和软件资产&＃xff09;以电子方式分配给审查者&＃xff0c;而且可以采用一种简单的方式获得并实现他们的审查。审查者和被审查者会获得关于评论的自动通知和提醒。团队成员可以随时查看任何审查状态。这种方法可以减少工件审查过程中的浪费。

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

理想情况下&＃xff0c;在一个小型的敏捷项目中&＃xff0c;很少进行任务交接&＃xff0c;因为团队成员倾向于承担所有项目角色&＃xff08;编写实例、开发代码、测试和执行其他类似任务&＃xff09;。然而&＃xff0c;在更大的项目中&＃xff0c;或者在很少有全能人才的项目中&＃xff0c;任务交接是必需的。任务交接会引入大量的浪费&＃xff0c;原因如下&＃xff1a;

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

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

缺乏足够的细节&＃xff1b;

过时的工件&＃xff1b;

没能成功地将更改传达给团队&＃xff1b;

跬步进化论能够协助客户通过以下方式减少开发和操作之间的交接浪费&＃xff1a;

部署持续化和自动化&＃xff1b;

促进环境之间的应用的能力&＃xff1b;

提升组织和管理大量版本的能力&＃xff1b;

这些功能可以有效消除与部署软件相关的手动活动和容易出错的活动&＃xff0c;并帮助管理版本&＃xff0c;以及最终会显著减少浪费和风险的更改。团队可以更频繁地发布他们的软件&＃xff0c;以便可以更早地提供价值&＃xff0c;这样团队和组织就可以更快地获得反馈&＃xff0c;简化开发和操作之间的任务交接。

借助于研发流程的改进&＃xff0c;来自任何团队的团队成员都可以通过看板、即时通讯工具、电子邮件列表或 Web 中的视图来查看信息和关注其他团队中的变化&＃xff1a;

需求团队可以查看他们的哪些需求已经转换成正在运行的或已经测试的代码&＃xff1b;

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

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

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

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

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

不必要的流程&＃xff0c;重复的任务和不必要的文档工作可能会浪费时间。这个文档会给最终用户提供应有的价值吗&＃xff1f;

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

确定进程是否向客户提供了价值&＃xff0c;或者是否延误了客户获得价值的时间。手动部署进程就是进程浪费的一个很好的示例。有人编写很长的、详细的和完整的文档&＃xff0c;描述如何部署应用程序&＃xff0c;还编写了一些随后手动执行的指令&＃xff0c;以便将每个应用程序部署到测试环境或生产环境。在某些情况下&＃xff0c;组织会执行双重部署&＃xff0c;以确保正确遵循指令。大量的持续交付解决方案&＃xff08;例如TeamCity / Cloud Flow&＃xff09;都提供了一个图形化的进程编辑器简化了应用程序部署&＃xff0c;以便创建自动化部署。Jenkins 2.0新引入的PipeLine&＃xff08;图1&＃xff09;功能有助于减少构建或部署过程中造成的缺陷&＃xff0c;显著降低失败部署的风险。

 图1: Jenkine PipeLine样例

而且&＃xff0c;团队还可以配置持续交付工具来制定一个组织的进程&＃xff0c;有一些功能可以在整个过程中为团队提供无缝引导。有时团队成员或许会跳过某个进程。但是&＃xff0c;与团队成员不遵循进程相比&＃xff0c;持续交付工具更容易引导团队遵循进程。例如&＃xff0c;如果一个团队决定&＃xff0c;他们需要在其单元测试中检测 70% 的代码覆盖率&＃xff0c;如果代码覆盖率不符合这个标准&＃xff0c;那么持续集成可以触发Andon操作&＃xff0c;禁止代码交付。

如果团队想以某种方式进行工作&＃xff0c;或者发现进程的某些元素没有为他们工作&＃xff0c;持续集成工具还为团队在覆盖进程方面提供了灵活性。某个团队可能决定他们想要某些组件的更高层次的覆盖率&＃xff0c;或者他们想要有选择地强制执行代码覆盖率要求。例如&＃xff1a;集成需求进度的跟踪后&＃xff0c;团队成员可以等待已定义特性的细节&＃xff0c;直到实现他们所在的迭代。

持续发布能够通过消除手动进程&＃xff0c;实现更小更频繁的发布、持续集成、集成测试、测试虚拟化和自动化测试。这些实践还可以减少浪费&＃xff0c;因为它们不仅能够缩短周期时间&＃xff0c;还可以更频繁地接收反馈。能够通过查看价值链来评估整个进程的上下文中的自动化改进&＃xff08;图2&＃xff09;。

图2: 持续发布样例

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

缺陷会造成两种浪费&＃xff1a;修复缺陷所产生的浪费&＃xff0c;以及软件不能正常发挥作用而产生的浪费。

通过提高需求的质量&＃xff0c;有助于降低缺陷的产生率。它还有助于减少解决缺陷所需的时间&＃xff0c;这样就可以尽可能少地产生浪费。搜索、修复和解决缺陷的过程又叫做缺陷价值链。通常&＃xff0c;这会产生大量的成本&＃xff0c;因为它需要若干个团队或组织进行亲密无间的协作。

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

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

后来他们发现&＃xff0c;缺陷成本高于修复成本。上下文切换需要额外的资源&＃xff0c;如果后来发现缺陷&＃xff0c;则必须重复额外的进程&＃xff0c;这些都会带来额外的成本。为了及早发现缺陷&＃xff0c;减少与缺陷相关的浪费&＃xff0c;必须尽早在生命周期的早期进行测试。使用合理的持续交付配合自动化测试有助于降低整体研发成本。同时&＃xff0c;确保相关的团队或组织及时收到缺陷信息&＃xff0c;小批次地在短周期内处理缺陷&＃xff0c;也有利于降低修复成本。

在持续交付中增加恰当的自动化测试及修复流程&＃xff0c;并及时通知相关干系人进行Andon操作&＃xff0c;可以有效减少缺陷价值链数量&＃xff0c;提升修复缺陷价值链效率。