l

2010年2月11日 星期四

非加班不能搞定之台灣經濟奇蹟幕後無名英雄

02/11 00:30~01:54

今天聯絡了一位以前公司的同事,告知他 3/11 日有一個 Scrum 講座,看看他有沒有興趣去聽。這位前同事目前從事嵌入式系統領域的工作,而他的碩士論文又是研究 XP,所以 Teddy 認為他應該會有興趣。



不料,前同事的第一個反應卻是:『這個活動在禮拜四下午喔...如果是晚上或是假日,我還可以喬一下時間...』奇怪了,Teddy 心裡想,這種活動辦在上班時間不是很正常嗎,晚上和假日誰還要來聽啊?

前同事目前工作專案團隊包含他老闆一共有六個人,平常他都忙到 11~12 點左右才下班。『這在業界很正常啊』... 前同事說....聽到這裡,Teddy 也了解前同事的難處。工作這麼忙,怎麼可能利用上班時間聽這個和工作看起來沒什麼關係的 Scrum。對一般公司而言,除非是 Linux kernel 或是 Intel 新 CPU, 晶片組介紹,公司才可能放員工在上班時間出來聽課吧。想在上班時間外出聽軟體工程相關的課程...想太多...不予通過...

不過,Teddy 還是很厚臉皮的想把他騙出來。

Teddy:你可以把資料寄給你老闆,找他一起來。
前同事:我老闆更忙,每天都在開會。
Teddy:!@#%~@@zzzZ

這個對話最後以交換 Facebook 帳號作為結束。

***

以下是 Teddy 聽來據說是真人真事的故事。某個『X碩』的員工,每天下班都搭最後一班的捷運。有一天下班後他在台北車站換車,在月台上遇到一位不認識的老先生,這位老先生突然對他說:『年輕人,你看起來氣色很不好,要多注意身體』。連不認識的陌生人的看得出來『X碩』是很操滴。

等一下,看到這邊『X碩』的員工可能會不服氣的說:『我們都很少加班啊...因為過了12點才算加班...』所以,不算操,OK 的啦。

 ***

相信各位鄉民們或多或少都有親身經歷或是聽過這些『台灣經濟奇蹟幕後無名英雄』的加班史。想當年 Teddy 年幼無知的時候,也是經常凌晨 12 點之後才下班,有時候還直接睡在公司,晚上還煮稀飯或是綠豆湯當宵夜和同事一起分享。但是,專案有準時結案嗎?幾乎從來沒有(除了少數幾個接公家機關做做網頁的案子會準時結案以外)。採用 Scrum 之後,現在 Teddy 相信如果上班時間是 9:00,每天應該在 18:30 左右就差不多要下班了。由於強迫自己與團隊必須在 18:30 之前把每天的事情都做完,工作起來反而比較有效率,加上應用敏捷實務作法(agile practices)得宜,專案反而進行的非常順利。

根據一些來源不可考的馬路消息,軟體開發團隊平均一天能有五個小時有效率且專心的工作(coding)時間就已經很了不起了。

鄉民甲:亂講,那我每天在公司待那麼久是在做假的喔 ...

關於工時和工作成果的討論,長久以來已經有太多文獻可以參考,在這邊 Teddy 就不再說明(偷懶一下)。不過鄉民們如果剛好是程式設計師的話,可以做一個實驗,如果我們狹義的單獨計算每天『專心寫程式』所花費的時間,平均下來這個時間應該也是五~六小時左右吧。等一下,不要把『無意識 coding,無意識 debugging,開批鬥大會,MSN 打屁,收發 email,看新聞,在走廊上聊天,泡咖啡,喝下午茶,上廁所,看股票,使用網路 ATM 或網路銀行,填假單,申請費用,發呆假裝思考』的時間也算進去喔。

除了加班以外,是不是有可能藉由改善做事情的效率或是減少做錯事情的機率,來提昇競爭力呢? Teddy 覺的 Scrum 是一個不錯的入門方法,門檻低,很容易上手,可以分階段逐步改善軟體開發團隊的做事方法並且提高生產力。有空可以來聽聽或是自己找資料看。

