Ruddy Lee 分享空間

Emergent Design 演化設計

Posts Tagged ‘看板方法

看得見 : 看板讓你看得見

with one comment

  • Q&A : 實行看板方法與 PMP 或是 CMMI 有衝突呢?
  • 回答 :  當然不會衝突。

看板方法是精實開發的一員,屬於「視原則重於開發方法的一種漸進改革方式」。他的目的在讓工作流程被視覺化,讓我們的決策更接近事實、更容易作為改善的依據、更容易管理及更有效率。

.

眼見為憑  “To see is to believe"

形容不要輕信傳聞,看到的才是事實。聽來的傳聞是靠不住的,親眼看到才算是真實的。所謂;親眼看見的比聽說的要真實可靠。「看板方法」也就是這麼一回事,它要求我們要畫出價值流程圖來,也就是把開發過程呈現出來讓我們看見浪費所在,並依據他來加以改善(而不是用臆測或聯想的)。而 DevOps 也正是要依靠這麼一回事!讓你依據看見了的現象進行調整與持續改善。

.

投影片2

旅遊是一種透過看得見,來增長見聞的方法

.

看見流程、進度、問題及瓶頸

我們都愛旅遊,因為旅遊可以拓展人的視野,而視野寬廣的人容易讓人喜愛。自己也可以因為行萬里路而增長了知識,對人對事也似乎能夠看得更深更遠一些,好處多多。但這裡我們不談旅遊,我們想談的是「看得見」。

很多事情都需要你看見了,才會意識到也才會知道事情的原委,才曉得接下該怎麼來處理它。這樣的看得見正是看板所能帶來的好處。看板方法的第一條原則,「視覺化」。正是要求透過視覺化你目前的工作流程(產出價值流程圖,Value stream mapping)。讓你看得見工作流程的狀態、看得見進度、看得到問題所在、看到事情的瓶頸。然後才能正確地來進行改善的工作。

.

0 看得見

看得見: 流程、進度、問題及瓶頸

.

可視化的價值 –透明化

看板上流動的工作類別,決定了我們想看到的工作流種類。以開發作業為例,我們用"使用者故事"來描述需求,團隊並針對要如何達成這個需求而將它拆解細分成可以實作的Tasks,並針對各個Task作需要開發時間的估算,接著在卡片上壓上工時以便利追蹤,並在拉入"In Progress"時寫下開始時間,讓他明確地在看板上以貼紙的方式呈現出來,讓大家都能看得見進度及狀態。這個動作讓專案的進度完全落實在看板上頭,就專案而言就稱之為「透明化」。它是實行敏捷開發的基礎,也是主管對敏捷開發最愛的地方,就是能清楚的看得見專案開發的進度。

.

00 user story

.

卡片需要追蹤、更新及follow所衍生出來的問題

工程師容易患見樹不見林的問題。因為工程師通常是把焦點放在工作上,而忽略了使用者故事所要達成的目標。這是Scrum 團隊最常患的迷失,也就是把Task當成目標,這便是「非技術債」最常誕生的原因之一。它往往不是使用者故事寫得不好所造成的,而是工程師經常用 Task 來取代開發作業的目的所造成的結果。此時,Scrum Master是最可以改善這類迷失的當然人選。我們可以在站立會議時適時的提醒工程師在更新工作時,再次正視這些工作的目標,簡單的討論一下距離達成目標的距離,聽聽團隊的意見,不但可以避免忽略了真正的標的,而且可以讓團隊更專注於達成目標的使命感,是一舉數得的動作。

卡片上充足的訊息能讓觀看的人獲得更多的資訊,但適度凸顯重要的訊息(運用顏色、特殊標籤等方式)會遠大於一大堆相同分量的訊息要有價值的多了。也可以便利團隊就事論事的進行問題討論。

.

0 看得見卡片

原本十分抽象而簡單的卡片,在看板上是需要被賦予了各種屬性及訊息。

.

可視化價值流動

在工作步驟與步驟之間,代表的是一個工作的輸出(成果),以及它流動到另一個工作時轉變成輸入的過程,這個轉變的過程正是預告將要製造出的價值所在。工程師則是負責製造達成這個目標的人。團隊依據卡片上對工時的估算,小的Task我們可以很快的看到成果,較大的工作則可以持續在卡片上更新它的進度,讓大家都清楚目前距離達成目標的距離,然後以一個團隊的形式來共通承擔這個任務的成果。

 .

可視化問題及阻礙因素

看得見風險是看板的一大功能。由現象的解讀我們便容易推論出專案接下來可能發生的現象,美其名或許可以稱之為預測,但實際上只是一種後果的猜測而已。團隊可以依據看板上的徵兆,共同討論、共同決定對策(這是團隊表現出自我管理能力的地方),這一點可以提升團隊對任務負責的心態,也能夠具體的提升團隊自我管理的能力,相對於處理的問題或瓶頸而言,是更有價值的一環。

