衡量您的IT OPS –第1部分

62 阅读 0 评论 41 点赞

我是靠谱客的博主彩色绿草，最近开发中收集的这篇文章主要介绍衡量您的IT OPS –第1部分，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

在上一篇文章中，我简要解释了衡量IT OPS为持续改进（CI）奠定基础的重要性。然后，我列出了我认为很少且必不可少的IT OPS度量标准，这些度量标准构成了CI环境。其中第一个是FALT （功能平均提前期）。这是哪种措施，为什么重要呢？

FALT让我们一目了然，这是企业要求该功能之前（或者在您谈论敏捷时在积压中发现它的位置，或者在您谈论精益时在处理队列中找到它的位置）之间经过的平均交货时间。当此类功能交付生产时。如果可以肯定的是，企业要求的可交付成果在今天比明天更有价值，因为更早交付可以最大程度地提高投资回报率（ROI），那么，提前期较短就意味着更高的业务价值。此外，将功能部署到生产中所花费的时间越长，成本越高（请考虑简单的工时乘以x平均资源成本），并且由于我们刚才所说的，ROI越低。对于某些类型的公司，例如初创公司，交货时间的微小差异可能会导致生存和失败之间的差异。

第二个方面很重要。在最近几个月中， 持续交付已越来越受欢迎。 Humble和Farley在他们的书中谈到了这种看待软件交付的新方法，因为他们意识到，软件交付产品的时间越短，投入生产的价值就越大，从而为要求它的利益相关者提供价值。在“敏捷”中，如果故事通过演示使产品所有者满意（我喜欢本文中 Mayank Gupta给出的“在敏捷中完成的定义” ），并且通过连续交付将故事视为“完成” ，则在功能已实现时就完成了故事已部署到生产环境中，可以使用了。这对新手敏捷从业者来说似乎很小的区别，但是想象一下，您拥有10多种通过UAT并准备投入生产的功能；你能说你完成了吗？令您惊讶的是，有多少敏捷从业人员会回答“是”，但事实是，这10多个功能中没有一个提供任何商业价值，因为目标受众无法利用它们。

因此，要衡量某个功能部件的平均提前期，我们考虑两个日期：此要求找到其位置的日期是某个队列（待办事项只是另一个没有限制的队列）和该功能部件投入生产的日期。

测量FALT的一种方法可能是：

定义服务等级 （COS – 看板中欢迎的概念）。服务等级（COS）只是生产交付品的一种。每个组织都有其类型，但仅举几例，我们可以考虑其中的一些：业务交付，生产错误修复，常绿化，遗留系统的维护等。
定义一个包含三个部分的电子表格：一个用于收集每个COS的详细数据；另一个用于收集COS。一个用于计算平均值，另一个用于定义验证列表（在我们的示例中，唯一的一个是COS列表）

可以在下面找到此类电子表格的示例：

第一个工作表包含每个COS的详细数据和一个图表，该图表是使用第二个工作表中计算的每个COS的平均提前期创建的，如下所示：

对于此示例，我还创建了第三个工作表，其中包含COS的验证列表，如下所示：

然后可以使用验证列表来约束COS列中的值。

查看图表（如果需要，可以查看工作表2），这很明显（并且很有帮助），可以看出需要将注意力集中在什么地方；在这种情况下，常绿项目（代表纯成本）似乎是主要的瓶颈，从项目进入工作队列到最终部署到生产，平均需要288天。

数据不一定是好坏，这就是要点：重要的是简单地拥有它们，以便IT组织可以对数字看起来健康还是需要解决一些瓶颈做出自己的决定。。例如，可能在进一步调查后发现，由于需要与使用升级系统的下游系统进行协调，因此在该特定组织中，Evergreening项目的本质实际上需要很长的交付时间。如果该IT组织没有衡量IT OPS，并且说在预算年内交付了所有必需的功能，那么误入误报的风险可能会很高，而问题是：“您的IT状况如何”？（误判）答案应该是：“太好了！今年，我们交付了我们所有的要求！”。真正的问题是：您能做得更好吗？

希望本文对您有所帮助。在我的下一篇文章中，我将讨论一种建议的方法，该方法用于度量已部署功能（DECODEF）的开发成本，如我上一篇文章中所述。

转到第2部分

参考： 测量您的IT OPS –我们的JCG合作伙伴 Marco Tedone在Marco Tedone的博客博客上的第1部分。