友藏內心獨白:現場有沒有請 show girls?

2010年2月7日 星期日

還少一本書: The Timeless Way of Building

02/06 23:33 ~ 02/07 02:19

幾天前在 Facebook 上的『Scrum Community in Taiwan』看到十分熱心的柯兄轉貼的一篇文章 Top 20 Best Agile Development Books, Ever,這20本書 Teddy 碰巧翻過 18 本 (請注意,翻過並不等於看完,更不等於看懂...只是... 翻過,沒什麼特別的意思...),這些書有空的話都應該要『翻』一下。不過,Teddy 對於原作者的排名,略有一點意見。引用一下原作者的資料,看一下前10名的排行榜:
  1. Agile Software Development: Principles, Patterns and Practices by Robert C. Martin
  2. Refactoring: Improving the Design of Existing Code by Martin Fowler
  3. Agile Estimating and Planning by Mike Cohn
  4. User Stories Applied: For Agile Software Development by Mike Cohn
  5. The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas
  6. Agile Software Development: The Cooperative Game (2nd Edition) by Alistair Cockburn
  7. Agile and Iterative Development: A Manager's Guide by Craig Larman
  8. Extreme Programming Explained: Embrace Change (2nd Edition) by Kent Beck
  9. Agile Project Management: Creating Innovative Products by Jim Highsmith
  10. Continuous Integration: Improving Software Quality and Reducing Risk by Paul M. Duvall, Steve Matyas, and Andrew Glover

再怎麼輪,榜首也不應該是 Agile Software Development 這一本啊。Teddy 認為這本書寫得最棒的是專門講設計原則的章節(第8到12章以及第20章,The Single-Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Dependency-Inversion Principle, The Interface-Segregation Principle, Principles of Package Design)... 自首無罪... 其實 Teddy 也只看了這幾章... 不過這不是重點,重點是,雖然學會並實用這幾個設計原則就可以騙吃騙喝 一輩子 一陣子,但是很多原則並不是作者原創性的作品 。例如,The Open-Closed Principle 和 The Liskov Substitution Principle 在更早之前 Bertrand Meyer  的名著 Object-Oriented Software Construction 這本書就有提到了(這本書很大一本,裡面還有一狗票的設計原則等待鄉民們去挖寶)。

從抽象到具體的順序來看,Teddy 覺得第一名應該是 Kent Beck 寫的 Extreme Programming Explained: Embrace Change (第一版和第二版都應該看一下),因為 Teddy 是讀了 Kent Beck 的書才接觸 agile methods 的,所以本書自然榮登 Teddy 心目中的第一名。

********************

依照往例,以上內容也不是本篇的重點,以下才是本篇的重點。

俗話說『女人的衣櫃總是少一件衣服,女人的鞋櫃總是少一雙鞋子,男人的車庫總是少一部車子,小朋友的卡通總是少看一個小時,宅男的電腦總是少一顆硬碟』。依此類推,『程式設計師的書櫃,應該 總是少一本書』。今天 Teddy 要補上這一本書,一本 agile people 應該要看的書:The Timeless Way of Building (建築的永恆之道)。

看過 Design Patterns 的鄉民們應該有聽過 The Timeless Way of Building 這本書。Teddy 當年因為要研究 patterns 在其他領域的應用才去看 The Timeless Way of Building。在看這本書的當下,只知道它是啟發 software patterns 理論與應用的始祖,並不覺的它和 agile methods 有什麼特別的關係。簡單的說,作者在這本書對於『如何建構有活力,有生氣的建築物』闡述自己的一套理論,這個理論就是 pattern languages 理論。以 Teddy 有限的智慧,無法三言兩語說明清楚(ㄟ,其實 Teddy 也懷疑是否真的了解... 鄉民甲:你是來鬧的嗎?),直接看一段書上的文字比較快:

It (i.e., the timeless way) is a process which brings order out of nothing but ourselves; it cannot be attained, but it will happen of its own accord, if we will only let it.

