【Kanban看板及Lean精實的技巧在大型軟體開發專案】

by  Ruddy & Franma

Ruddy 老師的課一定會有主題電影,這次是露西!

Kanban(看板) 源自豐田式管理,由 David J. Anderson (看板方法之父),將其轉化為 Kanban Method (看板方法)應用於敏捷開發。(推薦書藉:Anderson 的著作 - 看板方法:科技企業漸進變革成功之道,另一本 Henrik Kniberg 的書「 精益開發實戰:用看板管理大型專案」似乎更有名,但 Ruddy 老師以為該書部分論述易生誤導,建議先看 Anderson 的書。)

看板的重要組成,區分為 To Do –> Work In Progress(WIP) –> Feedback –> Done 四個併列的垂直區塊,任務(Task)會處於四個狀態之一,透過拖拉的在狀態間移動,以求一目瞭然,突顯問題。其中,處於 In Process 的任務數量要愈少愈好(因為 Multitasking is Evil!),放進 Done 的項目要經過檢討後才能刪除。

多工是不好的!(文獻) 電腦靠多工能減少閒置提高效率,但人類在多工切換時,效率卻會嚴重下降,尤以 Programmer 為甚。

Kanban 只是很簡單的 FlowControl,重點在 Lean,不浪費,可以跟現有流程方法結合併用。

薑!薑!薑!薑!Ruddy 老師的自製看板系統內附上課講義登場!嗯… 很好,用HTML5 + CSS3 + MVC + AngularJS + SingalR(用於多看板即時同步狀態)寫的,並聲明以後不會再用 Windows App 寫上課程式。(心中OS:老師明明在寫 XAML,一眨眼就點完 AngularJS、MVC、SignalR 技能是要逼死誰?)

比較常用的開發方法:(括號內數字為流程產出項目的數量)

RUP(120+), XP(13), Scrum(9), Kanban(3), Do Whatever(0)
愈向右約束愈少、適應性更高,看板要求少,僅次於瞎搞(Do Whatever),容易實現,亦較易與現有方法併用。看板只規定兩件事:工作流程圖要可見、WIP要有上限(記住:多工是邪惡的)

Lean 的核心精神:不浪費!
Programmer最大的浪費,製造一堆 Bug,Debug 得很開心,卻全無生產力。

格言:敏捷不是學完一種敏捷方法就可以擁有的,是透過不斷追求所換來的成效。

格言:看板系統!= 看板方法,看板方法是一種不浪費,實現可持續的步調、克服變革的阻力。

敏捷化案例:

士氣低落,成員程度不均,協同合作困難,部分人仍陷於其他專案的泥淖,充滿某某人要離職耳語的末日專案團隊。

成功的管理作為:

*專注於質量
*減少進行中的工作
*頻繁交付
*根據交付速率來平衡需求
*消除變異性的根源,提升可預測性

為什麼不要有半成品(WIP)?同時間多工作好嗎?

