關於測量資料用於團隊改進的一些事兒

2021-09-17 06:16:04 字數 1795 閱讀 9855

敏捷團隊需要測量其sprint速率,以幫助團隊計畫並跟蹤其進度,同時也為產品所有者規劃產品發布提供洞見。那麼當團隊想要改進自身的時候,是否也可以使用速率資料?若干作者圍繞速率撰文,並針對測量速率以改進團隊生產力分享了各自的關注點。

\ 如果了解了團隊的速率,那麼我們將能夠了解:\

她還列出了一系列能夠對速率產生影響的因素:\

george dinwiddie編寫了一篇題為跟蹤速率的部落格文章。在文章中他表示,由團隊測量速率是有幫助的行為,因為它會幫助我們了解團隊工作情況如何。但是他也針對使用速率資料來測量生產力給出了警告:

\

\

速率並不是對生產力的模擬,然而人們很容易陷入這種思維陷阱。「在一次sprint中,我們可以完成的故事點總量是28個。」但28個故事點並不是工作總量,而是一種預估。(……)我們可以使用更多的故事點進行預估,或是將工作切分為更小的故事,以此來輕易地操縱這種預估的總量。這是如此簡單,我們可能在不經意或非刻意的情況下就這麼去做了。

\ (……)儘管速率也許能夠用來大略地跟蹤生產力,但隨著我們試圖這樣使用它來促進生產力提公升而失效。

\

\

2023年,tim ottinger發表了一篇部落格文章觀察敏捷團隊速率發現的14件怪事,在其中針對他經常遇到的關於速率的問題,給出了一系列答案。他首先表示,雖然我們可以測量速率,但卻無法直接地控制它:

\

\

速率是一套「測量儀表」,而不是「控制旋鈕」。我們不可能簡單地將它調高——這樣做只會讓我們把它弄壞。

\

\

tim認為,團隊績效提公升與團隊速率測量結果之間的關係,可能會非常複雜:

\

\

當團隊表現提公升時,要麼速率上公升而故事點大體保持不變,要麼速率基本相當而分配給每個故事的故事點有所減少。然而,在某種程度上,很多時候二者都會出現。這也正是我們無法跨團隊比較速率的原因之一(當然,還有其他許多原因)。

\

\
\

對組織機構來說,始終如一地施行高速率的團隊是非常寶貴的。而那些往往更不穩定的團隊——在乙個sprint中落實高速率,而在接下來的則出現大幅**——將不像它們最開始表現出的那樣有價值。

\ 其原因在於,速率的價值無法與可**性相比擬。在敏捷團隊中我們所做的許多事情,都是以增加團隊可**性為目標而完成的。團隊可**性越高,我們對未來的規劃就越高效。這讓我們能夠更聰明地面對風險,並且基於我們的團隊在給定的時間表中有能力交付哪些東西,來制定更加現實的戰略。

\

\

對於想要變得更加具有可預見性,同時又希望自身速率得到提公升的團隊,jeremy給出了一些解決方案:

\

\

那麼,是否這就意味著團隊不應該努力測量出自己的速率?其實並非如此,而是意味著團隊不應該以提高速率作為其目標。與之相反,團隊應該專注於為提高速率所需採取的那些行動。採用這類實踐將自然而然地得到更高的速率,例如持續改進工程流程,或是系統地識別並消除風險。

\

\
\
\

tim ottinger總結了他對敏捷團隊速率的觀察,對此他表示:

\

\

速率最大的問題,來自於不理解它卻又將它當作生產力或繁忙程度的通用指標。使用速率的訣竅在於,不要過分嚴肅地對待它;同時,應該以改進我們的工作系統和組織機構為重點,而不是提公升團隊的速率。

\

\

檢視英文原文:concerns about measuring velocity for team improvement

關於氣泡排序的一些改進

恢復內容開始 氣泡排序 一般氣泡排序我們都很容易想到以下的方法,但事實上氣泡排序還有一些地方可以改進。最主要的方法是引入標誌位。最後一行是輸出的結果 改進方案一 看到上面執行結果,第4,5,6,7趟都是沒有發生逆序對的互換,但演算法還是依舊進行了比較。為此,引入乙個排序標誌。最後一行是輸出的結果 由...

團隊管理 關於技術團隊管理的一些想法

做lead programmer已經4,5年時間了,從雲日誌扒了些以前的感想寫在這兒。主程的主要工作是 1,評估並執行程式組的計畫。在程式組開始制定milestone,sprint的計畫時,應該已經和design團隊有明確的溝通,定義 了功能的具體需求和優先順序,一定要不要等到做團隊計畫時才來定需求...

關於JSI裝飾引擎改進的一些想法

今天看到 url 大俠發布的sui,也看了一些設計及實現原理。覺得也應該吧自己以前的一些想法拉出來曬曬,交流一下,也希望對sui的發展能有些參考價值,僅供參考而已。文章是一年前寫的,而且這些想法也在我jsiside中得到實現。與sui重灌出擊的風格不同的是我在jsiside中的實現是非常輕量級的。q...