if 我是前端團隊 Leader，怎麼用好看板進行任務管理?

時間 2019-11-05

標籤前端團隊 leader 怎麼好看進行任務管理简体版

原文原文鏈接

看板是一種很是常見的任務管理機制。咱們使用到的大部分團隊協做工具中都有看板的身影，例如 Tower、Teambition、Trello、Github、Gitlab...前端

看板不只能夠用於團隊協做，也能夠用於對我的時間進行管理和優化。 但是你真的會用看板嗎？git

Wiki 上面的解釋是： 看板是豐田生產模式中的重要概念，指爲了達到及時生產（JIT）方式控制現場生產流程的工具。及時生產方式中的拉式生產系統可使信息的流程縮短，並配合定量、固定裝貨容器等方式，而使生產過程當中的物料流動順暢.github

從上面的定義中須要注意如下要點:算法

及時生產 - 這是一種經過減小生產過程當中的庫存和相關的順帶成本，改善商業投資回報的管理戰略。
控制現場 - 看板是一種現場還原和現場控制方法
拉式生產系統 - 傳統的軟件開發都是使用推(Push)模式，即規定某個任務由指定人在指定時間內完成。而拉式生產系統，更像生產者-消費者模式，看板就是一個信號等，當上遊有已完成的任務，通知下游開始處理這些任務
定量 - 流程上的每一個環節是有固定帶寬的，這有助於暴露流程上的瓶頸

《解析精益產品開發（一）—— 看板開發方法》對看板總結得很是好, 看板工具的實質是：後道工序在須要時，經過看板向前道工序發出信號——請給我須要數量的輸入，前道工序只有獲得看板後，才按需生產。看板信號由下游向上遊傳遞，拉動上游的生產活動，使產品向下遊流動。拉動的源頭是最上游的客戶價值，也就是客戶訂單或需求。shell

下面會按部就班，介紹看板應用的幾個階段。若是你的團隊還停留在第一個階段，不妨試試繼續深刻實踐。併發

文章大綱框架

系列文章wordpress

第一階：從既有的流程開始，流程可視化

將開發流程可視化是看板的最基本的用法. 上面是一個典型的看板實例，它直觀地描述了一個功能項的生命週期以及該團隊的開發流程。它給咱們展現了這樣一個流程:工具

需求分析 -> 產品設計 -> 開發 -> 測試 -> 部署
複製代碼

流程的抽象

每一個人、每一個團隊工做流程都不同。在設計看板以前咱們須要梳理一下本身的工做流程.佈局

好比’我的‘的流程就很是簡單了，就只有一個動做：'作與不作'. 因此我的看板一般是這樣的

todo -> doing -> done
複製代碼

你會發現，即便很簡單的流程，流程的每一個環節都會有三個子模塊：未作/正在作/已完成. 對於我的看板而言，劃分這三個模塊，主要是爲了還原當前的現場。對於團隊而言，這一點更爲重要，你能夠經過看板直觀地跟蹤任務開發的進度

咱們團隊目前的開發流程也很簡單是：

設計 -> 開發 -> ...
複製代碼

設計: 應用設計，可選，通常在開啓一個項目或者重要的功能開發時會進行概要設計
開發: 正常的開發流程

固然這僅僅是前端團隊的’局部‘流程，完整的軟件開發流程如第一個看板實例所示。由於咱們不是一個’敏捷‘團隊，只要負責前端開發這個環節便可. 大局上看需求分析、產品設計、測試以及部署不在咱們的控制範圍以內。因此不該概括到咱們的開發流程中。

不斷改進的流程

流程不是一成不變的，它會隨着實踐的深刻不斷演化。舉個例子，由於咱們團隊成員能力和經驗不均勻，好比新手代碼常常出 Bug，細節也沒有作好。怎麼解決？

首先想一下可否在流程上作一下改進, 來減緩或杜絕這種狀況，提升代碼質量?

反覆思考和討論後，咱們決定在 開發 環節以後添加了一個 交叉測試/Review/用戶體驗測試 環節。這個包含三層含義, 交叉測試是指定其餘人來測試、Review指的是代碼層次的審查(白盒)，用戶體驗測試則是從用戶角度觸發進行驗收測試(黑盒)。

下面是改進後的看板(設計 -> 開發 -> 交叉測試):

看板的範圍

顏值很高的我的看板

