番茄工作法就好像小而實在的 Scrum

The Pomodoro Technique – Scrum in the small

番茄工作法就好像小而實在的Scrum

 IT部門如何克服中斷太多沒時間開發專案的問題呢?

世事變化實在太快,市場的起伏不斷牽動著技術的起落,造成大家都在喊著時間不夠用。技術單位;尤其是IT部門,手頭維護的工作都忙不過來了,還要時時留意應該吸收那些新技術,擔心自己負責的開發專案沒進度(總要時時力爭上游才好保住飯碗),哪來的時間啊!?

這個時候你需要的是「時間管理」,因為與其向老闆或主管去爭取更多的自主時間,還不如善用自身的時間,想辦法提升自己的效能。介紹一種再簡單不過的時間管理法給已經在用 Scrum的團隊 ──番茄工作法(The Pomodoro Technique,這是意大利文的番茄),貫徹它你可以提升自我對時間的有效運用,進而影響到整個Scrum團隊的效能,怎麼做呢?! 就從在25分鐘內極度的集中精神開始(其實番茄工作法這個名稱的由來是在廚房裡找到番茄計時器來計時的典故,現在大家都採用電腦裡的程式在計時了,不過還是喜歡把它畫成番茄的樣子)。

番茄工作法: 是一種時間管理理論

目的在讓使用者集中聚焦 on focus,善用人類的特性創造新知,從而事半功倍地完成專案工作。步驟很簡單。以一項需要一天時間的專案為例,將你的時間預算分割成小的時間段,不斷累加,然後階段性的休息。比如,你工作25分鐘休息五分鐘。

每25分鐘的工作時間就被稱為一個“pomodoro”。原創者Francesco Cirillo用了一個類似蕃茄的廚房計時器作為個人計時器,接著就以其命名了這個理論。

4 個 pomodoros之後(相當於工作了100分鐘休息了15分鐘),你就可以來一個較長的休息15-30分鐘。

每完成一個pomodoro,在你的工作進程中標記X並且記下每25分鐘你想罷工不幹或者另從其他的衝動次數。

番茄工作法就好像小而實在的Scrum

● Scrum將專案分成多個 Sprint的週期,Sprint開始時做Product backlog的planning meeting,結束時做review meeting,其中每天都要做 Standup meeting。

○ 番茄工作法的週期則為一日,工作流程由五個階段構成,分別是在一日的開始時先做《計劃》,而在一日的結束時進行《紀錄、分析、可視覺化的處裡》,在一日的開始及結束中間則不斷的進行《追蹤》的動作。

● Scrum 讓成員自主;自行選取每天要處裡的backlog事項。

○ 番茄工作法則將工作事項列表(Task list),讓成員能夠在25分鐘內集中精神,全神貫注的依序來解決這些工作事項。

● Scrum 比喻開發工作為馬拉松式的長跑,要均勻配速才能持久(加班不能解決問題)。

○ 番茄工作法則每進行一個25分鐘就要休息5分鐘,稱它為一個番茄時間。每進行四個番茄時間就要做一次較長的休息(15~30分鐘),目的在減少舒緩全力集中精神工作後的壓力(能夠集中精神才有效率,冗長工時但效率不彰是負面的效益)。
好處 】 —  頻繁的休息可以保持大腦清醒和關注。
據Pomodoro的官方網站稱,這個方法很容易使用並且效果卓著。“你可能會在一兩天的工作或學習中感受到效果,但是真諦在於堅持七至二十天”。

如果你有許多繁雜的事情要做,用蕃茄工作法絕對要比你緊盯著時間計畫表要快得多。看著計時器中迅速減少的時間會促使你儘快完成手頭的工作,而將任務分攤到2-3個pomodoros來完成時會讓你時刻保持清醒和新鮮感。你可以利用持續的pomodoros完成工作,並且儘量減少拖延。漸漸地,你會遵循 “蕃茄時間” 來工作,更好地掌握工作負荷。

很多人愛用嗎?】

著名的”煙硝中的Scrum和XP” 作者Henrik Kniberg也是他的擁護者。

蘋果非官方Blog的Steven Sande是Pomodoro的忠實支持者。並且編撰了一套與蘋果相容的Pomodoro工具。在他還未使用pomodoro之前,他說道:“有時我根本就不知道如何規劃我一天的時間,因為我這也做一點那也弄一些,結果什麼都沒有完成。”

另一位pomodoro的擁護者是華爾街日報的Sue Shellenbarger。Shellenbarger試用了Pomodors和其他一些類似的時間管理法, 然後總結到:“這種方法會平緩因時間流逝而產生的焦慮,同時效率也更高;舉個例子,間斷性的休息,使精力充沛的我只花了一半的時間去核實一個專欄。”

相輔相成

就SCRUM的精神而言,番茄工作法正好拿來教導個人如何善用自己的時間,並透過有效的提升個人的效率,影響到團隊的效能。

