目前分類:Kanban (113)

瀏覽方式: 標題列表 簡短摘要

有人說 Scrum 改成 Kanban 很容易, 只要在 task board 中的欄位加上 WIP limit 就可以了. 所以原先的 scrum board

ToDo -> In Prog -> Done

便會長成像
              (WIP = XX)

kojenchieh 發表在 痞客邦 留言(0) 人氣()

在李小龍的截拳道中, 有定義出四種攻擊距離: 踢技, 拳技, 抓技, 寢技.

截拳道強調四種距離在戰鬥中都同樣重要。多數武術專注於其中一或二種距離,但李小龍認為真實格鬥中四種距離都隨時會發生,所以要全面地訓練。

 

28431440640  


可是在 agile 開發方法中, 常常會出現只用一種方法, 或是只適用一種背景的開發方法, 因此在推廣常會遇到阻礙. 例如 scrum/XP 大多是用在單一開發團隊的狀況, 若是對於多個團隊, 或是維護為主的團隊, 便會適應不良.

kojenchieh 發表在 痞客邦 留言(0) 人氣()

2013 David Anderson 在 Lean Kanban University 上發表了一個演講, 其中提到李小龍, 引用他的哲學來說明 Kanban, 讓我十分驚豔不已.

以下是李小龍的想法和 Kanban/Lean 想法的對照:

 

Bruce Lee nunchucks Way of the Dragon  


kojenchieh 發表在 痞客邦 留言(0) 人氣()

在社群或是公司中, 常常會聽到以下問題:
agile/Scrum 的想法很好, 但是我們公司的文化不喜歡改變這麼大
我們的組織不喜歡不斷的衝刺 (sprint), 太累了
我們的成員成熟度不夠, 無法自動自發
我們只想求溫飽, 不需要一直追求完美

kojenchieh 發表在 痞客邦 留言(0) 人氣()

豐田系統的效率是舉世有名的, 那他們如何來改善他的工作流程或是做事方法呢? 以下是個人小小整理心得:

1. 狀態視覺化
將工作流程和狀態給視覺化, 發現到異常現象, 立刻來處理. 以下是如何利用 Kanban 來視覺化狀態的簡介
http://kojenchieh.pixnet.net/blog/post/343997120

kanban_board_blocked  

kojenchieh 發表在 痞客邦 留言(0) 人氣()

上次在網路上看到一個例子(sorry, 我忘記出處), 來描述為什麼要用 WIP limit (Work in Progress), 想來跟大家分享:

Kanban 最主要的是看 flow 的流動是否順暢, 任何會影響 task 在工作流程上的移動, 都可能會是問題. 但是你要如何及早找出有問題的地方呢? 

你可以把這件事情想像成實體的河流流動, 你要如何觀察這個河流是否流動順暢? 是否有淤積? 在台灣常聽到的做法, 是在冬天水量較少的時候, 安排清淤泥的工程.  

4fa6ce280b98  

kojenchieh 發表在 痞客邦 留言(0) 人氣()

很多人問說一定要實體看板嗎? 為什麼不用 Trello 或者是其他電子系統呢? 個人覺得理由有下:

 

1524639_730825093595553_948745587_n     

1. 精神比較重要
對很多團隊來說, 都是剛剛實施 agile 沒有很久, 還並不了解 task board 的作用什麼, Task 要怎麼寫. 因此在早期是需要對大家做機會教育的, 然大家面前提醒大家, 這個 task 要如何移動, 哪些資訊沒有填寫, 要如何在立會時報告 task 內容. 因此重點不會是在要用電子系統或是軟體工具, 而是大家是否有注意到要小心的事情. 此外, 如果要很多錢來買, 老闆還會覺得不知有沒有效果就要花錢, 之後還可能一直碎碎念.

kojenchieh 發表在 痞客邦 留言(0) 人氣()

目前正打算整理 Kanban 相關的基礎知識, 赫然發現自己會的東西真的不多, 但是要花時間學好的項目不少, 明年繼續好好加油. 打算把一些相關文章和觀念彙整起來, 然後都是由這一篇當起始點來找起, 這樣就可以知道自己已經了解多少了 XDD

 

1524639_730825093595553_948745587_n  

1. Kanban 簡介
(1) Kanban 不是軟體開發方法

kojenchieh 發表在 痞客邦 留言(0) 人氣()

精實軟體開發是根據精實原則所產生的, 因此你必須先了解什麼是精實原則, 才能知道精實軟體開發重點放在哪裡. 在 Lean Software Development: An Agile Toolkit 一書中, Mary 整理出了以下原則:

 

can-stock-photo_csp11263618  


1. 消除浪費 (Eliminate Waste)
在這篇文章中描述了軟體開發中常見的浪費是什麼

kojenchieh 發表在 痞客邦 留言(0) 人氣()

看板並不是軟體開發方法, 他是變革管理的方法, 當客戶所提出的需求, 和團隊的能力不匹配時, 它能即時展現這樣的狀況, 讓你能得到警告. 當你實施改進做法, 你也可以從看板上看出, 這個方法是否有效.

那當客戶需求和團隊能力不匹配時, 我們會怎麼做呢? Kanban 的想法是這樣的, 當進來和出去的不能匹配, 會導致每個項目處理的時間變長, 所以要解決的問題是如何讓處理的時間變短, 讓客戶能儘快拿到有價值的商品, 也就是 cycle time 越小越好. 

 

scale1  


kojenchieh 發表在 痞客邦 留言(0) 人氣()

