如何在软件开发车间中找到约束？

Question

让我们将约束定义为任何阻止系统实现其目标的约束，然后查看组织中的DevOps目标。

一个很好的定义是"DevOps支持从开发到IT操作到客户的快速特性流“。改进DevOps可以通过消除流动障碍来实现。

首先，我们必须在流程中找到这些约束。也许有多重障碍，我们如何决定首先消除哪一个障碍？

Eliyahu . Goldratt博士的名言是

没有在约束条件下作出的任何改进都是幻觉。

这种约束一旦被发现，就成为系统管理的一个重要的聚焦机制。那么，如何在IT组织中识别约束呢？如何改变它以获得更好的流动的好处呢？

Answer 1

在任何过程中识别约束是一项相对简单的任务。工作在整个组织中从一个人转移到另一个人，它只会在约束面前堆积起来。例如，您可以查找阻塞未解决问题数量最多的人员或团队。这取决于您如何跟踪工作流程，但如果您确实跟踪它，那么识别约束通常不会太困难。它有助于了解您的组织的价值链，并简单地跟随它们。

约束条件可分为三种类型：

• 人:个人特有的特殊技能或知识。
• 策略:一种书面或未写入的策略或流程，它通过增加延迟或降低吞吐量来限制工作。
• 设备:特定的计算机系统可以限制您通过它的速度或可以同时使用它的人数。

在软件方面，软件交付过程通常是一种约束，因此连续积分 / 连续交付是提升该约束的一种强有力的方法，而为了提高工作的吞吐量，常常需要将组织置于此约束之下。通过软件交付中的自动化，您可以消除缓慢的人员，以及通常代价高昂的政策障碍和批准。与其他两种设备相比，以计算机系统升级形式出现的设备成本相对较低。

QA是流程中可能的约束的另一个例子。人工质量控制是工作密集型的，甚至自动化测试也可能受到设备的限制，以防软件在昂贵的硬件上运行。但是，在QA中最常见的约束是策略，它往往与任何问题雪上加霜。QA过程的延迟和较小的吞吐量会导致更大的工作量，从而将成本推到代码集成中。

Answer 2

不幸的是，这里没有一个答案。如果你问你团队的每个成员，他们可能都有不同的答案。与其试图对诸如“文化”这样的广义事物进行根本原因分析，不如把目光转向投资回报。解决瓶颈附近的问题通常会比瓶颈更远的RoI，但如果再做5分钟就能得到90%的好处，那么谁在乎呢，做必要的事情。