Categories
程式開發

Git團隊協作(一):如何組建充滿鬥志和凝聚力的團隊?


編者按:本文節選自童仲毅譯《Git團隊協作》一書中的部分章節。

團隊成員

在小團隊中,可能一個人就承擔了很多角色。緊跟小團隊中每個人的日常工作相對容易。然而,在大團隊中,角色可能分散在不同部門。那些對代碼庫進行用戶驗收測試的團隊,可能從來沒有和被測試產品的設計師和開發者說過話。兩種團隊都可能遇到問題:如果沒有足夠的背景知識,卻被提出了更高的要求,最後注定會有所遺漏;團隊之間人為的屏障總是會增加他們之間的緊張關係。在開發代碼時,這樣的隔閡可不是什麼好事。

你是否聽說過“以終為始”這句話?當我構建軟件時,總是在替別人構建。即使我拼命回憶,也想不起來自己曾經出於自娛自樂的目的開發過某個產品。我不是天生的黑客。我被軟件吸引,是因為它能帶給別人價值。每次我坐下來解決一個問題時,想的都是給用戶提供更好的體驗。我希望避免反复,也希望保護用戶的安全。我希望他們感覺到自己心靈手巧,而非笨拙。如果在我和用戶之間還隔了客戶,我有時還需要改變客戶思考問題的方式,以便滿足他們的商業目標,同時保證終端用戶的良好體驗。每當我們坐下來工作時,應該從描述希望為用戶解決的問題開始,也就是從用戶故事(user story)開始。

接下來,在測試驅動開發流程中,你將會編寫驗收測試,界定如何知道問題已被解決。聲明會依據編寫用途被自動化測試套件、質量保證(QA)團隊或是同行評審員使用。如果提前與測試團隊商定驗收測試,那麼開發者會更清楚工作的產出應該是什麼樣的。一般來說,測試應該描述需要解決的問題,而不是規定將要使用的技術。

測試流程應該包含安全性評審。規模更大的公司有幸擁有專門的安全專家。讓這些專家儘早介入這個流程,請他們教你如何編寫安全的代碼。如果你的 QA、安全和開發團隊是分散的,在一開始將他們聚在一起,這會使測試流程變得更加有趣,因為開發者力圖提供完美的代碼,而測試團隊力圖挑刺。

如果部署不由你負責,同樣讓運維團隊儘早介入。保證你的開發環境和最終的產品環境越接近越好。理想情況下,你應該使用構建腳本(build script)來盡可能自動複製環境。你可以選擇使用 Docker(http://www.docker.com/)和 Vagrant(http://vagrantup.com/)來創建環境副本。和運維團隊一起,使用諸如 Chef(https://www.chef.io/chef/)、Puppet(https://puppetlabs.com/)或 Ansible(http://www.ansible.com/home)這樣的工具創建管理配置文件的基礎設施。

講到開發的技術棧,如果你在使用開源軟件,請了解一下你將要使用的產品的開發社區。我們很少遇到新的問題,而有的人可能已經遇到過你的問題。在代碼社區中尋找導師,同時指導別人。打破團隊的邊界,走出辦公室,可怕的問題會變得簡單得多。

當促進大公司中部門間的協作時,可以減少代碼在原地閒置的時間。閒置的代碼會以各種方式耗費你的金錢:新特性的代碼可能阻礙你賺更多的錢;修復 bug 的代碼則可能阻礙你停止損失。閒置的代碼慢慢就不新鮮了。代碼等待評審的時間越長,它可能偏離你的主分支越遠。它偏離得越遠,同步並預發這些工作就越麻煩。

最後,我們會審視自己的團隊。技術架構師負責規劃解決方案應該如何實施。架構的決策應該有文檔記錄並儘可能共享。架構師可能也是編碼團隊的一員。編碼團隊可能由前端開發者、後端開發者、設計師和項目經理組成。我有時候也和商業分析師一起工作。如果你在敏捷開發環境中工作,可能還需要一個敏捷專家和一個產品負責人。

我傾向於在這樣的環境中工作:無論哪裡有需要,每個人都願意伸出援手。自我管理的團隊通常彼此非常信任和尊重。不過,這種狀態是需要你努力構建的。共識驅動的開發最適合小規模的內部項目,但這並不意味著你不能在其他地方嘗試協作。管理項目時,我喜歡讓開發者選擇他們想做的工單。這增加了他們的自主性,如果需要,讓開發者從任務中解脫片刻。不過,我也發現有些人喜歡別人替他們分配好工單。

沒有一種方式可以組織所有團隊或管理所有項目。一個充滿鬥志和凝聚力的團隊,其秘訣是尊重團隊中的每個人,只要有可能,就根據他們的喜好來改善流程。

圖書簡介http://www.ituring.com.cn/book/1779

Git團隊協作(一):如何組建充滿鬥志和凝聚力的團隊? 1