可視化排隊queue 及瓶頸

看到問題便可以針對問題進行改善,這是看板最能發揮精實精神的地方,也就是運用「看見浪費」,來實踐精實第一大原則,也就如何「消除浪費」的具體方法。我一直以為看板之所以稱為方法(Kanban Method)的地方便在這裡,它是一種消除浪費的方法。

產生Queue的地方,便是出現盈餘時間的地方,也是多出WIP(Work In Progress)限額的地方,就是我們可以加以改善的地方。在運行看板的時候,在這裡的半成品(WIP)已經從原本的一種猜測,轉變成是一種現象了。依據這個現象,我們便能夠對看見到這樣的現象,針對它來進行改善的工作。

.

看板方法是一種消除浪費的方法。

.

看見之後,要如何來改善呢?  看板方法的第二條原則:設定WIP限額就是要完成這件事。我們下回再來談吧!

廣告

Written by ruddyllee

2015 年 10 月 15 日 at 12:24:43

精實開發與看板方法導讀

with 6 comments

封面

2015/03/23 出版

這本書是寫來供自己上看板方法課程用的教科書。過去我上課時都是採用看板之父David J. Anderson 所寫的《看板方法:科技企业渐进变革成功之道》這本Blue Print的簡字版作為教材(它是Amazon 2014 暢銷書),現在終於有自己的教材了! 真是人生一大樂事。寫書的最大動機是因為看板之父的書(2010)內容沒有補充那些新增的資料,與其一直在做補充,不如自己辛苦一下了。

.

第一章寫的是精實軟體開發

看板方法隸屬於敏捷開發的精實Lean之下,但看板方法書裏頭卻沒有特別提到精實的原則,所以我在一開始就先來補足這一塊缺少的部分。首先簡述了一下Lean 的由來與敏捷軟體開發(Agile software development)的關係,然後就開始說明依據Mary and Tom Poppendieck 的名著《Lean Software Development An agile Toolkit》所整理出來的精實七原則。

  1.  消除浪費 Eliminate waste – 由識別浪費做起。
  2.  增強學習 Amplify learning – 如何表現的超越自身的能力的最佳方法就是學習
  3.  盡量延持決策 Decide as late as possible – 盡量多思考清楚再作決策。
  4.  盡快交付 Deliver as fast as possible – 客戶需要。
  5.  授權團隊 Empower the team – 自主團隊擁有最佳的效能。
  6.  崁入完整性 Build integrity in – 在了解需求同時進行開發。
  7.  著眼整體 See the whole – 避免局部優化。

上面這七條原則,就是熟悉以後便可以受用不盡的「精實原則」。老實說,這樣的原則可以適用在所有的人類行為上頭(上ㄧ回問我精實lean要如何善加運用的人,是一位從事婚顧的專家,她覺得真的是好用極了),是一種放之四海皆準的原則。我個人覺得是公司行號或組織團隊拿來醞釀企業文化的基礎規範。它們全部加起來只有31個字,卻宛如朱子家訓一般的終身受用。

 .

》關於第二、三及第四章,足夠拿來做教學用了!

如果你要上一天8個小時的看板教學的話,這三章就擁有足夠的基礎資料了。第二章是簡介,第三章則是將相關的基本理論都納進來的一章,雖然是按步就班的描述,但資料繁多而比重也不均勻,一口氣都講完會有些個混亂,講師可以挑比較重要的部分做講解即可。第四章則是實作的開始,實作「看板牆」。

第二章看板方法 Kanban Method

  • 解釋何謂看板方法: 是一種運用精實原則來控制流程的方法。它具有四個基本原則及六個實務。
  • 為何要使用看板方法: 使用看板方法就是達到漸進式的敏捷改革之道。
  • 哪些地方可以用到看板方法: 只要是有流程的地方就能適用,因為它是運用在流程管理和改進的一種高效能的方法。

第三章看板方法的六大核心實務(所有章節裏頭,東西最多,也是看起來最為雜亂的一章。)

建置看板方法的核心步驟,David J. Anderson 所寫的《看板方法:科技企业渐进变革成功之道》只描述了前三個步驟。後面三個則是後來才追加進來的。我把他們歸類為策略而非步驟。是你在實踐了前三個步驟之後,應該繼續完成的改善策略。

其中第一步是最重要的一步,「視覺化目前的工作流程」是讓自己能夠正視目前開發作業的流程步驟,這是作為接下來進行改善動作的基礎。這個動作我們稱之為繪製價值流程圖(Value stream mapping),它是識別流程浪費的基礎,目的是在消除浪費之前,先行識別浪費的所在,才能對症下藥。但這裡僅僅是看板方法的第一步,因為我們在這裡只是先行識別目前的工作流程,最終的目的則是持續改善,追求最高產出。因此除了要消除浪費之外,一個大的前提是要能追求最高產能。所以必須對半成品數加以限制,而這是看板方法用來提升生產率的最佳方法。