人們通常善於解決問題, 但是比較不擅長去把有問題的地方給找出來. 在精實思想中, 它整理出一些有問題的地方: Muda, Mura, Muri. 我特定把他們在整理了一下, 時時刻刻提醒下自己, 這些 bad smell 要特別小心.

 

 

BlogMudaIsNotTheOnlyFruit 
1. Muda (浪費)
做一些不會對產品加值的事情

kojenchieh 發表在 痞客邦 留言(0) 人氣()


在精益思維中, 排除浪費是一間非常重要的事情. 在製造業中, 什麼是浪費大家已經定義的很清楚了. 可是在軟體開發中, 大家對這樣的事情還不熟悉.

因此 Mary 和 Tom Poppendieck 在Lean Software Development: An Agile Toolkit 一書中, 很詳細說了軟體開發有哪些浪費. 其中有一項浪費是半製品, 也就是未完成的工作. 什麼事未完成的工作, 例如沒有被檢視的需求文件, 設計文件; 或是寫完但未經測試的程式碼. 只要不是最後可以交付到客戶手上的功能, 任何中間產物都算是未完成的工作. 即使你可能已經檢視過, 或是測試過, 只要沒被客戶驗收認可, 都是可能會有變, 會不再算數.

那我們看板中要如何管理半製品呢? 我們可以用 WIP (Work-In-Progress)來觀察. 如果我們能讓 WIP 的數目越小, 也就是代表半製品越少, 那可能的浪費也就越低.

kojenchieh 發表在 痞客邦 留言(0) 人氣()

在討論 Kanban 和 Scrum 的差別時, 大多數的人都是參考 Henrik Kniberg 的 scrum and kanban making the most of both 書中的說明. Al 則是從兩者的思考方式來比較, 我想從思想上來做探討, 會讓你更深入他們的差異性. 以下是 Al 的比較結果:



2012-01-Agile-vs-Lean-Kanban-Board6  


kojenchieh 發表在 痞客邦 留言(0) 人氣()

我發現到 Al 大老對 LKU 槓上了, 兩邊對 Kanban 有著不同見解. 對我來說這是不錯的機會, 從他們討論中, 讓我可以思考 Kanban 到底是什麼.


al-shalloway-kanban  


Al 認為, 一般來說, 談到 Kanban 可能有以下幾種意思:
1. 一堆有資訊的卡片, 通常用小寫的 kanban 表示

kojenchieh 發表在 痞客邦 留言(0) 人氣()

這是我在 qCon 上海 2013 所發表演講的摘要 (http://www.qconshanghai.com/node/403), 描述在專案中使用 Kanban 的經驗. 歡迎大家多多指教.


專案背景
首先先介紹專案的背景. 這部分其實很重要, 因為我的解藥可能會是你的毒藥. 你必須要先了解的背景和來龍去脈, 這樣你便可以判斷是否可以套用在你的專案中. 因為沒有所謂的銀製子彈, 只有較合適的做法.

kojenchieh 發表在 痞客邦 留言(0) 人氣()

  

很多人認看維護團隊適合使用看版, 所以我很理所當然地在維護團隊中嘗試它. 一開始時, 我定義處理的流程如下 

 

To Do —> In Prog —> Done
 

kojenchieh 發表在 痞客邦 留言(0) 人氣()

看板最重要的事情, 就是要把工作流程視覺化. 很多團隊在開始使用看板時, 會把工作流程上的步驟, 變成看板上的每個欄位, 然後查看工作是否進行得很順暢.
 
通常我們會把 DOD (Definiton of Done) 貼上看板的欄位上面, 提醒團位成員要遵守這些規矩. 可是你也知道人性就是會忘記一些事情, 因此我們可以改變一些, 來讓看板更有用: 把做完的條件變成是看板上的欄位.
 
例如: 開發人員完成架構設計後, 必須要通過檢視才算是完成. 或是程式撰寫完畢後, 需要經過資深同事檢查完, 才可以算是寫完. 
 
這樣狀態就很清楚, 我們就可以在看板上很容易知道這個功能是否是真的做完, 還只是自己做完而已.

kojenchieh 發表在 痞客邦 留言(0) 人氣()



當開發人員在解 bug 時, 常常會有想換種寫法來解決問題的作法. 這個方法比較方便, 可以不用管過去的作法, 尤其是當原先程式不是你寫的.

這時候, 經驗老到工程師會說, 如果沒有找出 root cause, 只是換種作法, 事情可能沒有真正被解掉, 之後有可能會再冒出來.

kojenchieh 發表在 痞客邦 留言(0) 人氣()

在 2000初期時, XP 開始盛行, 那時候出版了一系列的 XP 的書籍, agile 的方法也開始討論.

那時候我覺得這些想法很吸引人, 很值得去學習. 只是覺得 TDD, CI, refactoring 這些東西學起來還蠻花時間的, 不容易在組織內推行, 要花不少時間才能精通, 才能看到績效.

 

後來 Scrum 出現之後, 發現他似乎比較容易導入, 因為只要開一些會就可以(誤), 進入門檻低很多, 不需要花很多時間就可以開始, 並且可以看到結果.(不見得是效果(誤 again))

文章標籤

kojenchieh 發表在 痞客邦 留言(0) 人氣()

Kanban 不是軟體開發方法

kanban example 1

很多人會拿 Kanban 和 Scrum, XP 或者和 waterfall 比較, 看看哪一種方法適用, 哪一種能夠解決目前公司的問題

kojenchieh 發表在 痞客邦 留言(0) 人氣()

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