代替非常簡單的方法，我們需要尋找在不同上下文中工作的協(xié)作和交互模式。協(xié)作需要付出一定的代價，但會產(chǎn)生非常好的效果。但是，有時候最好在團隊之間引入一種界限。JAXenter編輯Hartmut Schlosser在2016年DevOpsCon上與Matthew Skelton進行了交談，探討了協(xié)作的必要性以及如何形成良好的團隊結構。

JAXenter：嗨，我是Hartmut，我和慕尼黑DevOps-Con的Matthew Skelton在一起。我認為您現(xiàn)在的會議很精彩–您談到了團隊組織/團隊協(xié)作/團隊結構，并介紹了一些團隊拓撲。為什么具有一組不同的團隊拓撲有用嗎？

Matthew Skelton：嗯，我們發(fā)現(xiàn)，團隊可以通過多種不同方式有效地合作。建立團隊時，有很多方法可以使團隊效率低下。實際上，沒有一種單一的團隊結構或協(xié)作模式可以起作用。這取決于業(yè)務目的是什么；這取決于組織要實現(xiàn)的目標。這取決于他們采用技術的方式。這取決于他們移動的速度-各種各樣的事情。

而不是說“哦，開發(fā)需要與運營進行對話和協(xié)作”的非常簡單的方法。這是一個很好的起點。但是我們發(fā)現(xiàn)的是，我們需要更加具體，并尋找在不同環(huán)境下工作的協(xié)作和交互模式。

JAXenter：讓我們更具體一些。什么是衡量公司需求的團隊結構的一個好例子？

Matthew Skelton：很好。假設某個組織正在嘗試快速發(fā)現(xiàn)某些事物，例如試圖發(fā)現(xiàn)新技術。假設他們正在從AWS上的虛擬機遷移到Kubernetes或類似的東西，那么構建軟件或應用程序的人員以及提供某些基礎架構的人員可能需要在那時密切合作。這樣，他們才能真正理解在應用中采用Kubernetes之類的操作含義。

因此，讓這些團隊緊密合作非常有價值。不需要緊密合作也很有用，因為協(xié)作需要付出一定的代價。它很昂貴，但可以產(chǎn)生很好的效果。有時候最好在團隊之間引入一種界限。具體來說，產(chǎn)品團隊可以通過這種方式簡單地依賴平臺，并在平臺之上交付他們的東西。此時，與IT運營部門進行協(xié)作的需求減少了，因為已經(jīng)解決了難題。

經(jīng)典示例是關鍵的云鑄造廠，其中應用程序和平臺之間存在硬性區(qū)別。存在的原因是因為難題已經(jīng)解決。因此，人們可以在平臺之上交付應用程序。這是一個具體的示例，可以感覺到主要情況，因此我們根據(jù)團隊的工作情況來考慮不同的團隊合作方式。

JAXenter：所以您會說協(xié)作在任何情況下都沒有價值嗎？

Matthew Skelton：我認為合作始終是有價值的。但是，我們必須明白，為什么我們正在協(xié)同合作和如何合作開發(fā)。究竟我們應該專注于什么合作？有時，最好將某些事情編碼為服務可能更好。

JAXenter：因此，讓我們看一下更廣泛的背景。我們在DevOps會議上在這里，您在談論團隊結構，但團隊結構還不是全部。是什么將生命帶入了這種結構？

Matthew Skelton：這是一個非常好的觀點。僅具有精心設計的良好團隊結構并不能單獨為您提供有效的軟件交付。我們需要研究文化方面的問題，我們需要確保我們擁有良好的，健全的工程實踐，并且這需要一些時間才能發(fā)展。就像我們需要一個生態(tài)系統(tǒng)。我們需要培養(yǎng)和關心這種文化，以實現(xiàn)良好的工程設計。

最終，企業(yè)或組織需要對其嘗試做的事情有一個非常清晰且消息靈通的畫面。因為有許多組織尚未真正驗證其產(chǎn)品或服務理念！因此，當他們要求IT或工程部門構建某些內(nèi)容時，由于業(yè)務概念或組織概念尚不明確，因此尚不清楚我們應該構建什么內(nèi)容。實際上，對于采用DevOps的人員和組織來說，變得越來越擅長于技術部分，以至于實際上暴露了業(yè)務或組織方面的缺乏清晰度，這是一件很平常的事情。那是一個有趣的地方。

JAXenter：什么是一個好的起點？我們擁有傳統(tǒng)的公司架構，現(xiàn)在想要取得成就。他們聽說過DevOps的想法，聽說過團隊的拓撲結構–您會如何建議？

馬修·斯凱爾頓（Matthew Skelton）：一開始的重要事情是選擇足夠小的東西，以使我們能夠獲得一定的牽引力，但并不是一件容易的事。我們需要從高級管理層那里獲得一些支持，以便我們可以對此進行實驗，如果您愿意的話，可以在播客中進行。它可能是一種產(chǎn)品，可能是一種產(chǎn)品領域，但是我們希望從中學習到很多東西。我們期望第一次做的不好，我們應該做錯一些事情，但是要從中學到很多。

某些員工可能會感到被排斥在外，但我們需要通過說“看，別擔心，您現(xiàn)在不在這個團隊中”來帶他們走，但我們的計劃是稍后向您推出這種方法。因此，請稍等片刻，參加午餐時間的披薩會議，了解我們在做什么，隨著時間的推移，我們將逐步向其他團隊推廣這種方法。” 嘗試同時更改整個事情可能會奏效，但是對于大多數(shù)組織來說，這可能不是最好的選擇。

JAXenter：您認為這是自上而下的過程還是更多的自下而上的過程？

馬修·斯凱爾頓（Matthew Skelton）：兩者結合在一起。我們需要建立一種良好的工程文化，一種從底部到底部進行實驗的學習和安全文化。有時我們會變得非常有進取心，或者人們害怕他們，那么我們需要弄清楚如何對待他們。也許在某個地方，但是自上而下，它需要組織管理層的認可和意識，這是值得投資的東西。因此，自上而下和自下而上的結合是正確的方法。通常，我們希望從小處著手，然后再擴展，而不是嘗試進行重大改變。有時這是必需的，但通常最好以一種流方式進行，然后從中進行擴展。

JAXenter：謝謝！