过去几天，我在一个技术研讨会上讨论了敏捷和 DevOps，在准备演讲时我做了一些反思。我意识到，我目前的理解水平的故事可能很好地说明了我们迄今为止遇到的挑战和解决方案。当然每个人的故事都不一样，但这是我的，与社区分享可能会帮助一些和我一起旅行的人。
一张图片胜过一千个单词，这里是我将用来描述我的旅程的视觉效果。
（注意：Y 轴表示成功，或者我喜欢称之为“准时回家的机会”，X 轴是我职业生涯的时间轴）
瀑布阶段——又名食谱书
当我从大学加入工作队伍并在 IBM 研究实验室对编译器、自动驾驶汽车和其他我被允许探索的有趣主题进行了一些研究后，我立即投入了项目工作。当然，按照惯例，我参加了公司培训，了解了我们的瀑布方法以及相关的流程和模板。我很惊讶，项目工作看起来如此简单。我得到了方法、流程和模板，我所要做的就是遵循它们。我着手掌握这种方法，并在我掌握得更好之后取得了初步的成功。我发现了成功的“食谱”，它准确地描述了每个人应该如何行事。很明显，我的职业生涯很成功。
敏捷阶段——又名一本更好的食谱书
一切都很好，直到我接手了一个项目，而其他人为其创建了一个项目计划，该项目计划在 12 周的时间内完成。我继承了项目计划和甘特图，并开始交付这个项目。很快就发现需求非常不明确，甚至客户也不了解我们构建成功解决方案所需了解的一切。最初的 4 周过去了，一如既往，我根据时间表传达了 33% 的完成情况，尽管我们显然没有取得应有的进展。走出状态会议，我意识到这不会很好地结束。我与我的利益相关者进行了非正式的会面，并向他们介绍了挑战。他们同意并理解未来的挑战，并问我该怎么做。巧合救了我。在我的团队中，我们配备了一名承包商，他在一系列咖啡（以及与此相关的啤酒）之前和之后与敏捷合作，他说服我尝试这种新方法。作为一个德国人，我非常符合刻板印象，因为我发现很难放弃我心爱的甘特图和项目计划，以及每周从我的团队收到的完成百分比的详细状态。很快，我们就与利益相关者形成了一种节奏，每两周交付一次增量解决方案。我慢慢放弃了一些作为瀑布项目经理学到的行为，慢慢成为了一名 Scrum 大师。结果令人难以置信，团队文化发生了变化，客户更开心了，尽管我们在不到 12 周的时间内交付了完整的解决方案（实际上接近 12 个月），但我确信我找到了一个更好的“配方”书”比我以前有的。显然，如果每个人都遵循这本食谱书，项目交付将会更加成功。
DevOps 阶段——又名工具的重新发现
过了一会儿，我又订婚了。客户希望更快地进入市场，而我们遇到了各种质量和期望设定问题。很明显，敏捷“食谱书”会再次提供帮助。是的，我们的第一个项目取得了巨大的成功，我们迅速提高了敏捷能力，越来越多的团队和项目采用了敏捷。然而，很快就很明显，我们无法随心所欲地缩短上市时间，并且敏捷“食谱书”常常创造出一种货物崇拜——人们早上起来使用便利贴并认为自己成功了敏捷从业者。专注于上市时间的挑战，我组建了一个团队来创建正确的敏捷工具，以通过敏捷生命周期管理系统支持敏捷流程，并引入了 DevOps 实践（当时我们还没有称之为 DevOps）。意图很明确，作为一名工程师，我认为我们可以用工具解决问题并迫使人们遵循我们的“食谱”。早期的结果很好，我们节省了大量的手动工作，工具的采用率在上升，我们可以从我们的 ALM 中获取状态。简而言之，我的世界很好。我去做一些不同的事情。过了一会儿，我又回到了这个项目，令我惊讶的是，我之前实施的解决方案已经恶化。我放置的许多伟大的东西都消失了或发生了变化。我想了解发生了什么，并花了一些时间进行调查。事实证明，相关人员在此过程中做出了一些小决定，这些决定慢慢地、慢慢地忽视了工具解决方案的意图和我们使用的方法。没什么大的变化，就是千刀万剐。那么我该如何解决这个问题……
精益阶段——也就是我终于明白了（或者我认为我现在明白了）
我一直都应该知道的事情对我来说变得越来越清楚：方法论和工具不会改变您的组织。他们可以支持它，但文化是缺少的重要成分。正如德鲁克所说：“文化早餐吃策略”。这是非常真实的。但是你如何改变文化……我当然还在这个旅程中，文化变革管理显然是我自己的下一个前沿领域。我很快了解到，我需要向人们传授敏捷和 DevOps 背后的原则，其中包括精益、系统思维、约束理论、产品开发流程和精益创业思维的要素。但是我如何真正改变组织的文化，如何避免“要改变人，有时必须改变（读作替换）人”这句老话。作为一名工程师，我在流程、工具和方法方面相当擅长，但真正的挑战似乎在于组织变革管理和组织流程设计。我想知道这是否真的是最后的前沿领域，或者在我掌握了这个领域之后是否会有下一个挑战……
好消息是，我们中的许多人都在共同踏上这段旅程，而且我相信，在我们仅靠工具和方法取得的巨大成果的背后，真正伟大的事情还在我们面前，因为我们掌握了文化转型，以成为DevOps 组织。