對應一下 agile 精神... agile 方法是一種流程(process, 也許有些人不喜歡把 agile methods 看作是 process,不過這裡把 process 看成做事情的步驟或方法就好,不用想成重量級的大部頭流程), 可以為開發團隊帶來某種『秩序』或『結構』。要變成一個 agile team 需要靠團隊自身的實踐,無法以強制規定或是工廠管理的方式來建立 agile teams。
 
The prople can shape buildings for themselves, and have done it for centuries, by using languages which I call pattern languages. A pattern language gives each person who uses it the power to create an infinite variety of new and unique buildings, just as his ordinary language gives him the power to create an infinite variety of sentences.

對應一下 agile 精神... agile methods 強調 no big upfront design, evolutionary design, simple design,除非開發團隊成員具有很強的 software patterns 基礎(當然還要有 testing 和 refactoring 等配套,等一下會提到),否則要滿足這些設計精神是很不容易達到的目標。

Once the building are conceived like this, they can be built, directly, from a few simple marks made in the ground---again within a common language, but directly, and without the use of drawings.

對應一下 agile 精神...XP 不是告訴我們,沒什麼事不要畫太多設計圖的啦 (source code is the design)。

Several acts of building, each one done to repair and magnify the product of the previous acts, will slowly generate a larger and more complex whole than any single act can generate.

對應一下 agile 精神... 有沒有聞到 refactoring,iterative and incremental 的味道。

Within the framework of a common language, millions of individual acts of building will together generate a town which is alive, and whole, and unpredictable, without control. This is the slow emergence of the quality without a name, as if from nothing.

對應一下 agile 精神...Scrum 本身是一個 framework,採用 empirical management model 而不是用傳統的 defined processes 來管理負責專案。

寫到這邊 Teddy 和周公的約會已經遲到兩個多小時了,加上這本書的內容實在過於豐富又有點抽象,在沒有準備的情況下 Teddy 也掰不下去了。總之,這本帶點哲學味道的書,對於想要獲得『華山論劍』資格的 agile 鄉民們,是屬於不可不搶的『九陰真經上卷』,練完之後如果沒有走火入魔保證內力大增。

友藏內心獨白:Teddy,你不要看到英文單字一樣就隨便連連看,小心被抓包。

2010年1月30日 星期六

多工,並不一定好

01/29 23:48 ~ 01/30 00:26

今天看到蘋果 iPad 上市的新聞,其中有一則提到,iPad 只有『單工』的能力,當你看書的時候,就不能聽音樂。此時 Teddy 心裡一想,都什麼時代了,怎麼還只有單工啊。光衝著這一點,就買不下手。

從電腦的角度來看,CPU 速度那麼快,一定要『多工』才划算。但是,如果處理事情的是『人腦』呢?單工是不是註定比較差?

***

最近這幾個 sprints 滿累的,因為最近 Teddy 主要的時間都在寫程式,而有 點(好大的一點)荒廢了 product owner (PO) 和 scrum master (SM) 的職務 。

這種一人分飾三角的情況犯了許多 Scrum 的禁忌,遇到的問題簡單的來說,PO 和 SM 都是 full-time job, 若是把大部分的時間都花在產品需求上面,就很可能忽略了 SM 要做的事。Daily Scrum 結束之後,也可能會比較少關注 team members 開發可能遭遇的問題,或是留意需要改善的 practices。當專注於 SM 角色時,產品需求就被冷落在一旁。只有一顆 CPU 要處裡兩個 jobs,只能做 time-sharing,沒分配到時間的工作只能挨餓了,相信有修過作業系統的鄉民們都了解。

更進一步,就是大家都知道的角色衝突。身為 PO 應該優先考慮客戶最希望獲得的功能,但身為 (SM + Developer) 常常會不經意從技術的角度來思考,因此有意無意之間,以 PO 角色挑選 stories 時,心中的 SM 或 Developer 分身就會挑出來幫忙一起亂挑,這就是一種衝突。