繪製價值流程圖 VSM: Value Stream Mapping太重要了這裏我舉了三個例子:

  • 範例一、BUG的修復作業流程圖示。
  • 範例二、遊戲公司開發、上市作業流程圖示。
  • 範例三、採用敏捷開發法SCRUM來運行ASP.NET的網頁開發流程。

這是開發團隊對照既有的工作流程到看板牆的重要步驟。如果換成談個人的工作效能的話,那就是個人的 To Do List 轉換到看板牆的作。

接下來;在描述半成品WIP的部分,借助了麥當勞的Drive Through取餐行為做了利特爾法則的第一次說明。然後談到看板方法處裡多工的方法,當然得責備一下「多工是不好的」Multitasking is evil,但是如何讓它更明確呢? 便是運用看板來清楚的區分工作渠道的方式。很快的進入「流程管理」的部分,目的在說明看板流程管理,追求平滑度,時效性,和良好的經濟成果,預測客戶的需求。

 .

策略4、5、6是三個較抽象的部分,需要一些實戰經驗才能體會,如果你沒有實作的經驗,就把他們拿來做指導原則即可。

策略4 :  讓規則明確 Make policies explicit

從三個方向淺談了一下制定規則方法: 工作方式、遵循限制半成品的限制及為服務層級協議SLA設定明確的規範。

策略5 : 落實回饋循環  Implement feedback loops

        由回饋的三個不同角色,說明它的內容:

  1. 來自團隊其他成員的回饋(這是普遍的團隊開發的浪費行為,始終忽略內部回櫃)。
  2. 來自接受你的工作人士的回饋。
  3. 來自客戶的回饋(外部回饋)。

策略6 : 由協作改善,經實驗演進 Improve collaboratively, evolve experimentally(using models and the scientific method)

        說明看板方法是「漸進式的變革」evolutionary and incremental,而非一般敏捷開發法的「小增量的反覆運算方式」iterative and incremental。

持續改善所依據的科學方法:「休哈特循環」(Plan-Do-Check-Action, PDCA),一個四步的循環,來自愛德華.戴明博士。

 .

第四章則是實作的開始,實作「看板牆

我們由實務開始,設計看板牆需要考量三個基本元素: 範圍(Scope)、工作項目粒度 (Granularity) 大小工作項目狀態(States)。如果你採用的是電子看板的話,制式的設計通常會提供一些模板讓你套用,容易讓人忽略了這三個基本元素。所以理想的做法是先用草稿的方式設計你的看板牆,隨後再去找類似的模板迅速的改成自己的設計。完全套用看板模板總是會讓人有所遺漏的。

.

》應該用白板還是電子看板,如果用雲端是未來一切運作的基礎去思考的話,則電子看板是必然的選項,實體的看板牆反倒成了可有可無的選項。但這裡我想強調的是,不要忽略了「溝通」的效果,最佳的溝通方式依然是面對面站在白板前面的溝通方式,這樣子的溝通效率是不容忽視的。

.

有趣的SCRUM運作模式下的看板牆設計

使用看板一定要在SCRUM的運作模式下嗎? 答案是不用。

看板方法可以適用在傳統開發法與敏捷開發法之下,運作起來二者並沒有太大的差異。但在書裏頭我則一直偏向敏捷式的開發方式,原因很單純,因為我教授SCRUM課程,所以刻意的加入了「SCRUM運作模式下的看板牆設計」這一節。希望對已經在實行SCRUM的團隊能有所幫助。

.

SCRUM是一個絕佳的軟體開發架構,但它一直忽略了工作板的效能設計,所以長期以來大部分團隊始終是「To-do、Doing、Done」的形式在運做著,不但沒有與實際的工作流程相吻合,也沒能協助改善效能。許多人士的一個遺漏重點;就是始終沒有去設定WIP的上限。沒有設限WIP值就等同於沒有實行看板方法(這是David J. Anderson所強調的。而大部分的Scrum Master也都知道半成品WIP是什麼? 但就是沒勇氣嘗試,別忘了SCRUM的價值觀: 專注、尊重、承諾、勇氣、開放、誠實、授權與合作。拿出勇氣來嘗試吧!)。

.

第五章個人看板 Personal Kanban: 類專案管理

個人看板則是使用在個人或是小團隊用來提升效能的開發過程工具(這句話出自個人看板創始者Jim Benson)。尤其是軟體界有太多一人專案存在了。他無需跟其他程式設計人員合作,整個專案就自己一個人從頭做到尾,這一章是為他們而寫的。所以才有類專案、類文件這種四不像的東西。

.

英雄再現」的時代 :  雲端運算對軟體開發的影響:「整合即是創造」

