團隊如何限制合適的在製品(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
- 適合小型外包團隊的5個Web應用程式組合Web
- 選擇合適的專案管理系統來支援專業產品研發團隊專案管理
- 如何為Kafka叢集選擇合適的Topic/Partitions數量Kafka
- 中小研發團隊如何找到合適的海外發行?你想知道都在這了
- 創業團隊如何把控產品策略創業團隊
- Amplitude產品團隊之旅
- 知識庫軟體對比:10款適合團隊的工具揭秘
- CIO如何建設數字化團隊
- 案例:低迷的產品研發團隊
- 團隊如何組織?前後端團隊與業務功能團隊的比較後端
- 自動化測試常見問題總結!(適合新手團隊)
- 中小團隊如何做單機類產品的遊戲測試?遊戲
- 閒談團隊的程式碼質量
- 產品團隊管理 - 如何制定、推行,優化工作流程優化
- 敏捷如何應對變化:敏捷團隊檢查和適應敏捷
- 中小團隊選擇一款合適的測試用例管理工具
- 如何成為一名拖垮整個團隊的產品經理?
- 限制End User Session數量Session
- PMCAFF微課堂「已結束」| 測試兄弟CEO揭祕如何提高創初團隊的產品質量
- 如何選擇適合你的企業資料管理類產品
- 產品團隊例會安排及流程
- IT團隊適用的工時管理系統有哪些?
- 如何使用kubelet 啟動命令限制Pod 啟動數量?
- 好的技術團隊和差的技術團隊的區別在於技術架構前瞻性和適應變化的能力架構
- 聊聊SwiftLint在團隊的實踐Swift
- Pipefy如何使用團隊拓撲方法建設敏捷團隊?敏捷
- 如何激勵敏捷團隊成為高績效團隊敏捷
- 如何管理好團隊,團隊需要同心圓建設
- 如何實現高效的團隊合作?
- 如何組建理想中的團隊?
- 如何帶好你的團隊薦