Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 十一月 2014

one day in kanban land 中文版

with 8 comments

 

中文版的看板一日遊(原文,請參考: Henrik Kniberg’s Blog)

1-34-61

7-9

d12_4 

廣告

Written by ruddyllee

2014 年 11 月 27 日 at 13:29:32

Scrum 捷徑: 敏捷測略、工具與技巧

leave a comment »

這本書跟它的書名不符,它所講得不是捷徑,而是確確實實的「敏捷測略、工具與技巧」。

23567348-1_u_1

這是一本不管你是否有執行過Scrum經驗的人,都值得去閱讀的書。作者是: Ilan Goldstein,這是他的第一本著作,但讓人羨慕的是幾乎所有寫過Scrum 書籍的暢銷作家都替他寫序了。包括: Mike Cohn、Kenny Rubin、Ron Jeffries、Lisa Crispin …,我的天啊! 讓人瞬間以為Scrum 的圈子好小好小喔! 這些傢伙的書都陳列在我的書架上,而且大部分都不只一本。老實說每一本都是經典,值得一再的閱讀。而他們竟然都願意幫這個年輕人背書,由此可見本書的價值。當然是非讀不可了!

一開始沒有打動我

我必須承認,書的第一章並沒有打動我繼續閱讀下去的慾望。我把它放下來了,放在床頭;因此我只要伸手就可拿回來繼續閱讀,但老實說「捷徑」這二個字並不討喜(或許是 Scrum But 給人的警惕),因此就放了好一陣子,一直到有一天我在找需求設計的相關資料時,順手翻了一下,在第四章、需求的細化裡,找到捷徑10:結構化故事細讀之下才恍然大悟,這裡頭寫的都是經驗, 一些整理消化過的經驗。感覺上作者好像是經過了這樣的挫折之後,他就把再次遇到時該如何處裡的方法寫下來了。整本書讀起來就是這個樣子,讓我好想把他立刻推薦給那些正在 Scrum 裏頭努力奮戰的人士。相信有了這本書至少讓你可以少犯些錯、少走不少冤枉路。

( 三個層次 Epic – User story – Task,

任務切片、切割,

技術故事 和 軟體錯誤)

第九章、估算

這一章裡包含: 捷徑13:關於估算那些事兒、 捷徑14:規劃卜克細則、捷徑15:轉向相對估算。有好幾個地方都讓人有英雄所見略同的感覺,這一點可見作者的功力不凡。可惜的是他總共只談了30個捷徑,喔!真是太少了,但已經寫了202千字。好吧! 也夠了。

.

