挖掘企業工具鏈的基本真相

要了解有關在大型DevOps和敏捷部署中哪些有效和哪些無效的更多資訊，我們需要資料。 問題是，眾所周知難以獲得資料，因為大部分資料隱藏在眾多私有儲存庫中。

諸如 DevOps狀態報告之類的 努力 透過使用調查資料回答有關諸如團隊或組織中部署頻率等實踐的問題，幫助我們獲得了一些瞭解。 然而，調查資料有其侷限性，正如Nicole Forsgren和我在“DevOps Metrics”中所描述的那樣，我們寫這篇文章是為了澄清系統和調查資料收集的權衡。 1 今天，我們對DevOps實踐的理解主要基於這一調查資料和軼事證據。 有沒有辦法擴充套件我們對DevOps的看法，包括研究DevOps的系統資料？

一種方法是檢查公共可用的儲存庫，例如由GitHub或Eclipse和Apache基礎託管的儲存庫。 但是，這項研究的結論僅限於開源專案的工作方式。 在規模，範圍和工作型別方面，大規模和企業軟體交付與開源交付有很大不同。

在我的博士研究中，我最初研究開源開發人員。 2 我的主管Gail Murphy推動我將我的學習擴充套件到企業環境中的專業開發人員。 我的職業生涯大部分時間都在進行開源開發，但我對這項工作的不同感到震驚。 我學到的最有趣的事情是專業開發人員每天工作的額外複雜性。 應用程式，系統，程式和要求的數量使我在更優雅的開源世界中遇到的任何事情都相形見絀。

在我的文章“  生產線類比的終結  ”中，我討論了先進汽車製造與軟體生產的關係。 3 汽車製造業的一個令人驚奇的事情是，工廠車間可以看到生產的“基本事實”。 走裝配線可以即時檢視工作流程。 我們在哪裡可以找到企業軟體交付的基本事實？ 這個基本事實如何改變我們對大規模軟體交付失敗的理解？

利用寒武紀工具爆炸

在我的上 一篇 文章中 ，我總結了“寒武紀爆炸”如何導致數百個DevOps工具的激增。 4 這次爆炸的一個關鍵原因是這些工具對於各種利益相關者的需求有多專業化。 例如，大型企業可能有十幾個不同的專家參與軟體交付，例如Java專家，AWS（亞馬遜網路服務）專家，設計專家或支援人員。 現在每個角色都有一個專門的工具。

這提供了一個有趣的機會。 使用這些工具的次數越多，特定從業者的工作就越多。 如果我們只能獲得這些資料，我們將有一個獨特的機會更好地瞭解DevOps和軟體交付在一般情況下如何在實踐中發揮作用。

挑戰在於這種端到端系統資料是不可訪問的。 它隱藏在組織的防火牆後面或鎖定在私有儲存庫中。 有時，供應商可以訪問切片 - 例如，軟體即服務支援臺工具供應商可能擁有關於支援服務單的跨公司資訊。 但是，這只是價值流的一個切片;  它錯過了所有開發和其他上游資料，並沒有提供端到端的檢視。

在我對開源和專業開發人員的研究中，訣竅是使用開發人員對工具儲存庫的訪問作為這些儲存庫中發生的事件的代理。 但是，再一次，這只是價值流的一部分。 但是，透過該實驗，我意識到我可以訪問那些能夠看到端到端儲存庫集的人：企業IT工具管理員。

價值流整合圖

我的公司Tasktop與負責敏捷和DevOps工具鏈的許多企業IT工具管理員密切合作。 我們的解決方案架構師進行的每次參與都會導致建立 價值流整合圖 。 我第一次看到這些圖表時，我意識到我的資料集與我在博士研究期間收集的Gail一樣有趣。 這些圖描繪了值流中的每個工具儲存庫，儲存在這些儲存庫中的每個工件型別，最重要的是，工件型別如何相關。 這些圖表不是透過學術研究收集的，而是透過與企業IT工具管理員及其工具合作的資料收集流程收集的。 這些資料偏向於Tasktop的客戶和潛在客戶，他們往往是500家企業IT組織，他們希望透過一個或多個工具進行整合。

Tasktop收集了308個這樣的圖表。 圖1顯示了其中一些。 它們是企業工具鏈的基本事實的迷人視窗。 因此，他們可能會以有趣的方式告知未來收集軟體交付資料的努力。 在這裡，我提供了我們從中學到的內容的高階概述。 更詳細的分析將出現在我即將出版的 Project to Product中 。

這些圖提供了價值流中每個工具的時刻總結，以及每個工具中捕獲的關鍵工件的資訊，以及它們應該或應該如何連線的資訊。 這些圖表並未詳盡地列出組織中的所有工具儲存庫或所有工件型別。 它們也不提供有關這些工具中資料的資訊 - 例如，缺陷的數量和型別。 但它們確實提供了有關這些組織的企業IT工具鏈組成的基本事實。

資料揭示了什麼

在這一組之外可能有相關的工具。 例如，這些組織最近才報告漏洞跟蹤工具是其DevOps工具鏈的一部分。 工具缺少結果並不意味著它不存在，只是因為當時沒有考慮將其包含在組織對連線值流的檢視中。

這些圖來自Tasktop客戶和潛在客戶，他們定義了他們想要連線的工具和工件。 大多數圖表來自財富1000強中的企業IT組織。表1顯示了行業細分。

表2列出了所使用的工具型別。 正如預期的那樣，敏捷規劃和應用程式生命週期管理（ALM）工具占主導地位，但IT服務管理，專案組合管理和需求管理也構成了工具鏈的關鍵部分。 即使在敏捷和DevOps時代，需求管理工具仍然顯著使用。 相比之下，連線客戶關係管理（CRM）和安全工具的舉措仍然很少。 總而言之，該資料集包括使用55個工具。

更有趣的是在工具中跟蹤了哪些資訊。 表3提供了對建立的工件以及工作型別的深入瞭解。 在較高的層次上，想象一下這些工件對應於流經執行軟體交付的各種工具的小部件。 在接下來的文章中，我將討論這些不同型別的工件的相關性。

結合表2和表3中的資料，我們觀察到工件跨越了多個工具。 例如，透過敏捷，ALM，需求管理以及有時IT服務管理工具跟蹤功能。 我們將此解釋為另一個跡象，表明大型敏捷和DevOps環境中的工具數量及其專業化正在增長。 但是，儲存在這些工具中的工件型別（參見表3）要小得多，並且工件往往跨越多個工具。 例如，單個缺陷可以跨越敏捷，ALM，需求管理和IT服務管理工具。

表4中列出了一些最有趣的發現。我們發現只有1.3％的組織使用過單一工具。 更有趣的是，69.3％的組織將工件連線到三個或更多工具上。 更令人驚訝的發現是，超過42％的組織需要整合四個或更多工具，這表明開發大型企業軟體所涉及的複雜性。 它還支援這樣一種觀點，即軟體開發中角色的專業化很常見。