一千萬個為什麽

搜索

DevOps轉型的目標是哪些組織類型?



由於我在這方面缺乏詞匯量,我不確定如何在我能提出問題之前指定我想談論的兩種類型的組織。任何能夠提供更好措辭的人都可以自由地改善這一點。 可能有混合類型,但我想我必須極化一點才能說明問題。

OrgType1: "digitalized product organizatons" either B2B or B2C, they have their products, as they become more and more digital, they have some own IT product teams and IT operations. They have found out that they need (more than before) product diversification quite recently.

OrgType2: "digital consulting service organizations" (not necesarily just IT consulting but they are typical example here) these guys are B2B only, if they have sustainable products and related operations then it is rather a side effect. Rather, their software product lifecycle is limited to just one or several projects, and that diversification has always been their core business. Actually, the real product is here much more every single member of this organization who depending on the role might, but by far not always does, develop software.

那麽OK,所以OrgType1顯然是我們已經知道的,DevOps有很大的幫助,因為已經建立了交付流程,它們被破壞,需要優化,等等。那麽,更大的組織由許多部分,地區業務部門,業務部門,部門組成,並且每個部門都將其業務與他們自己的品種相結合。好的 - 無論如何可以有一些進化。

OrgType2只關心DevOps,因為它對客戶來說很重要(或者他們甚至出售DevOps咨詢;但是,如果涉及到現場軟件開發,那麽您幾乎在每個項目中都從零開始,而且這種情況會隨著OrgType1通過所有部門,業務單位等,但這是值得的,因為每個“DevOps實體”都是從1-2個需要發現他們的人開始的。看起來像OrgType2以更密集的方式“被設計孤立”,這使得它也具有可伸縮性和持久性。

這一切都經過考慮並考慮在內,從我目前的角度來看,問題是:DevOps實踐如何應用於OrgType2,可能有資源在其中進行了探索?

轉載註明原文: DevOps轉型的目標是哪些組織類型?

一共有 2 個回答:

如果不超過第一個組織類型,則DevOps適用於組織類型2,即企業對企業實體。這裏有兩種可能的情況:

Scenario 1

首先他們向企業銷售產品或服務。就DevOps而言,這使得它們與組織類型1幾乎沒有區別。盡管他們的客戶是一個企業/一群個人,但他們正在向客戶提供產品或服務。這位客戶恰好是一個企業,而不是一個私人,這與DevOps的執行無關。與具體的軟件目標,明確定義的需求或其他情況相比較,最佳價值和客戶服務將由DevOps模型提供,原因不需要在此重申。

情景2

在這種情況下,這種情況恰好有點更為特殊,組織類型2正在為企業提供咨詢服務。據推測,通常情況下,企業會在顧問的專業領域內聘請顧問為企業提供幫助。企業有技術支持來協助特定技術,並可以與工程師簽訂遷移合同,但是當風險管理,整體架構設計,流程,流程和高層次問題出現時,這是一個顧問聘用他們的時間>商業建議。

這就是為什麽記住 DevOps不是角色的重要性。我認為,DevOps代表了企業或組織的管理流程 - 甚至是一種哲學。這或多或少是實施敏捷方法的具體方式,它已經遠遠超出了發展包括許多學科和部門。因此,DevOps是一攬子交易 - 為了在DevOps取得成功,您必須致力於具體的組織管理經營理念。

事實上,為了說明這一點,在“鳳凰項目”中,董事會成員Erik Reid反復將該書的主角Bill Palmer拖到零件制造工廠,以便通過吸取制造業的商業經驗教訓來向Bill演示和教授關於技術和軟件開發的事情。

這就是作者Gene Kim,Kevin Behr和George Spafford所說的DevOps不僅僅是做事或特定技術的方式,而是一種業務哲學,簡單地被各種nom de plumes所熟知。

因此,為了向咨詢顧問所咨詢的公司提供最佳價值,咨詢師有義務展示和解釋DevOps的價值,並協助公司成功執行這一商業理念並指導公司專門針對技術和方法。簡而言之,咨詢公司的工作是作為“Erik Reid”擔任任何業務合同的咨詢服務。

簡而言之,DevOps對於組織類型2應該非常重要,因為它是他們作為顧問的工作,向客戶解釋為什麽它很重要 - 他們應該始終銷售DevOps咨詢。與拒絕考慮DevOps的公司合作的顧問應該有禮貌地考慮暗示他們可能不合適。他們的客戶可以從任何地方雇傭一個通用的代碼猴,如果他們想繼續(不成功)繼續按照他們一貫的方式完成項目。

我覺得開發工具涉及的不僅僅是開發的產品,還包括用於從創意到實際應用的過程。組織2認為,可以使用開發工具來設置統一的方式來收集需求,合並/強制執行分支策略,設置/維護CI。這只是開發團隊。

每個組織都不僅僅是開發者。 Org 2可能會有一個銷售團隊。有什麽可以做的銷售收集要求更有效的方式,或組織他們。是否有一個共同的用戶界面元素,所有的應用程序共享,所有客戶抱怨。

這些只是我對Dev Ops的一些看法。我對這個角色很陌生。我認為這個角色是對發展過程中的所有過渡以及發展過程負責的。從理念到需求,到用戶故事,工作跟蹤,測試,發布,然後收集反饋以再次用作需求收集時,可以輕松實現。

我想有時你必須創建你想要挖掘的數據。今年(2017年)微軟的會議專註於Dev開發者的一整天。我無法去,但會議可以在你身上找到。你可能感興趣的一個(我已經排隊等待觀看)是為每個團隊開發ops 。另一個我剛剛瀏覽主題演講與Donovan Brown:從0到DevOps (I沒有看過其中任何一個,但他們似乎適用)