在執行SCRUM的專案開發時,你是否覺得時間始終不夠用, interrupt 實在太多,每日的實質工時始終停留在 2~3小時之間(也就是Burn down 圖的指數維持在50% 以下),這個時候身為Scrum master的你我正是祭出番茄工作法的好時機了。

你還在等甚麼? 現在就去下載Pomodoro工作法的小工具,開始你的時間管理之旅吧!

參考:

  1. 番茄工作法,Francesco Cirillo的中文版  http://www.pomodorotechnique.com/resources/ThePomodoroTechnique-CHN_v1-3.pdf
  2. Pomodoro Technique Illustrated番茄工作法圖解    http://book.douban.com/subject/4199701/
  3. Pomodoro 工作法小工具http://playpcesor.blogspot.com/2010/01/keep-focused-25-pomodoro.html

Scrum 如何估算專案開發的時程?

Scrum 如何估算專案開發的時程?(有學員問了這個好問題, 這通常都是老闆們才會問的問題)

Run scrum時;如果你想了解一下專案大概要花多少時間來開發的話(每個老闆都關心這件事,那就來試試這個吧! 我都是這麼做的)。

書上沒有教如何畫甘特圖以及怎麼做系統Break down,那要如何來估算專案開發的時程?

(一定要再看這篇https://ruddyblog.wordpress.com/2012/07/ )

書上只有說道:先衝刺一次就會知道,如果還不知道,那就再衝刺一次,落實做好Scrum的會議(Sprint計畫會議、每日站立會議、Sprint結束會議還有Sprint檢討會議)及 Sprint 的時間盒管理,結果就會自然浮現(也就是Emergent design囉)。

嘿! 約耳不要再開玩笑了…

(約耳所謂的無痛軟體時程run Scrum的團隊一定要參考一下🙂
參考: http://chinesetrad.joelonsoftware.com/Articles/PainlessSoftwareSchedules.html

這一點,尤其對資訊界的新人而言,如果你不明講,還真是一團迷霧!

(所以我一向都用以下的分析手法教他們一些基礎的劍招 —- 說穿了就是【畫圖】(老實說Run Sprint 時那有時間來畫圖ㄚ!), 這是一些簡單到不能再簡單的分析及時程預估法則,但學會了以後還是得想辦法忘掉才成…)

此時;張三豐的箴言又浮現出來了:『…無招勝有招』,但是話說,你還是必須從基本的招式開始,等到一切招式都記熟了,才有本錢可以忘記那些死記下來的動作,融合成為真正屬於自己的劍術。這段話的意思是,那些基礎的東西,你懂得越多自然是越好的(例如: OOAD是甚麼?),就更能融會貫通在自己的本質學能中,也就能夠自然而然地成為你的內功基礎了。

閒話表過,接著我們來談一些基礎到不能再基礎的劍招:

步驟一、運用HIPO (Hierarchical Input Process Output)的分析技術將抽象的Use Case描述,利用將輸出入明確隔開來的圖示法,從其中分析出流程(Process)及各個大的模組(Module) 區塊。這是起手勢,練的熟練了對專案的了解就越快進入狀況。

步驟二、依據 HIPO 畫出功能圖(Function Diagram),將各個大的區塊再breakdown成更小的區塊,讓它可供較明確的討論使用,或甚至breakdown 到可以開始撰寫程式的模組為止,再來進行工時的估算。此時;專案的概略開發時程就可以浮現出來了(視專案的大小,以每天或每小時為預估的單位)。

步驟三、再依據 Process的部分劃出順序圖Sequence Diagram或流程圖Flow Chart(專案很小時採用順序圖,較大的專案就要靠流程圖了),藉以明確化測試案例(Test case)。這是最有趣的一個步驟了,當你開始寫測試案例時,通常你又會回去改上面的步驟一、二的HIPO圖示及Function diagram了。這是對得、也是好的一部分,就因為這幾個東西的相依性,讓我們足以反覆的思維自己所畫出來的圖示是否合乎邏輯,當然也可以拿來驗證這個 use case 的合理性,這是相當值得的。

至於得到的專案預估時程,則僅供參考了,這是做給雞看的(Scrum的老故事了,老闆是雞,開發人員則是豬: http://zh.wikipedia.org/wiki/Scrum)。

註:
1. HIPO (Hierarchical Input Process Output)
IBM用了幾十年的老東西了,原始文件檔如下:

http://es.wikipedia.org/wiki/Hipo : 這一篇Wiki 的說明網頁談多了些, 但多加的那些東西是為了彌補HIPO的缺陷才衍生出來的。(HIPO的一些缺點,例如: (1)無驗證功能,造成功能的完備性很難被驗證。(2)未能反映系統性能要求。(3)遇到規模大的系統會產出大量的資料,不易維護。)

2. 功能圖Function Diagram
適合專案初期拿來分析會用到那些技術?會產出那些個模組的相當簡單的模組方塊圖。
這是由抽象的討論或模糊印象的輪廓下,轉化成為比較具體、較明確化的第一個步驟。通常這種採用一個一個模組來估算個別工時,再一起加總起來的方式,所得到的估算值都會比最後結果要長一些,這是因為估算的時候依據半天或小時來計算下所產生的誤差。

3. 順序圖Sequence Diagram
順序圖有很多優點,它能夠清楚的描述事件的順序,也顯示了什麼時候物件被建立和銷毀,在操作的容易被了解上表現得很優秀,更重要的是它能夠捕獲事件之間的競爭條件。然而雖然有這麼多優點,但老實說它們也不是完美的工具,因為它太占空間了,只要多幾個狀態,畫出來的結果就會複雜的一踏糊塗,根本沒辦法看,而且也不能很好的表示協作物件之間的相互關係。所以盡管順序圖是強而有力的,但我仍然認為密集而潔簡的流程圖更令人愉快。

4. 流程圖 Flow Chart or Activity Diagram
用來來描述工作流程,業務流程和其他的程序。它夠簡單且易讀易懂,是人們用來相互溝通流程的好圖示。

UML活動圖Activity Diagram: http://www.dotspace.idv.tw/Jyemii/umlcolumn/articles/umlwriting/tipuml05.htm
http://translate.google.com.tw/translate?hl=zh-TW&langpair=en%7Czh-TW&u=http://edutechwiki.unige.ch/en/UML_activity_diagram

已加上的標籤

在竹科上SCRUM的課程: reading SCRUM

與第二組可愛的隊員合照

在竹科上SCRUM的課程

第一次試著運用讀書會的方式,把原本應該是程式開發的一次Sprint的迭代過程改成運用閱讀來進行(好棒! 我稱他為 Reading SCRUM),在為期三天的敏捷開發法 SCRUM課程中實際的run了一次 Sprint, 真是有趣,效果也比我預期的好太多了,看到很多人性的可取面,第一次上SCRUM課程感覺得這麼累,但卻這麼過癮~~~真是教學相長!

讀書會的專案設計

下面是讀書會的專案設計文案,有興趣的人請參考,過程挺精彩的,或許是這群學員的求知慾望旺盛吧! 我總覺得自己好像一下子年輕了好多好多~~

Listing 出來的書都真的買來了,其中(2) Succeeding with Agile ,by Mike Cohn依照組數買了許多本,花了不少精力把這些書扛過去,但看著學員們閱讀時的專注表情,真是太值得了! (雖然成本增加了許多,但我一定會繼續做下去的,因為太值得了,SCRUM的講師們有興趣的話,不妨試試看,這也證實了 SCRUM 的多方面運用性)。

為了這個課程把清明掃墓祭祖的家庭活動延了下來,夜深了…讓人倍感思念已經過世多年的老爸老媽,好想念您們!

專案文檔
專案文檔

有一點要特別提醒講師的,那就是不要輕估了學員們閱讀的能力,千萬別把範圍訂得太小了~

總是會有一二個團隊把閱讀的範圍定在只挑選單獨的一本書及裡面的一個章節上頭,說得好聽是集中精髓–精讀,但基本上是見樹不見林。一般的老闆最討厭這種情形發生了,他總希望專案能做到的功能越多越好,這一點講師們可以把專案鐵三角拿來作機會教育,「範圍 – 資源 – 時間」的調整練習,但千萬別犧牲了中間的品質。這是最值得強調的了。

SCRUM 課程圖示

scrum process chart.png

2017版

Silverlight + Sketchflow on cloud: 圖在Azure 上頭了,Sketchflow 也依然可以修改~~~

這是一張上課前十分鐘的手繪SCRUM + XP 課程導讀這是我習慣在上SCRUM 課程的前十分鐘,以口述並運用白板手繪的方式作為導讀用的,目的是希望加深學員的映像,讓他們開始產生運用SCRUM時會碰到的問題聯想。
提供有興趣的人做參考。

想要進階學習的人,推薦: Succeeding with Agile: Software Development Using Scrum, by Mike Cohn.

順便回答一下,為何TDD如此難以推廣呢?

因為,Emergent Design: The Evolutionary Nature of Professional Software Development 這種衍生性的設計思維方式,是要經過訓練養成的,一般擁有高度自信心的人比較容易接受。寫程式的人如果在剛開始學程式撰寫時沒能養成這種習慣,日後要靠自我學習的方式來取得領悟,那就難上加難了。這是我推廣TDD多年以來的心得,深深感覺到學校教育的重要性是不容忽視的。

怎麼推廣 TDD 呢? 就是要激起他的熱情就對了! 他比加班更有效~~~

附註:

Emergent Design 其實不是甚麼新玩意兒,程式設計人員常常會沒有太多規劃,坐下來就一直遇招拆招的寫下去,一直到一個一個的function產出了來,也沒甚麼特別的感覺;基本上它就是,這就是了。(但記得要基於Testing來做,也就是先產生錯誤訊息才是TDD,要讓解決錯誤訊息成為首要的思維路線就是了)