上面看到了’我的看板‘、’團隊看板‘，以及’一個涵蓋完整軟件開發流程的看板‘。你會發現看板應用得很是廣，能夠應用於不一樣的層次，表示任務的粒度也不同。

咱們前端團隊內部就有兩個看板，一個是周計劃看板，一個是任務看板。

周計劃看板任務粒度是'項目'或者'重大功能'，用於規劃和跟蹤每週的大概任務；而任務看板則是各類細化的任務, 例如小的功能、Bug修復、細節優化. 粒度平均在1人/天如下，能夠最大程度還原每一個開發成員的開發現場。

在團隊協做層面, 咱們還有一個研發看板，這個和第一個看板例子類似，還原一個應用完整的研發流程，每一個團隊佔用看板上面的一欄，展現和跟蹤團隊之間的信息流動:

研發看板

優先級劃分

上面咱們團隊看板中，有幾個比較特殊的欄: 計劃/本週待辦/緩衝區。主要欄主要目的是爲了給任務劃分優先級，讓團隊專一於目前應該優先處理的任務。

看板中優先級能夠經過兩種方式來處理:

1. 拆分看板:

例如優先級排序 緩衝區 > 本週待辦 > 計劃

計劃 - 近期須要進行的任務，有些任務優先級很低，可能一年半載都不會處理。這一欄有點像備忘錄
周計劃 - 從計劃欄中篩選部分任務，做爲本週的’開發目標‘。表示本週計劃要完成的事情
緩衝區 - 從周計劃中篩選優先級最高的任務，須要優先被處理
已完成(周結束時間) 放置每週已完成的任務, 這個和周計劃相對應，能夠反饋’周計劃‘完成的進度。

咱們一般會每週’歸檔‘一次已完成欄。若是使用Tower，能夠經過’查看歸檔‘，獲取全部的以周爲單位的歷史記錄

2. 設置任務優先級

在任務層級也能夠設定特殊的標籤，來標記任務的優先級。另外也能夠將高優先級任務排在隊列前面, 表示任務的優先級

下圖使用 Tower 能夠爲任務設置優先級，它會使用不一樣的顏色來標註它:

推模型(Push)與拉模型(Pull)

仍是左耳朵耗子, 他在某期節目提到的’x 型人才和y 型人才論‘，讓我印象深入, 他指出人才能夠分爲兩種:

x 型人才: 給任務就作，不給任務就不知道作什麼
y 型人才: 自驅動、擁有自主性和主動性，對企業有歸宿感。這種人適合作管理者

大部分人都是x型人才，因此企業須要花高一點的薪酬僱傭y型人才來管理和驅動x型人才。但我認爲這不是天生的，在後天給予必定的責任和鼓勵，或者在某些管理機制下，咱們也能夠成爲 y 型人才，甚至成爲 y 型團隊。不少敏捷理論就推崇’團隊自治‘、但願團隊以及成員能夠自我驅動，推進業務的發展。拉模式也能體現這種思想.

傳統團隊都使用推模式，由Leader將任務分配給團隊成員, 指定完成的時間和各類指標。這種方式也稱爲推進系統(Push System), 它通常依賴於時間的排定，時間到了就被’被動地‘推進去作某些事情.

而看板很是適合拉模式。因此看板也被稱爲信號板(Signal), 你能夠將任務當作一個’事件‘，由事件來驅動工做(相似生產者-消費者模式)。這仍是有點像工廠的流水線，上游的產出就是一種’事件‘，下游主動去拉取上游的物件進行處理.

這種模式的好處是，Leader不須要再去關心細微的工做分配和決策，讓團隊成員本身有效地安排事件。另外這也能夠避免出現這樣一種狀況：團隊成員只熟悉其中某些項目，或者只會作、只負責一類事情。這使得成員離崗時，團隊會變得比較被動，由於其餘成員對離崗成員的工做狀況不熟悉。所以拉動模式，也可讓團隊成員離開本身的溫馨區，參與和熟悉各類項目

咱們目前使用的是混合型, 有些任務是提早指派合適的人去作的，而若是看板中沒有指定負責人，這個任務就能夠由任何人來負責，推拉結合。

暴露瓶頸

流程上的多個環節會像管道(pipe)同樣，經過輸入輸出鏈接在一塊兒:

tasks -> (流程1) -> (流程2) -> Done
複製代碼

上一個流程的輸出(Done)，就是下一個流程的輸入(Todo). 按照理想的狀態，信息流應該是流暢、平穩地在管道上流淌的。若是某個環節出現瓶頸，那麼可能會致使忙的忙死，閒的閒死。

