DevOps宣言 翻译
原文链接
BY ERNEST MUELLER | OCTOBER 15, 2010 邵栋 翻译 2017.5.22
最近大家在讨论曾经在德国汉堡的DevOpsDays上讨论的DevOps宣言，我在想，现有的敏捷软件开发宣言有什么问题？我们不能把这个作为统一的指导原则吗？
让我们看一下敏捷软件开发宣言的价值观和原则。如果不是从纯代码开发者的观点，而是从系统的角度来看这份宣言应该是怎么样的？下面是我的一个尝试：
DevOps宣言
我们一直在实践中探寻更好的运行系统的方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的系统 高于 详尽的文档
客户以及程序员合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
这没有很大的不同。在我看来，我们可以毫无保留地接受一些条款。作为一个以系统管理为工作的人，我对个体和互动高于流程和工具感到紧张（这是否会促进牛仔心态？） - 但这并不是说自动化和工具不好，事实上它是必要的（看看敏捷软件开发实践，有明确的过程和工具），但是参与的人应该永远是主要关注点。 我的观点是敏捷宣言与开发、运维或业务无关，这是一个通用的合作模板。而对于Ops vs Dev而言，“DevOps”有非常不同的观点吗？不是很多。
我们还有敏捷软件开发的十二条原则， 仍然是抽象度很高的内容，但这里是我认为我们开始在现有列表之外有更多独特的问题。
DevOps宣言背后的原则
我们遵循这些原则：
- 我们最重要的目标，是通过持续不断地及早交付有价值的功能使客户满意。 （比“软件”更通用）
- 软件功能只有在完整的系统交付给客户后才能实现。对于用户来说，非功能性需求与功能性需求一样重要。（新：为什么系统很重要）
- 基础设施是代码，应该同样进行开发和管理。 （新。）
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。（相同。）
- 经常地交付可工作的功能，相隔几星期或一两个月，倾向于采取较短的周期。（软件 - >功能）
- 业务人员、开发人员和运维人员必须相互合作，项目中的每一天都不例外。 （添加运维人员。）
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。 （相同。）
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 （相同。）
- 可工作的软件并进行完整交付是进度的首要度量标准。（添加系统。）
- 敏捷过程倡导可持续开发。责任人、开发人员、运维人员和用户要能够共同维持其步调稳定延续。 （添加运维人员。）
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 （相同。）
- 以简洁为本，它是极力减少不必要工作量的艺术。（相同 - KISS原则）
- 最好的架构、需求和设计出自自组织团队。（相同。）
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。 （相同。）
这是一个极简集。
这听起来像是仍然把软件放在第一位吗？是。这是合适的。系统是向用户传达软件功能的，它们独立存在没有任何价值，我是作为一个系统管理人员说这句话的。然而，我在几个地方将“软件”改为“功能” - 使用系统和现有软件（开源，COTS等），您可以为用户提供有价值的功能，而无需您的团队编写代码。
无论如何，我喜欢将自己将运维工作内容插入到现有的敏捷过程中的想法，而不是另起炉灶的“DevOps宣言”，那样会不得不回答很多原始敏捷宣言已经回答的问题（例如“业务怎么样？”） 。我认为DevOps的要点之一就是“嗨，敏捷背后的概念是完整的，但是我们忘了在合作中包括我们的运维人员，可以理解，因为10年前，大多数应用程序都是桌面软件，但是现在许多（大多数）是服务，我们是创建和交付应用程序的重要组成部分。“
大家的想法是？
