在20世紀80年代和90年代，軟件的規模還比較小。開發者編寫軟件，將它交付給“制造環節”，如保存到軟盤或光盤中，然后就可以發往商店。商店負責將它銷售給用戶。如果用戶遇到問題，那么他們就會呼叫客戶服務。客戶服務的目標是避免客戶與軟件開發人員直接溝通。如果系統管理員遇到了規模問題(自動化安裝或讓一臺服務器處理更大的用戶量)，那么他們會根據操作手冊的說明進行操作，但是他們大多數時候會將這個問題轉交給真正了解這些產品的開發工程師，然后由他們負責開發出真正的解決方案。
開發人員與客戶的關系:一對多。
與客戶的互動:禁止。
系統管理任務:偶爾。
敏捷是如何改變您與開發人員的互動的?
我認為開發運維是敏捷方法的必然結果。如果一個軟件團隊由于更快的發布周期和更高效的交流而需要提高自身的效率，那么將系統管理員加到這個過程中不是更有意義嗎?
開發運維與敏捷之間存在很多的相似性。它們各自都是對方的演化，而開發運維必然加入敏捷宣言的實踐方法和理念。敏捷宣言最早發布于2001年，當時Web真正成為了一個正式成熟的平臺。它的主要概念有
個體活動與互動通過過程與工具實現；
通過全面文檔指導軟件開發；
通過合同協商開展客戶協作；
按照計劃來處理變更。
當然，敏捷過程和方法不僅僅包含這四個原則，而且從敏捷宣言公開發布以來，敏捷的定義及其實現也一直在不斷地增加和發展中。
敏捷實踐提出了一種新的網站制作軟件開發方法，而開發運維則更進一步它基于這些實踐方法，但是主要關注于加強開發與運維之間的協作和技術互補，從而使開發與運維的角色與職責互相連接(現在幾乎涉及各個方面)。它引領了一場文化轉變，讓運維人員的工作方式更靠近軟件開發人員，其中包括解決問題的方式及參與設計和部署過程的方式。
本文地址：http://murenxiang.com.cn//article/4481.html