利特爾法則(Little's law)

Lead Time(產出時間)= 存貨數量×生產節拍
Throughput Rate (生產效率)= WIP(存貨數量)/ Cycle Time,CT(周期時間)
要提高生產效率有兩種做法,提高WIP數量或減少CT。實例:麥當勞得來速。WIP 增加,Thoughput 上升,但 CT 也上升。用些許 Throughput 降低去交換 CT 明顯下降,值得!增加盈餘時間,讓員工有時間學習、幫助其他人,對團隊發展有益。

效能高的資源要放對地方,才能有效提高產率,故要每天觀察看板進行調校,以求減少浪費,達到最佳的 Throughput。

看板方法重點:

  1. Visualize workflow :電子跟實體各有好處
  2. Limit Work-In-Process:讓人員專心處理一件事,Cycle Time下降
  3. Measure and Manage Flow 管理流暢度:可以 CFD(累加流程圖)可以看Cycle Time

七原則:消除浪費、增強學習、盡量延遲決定、盡快交付、授權團體、嵌入質量、全域優化

Franma:個人經驗分享 - 混亂的專案,做不完的工作,雜亂的需求,層出不窮的Bug。

  • 花一週時間把所有工作記錄下來,禁止成員私下接受客戶指令
  • 對工作 Breakdown、界定關聯,重新評估排序
  • 當年用Excel管理,開發、認領工作、…、驗收 12個步驟,靠行政(妹)人工追進度
  • TFS及看板簡化了上述任務管理,轉檯很久再回到專案,也能藉視覺化的具體資訊快速上手
  • 不要貿然導流程,一定要有「妹」輔助(誤)

Trello:另一種管理任務的選擇,很適合管理私人工作。VS 可以與 Trello 密切整合,雙向同步。將工作任務混合進 Trello 與私人項目一併檢視。

個人覺得這場最受用的觀念 - 個人看版(Personal Kanban,詳情可見 Ruddy 老師的專文

一個人跑 Scrum 有點蠢,但絕對可以藉由個人 Kanban 減少浪費,提升個人效率,管理好自己的生活與工作流程。逼自己檢視面臨的任務(不一定是工作,修吸塵器、騎車攻武嶺也算),衡量各項之間的優先順序!(個人覺得是時間管理中 重要、緊急 維度分析的具體實踐)

如何改善:開始結束時間(Cycle Time)、每項工作是否按步就班在可接受範圍內做完、超過WIP限制的狀況是否嚴重?要放寬WIP上限還是緊縮?

因為看得到所以知道:漏了什麼?每日排序、提醒(井然有序)、睡前自問(我忙嗎?目標是要逐漸不忙)、提醒自己

年看板、月看板(不漏東西)、星期看板(主要檢視對象)

課程相關資料下載:http://1drv.ms/1xyToMp

筆記完畢,謝謝收看,各位學員我們明年見!
(揮手下降… 但隨即被眾人拖上來) 

【後記】

應該有不少人發現,2008年開播的 TechEd/TechDays 文字播報隨堂筆記,今年怎麼沒了?

基於某個奇妙念頭,今年 TechDays 開始前就決定不寫隨堂筆記,雖然這是長達五年的傳統,但我們都知道:Deadline 是用來 Delay 的,傳統是拿來打破的,大家說是吧?(謎:並不是!)不過認真上課,抄紙本筆記還是要的。無奈造化弄人… 第二天在會場遇到 Ruddy 老師,冷不防被預告要欽點我幫大家抄筆記!噗,身為中年程序員,被心中的燈塔點名是種光榮,自當戳力以赴。而「Deadline 是用來 Delay 的,傳統是拿來打破的」之外應該還要再加一個「決定是用來推翻的」,也算實踐「敏捷」精神啦!於是,原本不存在的隨堂筆記出現啦~ XD

再回到:為什麼不寫了?奇妙的念頭是什麼?

說來有些可笑,扯不上什麼評估考量,就只是很單純的念頭,不想寫了。我不知道大家有沒有經歷過,但真的就這麼簡單,連自己都覺得莫名其妙 XD

人生,開始或結束某件事,不一定要有理由~ (事隔多年,忽然對阿甘正傳裡的這一段很有感覺,想跟阿甘說:嗯,我懂~)


Comments

# by Franma

「 人生,開始或結束某件事,不一定要有理由」 真的是太貼切了~~~~

# by youhongli

請問 課程相關資料下載:http://1drv.ms/1xyToMp 目前已失效,是否有其它下載的地方?

# by Jeffrey

to youhongli, Ruddy老師的相關文章在 https://ruddyblog.wordpress.com/2014/09/17/%E5%AF%A6%E6%96%BD%E7%9C%8B%E6%9D%BF%E6%96%B9%E6%B3%95%E4%B8%80%E4%BA%9B%E6%B3%A8%E6%84%8F%E4%BA%8B%E9%A0%85/ ,可以留言問看看。

Post a comment


55 - 21 =