(捷徑30: 終極捷徑,第一句是 “Scrum 困難而具破壞性",你有這種感覺嗎?)

.

推倒重來

書的結尾;讓我聯想到《簡約之美》這本書,他談到"推倒重來"的理念。很多設計師面對複雜的系統設計時,經常會選擇推倒重來的決策。因為擔心會設計出不容易維護的系統,而寧可選擇多花些時間重新來過。其實;重新寫過並不是最好的抉擇,要設計成能夠持續改善的系統才是最佳的抉擇。

.

Written by ruddyllee

2014 年 11 月 24 日 at 01:04:03

看板方法第一個基本原則 : 從既有的流程開始 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

再談 Scrum But

leave a comment »

為何再談 Scrum But 呢?

雖然只是一個反面的字眼,但實在有它的重要性存在! 如果再給我一次顧問相同團隊的機會,我一定不會讓他們把 Scrum But 當成只是拿來博君一笑的不重要話題,因為"檢討“在我們累積經驗的過程中佔著重要的比例。 下面有一些自我提醒,團隊可以拿來檢討及測試自己 Scrum But 的程度,非常適合 Scrum 團隊拿來做自我檢視時採用,請參考:

(無招勝有招。你所遭遇到的情況可能跟下面所說的不見得相同,所以這些個教條僅供參考)

 

※ 如果在站立會議的時候,團隊成員分別向 ScrumMaster 報告自己的狀態,請留意貴團隊執行的可能是 Scrum But.

在 Scrum中,團隊不是為 ScrumMaster在工作;相反的ScrumMaster是為團隊工作。

好的Scrum Master會立刻提醒團隊應該向大家報告才是,

但也會默默記住那些人需要做敏捷程度的提升。

※ 如果你的開發人員不斷超越測試人員的進度,你可能是 Scrum But.

在一個 Sprint中,團隊自我管理並對工作共同負責,讓他們相互超越是正向的競爭

會提升戰力,但只有在流程順暢協調下

才能在短時間內達成任務。

※ 如果你的開發團隊沒有進行應該有的文件製作,甚至缺少文件製作,你可能是 Scrum But.

很多人誤解 Scrum甚至認為敏捷開發是不用製作文件的,這是嚴重的誤解,

請參考一下《 實例化需求》

※ 如果你的 Sprint Demo 會議失敗了,你可能是 Scrum But.

 雖然失敗乃兵家常事,團隊不可能每次demo都成功的不得了,

但ScrumMaster的職責就是要協助團隊盡早發現問題

避免這種在客戶面前的失敗。

※ 如果你的團隊成員都不敢嘗試新的想法,因為他們害怕可能會失敗,你可能是 Scrum But.

程式設計本來就是一種經驗主義,在嘗試與失敗中成長是在所難免的。

失敗是累積經驗的必經過程。

 ※ 如果你的回顧會議開成了對人不對事的情形,你可能是 Scrum But.

回顧會議應該著眼於你的工作以及團隊如何在一起協同合作的方式,

要經常思考如何善用工具它來達成你的任務才是。

※ 如果你堅持先將所有的使用者需求都先詳細的定義清楚,再來開始你的第一個Sprint,你可能是 Scrum But.

傳統的開發方式總是習慣把需求都搞清楚了才開工,

但現在的開發團隊都知道需求必須隨著市場的異動而改變,

只是有些老闆或主管還是有這種不知道是該稱讚還是該罵的習慣。

※ 如果你經常堅持於維持原來的發布計劃而不做變通,你可能是 Scrum But.

Scrum 是一種經驗主義,有很多時候我們會以一種嘗試看看的心態來進行開發作業,

所以變通是一種不可或缺的屬性。

※ 如果你將數據指標看得比表現得優異更重的話,你可能是 Scrum But.

在執行Scrum的時候我們經常可以收集到許多的數據,不論是burndown 或是

CFD圖都有著大量的數據可以做參考,但請務必堅守它只是做參考的原則。

※ 如果你凡事都要通過管理階層來做決定的話,你可能是 Scrum But.

Scrum 團隊必須是一個能夠自我管理的團隊,

也只有經由這種自我管理所產生的責任感才可能,

才能讓團隊進取而主動。

※ 如果你依據成員的角色,主動指派工做事項給團隊的成員,你可能是 Scrum But.

Scrum 的團隊是自我組織的,團隊成員會因為他們有能力這麼做,

而自動做出貢獻,不應該由任何人所指派。

※ 如果您對 Scrum團隊教條式的使用以上所列的這些個項目來制定規則的話,你可能是 Scrum But.

敏捷的有效來自於遵循它的原則,而 Scrum則是關於實施這些原則的精實框架。

上面所列出來的項目只是用來強調這些原則用的。拿來當作規則,

強制採用它,就完全不符合敏捷的精神了。

只有持續追求改善才是最佳做法。

唯有堅守目標、持續改進,才能發揮Scrum克服複雜專案的功能

我們很難做到百分之百的 Scrum 開發,或許做到七成或許是八成,但這不是重點,真正最重要的是持續改進

Scrum 團隊的一個共同目標是,讓整個團隊在 Sprint之內完成所承諾要完成的工作項目。也就是;採用漸進式累積的方式來完成任務,不是一次決生死的傳統、都預先計畫好了的工作方式。我們都曉得寫程式是一種學習的過程,而團隊開發本身也是一種團隊的學習模式,必需透過不斷的演進讓團隊越做越好,越能適應專案的變化,就越能提供給客戶市場上真正的需求。

(參考自 You May Be a Scrum-But )

Written by ruddyllee

2014 年 11 月 15 日 at 21:16:24

張貼於未分類

Tagged with

Scrum But …

leave a comment »

如果你在執行Scrum 但却因為某些因素而必須放棄或違背部份 Scrum 的準則時,就稱之為: Scrum but.

(Scrum 的發明人之一Ken Schwaber 的說法是: Scrum … but…, 他同時在 scrum.org 網站上談到如何處理這種情況。)

反對者: 敏捷開發堅持不要 Scrum but
當開發團隊採用一種來"半套的方式“,不去採用敏捷開發法的一些準則,則結果非常可能是得不到敏捷的效果,反而造成專案開發失敗是很有可能的事情。因此呼籲想要採用敏捷開發的團隊,一旦你決定採用某種開發法時(例如: Scrum)就請務必依照他的準則來實行,否則很容易招致失敗。這並不是該方法無效,而是你沒有按步就班的去執行它,自然就容易失敗了(聽起來好像蠻合情合理的)。

※ 這是一個充滿爭議的話題!如果一定要按步就班的堅守原則的話,又好像違背了敏捷的初衷? 失去敏捷所謂的高適應性了。(透明化、檢驗、適應性是 Scrum 的三個支柱 Three pillars)

 .

因此有了另一派說詞的誕生

實在是因為某種原因,促使我們必須放棄某些有用的角色、規範或方法。而尋求其他的解決之道,當然,有時候只是一種短暫的措施,隨後會盡快的回復到正常的開發方式。所以就有了:

ScrumBut 的專有語法:  

(ScrumBut)  (Reason)  (Workaround)

範例:

»  (We use Scrum, but)  (having a Daily Scrum every day is too much overhead,)  (so we only have one per week.)

»  (我們使用Scrum,但是) (回顧會議實在太浪費時間了,) (所以我們每二個Sprint 才會進行一次。)

»  (我們使用Scrum,但是) (我們的功能實在太大需要較多的開發時間來建立,) (所以我們每個Sprint 長達六周。)

 »  (我們使用Scrum,但是) (我們的專案實在太大需要很多的開發人員,) (所以我們有一個20人的Scrum團隊。)

.

我們使用 Scrum,也修改了Scrum (ScrumButs and Modifying Scrum)

Scrum.org 是少數敏捷開發法中願意主動來面對這個充滿爭議的論點。

由大處著眼來看待他的話;由於軟體開發沒有銀子彈存在,因此也當然沒有放諸四海皆準的開發方法,對於個別的軟體開發方法,實在沒有必要削足適履勉強照單全收的道理。

由小處著手來看待他的話;每一種軟體開發方法都有他一定的組成元素與架構,務必要相互搭配才會有它的效益產生,任意去改變組合當然會壞了他的效用,若是因此而招致失敗,自然不在話下。

.

敏捷開發是經驗主義

所謂的經驗主義也就是依照所觀察到的現象來做為分析的依據。 必須通過實驗研究而後才去進行理論推導。因此經驗在這裡就顯得十分的可貴,這也正是所有的敏捷開發法幾乎都做持續改進的原因,因為他們都是從一次又一次的過程中得到回饋,再來進行修正吸取經驗,然後再以此為依據進行持續改善的。

所以每做一次便可以得到一次的經驗,以這個觀點來看上面的爭執,便可以發現其實二者沒有太大的差別,只要「做一次便知道了」,重點是要會吸取經驗再做修正。當遇到非改不可的情境時,就改一次來試試看啊! 結果自然會告訴我們是對與錯。然後再來修正就是了。若是不敢嘗試才是不敏捷的做法。但若是遇到不能反覆的環境怎麼辦呢? 遇到只能嘗試一次的情境時,怎麼辦呢! 我會建議先對環境做出改變,讓他具有執行敏捷開發的基礎再來嘗試吧!

小規模的漸進式改善模式,一直是敏捷開發藉以取得回饋再作改進的方法(也是一種機會),是基於勇敢果決的精神,用來迅速累積經驗的做法。說得簡單了,如果你還有疑惑的話,請參考 Mike Cohn 的《 Scrum 敏捷軟件開發》,類似的敏捷觀念充徹全書。是我每次遇到瓶頸時就去翻閱的圖書,推薦給大家。

.

持續追求

在教室之外,便要面臨真實世界的挑戰,理論跟實際要做起來還真不是那麼回事兒。有空的時候,去執行一下 ScrumButt 的測試,他會在結尾時給你一個分數,然後告訴你平均值是 51分,請你參考。Run個二、三回試試看你能拿到幾分,分數的意義當然不大,但一旁的百分比才比較有意義,他透露出來一般的平均值,試著看看字自己在哪一個區間,回顧一下,還挺有意思的。

scrumButt

.

這種測試當然不會很準確,但我們都知道它的意義,就是要提醒我們去持續追求理想。

.

Written by ruddyllee

2014 年 11 月 11 日 at 18:09:48

張貼於未分類

Tagged with

先學 Scrum還是 Kanban?

leave a comment »

先學寫程式還是先學測試?

對於初學者或新人而言由測試開始是再好不過的了。

一旦寫程式的功力夠了,製造缺陷的機率自然會下降些,這個時候再來寫程式,才不會害己害人。

原因很簡單;因為缺陷是程式沒寫好所造成的,所以要學寫好程式,先學如何測試別人的程式,先看懂別人的程式,再來嘗試寫好程式,似乎會好一些!

.

先學 Scrum還是 Kanban?

大部份的時候;你可能完全沒有選擇的餘地,這可不是老天能安排的,而是看老闆的安排。

從屬性上來看:

Scrum 容易探討未知,處理複雜專案,拿來開發新東西威力無比。

Kanban 是教我們如何自我檢討,可以迅速消除浪費,而得到好的效能。

如果你是開發團隊,當然是先從Kanban 開始。先檢討好團隊的基本動作,整頓好了再來開始作新的東西,從事開發的動作,自然少浪費。這是精實Lean 的好處。

(有太多開發團隊,只曉得一意往前衝刺,忽略了自己在開發上的浪費,這會造成很難走得久遠,尤其是Startup的團隊尤其如是。)

如果你是維護團隊,當然是先從Kanban 開始。視覺化是最大的亮點,團隊可以看見工作上的維護流程是一件相當有價值的事,針對個人亦是如此,人們常常因為養成習慣了,就一直持續做同樣的事情,很少會有機會回過頭來檢討,哪裡做得浪費了應該改進。看板方法的第一步: 視覺化。正是團隊可以拿來持續改進的基礎。這一點對維護工做更顯得珍貴。

如果你是測試團隊,當然是先從Kanban 開始。看的見以後才可以減少猜測的比例。測試團隊在擬定測試計畫之前,一定要對待測的產品或程式有足夠的了解,才可能開出實用的測試案例,不至於浪費大量的測試資源。或做了過多的重複性測試。

.

(你可能覺得奇怪,為什麼都是 Kanban Method 先行呢? 其實原因很簡單,因為它"單純“,不是簡單喔! 它沒有想像上的簡單,因為它可以演進得很有深度,但是它的目的很單純,就是追求效能。不像 Scrum 的目的,是要來應付複雜的專案開作業,基本的方向就完全不一樣的)

.

將看板方法融入Scrum的開發過程才是上策

看板方法是一種流程控制,他不是一種具有完備基礎的方法學,雖然他的潛在發展相當可觀,但目前他仍只是一種提供我們產出高效能的流程控制法而已。他缺少需求描述、沒有完備的會議規畫、少了團隊職責分配,少了很多很多軟體開發上該有的措施,這一點讓他看起來十分空泛,但就是這個特性也讓他十分適合融入其它開法方法中,尤其是 Scrum。

看板方法之父 David J. Anderson 是在Microsoft 公司推行敏捷開發法 Scrum 的時候發明看板方法的。他原本的目的只是要求能夠在最少阻力之下順利在組職中推行敏捷式的開發法而已。卻由於他熟悉限制理論的運作而開創了看板方法Kanban Method。做出了對敏捷開發的精實Lean 一支的重大貢獻。也就是這樣的典故,讓看板方法Kanban Method可以十分容易的融入到Scrum的開發過程。

著名的《 Essential Scrum 》 的作者Kenneth S. Rubin(它是2013年Amazon 敏捷理論最暢銷書),書中就大量的採用 WIP(Work-In-Process)的觀念,實際的運用在工作看板上面。讓Scrum在開發流程上減少了許多的浪費現象。

 .

※ 看板方法先行

因為它可以減少組職在推行敏捷上的阻力,它能讓工程師以最好的節奏持續進行開發工作。又能將精實觀念帶入團隊運作。

※ 融入Scrum的開發過程

因為看板方法的流程控制方式是用來提升Scrum運行迭代開發時的效能。讓 Scrum 能真正用來克服複雜的軟體程式開發過程。

.

Scrum 的目的在解決複雜的軟體開發作業

許多人誤把Scrum 當成加速軟體開發的銀子彈。這是錯的! 他的目的不在加速開發(加速開發工作是開發工具的廣告詞),它的目的是在解決複雜的軟體開發作業,讓它提高成功率。在協助團隊能夠提供給客戶真正要的產品,且讓他在市場上具有實際的競爭力。這一點也正好是看板方法所缺少的。

開發團隊千萬別因為實施了看板方法而誤以為需要把 Scrum 拋棄了,這是一種錯誤的想法,讓他們相輔相成才能有更大的效益。下一回就來談"運用看板方法的十個不應該放棄 Scrum的理由"。

.

測試難還是寫程式難

讓我們回到一開始的主題,到底是測試難還是寫程式難? 其實正確的說法應該是寫出正確無缺陷的程式難! 實際上程式設計人員在寫出程式之後,也必須透過測試,才知道他是否能正確運行。因此"寫跟測"實質上是一體的二面,一樣重要。

至於Scrum 與 Kanban Method 之間,則都是通往敏捷開發的路徑。已經在使用 Scrum 作開發工作的人士,學習 Kanban Method 可以讓他們進入精實的領域,有所依據的持續追求更好的效能。先學會Kanban Method 再跨足 Scrum 的人呢? 則可以看到敏捷開發在處理複雜問題上的具體方法,真正懂得去追求效能之外的正確性與方向。

先學 Scrum還是 Kanban? 二者之間並沒有衝突存在,端看你現在最需要的是那一樣,那一樣就先來吧!

Written by ruddyllee

2014 年 11 月 10 日 at 14:46:40

張貼於未分類

Tagged with , ,

看板方法: Lean Coffee

leave a 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/http://limitedwipsociety.ning.com/page/lean-coffee。 有興趣的人可以去逛逛。接著來說明一下執行的步驟:(這二個團隊都沒有強制的規範,非常符合他的精神,我個人非常喜歡,下面就盡可能簡單的說一下,大家隨興囉!)

步驟一、以下面的個人看板做開始 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