看板与DevOps有何关联?

减少浪费,优化价值流,并持续向满意的用户交付价值。
148 位读者喜欢这篇文章。
two women kanban brainstorming and brainmapping with post-it notes on a whiteboard

CC BY 3.0 US Mapbox Uncharted ERG

看板并非新生事物;事实上,它的历史比本文的大多数读者都要长。当我们把丰田公司在其主要工厂车间引入看板的年份(1953年)添加到我们分析DevOps DNA的文章中的时间轴图像中时,它的历史便显而易见了。

DevOps timeline

二十多年来,我一直在直观地使用看板,以某种形式或另一种形式,来跟踪个人计划、工程项目和数字化转型。直到最近几周,我才开始思考看板的起源、力量以及与其他框架和系统的协同作用,同时向团队介绍看板,并帮助他们将看板作为我们通用工程系统中一个强大的系统来接受。

什么是看板?

看板的意思是“视觉信号”,起源于丰田制造业。它由大野耐一开发,旨在提高制造效率。当我们跳跃到几十年后的未来,看板是对敏捷和精益的补充,通常与诸如Scrum、Scaled Agile Framework和Disciplined Agile等框架一起使用,以可视化和管理工作。

Kanban complements agile and lean

您可以在互联网上、书籍中以及与其他已经接受该系统的工程师的热烈讨论中探索看板的多种解释。在我们通用的协作和工程系统上下文中,看板提供四个关键实践:

  • 可视化工作: 我们可视化所有工作,并寻找诸如卡片变红色之类的触发因素,这表明它们代表的工作被阻止或已经休眠超过两天。
  • 限制在制品: 我们就(软)在制品限制达成一致并强制执行,以鼓励减少批量大小并管理队列长度。
  • 关注流程: 我们拉动而不是推送工作,这有助于我们将承诺推迟到满足我们的完成定义 (DoD) 并且我们有能力提交到下一个活动
  • 持续改进: 重要的是测量工作从进入我们的积压工作到完成整个过程所需的时间(前置时间),以及我们的工作效率(周期/前置时间)。这使我们能够不断检查和改进我们的工作方式并跟踪进度。

Kanban practices and terminology

我们使用色彩鲜艳的视觉卡片来表示在一个或多个泳道中的一个或多个活动中流动的活动。 每个看板列代表一个活动,每个泳道代表一个人、一个组或另一个用于分割卡片的桶。 卡片的颜色没有规则,但红色通常表示有问题。 但请记住将颜色与有意义的图标结合使用,以可视化色盲用户的特殊状态。

我们应该将承诺推迟到满足我们的就绪定义 (DOR) 之后,以便我们可以确保更快、更高质量地实现我们的完成定义 (DOD)。 我喜欢这两个不同的术语(DOR 和 DOD),因为[产品负责人]应对 DOR 负责,而团队可以拥有 DOD 的所有权。” —Mathew Mathai

我经常用这个比喻向新团队解释前置时间和周期时间之间的区别:想象一下你走进一家餐厅。 你坐下来,研究菜单,然后决定你想喝什么和吃什么。 当服务员接受你的订单时,前置周期时间开始计时。 当酒吧开始倒你最喜欢的药剂,厨房开始准备你的饭菜时,周期时间开始计时。 当订单到达你的餐桌时,如果(且仅当)你满意,前置时间和周期时间都会停止。

因此,前置时间衡量的是您(客户)必须等待多长时间才能收到您的订单。 周期时间衡量的是准备订单的活动的流程时间。 从客户的角度来看,前置时间很重要。

重要的是明确你的策略,例如你何时开始测量前置时间和周期时间。 有些顾客在进入餐厅时就开始他们的“不耐烦”时钟,而另一些顾客则在下单时开始计时。 在这两种情况下,他们都需要了解你如何衡量你的流程,以避免误解、不切实际的期望和失望。

此图像是从我们的信息传输海报之一中提取的,它总结了我们开始采用看板系统时的主要经验教训。

Key kanban learnings

DevOps呢?

使用PowerShell自动化Linux、macOS和Windows进程中,我们简要介绍了价值流映射。它使我们能够衡量个人和总的前置时间、周期时间、效率和质量,并揭示出彼此抵消的不同活动、组和孤岛。

value-stream mapping

你会注意到看板和价值流映射图像之间存在相似之处。两者都可视化关注由在视觉板上拉动的单个卡片表示的活动流程。

Continuous delivery pipeline

持续的流程和效率是健康的DevOps思维方式的核心。它转化为持续交付管道,如上所示,它将不同的团队(例如业务、开发、安全和质量保证)联合起来,以实现从构思到生产的想法。持续衡量和简化交付管道不仅有助于提高价值流,还有助于提高价值质量。

应该很明显的是,(与看板类似)这里的重点是流程。在看板中,在活动之间来回切换是不受欢迎的,并且在持续交付管道中是不切实际的。这让我想起最近的一次白板讨论,我们在讨论可视化和管理需要两个团队完成的工作流程的挑战。

Dividing a job between two teams

如此处所示,我们将需要团队 X 执行活动,然后是团队 Y,再次是团队 X 的作业切分为三个故事。这三个故事由两个看板上的三个卡片可视化,从 A 流到 B 流到 C,团队 X 和 Y 拥有明确的所有权,我们可以独立地将它们测量为前置时间和周期时间。

我们正在漂移到另一个令人兴奋的流程优化主题……让我们回到最初的问题。

看板和DevOps之间的关系是什么?

Donovan Brown将DevOps定义为“人员、流程和产品的结合,以实现向最终用户持续交付价值。

当我们分解这个定义时,我们意识到DevOps思维方式的核心是持续交付价值并让我们的客户满意。

  • “来自利益相关者的反馈至关重要。”
  • “超越当今流程的局限进行改进。”
  • “没有新的孤岛来打破孤岛。”
  • “了解您的客户意味着跨组织协作。”
  • “通过热情激发采用。”

看板系统帮助我们可视化并提高价值交付的效率,从而让客户满意。我认为,如果您对看板感到满意,您将通过可视化流程改进反馈持续创新来享受DevOps的全部好处。

我们拥有最好的协作——协同作用, 或者说是共生

标签
User profile image.
自 80 年代中期以来,我一直致力于软件工程的简单性和可维护性。作为一名软件工程师,我分析、设计、开发、测试和支持软件解决方案。

评论已关闭。

Creative Commons License本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。
© . All rights reserved.