AI考拉技術分享會--kanban管理從實踐到入門

前言

上回書，咱們簡單地入門了敏捷開發中的scrum模式,在實施的過程當中，其實也是出現了很多問題須要解決。
那麼這種模式有無弊端呢？--有！臨時加入的需求排不過來怎麼搞？開發時間延時交付不了需求被噴怎麼辦！一天站會這麼多？！
那有什麼解決方法呢？--嘗試另外一種敏捷模型，kanban管理。 爲了解決敏捷模式中遇到的瓶頸，考拉技術開發小分隊實踐了kanban管理，由此對敏捷有了新的認識。

1、scrum的痛

scrum做爲敏捷的落地方法之一，用不斷迭代的框架方法來管理複雜產品的開發。經過其獨特並固定的管理方式，從角色、工件、和會議出發，保證項目的不斷優化。
在落地過程當中，須要與團隊的具體狀況結合，否則，就可能會衍生不少問題:

1. 項目估時不清晰：因爲scrum沒有具體交付日期，需求方會不間斷增長新的需求，致使開發團隊總體進度延後，出來的效果不盡人意；
2. 團隊分工不清晰：product owner沒法清晰知道每一個需求的進度。

scrum模型多適用於職能單一的團隊，他們可以較好地管理需求，團隊內部分工也較爲清晰，product owner也能夠更加合理安排內部分工。
那麼對於常常周旋於不一樣任務之間的開發團隊呢？kanban管理或許可以解決開發團隊的問題。

2、kanban管理的起源

kanban管理最初起源於20世紀40年代末，是豐田汽車公司爲了達到及時生產（JIT）方式控制現場生產流程的工具。
JIT生產方式與拉式開發理念不謀而合，具備如下優勢：

1. 控制庫存：下游須要時上游纔開始生產，有效控制庫存；
2. 加速流動：進入生產環節的物料和半成品，很快就被拉入下一環節，實現了保證安全庫存的前提下物料最快流動，提升工程的運轉效率；
3. 靈活響應：用戶需求變化經過看板行程的信息流快速傳遞至各個環節，系統可以作出快的響應；
4. 促進改善：庫存下降和流動加速，可以使生產問題快速暴露，好比生產環節的質量問題很快就會被下個環境發現。 JIT認爲庫存會帶來商品的堆積，致使成本的增長，它鼓勵企業逐步消除庫存，以減小生產過程當中的成本，逐步達到"零庫存"狀態。

   

3、kanban管理的優點

基於kanban管理的工做方式，可以將商品的庫存量和實際消耗量對齊，只有當庫存消耗殆盡纔會發出信號，讓生產端開始交付新一批產品。在下降庫存下，下降了庫存管理以及倉儲開銷，並能更加靈活地調整生產計劃，及時發現生產過程當中的問題。

4、敏捷開發中的kanban核心和原則