在雲端時代裡是一個「英雄再現」的時代。雲端的初期,諸事煩雜需要群策群力才足以建置這樣的雲端世界,但隨著雲端的逐漸發展成形,那些整體性的服務卻反而成為個人可以加以整合發揮的世界(我一度認為現在的軟體開發已經太複雜了,不太可能再有像早年的 DB3或是Clipper等一個人就做得出來的佳作,但雲端時代又有機會了),因此我常鼓勵年輕工程師,未來十年將是一個「英雄再現」的時代。

過去我上敏捷開發課程時,經常被問到「一個人的專案管理」該怎麼運作呢? 答案是,就交給「看板方法」了。

所以就提出了類專案(Similar Project Management)的概念。也就是架構出一個看似完整又不是那麼在意它是否完整的專案管理過程。而那個可有可無的文件製作就稱之為類文件。

 

» 是可以再多花些精神更仔細的來探討這個「一個人的專案管理」他是一種未來會逐漸增多而無法避免的趨勢,在雲端時代裡是「英雄再現」的時代。就交給下一版本再來做補充吧!

.

這一章的重點在個人看板上頭,一個簡潔的個人看板製作。個人看板製作步驟如下:

步驟一、視覺化

  1. 建立你個人的價值流程(To do list)。
  2. 建立你的工作事項卡片(別忘了編排一下它們的優先順序)。

步驟二、設定WIP限額

步驟三、開始運行拖拉系統的動作(管理看板)。

 .

第六章個人看板與生活讓生活與工作相得益彰(一個跟技術無關的章節)

談看板如何運用在個人身上。看板可以提升效能,不論是個人或是團隊或是企業。這一章純粹是為那些想提升個人工作效率的人士而寫的。在這一章裡面,沒有涉及任何開發方法純粹在談提升個人校能,由To do list 個人看板。強調的是「你想要的是什麼與你做了些什麼來達成它」。我參考了Jim Banson的分析作法。提出一些個自問:

透過個人看板的運作,你能看到:

  • 你想要的是什麼? (What you want)
  • 你做了些什麼? (What you do)
  • 你是怎麼做到的? (How you do it)
  • 你跟誰一起做的? (Who you do it with)
  • 你完成了些什麼? (What you complete)
  • 那些是你尚未完成的? (What you leave unfinished)
  • 你做事情的速度如何? (How quickly you do things)
  • 是什麼原因造成你的瓶頸? (What causes your bottlenecks)
  • 是什麼時候?為了什麼造成拖延. (When and why you procrastinate)
  • 是什麼事情會造成你著急. (When and why certain activities make you anxious)
  • 你能承諾些什麼? (What you can promise)
  • 什麼情形之下,你可以說不. (What you can say No to)

 .

第七章預測未來 : 減少變異性,增加可預測度(談看板的好處)

本章是獻給主管們的。在我們每天努力的工作中,即便在事前已經花了那麼多時間在開會、做計劃、討論及協調,但事情卻往往還是表現得差強人意,到底要怎麼做才能表現得更好呢? 採用看板方法;嘗試將豐田傳奇的成功經驗分享到軟體的運用上,可以嗎? 看板是製造業的東西;製造業是製作、組裝東西的,進行的是穩定不變的自動化製造鏈,而軟體開發卻是知識工作者的創意結晶,之間的差異實在太大了,我們該如何來調適呢? 這是試著採用休哈特的變異性理論,針對內部變異性: 使用者故事的工作粒度及工作項目的分類。以及外部變異性:需求的捕獲及急迫需求的處理。理論還待進一步生成,請先做參考了。

.

第八章、持續改進

人月神話

這一張圖(人月神話的封面)道盡了軟體40年來的緩慢成長。今年剛好是這本書40周年紀念,作者:佛瑞德.布魯克斯是IBM System/360系統之父。這張圖是當年的封面也是我第八章的封面,紀念一下偉人。隱喻的是沒有銀子彈的觀念,但一直到現在許多IT主管依然會犯這個錯誤。(哈哈!這一段的說明在第七章裏頭)

 .

» 其實;原本有〈 第九章雲端運算對軟體開發的影響 〉,但為了省紙張而拿掉了,其實是為了替讀者省錢拿掉的(跟這篇導讀為何不在書的前面,而反而出現在這裡是一樣的)。但請放心;過幾天會陸續在Blog上登出來的。

.

« 最後 »

.

  • 如果你是要拿來作為看板課程的教材使用,第二、三、四章就夠了(記得附錄也要參考一下)。

  • 如果純粹看精實Lean的話,則只有第一章有較仔細的描述(如果你採用看板之父的書來上課的話,對精實Lean這部份我的書就可以變成補充教材了)。

  • 沒有開發經驗的人請看第六章,裏頭完全沒有軟體開發的影子。

  • 主管請參考一、七及八章,這幾章是專門為管理人員所寫的章節。

 .

對精實理論而言;我講少了,也談得太簡單了,他可以是齊家治國平天下的東西,我卻只把它描述成看板方法做抉擇時的依據(真是該罵)。待下回改進!

