在20世纪80年代和90年代，软件的规模还比较小。开发者编写软件，将它交付给“制造环节”，如保存到软盘或光盘中，然后就可以发往商店。商店负责将它销售给用户。如果用户遇到问题，那么他们就会呼叫客户服务。客户服务的目标是避免客户与软件开发人员直接沟通。如果系统管理员遇到了规模问题(自动化安装或让一台服务器处理更大的用户量)，那么他们会根据操作手册的说明进行操作，但是他们大多数时候会将这个问题转交给真正了解这些产品的开发工程师，然后由他们负责开发出真正的解决方案。
开发人员与客户的关系:一对多。
与客户的互动:禁止。
系统管理任务:偶尔。
敏捷是如何改变您与开发人员的互动的?
我认为开发运维是敏捷方法的必然结果。如果一个软件团队由于更快的发布周期和更高效的交流而需要提高自身的效率，那么将系统管理员加到这个过程中不是更有意义吗?
开发运维与敏捷之间存在很多的相似性。它们各自都是对方的演化，而开发运维必然加入敏捷宣言的实践方法和理念。敏捷宣言最早发布于2001年，当时Web真正成为了一个正式成熟的平台。它的主要概念有
个体活动与互动通过过程与工具实现；
通过全面文档指导软件开发；
通过合同协商开展客户协作；
按照计划来处理变更。
当然，敏捷过程和方法不仅仅包含这四个原则，而且从敏捷宣言公开发布以来，敏捷的定义及其实现也一直在不断地增加和发展中。
敏捷实践提出了一种新的网站制作软件开发方法，而开发运维则更进一步它基于这些实践方法，但是主要关注于加强开发与运维之间的协作和技术互补，从而使开发与运维的角色与职责互相连接(现在几乎涉及各个方面)。它引领了一场文化转变，让运维人员的工作方式更靠近软件开发人员，其中包括解决问题的方式及参与设计和部署过程的方式。
本文地址：//cosda.cn//article/4481.html
