如何有效地提升開發團隊的水平? - bravenewgeek

banq發表於2019-01-18

客戶經常會問的一個問題是:如何有效地提升開發團隊的水平?你如何讓一組從未編寫過Python的工程師使其成為高效的Python開發人員?你如何讓從未構建過分散式系統的團隊可以構建可靠,容錯的微服務?讓從未有云中構建經驗的團隊負責構建雲軟體?
有人說培訓會提升團隊水平,引入一個可以教我們如何高效編寫Python或如何構建雲軟體的諮詢公司。透過訓練運維和開發人員。
我反問那些提出這個解決方案的人:你什麼時候知道你準備好了?兩天的培訓是否足夠,還是我們應該選擇為期三天的培訓?為期六個月的雙編碼訓練營?您需要在培訓計劃上花費了大量現金,更不用說讓一支昂貴的工程師團隊參加多天或多周研討會的機會成本。權衡取捨值得嗎?或許,很難說。當下一個新事物出現時會發生什麼?我們必須重新開始整個過程​​。
其他人認為技術工具將有助於提升團隊水平。CI / CD管道將使開發人員更有效,並能夠更快地釋出更高質量的軟體。機器學習產品將使我們的待命體驗更易於管理。無伺服器將提高工程師的工作效率。自動化將改善我們公司的緩慢和官僚程式。
對於這種解決方案回答很簡單:工具通常是用於對付破碎或低效政策的創可貼,而政策則是組織的疤痕修補。工具可能很有用,但它們不會修復你破碎的文化,它們肯定不會使你的團隊升級,只能補充它們。
還有人說開發者的工程方法會使團隊升級:進行結對程式設計或測試驅動開發(TDD)的團隊將更快地升級並且更有效 - 或者scrum,或敏捷,或者mob程式設計。沒有遵循這些做法的團隊需要更長時間才能做好準備。
這些東西可以提供幫助,但實際上並不重要。如果這聽起來像不尊重你了,你可能想停下來思考一下這些教條。我見過團隊使用scrum,結對程式設計和TDD編寫了可怕的軟體;我也見過沒有編寫單元測試的團隊編寫出色的軟體;我見過團隊在本地實施DevOps;我已經看到團隊在雲端完全孤立操作和開發。這些是工具箱中的工具,團隊可以選擇利用它們,但它們不會神奇地使團隊做好準備或更有效率。

一個例外是程式碼審查。(審查者必須是非程式碼作者)

程式碼審查是有助於提高軟體質量的一種做法,並且有經驗 資料可以支援這一點。結對程式設計可以是指導初級工程師並確保其他人理解程式碼的好方法,但它不能代替程式碼審查。在與另一個人合作的過程中,自己創造一個糟糕的想法同樣容易,但當你引入一個不受外界影響的人時,他們更有可能意識到這是一個壞主意。

程式碼審查是快速升級團隊的有效方式,前提是您有一些知識淵博的稽核人員來引導流程(作為推論,這意味著高績效團隊應該偶​​爾被分解以培養組織的其他部分)。它們為開發人員提供快速反饋,最終將其內化,然後將其灌輸到自己的程式碼審查中。因此,它迅速傳播專業知識。升級變得具有感染力。

當我開始在Workiva工作時,我親身體驗過這一點。我從未編寫過一行Python並且之前從未使用過Google App Engine,我加入了這家公司,其產品主要是用Python編寫並在Google App Engine上執行。在幾個月的時間裡,我成為了一名相當熟練的Python開發人員,對App Engine和分散式系統實踐非常瞭解。我沒有做任何培訓。我沒看過任何書。我很少配對編碼。透過程式碼審查(特別是小組程式碼審查!),我就把這些阻礙放倒了。

我們對程式碼審查無情經常讓新員工措手不及。使用這種方法,Workiva有效地將一個幾乎沒有Python或雲經驗的工程師團隊帶到了一個用Python編寫的基於雲的SaaS產品,然後在幾年內進行了IPO。

程式碼審查促進了一種將自我與程式碼分開的文化。人們自然受到批評的威脅,但是透過程式碼審查文化,我們批評程式碼而不是人。程式碼審查也是在團隊中共享上下文的好方法。當其他人稽核您的程式碼時,他們會了解您所處的位置。程式碼審查為您的團隊提供了一個脈搏,當團隊成員需要上下文切換到您正在處理的內容時,這可以提供幫助。

它們也是擴充套件產品開發其他功能的有效方式。例如,許多公司掙扎的一個領域是安全性。InfoSec團隊經常成為研發組織的瓶頸,並且經常受資源限制。透過開發安全稽核程式,我們可以更好地擴充套件我們處理安全性和合規性的方式。要求對安全性敏感的更改進行安全審查。為了成為安全稽核員,工程師必須透過必須每年更新的安全培訓計劃。谷歌進一步採用了這一想法,獲得了“JS可讀性”等不同領域的認證。

這就是為什麼我們在Real Kinetic 的諮詢強調指導和建立持續改進的文化。這也是我們為行動帶來偏見的原因。我們與希望開始採用新實踐和技術的公司進行對話,但感覺他們的團隊準備不足。這就是現實:你永遠不會有充分的準備,因為你永遠無法做好充分的準備。正如約翰加爾指出的那樣,軍隊所能做的最好的事情就是做好充分的準備來對抗前一場戰爭。這就是敏捷確實重要的地方,但只有在快速反應和轉動的意義上才能實現敏捷。

沒有什麼能夠取代經驗。

透過觀看電視上的職業體育運動,您不會成為職業運動員。您不會透過在書本中閱讀或進行培訓來構建可靠的雲軟體。要清楚,這些事情可以提供幫助,但它們不是策略。同樣,開發人員實踐可以提供幫助,但它們不是先決條件。通常情況下,它們會成為情感或哲學辯論而不是客觀討論。需要給團隊提供試驗和犯錯的自由度,以便發展這種體驗。他們需要開始做。

程式碼審查是一個例外。這是升級開發團隊的最有效方法。透過嚴格的程式碼審查,快速迭代和執行,您的團隊將比任何培訓課程都能更快地升級。如果您認為他們會提供幫助,請投資培訓或其他資源,但在合併到母版之前要求對更改進行程式碼審查。除了定期回顧,這是建立持續改進文化的基礎組成部分。專業知識將開始在您的組織中像野火一樣傳播。

相關文章