.

全書的結構如下:

撰寫章節的時候,我是運用 FeatureMap 的 user story mapping 工具先行架構全書的章節的,就是下面這張圖。需要的讀者,把你的 email 給我,我會寄邀請給你,然後你便可以在網路上看到圖稿了。Featuremap工具在二個 Mapping 圖示以下是免費的,也可以將圖稿匯出來變成 image 檔(下面這一張圖就是這樣匯出來的),它是我上 Scrum 及 Kanban 課程時必備的工具之一,可以安心使用。

.

書的結構

.

廣告一下 我的看板課程,通常每二、三個月會開一次課程。這一回二本書都將提供,一本是我的新書(精實開發與看板方法)另一本是David J. Anderson的看板方法Blue print. 剛好拿來來比較一下效果如何?!

cc

.

Written by ruddyllee

2015 年 04 月 06 日 at 11:26:36

看板方法第一個基本原則 : 從既有的流程開始 Start with existing process

leave a comment »

看板方法能夠迅速崛起的最大要素,可能要歸功於這個第一原則了。

從既有的流程開始  Start with existing process

這個原則的目的是: 透過優化現有的過程來驅動改革。但這樣做就能保證會成功了嗎? 下面是實際做的時候的致勝訣竅。

※ 我們用一個例子來做說明。

首先假設你正在準備一場演講,這是一個50分鐘的演示,而你想在5鐘內就能迅速擄獲觀眾傾聽的心靈,請問要如何開始呢?

.

訣竅是從「認同」開始

你必須先取得聽眾的認同。OK! 5分鐘過了,你怎麼知道已經取得觀眾的認同了呢? 對演講而言,聽眾的眼神跟頻繁的點頭可能是最基礎的認同了,演講者在侃侃說明主題的時候就可以很容易的觀察到聽眾的反應,觀眾的眼神跟點頭正是告訴講者你得到基礎的認同了。(一種公認最佳、最快速取得聽眾認同的演講內容,便是講故事: 一個3分鐘的故事,可能是取得觀眾認同最快的方法。)

.

是講者也是聽眾

接著呢? 試著讓自己由主觀的第一人稱的演講者,走向客觀與聽眾成為相同的第三人稱。

讓聽眾感受到你跟他們站在同一陣線上,而你的任務是來協助他們盡快理解這個主題。協助與理解」是這個階段的主要目的。當聽眾意識到演講者是來協助自己理解這個主題時,戒心與防線就會大大的降低下來,所謂的"喝倒采"與"不以為然"的表情也會消失殆盡,你會發覺講者與聽眾已經站在同一陣線上了(當你聽見台下聽眾不經意地發出一些認同的聲音,例如:喔~原來如此! 便是了)。

.

愉快的共同合作與改善

然後呢? 用聽眾的掌聲來確定你們合作的默契,並盡可能讓聽眾吸收到最重要的資訊,這便是講者最後的責任了,就是繼續努力的改善聽眾的接受度。你的多一分努力聽者可以清楚的感覺到學習的愉悅,這就是了。(與主題有關的笑話可能是快速得到愉悅學習的最佳方法。)

這個例子跟第一個原則有甚麼關係呢?

上面的例子演示了成功演講的三部曲:

  • 取得認同。

  • 同一陣線的相互協助、增強理解。

  • 愉快的共同合作、持續改善學習效果。

「從既有的流程開始」,代表的是由認同走到協助與理解。先用肯定的方式:  認同既有的工作流程就是對原來團隊的付出予以肯定。肯定對方的貢獻可以降低在角色上的對立關係。 有了認同跟肯定再進一步才能夠產生合作與改善的關係,也就是不分你我大家一起來從事改革的工作。接著要讓團隊看得到可以改進的地方,並願意主動去從事改善的工作。就是這樣的過程讓大家很容易的去接受看板方法,進而能在阻力最小的情況下實施改革。

.

說穿了訣竅就是 Understanding。 當聽眾與演講者之間沒有間隙,當開發團隊與改革者之間站在同一陣線,接下來才有可能同心協力一起追求持續改善了。

.

(參考: Kanban from the Inside,Understanding很難只用一個字來翻譯它: 理解,懂得,熟知,通曉,獲知或是 諒解 )

Written by ruddyllee

2014 年 11 月 19 日 at 12:36:45

看板方法: Lean Coffee

with one comment

Lean coffee 精實咖啡

老闆! 來杯精實咖啡…  開會了!

Lean Coffee(tm) is a trademark of Modus Cooperandi. We wanted to protect the name, so other’s didn’t mess with it. ( limitedwipsociety 也是 lean coffee的一支),他屬於一種小組形式的 Personal Kanban,目標在進行集體討論的互動學習

IMG_20141105_091920

一種隨興又民主的小組討論會議