PO 和 SM 能不能是同一個人,就好像總統能不能身兼黨主席是一樣的。答案當然是只要是我喜歡,有什麼不可以。但是,當總統身兼黨主席,輔選時搭空軍一號趴趴走或是在高速公路上驅趕民眾,就要承受『濫用行政資源』的批評。這就是角色衝突。這種衝突的成本,團隊就要自行決定是否概括承受。當然正港的 Scrum 是告訴我們『絕對不行』。以 Teddy 的例子,明知絕對不行卻也只能『明知不可為而為之』,因為案子還是要做下去。Teddy 在『逆練九陰真經』的情況下,武功還是有所長進,但是為了避免像『歐陽峰』最後練到走火入魔的地步,要常常提醒自己不要讓某個角色餓太久。飢餓30小時可以,飢餓30天可是會死人的。

2010年1月23日 星期六

麥甲我蓋布袋, Part 3

01/23 16:06~18:00

Teddy 身上好像有種特殊的磁場,以至於『麥甲我蓋布袋』系列文章一直有寫不完的題材。這次是發生在學校圖書館事件。話說 Teddy 在學校研究所唸了那麼多年的書(因為一直無法畢業...沒什麼好驕傲的),從來都沒有在圖書館印過資料(難道這就是沒辦法早早畢業的原因?)。幾個月前才在圖書館買了兩張影印卡,第一次影印就碰了一鼻子灰。此事細節暫且不表,但不好的經驗卻成為今天的導火線。

由於 Kay 推薦的書籍已經購入,今天中午和 Kay 從家裡出發到學校借書。Teddy 在二樓圖書館看『電腦王』和『爛 Run PC』雜誌,Kay 借完書之後就在一樓看不可外借的展示新書。這期的電腦王和 Run PC 剛好各有一篇文章是 Teddy 有興趣的,於是看完雜誌之後就準備把這兩篇文章印下來。走到二樓的影印機,耶,怎麼卡片插不進去。由於第一次 Teddy 也遇到同樣的問題,該不會又壞了吧。再仔細一看,影印機的燈都沒有亮,難道是進入休眠模式(電腦用太多...)。隨便按了幾個按鍵,還是沒反應。難道是...傳說中的...電源沒開?影印機面板上有一個類似 on/off 的按鍵,用力給他按下去,還是沒反應。嗯...很多安裝『暈倒死』作業系統的電腦,進入休眠模式之後就睡死了,一覺不醒,難道影印機也有同樣的問題?還是圖書館的影印機和 7-11 一樣,要用之前要先跟店員講一下,請他們開電?還是不要隨便亂按,問一下館員好了。

就在離影印機不到五公尺的地方,圖書館的『自學中心』前方有一個櫃台,裡面有一顆在桌上趴著不能再低的人頭,應該是位工讀生,問一下他好了:

Teddy:請問影印機好像有問題不能用。

此時工讀生甲,緩緩地抬起頭來,在他那極為福相的臉龐,左右各有一顆紅紅的小太陽。工讀生甲用他那迷濛的眼神,含糊地說著...

工讀生甲:啊,什麼影印機,我不知道... 這不是我管的...要找一樓的人...

這句台詞怎麼那麼熟悉,噯呀,都是 Teddy 忘性太好,第一次使用影印機發生問題的時候,Teddy 也來問過坐在相同位置的另一位工讀生。沒想到圖書館教育訓練做的那麼成功,不同的人,居然講出一樣的話... 這不是我管的。上次 Teddy 乖乖的在一樓和三樓之間跑來跑去,好不容易才把要印的幾張資料印好。這次 Teddy 故意考考這位工讀生。

Teddy:那可以請你幫我打電話給一樓負責的人嗎?

工讀生甲:打電話...阿...阿.... (顯然還沒從和周公的會議中回過神來)...打電話我也是要走下去啊?

這句『打電話我也是要走下去啊』Teddy 就很難了解他的明白。不管了...工讀生甲老大不願意的走出他的『城堡』。走了兩,三步之後,忽然好像是挖到寶似的,對 Teddy 說..

工讀生甲:ㄟ,三樓也有影印機,你要不要去三樓印。

