2018年5月21日 星期一

融會貫通看板後,就試著進入敏捷式開發管理"Scrum"的世界吧

在過去如大型建設等硬體工程上,例如以室內裝修為案例,在交屋驗收前,若是專案設計需要變動,除了最後交屋的時間會延宕之外,更常會遇到的是如隔間要打掉重作、已經鋪好的地板要挖起來變成大里石,選定好的材料要全部更換....等等硬體成本的浪費。

而在軟體開發的角度上,因為專案變動的需求影響到的硬體成本,較過去其他傳統專案較少,因此在執行專案的過程中,很常會遇到在交付前的需求變更。而為了因應這樣的狀態和需求,在「以變為不變」的管理方式中,如何有效管理自己團隊的節奏來因應這些需求,更是敏捷式開發「Agile 」的核心概念。

在上一篇的看板管理方法中,想必大家應該都對視覺化的管理和改善有了初步的認識,但看板的管理概念較為廣泛,多數用來記錄及管理這些從需求出發的Idea,到產出成功能和產品間所有的活動與歷程,重心會偏向在工作流程的追蹤和改善。

而若是今天收斂到需求的開發上來說,會不會有其他的武功更值得我們參考或使用,若是作過專案的朋友們,相信在有限的時間內對產品作收斂是相當困難的,一來是要挑戰團隊間的資源規劃、二來是必須應付業主的需求,這時候也許看板的範疇在管理上就會顯得較不受用。這時候我們會為各位介紹另外一種管理方式「Scrum」。

和看板概念非常類似,一樣是透過視覺化來追縱團隊進度的管理,但方法卻大為不同了,有聽過Scrum的朋友對下面這張圖一定很不陌生
 

了解看板(Kanban)方法的核心方法,活化你的管理思維

在上一篇看版管理方法的介紹中,我們已經為各位介紹了Pull & push system 的差異,以及WIP的計算理念。
也知道了看板的概念是將現有的工作流程視覺化,並依據整個工作流的觀察加以改善的管理方法。
而在這一篇文章中,會針對看板的核心六種方法,去作更細節化的解釋,作為我們在現實的工作流程與團隊績效改善的依據。

看板的六種核心方法如下:
1.Visualize (視覺化看板)
2.Limit WIP (限制WIP)
3.Manage flow (管理工作流)
4.Make policies explicit (定義工作流)
5.Implement feedback loops (落實回饋)
6.Improve collaboratively, evolve experimentally (合作改善)
接著將會以小編身為一個開發單位PM的經驗,來為各位介紹方法。
首先透過方法1,將小編目前的工作流程看板視覺化如下,並透過方法2定義WIP,定義方式為以團隊成員數來作依據。
看板如下:


2018年4月20日 星期五

透過Kanban(看板方法)管理,視覺化並改善你的工作流程

在現在敏捷當道的世代裡,大家對於Kanban(以下簡稱看板)來做為專案管理的方法,一定是不陌生,但實際上看板方法並非只是透過看板的形式,來提示團隊工作階段與任務,其中還蘊含了許多相當大的管理學問。
身為工程師一定常常在工作時被解不完的BUG淹沒,而PM一定也面對過排山倒海的需求,搞得筋疲力盡,而這些心聲也是看板方法之父David J. Anderson心中想要達成的目標,如何在有限的資源下,以一種穩定的Tempo來完成開發的工作,並且將工作流(flow)給定義出來,只有把這些基礎給打好,未來才有流程改善的依據可以遵循,而市面上也有許多軟體是使用看板方法來把每一個工作項目視覺化,但在了解工具前,我們應該要先學習使用看板管理法的核心理念。

如何有效把現有流程視覺化,並且改善他!


假設我們有一組原子筆的生產線,並且只有3個成員來維持產線的運作,分別是領料(領取原子筆的原件)、組裝(把他們組起來)與貼標籤(單純貼上),如下圖所示,並且定義每一個人"同時"都只能做一件事情,定義好工作之後大家就可以動工啦!

一般傳統的生產線,就是當一位A完成作業後,馬上把半成品移至下一個製程裡,如果今天大家在工作上的難易度都雷同相當,那應該可以培養出一種穩定產出的節奏,如下:

公司無情員工無義, 能怪誰?


來吧!我已有心理準備被眾人罵了!
(跟幾位朋友聊過後有感...)
..........................................
在職時不要擺爛,離職時儘量不要造成公司/部門的困擾, 因為如果你未來應徵主管職時,肯定會做 reference, 我面試一位經理後問了一下他之前主管與同事,立刻刷掉。