隨興的討論,運用簡單的看板(就貼在桌上,三個垂直欄位: 討論題目進行討論完畢),參與的人員個自提出有興趣的題目,然後每人兩票,票選出讓大家最想討論的主題,然後依優先順序開始快速的發言討論,限時5~8鐘的一個主題討論,小組隨時可以進行是否繼續討論的表決(以簡單的舉拇指手勢,向上表示繼續,向下表示結束,平舉表示沒意見)。完全民主的自由式討論,目的在追求LEAN。對時間也沒有特別的規定,大家覺得OK就繼續。小組以4~6人為佳。

隨興又具有高效能的討論方式

充分展現程式設計人員自主的個性和隨興的作風,十分適合自我管理團隊的運作,只要有人發起有人認同,短時間的溝通闡述Lean 的作為。太有價值了! 基本上非常適合看板方法的會後會可以採用的方式。二個非常基本的網站可供參考: http://leancoffee.org/  。 有興趣的人可以去逛逛。接著來說明一下執行的步驟:(這二個團隊都沒有強制的規範,非常符合他的精神,我個人非常喜歡,下面就盡可能簡單的說一下,大家隨興囉!)

步驟一、以下面的個人看板做開始 Personal Kanban

IMG_20141101_093814

 

找個桌子把它貼上去。有三個垂直欄位: 討論題目、進行討論、討論完畢。他們是用來描述討論的流程。

步驟二、產出討論題目 What to Discuss

IMG_20141101_094800

每個人都可以提出要討論的題目。把它寫在貼紙上,貼到” 討論題目”的欄位內。
接著進行簡單的表決,只要有二票以上的題目,就把他排到較高的優先順序,然後啟動計時5~8mins,開始進行第一輪的討論。

(貼紙、筆、計時手機 … coffee or tea?  夠了,這樣就夠了,但請把熱情帶來。)

步驟三、討論及投票 Vote and Talk

IMG_20141105_093459

每當討論告一段落就來進行一次數拇指的表決,表決結果向上數目大於或等於向下數目時就繼續討論,否則就開始切換下一個主題。

當時間到時,也是由表決的方式決定是繼續還是結束。

ok

隨興又民主的小組討論會議,參與人的心情決定一切,哈哈! 我在上《 看板方法的課程 》時會不斷的運用這種方式進行集體學習,這裡有一段影片可以欣賞。(時間的長短只要適當就好,無需太堅持,有熱情才是重點。)

好棒的手法,還記得團隊自我管理時需要制定一種"簡單的規範"讓大家有所依序嗎?這就是了。好記、好做、又有效率,這一點跟 SCRUM 的站立會議一樣有效又迷人!  推薦給大家。(下面這張圖就更仔細了! 從 UC Berkeley 來的說明)

lean coffee

原文說明:

lean coffee

.

上面的二張圖片是在上"看板方法"的課程時所拍下來的,目的是讓學員拿來做課後複習用的,大家把上課時最感興趣的專有名詞或理論拿出來討論、交換意見。講師則可以拿來當作學員們上課時的回饋。效果好極了!

但真不知道 Lean Coffee 運用在真正的大學生的學習上會有用嗎?! 找個機會來試一試。

下圖是課堂上採用的說明步驟:

18

lean coffee_1

Amadeus 亞瑪迪斯 進行 Lean Coffee

.

Written by ruddyllee

2014 年 11 月 01 日 at 10:19:14

看板方法: 持續修正系統的方法 — TOC 限制理論

with one comment

限制理論 Theory of constraints TOC,高德拉特  Eliyahu M. Goldratt

高德拉特(以色列物理學家)

高德拉特(以色列物理學家)

目標是解決問題並持續改善

從小到大我們就一直學習著要如何解題,考試;就是一個又一個的問題,想到就會讓人又討厭又害怕,擔心的當然是結果會讓人受逞罰,所以除了老師以外可能根本沒人愛考試。一直到畢業以後我們才知道這些只是練習而已,讓我們學習如何去解決更複雜更難的問題的簡單練習。「限制理論」是高德拉特想出來解決系統問題的方法。他的解題步驟是(Five Focusing Steps,五步聚焦法):

步驟一、找出系統的瓶頸。

步驟二、決定如何利用瓶頸。

步驟三、根據上述的決定,調整其他的一切。

步驟四、把系統的的瓶頸鬆綁。(就是解決它)

步驟五、假如步驟四打破了系統原有的瓶頸,那麼就回到步驟一。

(如果你正在看"目標"這本書的話,它是用小說的方式來說明理論,請耐心把它看完,上面這段步驟在第36回…)

這樣簡單的步驟有效嗎? 實話實說,還真有效!  在解釋何謂"限制"之前,先跟大家分享一下自己使用的例子: 偵錯五步驟!

偵錯也是一種解題的過程。當我們收到使用者找到缺陷Bug的回報時,第一步、先找出重現系統Bug的步驟或方法。第二步、最大化Bug來確認它的邊界限制。第三步、由邊界限制的狀態設法解決它。第四步、確認Bug解決之後,沒有造成其他的影響(產生其他的Bug)。步驟五、持續修正其它問題。