Teddy 一時不察,就被他呼弄過去了。三樓的影印機和二樓一樣不爭氣,Teddy 只好還是乖乖到一樓。一樓有兩位工讀生,一位是在大門口,負責還書的,另一位是 L 型櫃台的另一端,負責借書的。Teddy 前面有一位借書的讀者,等了一會輪到 Teddy...

Teddy:二樓和三樓的影印機好像不能用了。

工讀生乙:等一下我幫你看。

此時來了四,五個借書的人,等他們都把書借完,工讀生乙和門口的工讀生丙說了幾句話,就和 Teddy 到了二樓。從 Teddy 要印資料到現在,大概已經過了快 10 分鐘(沒計時,不過覺的等了有點久)。

工讀生乙:摸摸影印機,對 Teddy 說...嗯,我們一樓有影印機,不然到一樓印。

Teddy:好像是影印機的電源沒開吧?

工讀生乙:...摸摸影印機,找到電源開關,打開... 可以用了...

Teddy:(原來電源開關就在影印機左方)你們影印機好像是一早開館的時候就沒有打開啊!

工讀生乙:無言...

Teddy:我剛剛跟2樓的工讀生反應,他說這不是他管的。

工讀生乙:對啊,他只負責自學中心。

Teddy:(靠...過來一點,這句放在心中沒講) 難道要讀者上上下下跑來跑去。如果 Teddy 告訴他,影印機失火了,他也要說『這不是我管的,請找一樓』。

工讀生乙:你跟我講也沒用啊,我只是工讀生。如果你要反應,可以上網填寫讀者意見。

聽到這邊 Teddy 越聽越不爽,難道工讀生只負責領錢?這一句當然也沒講出來。索性資料也不印了,跟著工讀生乙到一樓櫃台。

Teddy:請找你們值班的職員出來,我直接向他反應。

此時工讀生乙有點嚇到的感覺,(難道遇到了包龍星,怎麼會有這麼刁的刁民... 設計口白...),不過還是撥打了一下電話....
 
工讀生乙 :沒人接耶...

Teddy:沒人接,難道是翹班?

工讀生乙 :不能這麼說。
 
Teddy:可以打他手機嗎?

工讀生乙 :我們只有分機號碼,不知道手機。
 
Teddy: 你在『騙肖耶』,怎麼可能連通訊錄都沒有,那發生緊急狀況怎麼聯絡... 這句話當然也沒說出口...

Teddy:不可能,你們一定有聯絡方式。

工讀生乙 :抱持寧死不屈的精神... 不然你等一下再來...

Teddy 眼看工讀生乙想敷衍我,直接走到職員辦公室外面往裡看,燈是亮著不過沒看到人。算了,先去把資料印好再說。

幾分鐘後 Teddy 下來一樓,借書的人還是很多。索性找門口的工讀生丙...

Teddy:麻煩幫我找一下值班的職員。

工讀生丙 :(撥打電話...) XXX,門口有人要找你。

工讀生丙 :XXX 請你直接進去。

Teddy 不屈不饒的往裡走,繼續奮戰下去... 打得有點累了... 看的人想必也累了。別走開,下面的更精彩。

**************************************

到了職員辦公室,說明了來意,這位職員倒也客氣,說會改進。不過,Teddy 都還沒抱怨夠本,反倒是他跟 Teddy 抱怨了一堆。

  • 我們的影印機是舊型的,沒有省電功能。因為節能減碳,所以沒有打開。(這句 Teddy 覺的有點唬爛的嫌疑,就算是真的好了,那也應該貼張紙條告訴要用的人自行開電源吧,然後用完再把電源關掉)
  • 這些工讀生也不是我管的,不過我會跟他們主管反應。
  • 我們也很難做事啊,像以前有個例子,有位校友說他忘了帶校友證,我們請他換證進入圖書館,他就不高興,大吵大鬧,最後還鬧到陳水扁那裡(對,鄉民們沒聽錯,就是暫時住在土城的那位陳先生,當年應該是總統)。結果學校上面就發公文下來... 噯呀,這種事看多了,遇到事情你說要管還是不管。(等一下,這關 Teddy 什麼事?關影印機什麼事?)
  • 現在的工讀生跟以前都不一樣了....
  • 我們這種作服務的很難作,尤其又是免費的... (暗示 Teddy 不要要求太多?)
  • 你也可以跟讀者服務組(類似這樣的單位,詳細名稱記不得)的組長反應,不過他二月一號就退休了。我看你二月一號之後再跟新的組長反應。(切,抱怨還要挑黃道吉日?)

