治理(遵从性)和敏捷交付

最近的一次讨论让我思考了治理(确保法规遵从性等)如何与“敏捷”交付方法相适应。我们讨论了如何建议客户在哪里应用敏捷方法以及为什么。当谈到治理时，有人抛出了这样的声明:“嗯，这就像瀑布一样，所以没有什么可做的。”

这份声明让我大吃一惊。我要求澄清。原因是治理需求是预定义的和固定的，而敏捷方法是基于协作和反馈循环来发现涉众的需求，并引导工作朝着最佳结果进行。

这个内部一致的论点激发了一个实现：

人们不一定连接围在其专业领域之外的点。

敏捷性的三个方面

重读最后一句时，我觉得有点晦涩难懂。毫无疑问，对于一个不是五秒钟前写的人来说，这更神秘。那么，让我们来分解一下。

长期以来，我一直认为“敏捷”涉及三个广泛的领域或方面:

1. 流程相关
2. 技术
3. 人类

一些敏捷主义者非常关注敏捷的人的方面。

当你听到/读到人们使用像安全，心,协作，他们正在考虑这方面的灵活性。

一些敏捷专家非常关注敏捷的过程相关方面。

当你听到/读到人们使用像优先产品待办事项列表，实证预测,轧波规划，他们正在考虑这方面的灵活性。

另一些敏捷主义者则强烈关注敏捷的技术元素。

当你听到/读到人们使用像软件工艺，测试驱动开发,内置的质量，他们正在考虑这方面的灵活性。

当一个人的个人专长主要集中于这三个类别中的一个时，要看到这些宽泛类别中的元素是如何与其他类别中的元素相联系、加强或激活的，这是很有挑战性的。这就是我所说的把一个人专业领域之外的点联系起来的意思。

进入精益思维

精益思维变得如此融合，敏捷认为我有时会忘记各种想法的起源。我们想要消除我们的软件交付过程中的等待国家和瓶颈的假设对我来说已经很自然，我忘记了它不是“敏捷”的根本基本的一部分（除了间接作为形成交叉功能团队的效果）。这是一个来自精益思想的概念。

精益思想很自然地适合提高敏捷性的目标。减少交付管道中的延迟(精益概念)自然会缩短软件消费者和生产者之间的反馈循环(敏捷概念)。因此，当考虑如何帮助客户提高敏捷性时，我自动地考虑减少他们交付管道中的延迟。

合规性检查和自动化

由于具有技术背景，很容易看到如何将治理需求的检查自动化，作为一种减少由人工专家进行事后手工检查所花费时间的方法。但是，那些在以流程为中心的背景下接触敏捷的人可能不会直观地看到这种联系。治理需求是固定的这一事实可能会导致他/她假设这样的需求必须像瀑布过程一样被处理。

对于技术人员来说，任何“固定的”需求都有可能被自动化。任何不需要协作和指导和调整反馈的内容都可能是脚本化的，因为它不会频繁更改。任何脚本化的内容都将比任何需要手动干预的内容(无论是手动服务器配置、手动回归测试，还是为遵从性而对提议的版本进行的手动审计)更加顺畅。

结论

考虑自动化可能比最明显的事情更有用。学会将彼此之间距离较远的点连接起来也可能是有用的。