Categories
程式開發

讓團隊成員每天準時下班的4條建議


如何在迭代的早期發現風險,是團隊主管(team leader)需要不斷磨練和提高的技能,它和大多數技能一樣,是一門藝術,也是一門科學。不幸的是,尚沒有一門針對這種技能的培訓課程。本文介紹了這些年來對作者幫助最大的4條專業建議,供大家參考學習。

讓團隊成員每天準時下班的4條建議 1

四件可以幫助您團隊避免錯過最後期限的事情

我在我軟件開發生涯的早期就已經被提升為團隊主管(team leader)了。

我擅長編碼。但不是很好。

不過我最擅長處理這樣一件事:為其他開發人員解決問題。

您知道開發人員更喜歡編寫代碼而不是閱讀代碼嗎?實際上我更喜歡閱讀代碼。我知道,這是站不住腳的。

晉升為主管之後,我很快意識到僅僅能為團隊解決問題是不夠的。我還需要能提前預料到對應的問題。

當我們能儘早發現問題時,解決問題的成本就會成倍地降低。左移策略(Shift left)。

如果我們在迭代的後期才發現問題,那麼修復問題的成本會大大增加。人也會變得緊張,需要投入更多額外的時間,並且消極情緒會層出不窮,團隊的很多人也都會受到影響。

我相信,這不僅僅是能否按時交付的關鍵因素之一(這是我老闆所很關心的),並且也是軟件開發人員能否擁有高質量生活(這是每個人都應該關心的)的最重要因素之一。

實現您的承諾,並阻止糟糕的事情發生,就要在迭代的早期發現風險

我相信,在sprint的前期就能識別風險是一項團隊主管(以及任何開發人員)可以隨著時間推移不斷磨練和提高的技能。它和大多數技能一樣,是一門藝術,也是一門科學。

不幸的是,尚沒有一門針對這種技能的培訓課程。如下是這些年來對我幫助最大的幾條建議,您可以嘗試一下。

專注於槓桿

我相信團隊中的每個人都是同樣重要的。但是在任何給定的迭代中,通常都有一小部分開發人員在處理某些事項,這些事項對整個sprint的成功完成有著不成比例的高影響。這些就是我們的槓桿點( leverage points)

在sprint的第一天,找出哪些是開發人員正在做的最重要的工作項。通常情況下,它是其他開發人員最依賴的工作項。其他情況下,則是開發人員所做的技術基礎工作,所有的一切都依賴於此。

多關注他們一點。問一些尖銳的問題,以確保他們考慮到了所有的角度:技術設計、可擴展性、測試、發布等。如果您能幫助他們成功地完成這些,那麼您的整個迭代就很可能會順利進行下去。

利用“站會”

導致開發人員在“站(stand-up)會”時不去談論他們阻滯點(blocker)的原因有很多。有時是因為他們怕延誤會議時間。有時是因為他們相信自己能解決自己的問題。還有可能是他們根本不知道自己一開始就有問題。

我喜歡問一些尖銳的問題。您不需要和每個人都一起鑽研,但您可以挑選一些人(槓桿點,leverage points)。我發現下面的問題可以告訴我很多關於開發人員工作的信息:

  • 是否(填寫依賴於此項工作的開發人員或團隊)對此進行了評審(review)?
  • 告訴我你功能的發布計劃?
  • 你對可擴展性測試有什麼想法?

讓團隊成員每天準時下班的4條建議 2

@LinearB開發團隊的每日“站會”(standup)

如果您得到的是一個附帶日期的簡潔答复,比如“我已經和PM和XYZ團隊一起評審了計劃,我們將在周二開始實施。如果你需要的話,我可以把文檔(doc)發送給你“,您會順利很多。

如果您得到的是“表象”,或者他們在與PM討論或一起評審計劃之前就已經開始羅列他們需要做的事情了,這時,您可能就需要深入挖掘下了。

專業提示1)確保每個人都了解您在迭代中的位置。當您埋頭寫代碼時,很容易忘記這一點。

專業提示2)對於您提出的問題,無論您聽到什麼樣的回复,都不要在會議期間回應。您必須讓事情繼續進行下去。如果您聽說某件事可能會被取消,在腦子裡記下來,然後繼續。

讓團隊成員每天準時下班的4條建議 3

為“站會”(或1:1會議)做好準備

