【Kanban看板及Lean精實的技巧在大型軟體開發專案】
by Ruddy & Franma
Ruddy 老師的課一定會有主題電影，這次是露西！
Kanban（看板） 源自豐田式管理，由 David J. Anderson （看板方法之父），將其轉化為 Kanban Method （看板方法）應用於敏捷開發。（推薦書藉：Anderson 的著作 － 看板方法：科技企業漸進變革成功之道，另一本 Henrik Kniberg 的書「 精益開發實戰：用看板管理大型專案」似乎更有名，但 Ruddy 老師以為該書部分論述易生誤導，建議先看 Anderson 的書。）
看板的重要組成，區分為 To Do –> Work In Process(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。
看板方法重點：
- Visualize workflow ：電子跟實體各有好處
- Limit Work-In-Process：讓人員專心處理一件事，Cycle Time下降
- 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
人生，開始或結束某件事，不一定要有理由～ (事隔多年，忽然對阿甘正傳裡的這一段很有感覺，想跟阿甘說：嗯，我懂～）