哈哈! 你也是這麼解題的嗎! 這不是巧合,而是一種思維,針對複雜的系統,千頭萬緒,你該從哪裡下手呢? 自然很直覺的問下列三個問題:

  1. 什麼需要改變?(What to change?):首要之務就是找到阻礙其達到更高的績效的限制或核心問題。然後把他弄清楚了。

  2. 改變成什麼?(What to change to?):針對上述之核心問題,尋找解決方案,希望能夠真正達到消除阻礙,讓系統達到高績效。

  3. 如何產生變動?(How to cause the change?):當找到解決方案後則必需進一步分析其障礙為何,並轉換成實施步驟讓大家都弄清楚了,以期順利推行變動。

TOC 直覺架構

限制理論的直覺架構

「限制」是甚麼?

它是在一個系統中,為了要達到他的目標,所遭遇到的障礙,稱之為限制 Constraints。也就是說任何一個會妨礙系統達到更高績效目標的要件或因素。都可稱之為「限制」。

高德拉特以為;任何一個系統,不管是實體的,如機器中心、物料的缺乏,或是管理方面的,如策略或程序等,皆有限制存在。如果沒有其限制,則此系統的產出或績效將會無窮大,不過在真實社會中這是不可能的。而限制理論 TOC 是一種管理的科學,它是一種應用在科學的方法,一種物理學的方法,適用在一般生活上問題的管理。看板方法之父 David J. Anderson 則把它拿來運用在軟體的開發上,而成為了看板方法實踐持續改善流程的理論基礎之一。他的說明如下:

五步聚焦法 Five Focusing Steps 是一種創建持續改善過程的簡單方法:

  1. 識別(identify) 限制。

  2. 做出決定,以最大化利用(exploit) 限制。

  3. 使系統中的其餘我有部分都服從於(subordinate)在第二步中所做出的決定。

  4. 突破(elevate) 限制。

  5. 避免惰性;識別下一個限制,再持續到第二步。

步驟說明:

第一步、就是要求我們找到價值流中的瓶頸。

第二步、要求我們找出瓶頸潛在的最大產出,並和實際現況做比較(自問一下;該採取甚麼措施讓瓶頸的能力可以發揮出來)。

第三步、要求我們做出必要的改變,來完成第二步。

第四步、針對已經改善的瓶頸再進行強化,讓他充分的高效產出,以達到持續改善。此時瓶頸的限制應該已經轉移到價值流的其他地方去了。

第五步、則是等待改進的狀況穩定下來之後,再重複整個過程,用以打造一個可以持續改善的系統。

這些原則談起來,還是很抽象,採用案例說明的方式可能會好一些,下回再說。

Written by ruddyllee

2014 年 10 月 26 日 at 15:42:24

看板方法: 四個基本原則 Four Foundational Principles

leave a comment »

 

看板方法 Kanban Method 定義:

看板是一種改變管理方針的途徑。它不是軟體發展、專案管理的生命週期或者流程。它是給現有的軟體發展生命週期或者專案管理方法中引入變化的途徑。

Is an approach to incremental, evolutionary process and systems change for organizations.

看板是一種透過漸進、演化過程來改變組織系統的方法。

David J. Anderson

看板的本质是一個很單純的想法,那就是半成品(work-in-progress,WIP)必须被限制。 

David J. Anderson

 

所以我們可以簡單的描述"看板方法" 為WIP約束系統。

 

.

想要實施看板方法或進一步了解看板方法,請依照這四個原則去思考:

四個基本原則(Foundational Principles):

原則1 : 從既有的流程開始 (Start with existing process)

目的是;透過優化現有的過程來驅動改革。因為這樣做一方面所承受的阻力較小,另一方面又容易看到成果。如果今天負責推動改革的人是我們,你會怎麼做呢? 或許你會先擬定好改革的步驟,然後按部就班的實行他。但是經驗豐富的 David J. Anderson 卻選擇先找出改革最大的阻力是甚麼? 就從這裡開始。

改革最大的阻力是人,因此他將啟動看板方法的關鍵放在變化要越少越好。他說:「你必須要抵制住改變工作流程、職位名稱、角色及職責,以及當前在用的具體實踐的誘惑。不要試圖去改變這些。要改的是半成品(WIP)的數量、與上下游的接口及互動的方式。」而那就是把現有的價值流程圖畫出來,不要試圖去改變它或重新發明一種理想的新過程。

 

原則2 : 同意繼續增量,漸進的變化 (Agree to pursue incremental, evolutionary change)

因為前提是在阻力最小的清況下做變革,因此不做較巨大的變化,依循敏捷開發小量遞增的精神,讓所有成員同意處於小阻力之下進行變革。

 

原則3 : 尊重當前的流程、角色、職責和頭銜 (Respect the current process, roles, responsibilities and titles)