當我剛被提升為團隊主管時,我對待“站會”的想法和我作為個人貢獻者時的想法並無差別。我從我的VP(副總裁)那裡得到的最好建議之一就是每天花30分鐘做“站會”前準備。

隨著時間的推移,我發現某些數據點是我可以發現潛在問題的準確指標。

WIP(Working In Progress,在製品)與剩余天數的比率。假設您的迭代還有5天,並且大多數團隊都還有1-2個WIP處於打開(open)狀態。如果您的一個開發人員還有6個,這可能意味著他們不能完成了。查看整個團隊及單個開發人員在迭代之間的平均WIP與剩余天數的比率是很有用的。如果您的WIP與剩余天數的比率高於正常水平,這就表明您的開發人員有工作超載問題,即使他們還不知道。

高交互PR(pull request)。如果您團隊的平均PR有5條評論,而您看到了一個有30條評論的PR,這可能意味著您的開發人員正在努力交付一個大家都很期待的東西,或者是存在尚未解決的內部爭論。

閃電PR。這就是我所說的沒有審查就合併的分支。有些團隊對此並不介意。我們必須避免這樣的事情發生,因為它能很好地預測質量問題。提前投入審查(review)時間總比事後返工要好。

複雜分支。我認為有大量的代碼變更及具有高百分比重構或返工的分支都是複雜分支。這些分支具有很高的風險,因此您需要確保它們有100%的測試覆蓋率,如果有必要,甚至可以提前安排審查週期(在PR發布之前)。

如果您把這些信息放在“站會”(或1:1的會議)上,它將能幫助您把時間集中在您個人能對團隊產生最大積極影響的方面。

專業提示3)在日曆上標出“站會”準備時間,以確保您不會分心。

明確週期時間

週期時間(Cycle time)是將一項工作編碼、審查並發布給內部或外部客戶所需的平均時間。我認為這應該是開發主管用來衡量團隊效率的主要指標。它還有助於了解週期時間的關鍵階段:

編碼時間(Coding time)。第一次發布PR之前,編寫代碼的時間。我們也稱之為歡樂時光😊

揀取時間(Pick up time)。 PR需要花費多長時間才能被揀取進行審查。

審查時間(Review time)。審查開始後合併PR所需的時間。

發佈時間(Release time)。合併後向客戶發布功能所需的時間。

如果您使用的是持續集成,那麼合併時間(merge time)實際上就是您的周期時間。

讓團隊成員每天準時下班的4條建議 4

對於在迭代過程中您從您的團隊那裡了解到的信息,週期時間是一個很好的檢查,因為它指出了您通常需要多長時間才能交付。如果您在每個迭代中都度量週期時間,並跟踪團隊的平均值,那麼就能很容易地看出您當前的迭代是否偏離了基線。

專業提示4)如果您正在尋找全面加速交付速度的方法,請查看下您週期時間的各個階段。這是檢測團隊瓶頸的一種簡單方法。

幫助你的團隊,幫忙業務方,幫助你自己

隨著我在早期診斷問題和幫助解決問題方面的進步,我開始注意到人們對我的態度發生了變化。

我的團隊更加尊重我了。他們知道我是來幫助他們,而不是來評判他們的。他們對我更加開放。我們都變得越來越親密了。

我的老闆注意到我們經常能在最後期限之前完成任務。他開始更加信任我了,讓我更多地參與戰略決策。

CEO(首席執行官)知道我的名字 🙂,他開始給我安排越級1:1。他真的聽我說話。後來,當我的老闆離職時,他支持我晉升為VP(副總裁)。

為你的團隊每天晚上能回家負責

我讀了很多關於如何導致軟件開發團隊有時會倦怠的有缺陷的文化或不准確的規劃。但並不像很多人所說的那樣,開發團隊在sprint中可以以不同的方式來阻止倦怠的產生。

讓團隊成員每天準時下班的4條建議 5

確保您的開發人員能夠回家和他們的家人、朋友、在線遊戲協會、或其他對他們來說最重要的事情呆在一起。

所有開發人員應該能每天晚上準時回家,花時間和家人在一起,看足球,玩《塞爾達傳說:荒野之吸》(Zelda Breath of the Wild)。

我認為團隊主管應該對此承擔個人責任。我們的人民由我們照顧。

關於這個話題,我還有很多話要說,我將在3月11日做一個現場直播。單擊此處觀看直播或獲取錄音

原文鏈接:

https://linearb.io/blog/my-team-goes-home-on-time-every-night/