還有一些有的沒的,實在講太多了,Teddy 也記不起來。

事後 Kay 說,看到 Teddy 走進職員辦公室,就知道 Teddy 又要和人家吵架啦。

難道下次要帶數位相機,用拍的就好,不要用影印機了?

友藏內心獨白:花兩小時寫這個鳥事,還不如去寫 paper...

有 test cases 改遍天下,無 test cases 寸步難行

01/23 02:24~03:28

如果要列舉 agile methods 對於軟體開發行為模式的影響,除了 iterative and incremental (IID) 之外,最重要且影響最深遠的應該首推自動化測試了(感謝 JUnit)。幾個很重要的 agile practices,包含 refactoring 和 continuous integration,如果沒有自動化測試就『破功了』。

Teddy 本身對於自動化測試的進化路徑如下:

  1. 沒寫過(不會寫也不願意寫)自動化測試。有沒有搞錯,程式都寫不完了,哪有時間寫測試。
  2. 開始用 JUnit 寫單元測試。
  3. 用 JUnit 寫很多單元測試。
  4. 用 JUnit 寫一些整合測試。
  5. 用 JUnit 寫一些功能測試。
  6. 嘗試在 JUnit 中用 mock object framework。
  7. 很少在 JUnit 中用 mock object framework。不是不好,而是不合 Teddy 的胃口。
  8. 用 JUnit 寫很多功能測試。 
  9. 當發現 bug 時,想辦法用寫一個測試來還原這個 bug(test-driven debugging)。
  10. 三不五時想到的時候,在開發新功能時,先寫 test code 再寫 production code (玩票性質的 test-driven development)。

最近 Teddy 與同事修改專案中某個模組,增加新的功能也同時重整 (refactor) 該模組許多類別的介面。還好該模組有相當多的測試案例,所以這麼大幅度的修改,『只』產生大概 10 個左右無法立即發現的 bugs。這些 bugs 都是現有測試案例沒有涵蓋到的(廢話...),所以當 Teddy 與同事一起 pair debugging 時,我們第一步就是寫一個測試案例來暴露出這個 bug。講白話文就是寫一個一定會失敗的測試案例,當這個 bug 修正之後,這個測試案例就會成功。

這次 refactoring 主要反應了某些軟體架構上的改變,算是所謂的 big refactoring。雖然前前後後一共花了三~四天才把全部的 bugs 改完(包含寫新的測試案例),整個過程還算順利。如果沒有這些測試案例,修改的過程應該早就失控了。這種『越補越大洞』的經驗,對於廣大的鄉民們而言應該不陌生吧。

很多有心想要導入 agile methods 的人會說:『要 programmers 寫測試案例好難』,『不知道要如何開始作 test-driven development』。Teddy 的經驗是,雖然 test-driven development 是一種透過寫測試案例來達到設計程式的目的(就是 TDD 應該算 design 而不是 testing),但是除非 programmers 已經將寫測試案例當作開發系統不可分割的一部分,否則並不容易推行 TDD。如果 programmers 寫測試案例就跟『喝開水』一樣簡單與自然,那麼一不小心他們就會慢慢演化成 TDD 動物。

結論就是:不能沒有你,test cases。


友藏內心獨白:這麼晚了還不睡,寫什麼部落格,小心明天被罵!

2010年1月20日 星期三

end-to-end stories:切蛋糕篇

01/20 22:56~23:45

蛋糕這種食物,在物質條件如此富裕的寶島台灣,相信沒吃過的人應該很少。就算沒吃過,也應該看過,如果沒看過,請到 8X度C 的櫥窗看一下。