若是你有細心思考，看板的流程管理方式有點像’工廠的流水線做業‘，若是某個環節阻塞，這個環節就會堆積不少元件，而下游則會出現空閒等待狀況, 而該環節的上游也會被阻塞。

經過看板的現場還原，咱們能夠容易地發現這種流程上的瓶頸. 怎麼解決這個問題？

這個能夠類比程序，當咱們發現程序上的一個性能問題時，一般有兩個解決的方向:

是不是算法問題? 可否使用更好的算法或者解決方案？對應到開發任務中，要考慮一下是否實現的方法不對？
若是是硬件的瓶頸，可否擴展硬件資源，升級好點的硬件？對應到開發任務中，要考慮一下是否要多加些人手？

下一節會介紹，我會介紹經過設置在製品數量(帶寬)，讓看板更容易地暴露瓶頸.

總結

經過看板咱們能夠獲得這些好處:

流程可視化: 經過看板能夠看到任務會通過哪些環節，當前在哪一個環節
還原開發現場:
- 直觀地跟蹤開發的進度
- 暴露流程瓶頸
- 貢獻看得見
拉模式: 自我驅動

第二階：在製品限制

大部分團隊對看板的應用只停留在第一階，即流程可視化。看板的魅力遠不止於此。第二個階段，咱們要開始限制在製品的數量。

什麼是在製品

在製品(Work-In-Process WIP), 也稱爲半成品。顧名思義就是部分未完成的任務。

在看板中, 一些欄會有在製品限制，用於限制該環節’同時‘能夠處理的事情。換句話說就是限制某個環節的’流量帶寬‘，或者說節流.

爲何限制在製品?

1. 更快暴露瓶頸

儘管在'第一階'時，咱們也能夠識別出流程的瓶頸，但並非特別直觀，至少從看板上較難察覺。你可能要詳細跟蹤詢問，才能瞭解哪一個流程卡住了。

限制了WIP後，每一個環節的帶寬是固定的，好比’測試‘環節的WIP限制是6，若是’測試‘環節到達限制，上游就沒辦法給它塞其餘任務了。這就暴露了'測試'環節的瓶頸

怎麼設定WIP的限制額也是比較重要的，設置過小，會致使併發處理的任務量變小，資源可能得不到利用，太大又不容易暴露瓶頸。下節會介紹如何設置WIP.

2. 避免中斷，避免上下文切換

限制WIP的另外一個好處，是減小成員併發處理多個任務的數量。

和計算機的進程同樣，進程的上下文切換代價是比較大的。對於開發者來講，任務中斷、任務調換也會浪費切換的時間，由於咱們須要調整/回顧思路來投入新的任務流程。

因此說經過限制WIP，可讓成員專一於正在處理的任務，作完這個任務再去拉取新的任務。

3. 盈餘時間

當下游出現阻塞，上游或下游可能就會出現盈餘時間。這些盈餘時間看起來像浪費，其實對於開發者或團隊來講，能夠作不少事情。好比:

休息/學習: 能夠利用這段時間來學習。對於前端來講，必須不斷的學習，提升本身的水平和競爭力，這對項目開發也是有益處的. 在996這種環境下，企業家逐漸剝奪了咱們生產生產力的能力。
幫助解決瓶頸: 下游出現瓶頸了，咱們能夠停下來，幫助他們解決問題。例如其餘同事由於某些問題卡住，咱們能夠幫助他一塊兒解決問題；再好比下游測試環節出問題了，咱們能夠一塊兒進行測試。做爲一個團隊齊步向前，變相提升團隊凝聚力和責任心
優化: 反思流程問題，考慮若是提升產能
其餘事情: 好比能夠進行交叉測試和寫文檔，優化開發工具

WIP要限制多少?

在製品限制值不是具體可計算的，須要長期經驗積累和磨合才能定下一個合適的值. 值越小，成員能夠更專一於當前的事情，加強成員之間的協做。值越大，能夠處理的事情更多，任務調度會更爲靈活。

一個基於經驗的、折中的公式是： 在製品上限 = 團隊規模 * 2 -1。

第三階: 結合Scrum

Scrum 也是一個敏捷框架. 它的規則很是簡單，可是要精通很是難。因此第三階段，咱們能夠嘗試將 Scrum 的某些規則融合到看板的管理流程中

簡單介紹一下Scrum