1. 可視化工做流(價值流）；

kanban管理讓產品的價值和價值流具體可見，工做流分爲不一樣的階段，每一個階段的需求都表明了不一樣的價值，一個需求從開始提出，通過分析、實現，測試，到最終完成，其價值不斷提升。所以產品的價值流是從左至右不斷提升的過程，也是信息的產出過程。
價值流中，用戶價值是可視的，開發團隊要清晰每一個需求的用戶價值,從用戶的視角去組織；其次，價值從提出到交付的整個過程，也應該是可視化的；最後，問題以及block也應該可視化。在價值流中會存在一些需求不明確、開發難度大等問題，不及時處理容易堆積成長隊列，影響開發效率。 隨着價值流動，開發團隊能夠及時發現項目中的問題，找到隊列最長的階段就能夠發現問題，這跟交通系統的瓶頸處老是出現長長的候車隊是一個道理。

2. 限制工做進程（WIP）

WIP指在對某一個環節內的全部工做（包括正在進行以及等待安排）的進行數量上的限制。若在環節內在製品數目未飽和，能夠從上一個環節加入新的需求，不然維持現有需求數量不變。 經過這個環節，團隊能夠更加專心開發目前的項目，縮短任務從進入系統到交付的時間。同時及時暴露團隊協做存在的問題，如溝通不良、需求定義錯誤、開發難度大、資源分配不均衡等。

3. 顯示化流程規則

經過明確的規則，能夠對整個流程不一樣階段的產品質量進行把控。在前一個階段的開發質量知足了「流轉規則」以後，方可轉入下一個開發階段。
開發團隊須要對即將落實到位的規則展開討論並達成一致。經過這個步驟，開發團隊能夠「持續改進」產品的流程以及質量，不斷優化產品。

4. 管理工做流動

爲了讓用戶價值順暢、高質量地流動，團隊須要管理好價值的流動。通常包含三項實踐：用戶價值的輸入、中間過程以及輸出。
1） 用戶價值的輸入：這是看板系統輸入環節和價值流動的源頭，輸入清晰、明確的用戶價值可以促進價值流流動，提升開發質量；
2） 用戶價值中間過程：站會是管理價值流動過程的活動，開發團隊天天都會安排站會，由團隊成員對看板牆中的卡片進行排列，梳理每一個用戶價值的完成進度、遇到的瓶頸，並解決這些問題；
3） 用戶價值的輸出：用戶價值在完成交付出去前，須要發佈評審，產品經理決定上線或發佈哪些需求以及發佈需求的策略等。
爲了對工做流進行有效管理，引入了一種度量方式--累積流量圖。繪製累積流量圖能夠獲得不一樣維度的信息，更形象曝光工做流中存在的問題。

5. 創建反饋，持續改進

基於價值流動，kanban管理造成了一套反饋體系，大致分爲兩類：一類是基於流動是否順暢的反饋，好比阻礙問題分類、緣由分析；第二類是關於用戶價值質量的反饋。創建反饋系統可讓開發團隊度量價值流動的狀態，發現工做流中的問題，不斷改進整個工做流模式，造成持續改善的閉環。
既然創建反饋體系可以暴露產品開發中的問題以及瓶頸，那麼發現問題後，如何解決問題呢？kanban管理推崇2種方式--團隊協做以及應用科學模型。
對於偶然出現的問題，能夠經過團隊協助的方式獲得解決，如分配更多的資源、成員的相互支持等；而對於系統性問題，須要系統、科學的模型進行指導，經過這些方式能夠不斷提升團隊持續改進工做流的能力，進而提高整個團隊的價值交付能力。

5、kanban管理工具

基於開發團隊的需求，可以使用jira的kanban工具；
kanban工具備以下的功能：

1. 不以sprint爲單位，團隊一直都只用一個看板，無需每週關閉和開啓sprint；
2. kanban管理一共分爲8列：
   ● 創意：產品經理收集需求加到這一列，能夠不以user story形式描述； ● 正在分析：產品經理正在分析的需求拖動到這一列，此時能夠將創意的card拆解成幾個user story；
   ● 下N個需求：產品經理不斷調整任務優先級，將即將要開發的需求拖動到這一列，這一列任務數量有限制，任務太多將會讓開發人員負荷過大；
   ● 正在開發：開發人員將正在開發的需求拖動到這一列；
   ● 等待測試：開發人員將開發並自測完成的需求拖到這一列，測試人員對這一列的需求進行測試，這一列任務數量有限制，任務太多將會讓測試人員負荷過大；
   ● 正在測試：測試人員將正在測試的需求拖動到這一列；
   ● 等待發布：測試人員將測試完成的任務拖動到這一列，開發人員對這一列的需求進行發佈，產品經理驗收；
   ● 已發佈：開發人員發佈完成並驗收完畢後，將任務拖到這裏，並點擊Relase記錄這次發佈的版本，這些任務將會不顯示在看板上。
3. 任務下方會顯示該任務停留的天數，以提醒團隊注意該任務；
4. Relase功能，能夠清晰看到每次發佈的功能；
5. report裏面有不少圖表，看板方法最經常使用的應該是堆疊圖，能夠看到各個階段任務的數量，以瞭解總體的狀況。

   

小結

在進行了kanban管理的實踐後，成員瞭解各個需求的進度，開發團隊的開發效率有了提升，就算臨時插入需求，也能根據優先級調整應對。
在敏捷實施中，適應公司的狀況，發現合適的開發方法，一直是使人頭疼的問題。kanban管理給出了一種新的方式，從產品開發現狀出發，首先可視化工做流並顯示化流程規則，接着經過限制在製品數量，推進開發團隊發現工做流的問題以及瓶頸，最後經過反饋系統以及團隊協做等方式，不斷優化工做流，提升團隊的開發效率，實現一個高效、順暢的產品開發工做流。
對考拉的dev而言，kanban管理是一種新的嘗試，也但願這種新的嘗試可以給更多dev帶來更多實踐上的革新。

參考資料：

1. 敏捷其實很簡單（4）--初識看板
2. 精益看板方法從理論到實戰 （1）—— 看板方法和看板實踐體系