假設鄉民們買了一個生日蛋糕,除非你是買來砸人的,否則吃之前應該都要先切一下蛋糕。蛋糕有兩種切法,水平切法與垂直切法。一般正常人類,採用的是垂直切法,所以切出來的每塊蛋糕,包含了整個蛋糕的每一層,一口咬下去,可以吃到最上層的鮮奶油,第二層的香草或巧克力夾層,第三層的布丁,第四層的水果...依此類推,真是太好吃了。

至於打從火星來的鄉民們,則是採用水平切法,切出來每塊蛋糕,就只包含某一層的餡料。一口咬下去,噁...吃到滿口的鮮奶油,或是布丁,水果...。這算是在吃蛋糕嗎,還是在吃 N 種不同的食物?

******************************************

軟體開發活動中的需求撰寫,無論是寫成 use cases,scenarios,或是 stories,認真一點的鄉民們,應該還記得教科書上一定會提到,要寫成 end-to-end [use cases, scenarios, stories]。想當年 Teddy 在當 OOAD 助教的時候,也不時提醒學生們:『你這個 use case 不是 end-to-end』不過說真的,在當下聽進去的人可能不多。

寫出非 end-to-end [use cases, scenarios, stories],就好像切蛋糕沒切好,吃的人(你的客戶)可能吃到整片的鮮奶油。你告訴他,這就是蛋糕...不可分割的一部分,先把這個啃掉,下次給你蛋糕的另外一層....N 個月後你就可以獲得一塊完整的蛋糕了。

所以,為了讓客戶在你切下每塊蛋糕的同時,就可以立即享用,你應該把一大塊蛋糕(某個需求),垂直切成很多塊的小蛋糕(很多較小的 stories)。每切完一塊蛋糕(每做完一個 story),客戶都可以吃到一整塊的蛋糕(得到一個對客位而言有價值的功能)。吃到一整塊蛋糕,即使很小一片,還是有算吃到蛋糕。吃到一整塊鮮奶油,即使很大一片,還是很噁...不算吃到蛋糕。

如果以後還有人問你:什麼是 end-to-end [use cases, scenarios, stories],如果是好朋友,就買塊蛋糕請他吃,如果是路人甲,就請他自己去看一下8X度C 的櫥窗。

2010年1月17日 星期日

Scrum 是一種制度

01/17 21:34~23:40

依稀記得大概在兩年半前看到 Scrum 這個字眼,當時直覺的反應是:『又來了一個 agile method』。市面上 agile methods 這麼多,要怎麼學?... 阿就... 亂學 挑選第一品牌 XP 就是了。抱著這樣的精神,Teddy 也就沒特別花時間去留意這個連英文單字都不知道是什麼意思的 Scrum。

幾個月後,也忘了什麼原因,實驗室的學弟被指派報告 Scrum。一如往常,聽完之後獲得槓龜貼紙一枚。當時只記得聽到一些奇怪的名詞,什麼『Sprint, Backlog, Daily Scrum...』為什麼不叫做 iteration, requirement list, stand-up meeting 就好, 還要自創武功名稱。這些老外是怕咱們單字不夠背嗎?當時 Teddy 最沒搞懂的,就是下面這張圖中央的這兩個圈圈。慧根不夠,一個 30 天的大圈圈,背著一個 24 小時的小圈圈,光看圖很難了解它的明白。


後來,實驗室學弟 被迫 自願在某個專案上採用 Scrum,結果又累積了另一張槓龜貼紙。當時 Teddy 正忙著撰寫博速論文,也沒心思幫忙。不過主要的原因還是 Teddy 自己根本不懂 Scrum,插不上手。

無奈老天爺還是不放過 Teddy,就在 Scrum 連兩槓之後沒過多久,無意間看到了 Scrum and XP from the Trenches: How we do Scrum 這本免費的電子書。這本書只有 120 幾頁,用平鋪直敘的方式搭配大量具體的範例來分享作者自己實施 Scrum 的經驗。這本書 Teddy 反覆看了好幾次,再搭配 Agile Software Development with Scrum 以及之前看過的一堆 agile 書籍,採用雞尾酒療法的精神卯起來一次服用,藥效很強,忽然有種被黃袍加身的錯覺,也想找隻白老鼠來試一下(PS:叔叔有練過,小朋友不要學)。

