團隊如何限制合適的在製品(WIP)數量
看板之父David Anderson曾說過“ 看板的本質是一個很樸素的思想:在製品必須被限制。 ”但對於團隊來說,確定一個合適的在製品限制可能是件棘手的事。
在《看板快速啟動指南》一文中,我們已經初步瞭解如何打造一個看板,今天我們來一起聊聊,在 啟動看板的過程中核心的一步:限制在製品。本文將和大家一起透過了解一些在製品的內容,來幫助團隊找到適合的在製品限額。
注意,制定在製品限額後並非一成不變,團隊可以根據實際情況,按照團隊的節奏來更改在製品限額。
一、為什麼要限制在製品數量
簡單來說就是為了避免團隊或個人同時做太多工作,避免讓下游流程負載過重。比如如果測試人員手頭已經有很多工作了,我們就不希望開發人員再繼續開發新功能,給測試人員增加負擔,而是希望他們騰出手來幫助測試人員儘快完成測試。
在製品限制就如同一個警告的訊號,在問題失控前引起團隊的重視。
二、哪些工作項屬於在製品限制範圍
在製品限制只適用於功能卡,也就是任務卡片內容為可直接交付價值的功能。像技術故事(非功能性條目,需要完成但又不屬於可交付物的東西)和Bug修復不包括在內。不包括Bug修復是因為,Bug通常都是緊急的,且非常小。另一個原因是,目前在看板上還沒有一個統一處理bug的好方法,因為bug有時會在進度看板上標出,而有時沒有。所以如果團隊的看板體系還不穩定和成熟,不建議就bug的管理制定太多規則。
不包括技術故事是因為,它雖然需要完成但並不能為產品負責人和客戶帶來直接的價值,如果將其置入在製品範圍內,不僅會佔用在製品數額,而且當測試遇到瓶頸時,測試的進度就會變慢,而研發已經完成任務就會被阻塞,無法進入測試,研發的在製品限額也會達到設定的上線,影響團隊流速。
只適用於功能的另一個原因是,能與團隊衡量工作的標準一致。不同的角色有著不同的工作內容,而對於任務的界定也會標準不一。只適用於功能,能讓團隊在任務項上保持一致,利於看板的流動。隨著團隊看板的不斷最佳化和改進,這些內容也可以根據情況適當改變。
三、如何限制在製品數量
1、利特爾法則
瞭解在製品要先了解下利特爾法則:同時做的事情越多,每件事情花費的時間就越長。 其公式為:週期時間=在製品數量/吞吐量
-
週期時間:完成每個工作項所需時間
-
在製品數量:並行的工作量
-
吞吐量:完成每個工作項所需的平均時間
舉個例子,A在排隊買快餐,已知A在第20個(隊伍的最後一位),且收銀視窗每分鐘能處理一個人的點餐需求,那麼這個隊伍的在製品數量就是20(個),平均吞吐率是1(人/分鐘),A從排隊到點完餐的這個等待時間就是“前置時間”。根據利特爾法則我們可以得出A的等待時間是20分鐘。因為在一段時間之內,保持工作量飽滿的話,每天能做多少工作基本是一定的,所以吞吐率基本上不會發生太大變化。如果這個時候我們想縮短平均前置時間,也就是等待時間,我們可以透過減少在製品數量來達成這個目標。
在例子中,就是減少排隊者的數量,我們都清楚10個人的隊伍和20個人的隊伍,前者等待時間更短。
2、在製品限制的基本原則
- 更低比更高好
雖然在製品限制越低,工作流動越快,問題也能被儘快發現,但 並不意味將在製品設定得過低。因為設得過低,可能會對流速造成干擾。比如直接設為1的話,流動中的任何干擾,都會讓工作停頓。
- 調整人員閒置或著工作閒置情況
有時團隊的WIP數量會太低,導致成員有時無事可做;太高,又會導致工作閒置,怎麼辦呢?那就根據情況邊適應邊調整。如果WIP太高,導致工作閒置,就需要降低在製品限制。如果WIP太低,導致人員閒置,可以在看板中列一個“我今天做什麼”的列表,這樣可以讓大家協作完成工作,比如研發同學不開發新功能,而是幫忙測試。這也符合在製品限制的精髓:
努力完成一件事,而不是努力開始做另一件事。
關於限制在製品,團隊可以記住一句話: 暫緩啟動,聚焦完成。團隊同意在開始任何新工作之前,要盡力完成當前手頭工作。這樣就能將在製品保持在較低的水平,因為只有完成了手頭的工作,才能開始新的工作項。當然,剛開始的時候會有些困難,但這是運用看板方法的一個必經過程。
- 沒有限制是不對的
不設定數量限制,這是不少團隊在匯入看板方法時最常犯的錯誤。沒有在製品限制會讓成員喪失積極性和改進的動力。久而久之,看板上的任務項也會越堆越多,很難再推動工作取得進展。當我們手上並行的事情越多,流程中所有工作項的前置時間就越長,此時限制工作數量,就能推動我們儘快完成手頭的工作,不斷改進流程。
3、限制在製品的四種方式
- 按照人數限制在製品
限制每個人可以同時啟用的頭像數,比如每人3個,當領取一個工作項後,就把頭像貼到工作項卡片上,頭像如果用完了,就不能再開展新的工作項了,開始新的工作項就需要儘快解決掉未完成的工作項。
- 按照列限制在製品
按列限制在製品數量,這樣能讓成員聚焦在工作項的流動上。比如,在下圖的
禪道
看板中,測試列的需求的最大個數顯示為5,那麼限制看板列的在製品限額就能促使團隊儘快移交完成的需求進行測試,獲取反饋和交付價值。
-
按照泳道限制在製品
用泳道來限制同時進行的需求的個數:每條泳道最多可以有多少WIP。這種方法的好處是可以根據不同泳道的優先順序來定義WIP,讓優先順序更高的泳道佔有更多的資源。這樣能促使團隊儘快完成已經開始的需求。
- 多種限制方法綜合使用
可以根據需要結合多種限制方法,可以結合上述的三種方式:泳道限制、看板列限制、人數限制來綜合使用。
四、結語
限制在製品是看板的核心原則之一,但限制在製品不是目的,改善流程才是,它只是一個能幫助我們發現阻礙能改善流動性的問題的工具。限制在製品也並不意味成員應該做更少的工作,而是指應該減少成員同時處理的工作。
在製品不是一成不變的,數量多少不重要,最關鍵是將團隊目前的在製品視覺化,根據團隊需要和節奏進行調整,如此才能幫助團隊的每位成員更迅速地完成更多的任務,交付更多的價值。
從現在開始,打造你的看板,找到適合團隊的在製品限額吧。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69982050/viewspace-2890707/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 團隊如何選擇合適的Git分支策略?Git
- 如何確定敏捷是否適合你的團隊?敏捷
- 看板中的WIP限制思想
- 如何提升團隊速率、保證產品質量和提升團隊積極性?
- 看板與Scrum:哪個更適合你的團隊?Scrum
- 團隊競技遊戲要限制團隊配合遊戲
- 選擇合適的專案管理系統來支援專業產品研發團隊專案管理
- 如何為Kafka叢集選擇合適的Topic/Partitions數量Kafka
- 中小研發團隊如何找到合適的海外發行?你想知道都在這了
- 知識庫軟體對比:10款適合團隊的工具揭秘
- Amplitude產品團隊之旅
- CIO如何建設數字化團隊
- 自動化測試常見問題總結!(適合新手團隊)
- 團隊如何組織?前後端團隊與業務功能團隊的比較後端
- 產品團隊管理 - 如何制定、推行,優化工作流程優化
- 聊聊SwiftLint在團隊的實踐Swift
- 中小團隊選擇一款合適的測試用例管理工具
- 敏捷如何應對變化:敏捷團隊檢查和適應敏捷
- 閒談團隊的程式碼質量
- 如何成為一名拖垮整個團隊的產品經理?
- 中小團隊如何做單機類產品的遊戲測試?遊戲
- 2024年適合團隊使用的專案管理工具有哪些?13款推薦專案管理
- 如何選擇適合你的企業資料管理類產品
- IT團隊適用的工時管理系統有哪些?
- 怎樣找到適合自己的產品呢
- 如何使用kubelet 啟動命令限制Pod 啟動數量?
- 7天銷量破百萬,《破曉傳說》製作團隊專訪
- 如何為您選擇合適的製造執行系統(MES)?
- 如何管理一個散漫的團隊
- 如何實現高效的團隊合作?
- vue init深度定製團隊自己的Vue templateVue
- SSL證書在保護域名數量方面有什麼限制
- 探索色彩搭配的奧秘:如何選擇適合產品的理想配色方案
- 如何激勵敏捷團隊成為高績效團隊敏捷
- Pipefy如何使用團隊拓撲方法建設敏捷團隊?敏捷
- ICML 2024 Oral | DPO是否比PPO更適合LLM,清華吳翼團隊最新揭秘
- 如何打造合作型團隊
- MySQL的欄位數量以及長度限制MySql