上圖一個典型的 Scrum 流程.

簡而言之，Scrum 首先會將應用開發過程拆分爲多個迭代週期，這個迭代週期稱爲 Sprint (一個衝刺)，週期通常爲1-4周。

在每次開始一個衝刺時，會從功能列表(Product Backlog)中，按照優先級和時間評估篩選出這個衝刺能夠完成的任務列表，稱爲衝刺列表(Sprint Backlog); 接着就在這個迭代週期裏專心完成這些任務

另外 Scrum 還定義了各類活動, 來進行持續的反饋和調整，例如:

Sprint計劃會議 - 在開始一個衝刺前，計劃一個週期內須要作哪些任務，對任務進行時間評估
每日立會 - 同步開發進度、發現開發中的障礙、增長交流和溝通
評審會議 - 在衝刺結束時舉行，用於檢查計劃中的工做，哪些完成了，哪些沒有完成。有些團隊會讓功能的負責人演示本身所作的功能，而後 PM 會看這個功能是否達到了要求
回顧會議 - 在衝刺結束時舉行，回顧和檢討本次迭代遇到的問題、以及如何改進

另外，Scrum還定義了各類角色和價值觀。這些不在本文的範圍以內，咱們也不會所有照搬. 有興趣的讀者能夠查看參考文獻

融合到看板中

設定開發週期

瀑布式和敏捷的明顯區別就是開發流程分割成多個迭代過程。按Scrum的定義就是一個’衝刺‘.

在咱們實際的開發中，會以一個星期做爲一個開發週期。我覺的一週的時間剛恰好，時間太長很難對任務時間進行評估，並且未知因素也會更多.

在一個星期開始前，從’計劃‘欄中篩選本週要進行任務，拖進’本週待辦’欄。這個過程就有點像 Scrum 的計劃會議

每日回顧

筆者天天開始工做時，就會將團隊成員彙集在一塊兒，對着看板簡單詢問任務開發的進度，回顧昨日的工做，看是否出現障礙。若是有障礙則及時處理障礙，若是任務超出預期，則考慮是否應該從新調整計劃。

總之就是儘早暴露問題，保證流程的順暢。在這裏看板就是一種重要的溝通工具。每日詢問的時間都很短，通常都不超過10分鐘，這個過程有點像 Scrum 的每日立會

在Tower中，完成任務後咱們不會直接將卡片拖入已完成列表，而是在最後一個環節點擊’已完成‘，這樣方便第二天對已完成的任務進行回顧，回顧完成後再統一拖入’已完成‘欄

流程監控

燃盡圖

燃盡圖是常見的Scrum進度跟蹤工具。它的外形以下:

橫軸爲開發週期，縱軸爲任務量. 理想狀態下，任務量在週期結束時應該變爲0，也就是說理想的線段是一條對角線(藍線), 這也是一條參考線。若是在某個指定時間點，紅線高於藍線，則說明進度有些延遲，反之就是超前

使用燃盡圖，咱們通常會一般會在每日回顧時在燃盡圖上繪製一個點，表示截止到此刻未完成的任務量

累計流量圖

累計流量圖統計每一天每一欄的在製品數量。從而能夠反映不一樣環節任務處理速率，以及暴露環節之間的瓶頸:

看板一日遊

下面模仿經典的文章《看板一日遊》實踐一下本文講述的看板使用流程。咱們使用的工具是 Tower，這個也是咱們團隊目前在使用的，功能基本夠用。

設計看板

假設咱們的前端團隊有3我的，開發流程是這樣的: 開發 -> 交叉測試 -> 部署。按照上面學到的知識，咱們設計了這樣的看板佈局:

建立任務

如今點開Tower任務建立窗口. Tower 的任務功能已經很是豐富了。爲了更方面其餘人處理任務，咱們對任務進行了一些規範

① 標題: 以 [scope] 概述 (時間評估).
scope 是指任務的範圍，例如項目A，項目B
- 時間評估 要求對耗時較久的任務進行評估。咱們通常推薦任務的粒度在3h 到 2d之間，小於3h考慮將任務進行合併，大於2d則考慮繼續拆分任務
② 指派負責人: 可選，不指派則說明採用拉模式
③ 任務的Deadline
④ 設置任務優先級
⑤ 詳細說明
⑥ 細化任務
⑦ 依賴任務
⑧ 任務標籤: 能夠指定任務的類型，例如功能、Bug、優化、重構