後來果真找到一隻小白老鼠,到現在一轉眼過了一年半。值得安慰的是,當年這隻白老鼠到現在還健康的活著 (至少 Teddy 認為牠還滿健康的啦)。這一年半的學習歷程,Teddy 有一點點感想整理如下:

第一次接觸:經驗不是很好,因為槓龜兩次。Teddy 覺的這不過是另一個 agile method 而已。

第一次實施:Scrum 是一個很簡單的框架 (framework),規範了角色 (Product Owner, Scrum Master, Team),活動 (Sprint Planning Meeting, Daily Scrum, Sprint, Sprint Review Meeting, Sprint Retrospective Meeting, Product Backlog Refinement Meeting),產出物 (Product Backlog, Sprint Backlog, Task Board, Burndown Chart, Potential Shippable Software) 。但是 Scrum 並沒有特別規範 practices。從這個角度來看,要了解 Scrum 其實很簡單,但是要實際運用 Scrum 來開發軟體,還是需要紮實的軟體工程基礎(簡單講就是 agile practices, 像是 continuous integration, unit testing, refactoring, test-driven development, pair-programming, review, design patterns... 這一些都要真的懂而且要採用)。

實施幾個月之後:Scrum 很累... 要讓這些 刁民 團隊成員乖乖的按照書上說的方法來進行 Scrum 還真不容易。


上完 Certified Scrum Master 課程:Scrum 框架本身元素很少,所以很簡單。但是 Scrum 的精神卻不容易達成。例如,Scrum 強調『持續改善』,這一點就很難。還有 Scrum 要塑造 self-managed team(講成白話文就是自我管理的團隊,就是一個老闆都不用管,就會把事情做的又快又好的團隊)也是很難。

看了 Succeeding with Agile: Software Development Using Scrum 這本書:這本書第五頁提到 Scrum 很難的六個原因,包含

  1. Successful change is not entirely top-down or bottom-up; 
  2. The end state is unpredictable; 
  3. Scrum is pervasive; 
  4. Scrum is dramatically different; 
  5. Change is coming more quickly than ever before; 
  6. Best practices are dangerous。
內容是什麼意思有興趣的鄉民們就去賣本書來看,Teddy 想講的是第三點『Scrum is pervasive』,也就是說,公司要導入 Scrum,不是只有某一個團隊,或是整個開發部門的事情而已,而是整個公司都要『換腦袋』。業務部門要知道在 Scrum 框架下如何跟客戶溝通,人力資源部門要改變傳統以個人來評量績效的方法(Scrum 講的都是團隊... 有點社會主義的感覺)。QA 部門不能只從規格來驗收軟體,還要從客戶是否真正需要來考慮。結論就是,這根本是 革命 嘛。

各位 agile 先聖先賢們,咱們只是想好好開發個軟體,有那麼嚴重嘛!

總之,Teddy 現在的感覺是,Scrum 其實是一種『制度』,在這個制度底下,要做的事情其實很多。好比民主制度,主流價值觀都認為民主制度很好,但是真正實踐起來卻很難,而且很花時間。以咱們台灣為例,民主國家形式上要有的元素都有了,但是實質面卻還是有很多進步的空間。買票,賄選,立法院打架,民粹,立法效率差...等等一狗票的問題都還存在,但是不繼續走下去好像也不行。實施 Scrum 的過程,有點像是從專制或是帝制換到民主共和制度一樣,以程式語言的術語來講,這就是一種『典範轉移』(paradigm shift)。會寫程式的鄉民們回想一下,從程序導向的思考模式要換到物件導向的思考模式花了你多少時間?所以實施 Scrum 要有長期抗戰的準備。

但是,先決條件是,你,你的團隊,還有最重要的是,你老闆要相信民主制度比較好。如果你的老闆是袁世凱,那實施 Scrum 是『祝恐怖』滴。此時還是大喊一聲『皇上聖明』比較實際一點。

友藏內心獨白:可以用『台澎金馬民主領域』申請加入聯合國嗎?