對於現有的流程、角色、職責和頭銜應該給予肯定,避免去做太大的改變。目的是能夠順利的推行看板方法,讓原本的組織能夠在微量變化之下,開始接受看板方法。

 

※ 前面三個原則在提醒你避開人為的阻力,目的是讓看板方法能夠順利展開。避免在還沒進行改革之前就先遭遇到阻力。

原則4 : 鼓勵各級在實務上的領導行為 (Leadership at all levels)

應該關注的重點在大家是否能夠對現有工作流程具有持續改善的精神,才是最重要的事了。這個原則在強調推行看板方法並沒有特定的領導人,能由各個階層真正去了解看板方法,並自動出來擔任領導的角色,這才是領導人物最好的選擇。

 

 

四個基本原則Four Foundational Principles的意義

這四個基本原則的最大意義在追求一個好的開始,前三個原則在提醒你避開人為的阻力,第四個原則責告訴你,讓對現有工作有改進熱情的人浮現出來 ,讓團隊自己能夠過審視自己現有的工作流程,並找出哪裡可以改進的地方,經過討論後能夠改善缺點變得更好。他想說的是: 請正視你現有的流程,在團隊和諧的情境下,透過改善讓它的價值可以凸顯出來。

Written by ruddyllee

2014 年 10 月 09 日 at 17:19:28

看板方法: 科技企業漸進變革成功之道

with 30 comments

book_0

今天要介紹看板方法的由來, 上面這本書是由看板方法之父 David J. Anderson 於: 2010年 4月所著。簡字版是 2014 年2月出版。這篇文章在我上 TechDays 課程時就想登出來了,想把好書介紹給大家。但由於台灣的書商都沒有進口,所以一直等到我拿到第一批書後,肯定大家可以在坊間買到書時才把他登出來。原文書名: Kanban: Successful Evolutionary Change for Your Technology Business.

看板方法

它是敏捷陣營中實施起來阻力最小,生產力又能大幅提升、前置時間大幅下降,而可預測性又絕佳的敏捷解決方案之一。好神奇喔 … 哈哈! 確實如此,所以我才會這麼急切的推薦給大家。另一個原因是Kanban Method 現在在美國正熱烈風行中,而我們現在開始追正是時候。為此放下了許多手上正在做的工作(包括一本 Scrum的教本),努力開始推廣希望大家能受用。首先說明: 為何他推廣起來阻力最小?

※ 實施起來阻力最小:

因為David J. Anderson 本身是一個微軟的 PM出身,他跟大家一樣知道變革會讓許多人害怕,人們會認為自己的技術是否落伍了,開始擔心害怕變革會對自己的工作事業帶來不利,這種恐懼常常會帶來一種莫名的對立,因此在還沒開始變革之前就已經採取抵制的態度了。所以他創始的看板方法選擇從哪裡開始實施呢? 就從現在既有的流程開始。由工作者本身最熟悉的地方開始。起步的秘訣是甚麼呢? 是精實精神中從豐田系統中學來的原則,先從不浪費開始,作法: 在識別浪費後消除浪費

※ 如何能讓生產力大幅提升?

由審視既有流程,依據 Little’s law的最大產出方法,接著找出阻礙最大產能的瓶頸所在,然後正視這個造成瓶頸的問題,把它顯現在看板上面,讓大家一起站在看板前面討論如何解決它,解決之後再持續進行改善的作業。

※ 前置時間大幅下降

過去我們都以為唯有透過良好的規劃及配合才能夠讓前置作業時間下降,但豐田企業的及時(Just In Time)備料讓庫存降至最低,讓半成品減至最少改變了工作流程的前置時間(Lead time),因此得到大幅下降。

看板還是看板方法 (Kanban or Kanban Method)

英文叫 Kanban,上網去搜尋會得到一大堆有關製造業的看板資料。所以請使用 Kanban Method去搜尋,因此中文就該叫做「看板方法」。簡體版的作者有用心在翻譯因此翻對了,值得買來閱讀。全書分成四部分:

※ 第一部分;導讀:  作者說出他的想法,以及創作看板方法的原由。

※ 第二部分;談使用看板方法的好處:  這裡有他個人做顧問時的經驗談,值得仔細閱讀。

※ 第三部分;開始談實施看板方法的步驟了。(由六到十五章,好長又夠完整)

※ 第四部分;談持續改進。在這裡你終於可以感受到精實軟體開發對作者的影響,以及作者由經濟學的角度來看精實軟體開發的第一原則: 消除浪費

接下來我就不在多說了,請讀者自己去看吧!(透漏一下,為了共襄盛舉,我正在寫一本有關精實開發的書,內容除了看板方法之外會大幅談到精實軟體開發,在這裡不想打廣告,因此書名就等出版後再說了!)

Written by ruddyllee

2014 年 09 月 30 日 at 15:09:20