l

2010年10月21日 星期四

消除浪費 (6):Delays

Oct. 21 22:09~23:22

七浪費之六:Delays,Teddy 覺的用原本 TPS 的用語 Waiting 好像比較容易了解。軟體開發的 delays 情況有:
  • 等待某人有空:例如,等待 DBA (資料庫管理員) 幫忙設定資料庫;等待 technical writer 幫忙寫使用手冊;等待『隊友』幫忙一起解 bugs;等待公司招募到新人。
  • 等待資源:等待測試設備;等待購買的軟硬體設備到貨;等待從 Amazon 買的書寄到台灣。
  • 等待某項知識。例如,等待 Product Owner 明確的告訴開發者所有的需求細節;等待 team leader 告訴你 bugs 要如何解,程式要如何寫;等待新人搞清楚專案狀況。
  • 等待核准。例如,等待老闆核准專案進行;等待法務審核合約;等待客戶畫押需求;等待批准需求變更。
  • 等待功能或產品完成。例如,等待系統分析師生出完整的軟體架構;等待系統設計師畫出全部的 UML 設計圖;等待程式全部完成以便測試;等待程式通過測試。

根據書上的說法,開發人員15 分鐘就會做出一個重要的決定(一秒鐘幾十萬上下?!),如果開發人員對於他正在做的工作有足夠的知識(例如,知道客戶到底要他做什麼),或是當他有問題時馬上就可以獲得解答,那麼開發人員就可以快速做出(較高品質的)決定。如果開發人員缺少足夠的知識或是沒有人可以回答他的問題,那麼聰明的人類只會有三種反應:
  • 停下手邊的工作,試圖去找出答案:原本的工作被中斷,如果找答案的過程很冗長,造成 task switching 的浪費。
  • 停下手邊的工作,找其他事情來做:柿子挑軟的吃,原本的工作可能變成 partially done work。最慘的就是不斷地找新的事情,沒有一件事完成,一直到 stack overflow 為止。
  • 猜測可能的作法,硬著頭皮繼續做下去:蠻幹,最後的成果可能不是客戶所需要的,需要 rework 或 relearning。這個現象常常在很多『有理想,有抱負外加有創意』的開發人員身上發現。
如果找答案的代價很高或是程序很繁雜(例如要聯絡客戶,協調其他部門的人),那麼屬於『宅男』,『宅女』類型的開發人員因為害羞與偷懶等原因,通常會選擇後面兩項作法。在情況允許下,如果瞎耗一段時間不做事又不會被發現,開發人員也可能會執行一個『空迴圈』不斷地等待下去,期待答案自己出現。這些行為都是一種浪費。

***

消除 delays 的方法很多,書上提到一個最簡單的做法:

Complete, collocated teams and short iterations with regular feedback can dramatically decrease delays while increasing the quality of decisions.

Teddy 幫鄉民們把上面這句翻成白話文,就是『採用 agile methods 就對了啦』。

PS:
Teddy 氣象小叮嚀:鄉民們,不必再等待不可能的『颱風假』,除非你的公司在宜蘭縣。

***

友藏內心獨白:等待『發薪水』和『下班』應該不算浪費吧...XD。

2010年10月19日 星期二

消除浪費 (5):Task Switching

Oct. 19 21:54~22:42

『七浪費』之五:Task Switching (工作切換)。等一下, 為什麼工作切換是一種浪費?現在這個高科技時代,不管是人,還是機器,不是都強調要具備『多工 (multitasking)』的能力嗎?所以:

老闆:每個工程師手邊同時至少要有三個專案,一個快結案,一個進行中,一個剛開始。
這樣才可以把工程師超到過勞死...的邊緣。

消費者:都什麼時代了,iOS 4.x 之前的版本居然膽敢不支援多工。難道我就不能邊玩 game 邊寫 mail 嗎... XD


學生:我最強,我可以邊上課,邊睡覺,邊聊天,邊玩手機,再加上邊吃泡麵啃雞腿。


學過作業系統的人都知道,工作切換便會形成『context switch』,只要有 context switch 就形成浪費。對電腦而言,context switch 可以是很 routine 的工作,對人腦就不同了 如果手邊的工作類型是屬於『不需要大腦也可以搞定的工作』,例如挑大便或是拔草,那麼工作切換所造成的浪費就比較少。但是,對軟體開發而言,大部分的工作卻都是需要『絞盡腦汁』的工作(路人甲:真的嗎?!)。如果時常切換不同的工作,有可能最後花在 context switch 時間比真正去做事的時間還來的多。引用一段書中的話:

When knowledge workers have three or four tasks to do, they will often spend more time resetting their minds as they switch to each new task than they spend actually working on it.

***


問題來了,實務上,你的老闆絕對沒那麼好心,讓你只做一件工作。所以,工作切換畢竟是難免的。書中舉一個例子說明如果減少工作切換的浪費。假設你的軟體已經釋出,因此你同時必須要面對『維護舊軟體』與『開發新軟體』這兩件工作。以下是書中提到減少工作切換浪費的方法:
  • 讓兩個人(或兩個小組)每個月(或每個 iteration)輪流負責開發與維護的工作。
  • 每天早上花兩個小時讓整個團隊處理維護的工作,其餘時間專注於新功能開發。
  • 仿效『急診室』的作法,先將每一個客戶所提出的維護需求加以分類,只立即處理『緊急』的維護需求(理論上只有很少量的維護需求是屬於這一類的),然後每一或兩週在看看有哪些維護需求是真正需要處理的(有時候客戶的維護需求放久了會自動消失...^o^)。
  • 把所有不同客戶所使用的軟體版本都放在單一的 code base,然後每週或每一個 iteration(定期)釋出一個更新版本。
***


結論:在實際的生活中,task switching 是難免的。但是請牢記以下兩點:
  • 不是塞越多的工作給員工就可以得到越多的產出,有時候塞了太多的工作,員工只是在不同的工作間『空轉』而已,最後一事無成。
  • 就算是需要 task switching,也有比較好的工作切換模式。例如,不要每隔 5 分鐘檢查一次 mail,那只會害你分心。最好是採用『定時定量』的方法,例如每天早上一到公司的時間,下午 1:30 以及下班前。
***


友藏內心獨白:為什麼總是在忙碌的時候,不斷收到 MSN/Skype 的訊息。

2010年10月18日 星期一

敏捷式例外處理設計 (10):自動化更新

Oct. 18 21:29~23:02

這個系列的文章有一陣子沒寫了,最近 Teddy 家裡一堆電子產品壞掉,讓 Teddy 想起了另一個敏捷式例外處理設計原則:自動化更新

先談一下 Teddy 維修的慘痛經驗。


維修奇美 42" 液晶電視

前一陣子 Teddy 買了 2 年多的奇美電視壞了,當初會買奇美,主要是『便宜』,和日系相同尺寸的電視相比,價錢大約只要 1/3 ~ 1/2,而且有三年保固現在電子產品的生命週期都那麼短,與其買一台很貴的日系電視,還不如買國產的用一用先,萬一 3 年後真的壞了,到時候液晶電視價錢一定降很多,再買一台新的也划算。


沒想到還不到三年就真的壞了,電視完全無法開機。Teddy 從網路上查到奇美維修站的電話,打去報修,和維修的師父約了好幾次,都說當天晚上沒有時間不能來,最後只好約了禮拜六(Teddy 的電視是禮拜一壞掉的,此時心中已經略有不爽)。


維修師父來了之後,居然雙手空空,什麼也沒帶。隨便看了一下電視型號與保固書,說了一句令 Teddy 吐血的話:你的電視還在保固期,我們無法維修,請聯絡『原廠』


就這樣,過了一整個禮拜,Teddy 的電視機居然都還沒進入到『維修狀態』。後來好不容易聯絡到『原廠』的維修師父,服務還不錯,當天晚上就帶著一個電路板直接到 Teddy 家裡來更換,當場就修好了,免費。這下子總算讓 Teddy 對奇美的信心指數稍微回升了一點(你看,台灣的消費者是很容易就滿足的)。


相信有類似經驗的鄉民們應該不少(維修過程與結果是好是壞就不一定了),以上的經驗告訴我們:
  • 為了搶 Time-to-Market (即時上市),很多電子產品的『品質』都只能作到『堪用』。
  • 消費者為了『嘗鮮』,心裡也都預期到『新的東西 bugs  很多』。
那麼消費者是白痴嗎?為什麼要去搶很有可能有問題的 天線 新產品?如果公司的產品『新穎(有賣點)』,『價錢有競爭力 (C/P值高)』加上『售後服務好』,那麼就算產品有問題,甚至有點貴,消費者還是很有可能會買單的(Teddy 內心獨白:iPhone 4 售後服務爛又貴,大家還是搶著買,可見光是『新穎』這一點就可以打死其他因素)

但是,如果『售後服務很爛』,消費者被騙一次之後就不太可能持續購買同一家的產品(除非你是 Apple

***

以上故事告訴我們,要推出一個成功的產品,至存在兩個互相衝突的力量 (conflicting forces):
  • Time-to-Market (想想 Eee PC, iPad 或 iPhone)
  • Quality (在這裡我們考慮 reliability)
以現在產品開發的趨勢,Time-to-Market 變得越來越重要,先推出產品把錢騙進來再說,那麼品質有問題該怎麼辦?聰明的生意人就想出了『到府維修』,『到府收送,『快速維修』甚至『終身保固』(是誰的終身?產品?消費者?還是廠商?,以降低消費者的『戒心』
,反正先買先享受,有問題維修很方便。



***

鏡頭回到軟體開發。軟體例外處理的最高境界,就是程式中所有可能發生的例外都被妥善的處理,如此一來在 runtime (程式執行時期)就不會因為有『未被處理的例外 (uncaught exceptions)』而導致程式當機或是系統出現一些不預期的行為。例外處理的目的很清楚,但是實施起來卻很難,關於這一點 Teddy  在『敏捷式例外處理設計的第一步:決定例外處理等級』曾經提到三個主要原因:
  • 屬於非功能性需求的例外處理很容易被忽略(時間不夠)
  • 有些例外是需求面看不到的,要到實做時才會出現
  • 真的不知道要怎麼處理(實做知識不足)
就算是以上三點都不成問題(團隊時間很多,實做的例外有人幫忙分析,開發人員清楚各種例外處理的實做技巧...地表上應該不可能有這種團隊...XD),實務上也幾乎不可能把所有的例外都處理好。為什麼?很簡單,因為『程式中可能會發生例外的地方情況太多了』,而軟體專案除非被取消了,總是有 release 的時間(就算是一個 delay N 年的軟體,它還是有 release 的一天),因此就算是一個資源很充裕的專案團隊,在軟體上市之前也很難把所有的例外都處理好。


想像一下,原本你開發的軟體可以順利執行在 Windows 2008 64-bit,但是有一天使用者安裝了 SP2 更新程式,你的軟體就無法再執行。這種『因為執行環境改變而導致系統無法順利執行』的情況實在太多了,當然你可以辯解說『我們的程式出生的時候,SP2 都還沒 受孕 釋出,我們怎麼可能預測未來?這是 SP2 的問題,不是我們的問題』。無論你如何解釋,對於使用者來說,更新 SP2 之後  Windows 跑得好好的,只有你的程式有問題,所以這當然是你的問題。


所以,兩週後產品就要推出了,環境相容性測試還沒做好,程式還有 一堆  一些 bugs,很多 少數例外還沒處理,怎麼辦?別擔心,Teddy 介紹你吃這一帖,保證 藥到 病除 ,就是:『自動化更新』。

對,就是『自動化更新』,明知軟體產品有問題還是要硬著頭皮推出,還好有自動化更新』這個法寶,當作最後的『安全網』。這就好像 奸商 廠商告訴消費者我們提供『到府維修』,『到府收送,『快速維修』甚至『終身保固』。 這麼好的『服務』,就放心給它敗家下去吧(小朋友出走中...)。

這時候,消費者早就已經忘了,『為什麼以前的電視看 20 年都不會壞,現在的電視看兩年就壞了。總之消費者與業者各取所需,

消費者:先買先享受(口袋又薄了)。

業者:先賺先贏 (股價又漲了)
***


結論:軟體功能做的爛沒關係,『自動化更新』一定要做的好。多學學人家 M$crosoft,多麼認真的更新啊,還會幫你重新開機喔...(路人甲:他馬總統的,我跑了三天的實驗...XD


***
友藏內心獨白:這一篇是抱怨文嗎?


2010年10月13日 星期三

這甘A賽減少 Relearning?

Oct. 12 23:00~ Oct. 13 00:18


M. Jwo (應該是先生) 對於 Teddy 胡說八道的『消除浪費 (3):Relearning』有點建言:

M. Jwo :自動化測試等無法減少 relearning 的時間才對。

Teddy:您說『這不是肯德基 自動化測試等無法減少 relearning 的時間才對』,可否說明原因?


M. Jwo :自動化測試甚至TDD等不是減少relearning,而是減少未來bug的發生。因為測試對裡面的細節不會描述,不然重構就無法發生。如果說自動化測試想要減少relearning,不如寫code的時候命名好一點,讓看到程式碼就能知道寫什麼,讓程式碼就是文件,比起測試部份更好。問題是這些都要回去看程式。真的想要減少除了pair programming以外,比如google實行的變形的方式,必須由supervisor才能commit code這些方法我覺得更好,不但有技術傳承更達到code review的功能。

***


除了虛構的路人甲以外,終於有一個真正的路人對 Teddy 唬爛的內容看不過去了(也許早就有很多...XD),剛好利用這個機會寫一篇文章也好(快沒內容可寫)。

基本上 M. Jwo 的講法 Teddy 完全同意,『寫code的時候命名好一點』,『pair programming』都可以減少 relearning 時間(最後那點關於 google 的作法 Teddy 不了就不加評論)。

大部分的鄉民可能會認為『測試』就是為了『找 bugs』。知道 TDD 的人會說『TDD 是一種設計,不是測試』。不管自動化測試,TDD 的『原意』或是『主要目的』是什麼,Teddy 認為其結果(或是副作用?!)是可以達到減少 relearning 的效果。

想像一下,如果你寫了一個 method X,但是沒有為這個 method 寫 unit tests。一個月後,有人回報你的系統有一個 bug,你花了 5 個小時才找到,原來這個 bug 發生在 method X 中。你『重新學習(重新發現)』到這個 method X 的行為有問題。如果當時有利用自動化測試將這個 method 的『正常行為』記錄下來,而且有頻繁的執行這些自動化測試案例,那麼當問題發生時,便可立即發現(假設你的測試案例可以測出問題),減低『重新學習』的時間。

***

用白話文解釋,有一個人(小明),從小不學無術,到處做壞事,從 16 歲開始就不斷地進出監獄,卻一直沒有學會教訓。一直到小明 50 歲的時候,遇到一個義工,在這位義工不間斷的勸說與教導之下,小明最後終於改邪歸正。此時小明語重心長的說了一句:

小明:如果早點認識你(義工) 我的人生就不同了。

小明就好比是『一支沒有測試案例的程式』,發生了 bugs 卻渾然不知要如何改正,從何改正。即使是坐牢(程式當機)的時候有點苦悶,但是出獄(重新開機)之後又固態復發(期待下一次的當機?!)。


喋喋不休的義工,好比自動化測試案例,當行為偏差的時候可以立即示警,以便即時改正。想一想,小明花了幾十年的時間才學習/重新學習到正常的行為,這當然是一種浪費。

(Teddy 內心獨白:這個例子有點牽強...一時想不出更好的比方)

***

每一個自動化測試案例都紀錄著『程式正常行為的某個執行路徑』,從這個角度來看,逐一去執行測試案例便可逐一的了解程式的(片段)行為,可以跟 code reading 互相搭配服用。
 
依據 Michael C. Feathers 在 『Working Effectively with Legacy Code』的講法,『Legacy code is simply code without tests』。為什麼大家都怕維護別人的系統?因為別人做的東西無法了解啊,就算設計的再好(套用一堆偉大的 patterns),程式的名子取的再棒(Kent Back 附身),只要沒有測試案例,難保改一行產生 N 個 bugs。

換個角度來看,如果鄉民們交接到一個有完整測試案例的系統,你新增了一個功能,跑了全部的測試案例,發現沒有問題,於是你『大膽假設』你沒有把系統改壞。所以,如果你沒有時間,你就不需要去立即被迫去『學習』這個系統的程式碼(延遲決定)。也就是說你可以暫時完全排除 relearning 的需要,這樣應該也算是有給它『減少 relearning 時間』的啦。

結論

阿貶內心獨白:自動化測試有沒有減少 relearning 的時間...有那麼嚴重嗎?!趕快放我出來先。

***
友藏內心獨白:感謝 M. Jwo 激發 Teddy 另一個瞎掰靈感。

2010年10月10日 星期日

消除浪費 (4):Handoffs

Oct. 10 22:39~23:40

『七浪費』之四:Handoffs,英翻中的解釋是『交接』。為什麼交接是一種浪費?舉個例子,有點年紀的鄉民們,應該都知道一種叫做『喝水傳話』的遊戲,玩遊戲的人排成一排,主持人先把謎底(通常是一句話)告訴第一人,然後這個人嘴裡要含著一大口水,頭朝上把剛剛主持人告訴他的那句話傳給第二個人,依此類推一直傳下去。通常最後一個人所聽到的內容和原本的那句話早已差了十萬八千里了。

一件工作,轉過一手之後,所剩下來的知識若能有原本的 50% 就算是很不錯了,所以,如果這件工作轉了 5 手,那麼就只剩下 3% 的知識

第一手 50% -> 第二手 25% -> 第三手 12%-> 第四手 6%-> 第五手 3%

知道的東西越來越少,就需要花更多的時間才能把事情做好,所以交接是一種浪費的行為

***

『交接』,從另外一個角度來看,又可以稱為:把『屎虧(不想去碰的工作)』丟給別人去做。相信大部分的鄉民都有把工作交接的別人,或是從別人那裡獲得交接工作的經驗,通常這種經驗都很差。

交接者內心獨白:我已經使盡渾身解數把知道的告訴你了,沒學到算你笨。

交接者內心獨白:東西這麼多,交接時間那麼短,你又講的這麼籠統,我怎麼可能學得會。一定是存心想要留一手不告訴我。(Teddy 補充:套句學弟常常說的話,『學長又沒交接給我!』)


一件工作丟來丟去,經驗傳承下去的比例也就越來越少,所以接到『屎虧』的人就要花更多時間去完成這件工作,這種經驗流失與需要耗費額外時間(包含把工作交接給別人所花的時間)才能完成工作當然也是一種浪費。



***

那麼,要如何減少交接的浪費呢?書上提了幾個方法:
  • 降低交接的次數(Teddy 內心獨白:這不是廢話嗎...XD)。
  • 組織 design-build 團隊(就是 Scrum 所說的 cross-functional teams。關於這一點 Christopher Alexander 早就提出類似的建議,請參考 Teddy 另一篇『Architect-Builder』。
  • 使用『寬頻』溝通方法。盡可能用面對面溝通(face-to-face)取代文件式溝通。(Teddy 內心獨白:Apple 聽到您的心聲,所以開發了 FaceTime。眾鄉民們還不趕快乖乖掏錢去買一隻 iPhone 4。)
  • 儘早且頻繁地釋出部份(先期)作品以便於獲得回饋。這句話 Teddy 要解釋一下,原文比較長:『Release partial or preliminary work for consideration and feedback--as soon as possible and as often as practical.』假設團隊中有 programmers 和 testers,如果 programmers 『自認為』程式已經做完了,所以把程式交給 testers 去測試(這就是一種『交接』)。但是如果在開發的過程中,programmers 從來都沒有跟 testers 討論過,那麼經過交接之後,testers 很可能不知道要如何測試,或是說無法測出真正的問題,甚至會測錯(都算浪費)。如果 programmers 在開發的過程便可以和 testers 討論,那麼便可以減少這樣的問題。

最後補充一點, Teddy 認為用來減少 relearning 的 agile practices,像是 pair programming 或 collective ownership 也都可以減少 handoffs 所造成的浪費。

*** 

友藏內心獨白:國慶日還沒休息,夠意思了吧。

2010年10月9日 星期六

消除浪費 (3):Relearning

Oct. 09 22:20~23:41

今日談談『七武器 七浪費』之三:Relearning也可以稱為『rework』。如果一次就能做好,就不需要『rework』,所以 『第二次(或以上)』的 work 當然就是一種浪費。但是為什麼不直接說 rework,而要咬文嚼字的說 relearning?

由於軟體開發事實上就是一種『學習新知的過程』,因此減少重新學習已知的知識,就可以減少浪費,所以特別用 relearning 來強調『軟體開發實為學習新識』的特質。例如,團隊中有老鳥跟菜鳥,菜鳥被分配到開發『用 Java NIO 實做非同步檔案讀寫』的某項功能老鳥對於此功能的技術十分熟練,但是被分配到該工作的卻是菜鳥。於是
  • 菜鳥花了一整天搞懂什麼是 Java NIO。
  • 菜鳥再花一天實做非同步檔案讀寫與撰寫單元測試
  • Tester 花了兩小時測出菜鳥所寫的程式有 5 個 bugs
  • 菜鳥解了其中的 3 個 bugs,另外 2 個看不出來問題再哪裡。
  • 菜鳥請老鳥幫忙做 code review,老鳥只花了 10 分鐘就找出 8 個 bugs (原本尚未解的 2 個  bugs 外加 6 個 tester 沒測出來的 bugs)。
  • 菜鳥將這 8 個 bugs 解完。
  • 經過這一番過程,菜鳥獲得 10 點經驗值,菜鳥一級升級為菜鳥二級
以上整個過程花了 6 個工作天,如果可以縮短學習的時間,便可減少時程的浪費。

***

大量的 relearning 對於軟體開發是一件『很傷』的事情,但是卻很難完全避免 relearning。團隊中幾乎不可能每一個人的知識與經驗都相同(如果能夠找『博格人』來開發軟體就太好了... 什麼,不知道博格人是什麼?來人啊,拖出去...看...Star Trek),因為『派工(分工)』的關係,又不可能把每件工作都交給最懂該工作的人來實做,因此便會造成 relearning 的現象。

另外,人是很『健忘的』,以前做過的事,曾經發生過的問題,日子一久,經常會忘記,因此相同的問題可能一再的發生,這也是 relearning(此時如果能找到『曾子』來開發軟體就好了,因為論語有紀載:『曾子不貳過』,這種人才找來寫程式最好)。


***

光知道 relearning 是一種浪費,那麼要如何減少 relearning 造成的浪費,這就傷腦筋了。請鄉民們想一下,有沒有哪一個 agile practices 是可以減少 relearning?知道答案的人,請將答案寫在明信片上,來信請寄『台北郵政 5408 號信箱』,前五名答對者本節目將提供神秘小禮物... XD

其實很多 agile practices 都和減少 relearning 有關,例如:
  • 自動化測試:將程式正常行為的『知識』紀錄在自動化測試程式中,當自己或別人不小心產生 bugs 時(破壞程式正常行為),能夠透過紀錄下來的知識立即發現問題(就是這些自動化測試案例),如此便可減少  relearning 所花的時間(可參考 『需求分析書中最重要的資訊是什麼』這篇)。
  • 採用 Design by Contract 或是 assertion。理由類似自動化測試,這些技術在 runtime 都可自動驗證程式的行為是否符合原本的預期。
  • Pair programming:師徒制是傳遞知識最好的方法之一,雖然過程辛苦了點。


族繁不及備載,請各自發揮。

***

友藏內心獨白:程式設計師徵人條件:具有博格人和曾子的性格。


 

2010年10月6日 星期三

消除浪費 (2):Extra Features

Oct. 06 22:27~23:46

Extra Features (多餘的功能)是軟體開發七種浪費行為中,最嚴重的一種浪費。為什麼?道理很簡單,如果某項功能連寫都不需要寫,那就不會因為要開發該功能而產生『Partially Done Work,Relearning,Handoffs,Task Switching,Delays,Defects』這些浪費的行為了。與其做出客戶暫時不需要的功能,而日後需要『時時勤拂拭,勿使惹塵埃』(開發與維護這些功能使其正常工作),還不如採取『本來無一物,何處惹塵埃』的策略,不是省事多了。

路人甲:那乾脆什麼都不做,不是最好。

Teddy :我也想什麼都不做啊,可是到了這種極端,你的銀行帳戶也會跟著『本來無一物,何處惹塵埃』。畢竟鄉民們大概都還是屬於俗世中人,尚未修煉到不食人間煙火的境界,所以『該做的,還是要做』。至於哪些是該做的,哪些是不該做的,就要靠各位的『智慧』去判斷了..XD。


***

舉個例子,Teddy 最近看到 Kay 買了 iPhone 4,覺的好心動,不由自主的便稍微研究了幾款智慧型手機,包括 HTC Desire,HTC Desire HDHTC Desire ,Nokia N8...,每一款都好想買。於是,Teddy 心中的小惡魔就不斷地找理由說服 Teddy,『智慧型手機好棒,可以為你的生活帶來極大的便利,趕快買一隻,趕快買一隻

在激情過後,Teddy 發現不管是那一款手機,目前暫時都不需要,先用 Kay 的 iPhone 4 就好了。Teddy 想起『住左邊,住右邊』這齣連續劇,裡面有一句對白,『公家有,用公家,公家沒有用朋友』,這樣最省的啦。如果 Teddy 當時衝動之下跑去買了不需要的手機(Extra Features),那就是大大的浪費了(Teddy 內心獨白:如果口袋夠深的話,好想給它浪費一下...XD)。這種情況在逛大買場的時候也常常發生,就算是事先寫好了購物清單,一不小心還是買了不必要的東西回家。


***

各位鄉民以前求學的時候,或多或少都有受到傳統軟體開發方法的洗腦,認為軟體專案事前的(需求)分析做的越多越好,系統要很有彈性,以便應付日後未知的新增需求(請參考『你的軟體架構有多軟』),搞得這些做軟體的人好像『算命師』一樣,要能預測未來。這種『過於彈性的軟體架構』或是程式設計師基於『追求使用最新技術的爽度所幻想出來的需求,就好像你的下一隻智慧型手機,下一雙高跟鞋,下一件衣服,下一台 3D 電視下一個女朋友,下一  XXX 一樣,過早投資,通常都是一種浪費。


問題來了,古人有云,要『未雨綢繆』,難道事先準備有錯嗎?不是都說『有備無患』,怎麼現在綢繆』和有備』都變成一種浪費啦,那是不是說每天只要躺著在家裡睡覺就可以當選啦。食神 軟工,我真是猜不透你啊!


長話短說,把握幾個 agile 精神:
  • 最高境界:本來無一物,何處惹塵埃。不需要的功能,就不要做。
  • 撐到最後一刻逼不得已時再做決定。問氣象局一個禮拜後的天氣,準確度可能只有 50%。若是問『今天』的天氣,準確度可能有 90%。如果問『昨天』的天氣,準確度就有 100% 啦。所以,愈晚做決定,通常比較不會出錯。這就是為什麼人人都可以當『事後諸葛亮』的原因。
  • 採用演進式設計。
  • 創造支援『逐步成長 』的開發流程,開發環境,與軟體架構。
  • 對於已經開發完成的功能,要『時時勤拂拭,勿使惹塵埃』。這跟養小孩一樣,要嘛就不生,既然生了,不管長相如何,身體是否健康,都要好好照顧。
講完收功。

友藏內心獨白:以上所言,不適用於『老子就是錢多,就是要促進消費,你咬我啊』這種類型的人。






2010年10月5日 星期二

消除浪費 (1):Partially Done Work

Oct. 05 22:21~23:28

在『軟體庫存』這一篇,Teddy 提到可以藉由降低軟體庫存來改善軟體開發流程。這裡面的想法其實是來自於 Implementing Lean Software Development: From Concept to Cash 這本書。該書將『Toyota Production System (TPS)』所提到藉由減少七種不必要的浪費來提昇產品品質的精神,套用到軟體開發中,用以降低開發成本並且改善軟體品質。


這七種浪費分別是 (括號為 TPS 中所採用的名稱),分七次逐一說明:
  1. Partially Done Work (In-Process Inventory)
  2. Extra Features (Over-Production)
  3. Relearning (Extra Processing)
  4. Handoffs (Transportation)
  5. Task Switching (Motion)
  6. Delays (Waiting)
  7. Defects (Defects)

Partially Done Work 

東西沒做完,這些半成品無法出貨給客戶,只能放在家裡,時間一久可能會有發霉的疑慮。屬於這類的例子有『尚未被實做的需求文件,尚未 check-in 的程式碼,尚未被測試的程式碼尚未被佈署的程式碼』。Partially Done Work 是一件很可怕的東西,首先,它會讓開發團隊有一種『進度正常甚至超前』的錯覺。


程式設計師們:功能都寫好了啊(其實還沒完整測試,所以只能算『半成品』)。


專案經理:好開心,好開心,每個人的工作都做好了。

經過  N 天之後,專案截止日期快到了。

專案經理:騙肖ㄟ,系統連安裝都有問題,是誰說做好的?(Teddy 內心獨白:胃潰瘍又發作了。)



***

其次,這種半成品數量太多,時間一久,開發團隊都忘了系統中哪些東西是可以用的,哪些是半成品。到時候整個系統要整合起來,又是一大問題。再者,東西放太久沒用是會『壞掉』的,沒錯,軟體或文件也會臭酸(路人甲:那放在冰箱不就好了...)。

例如,以傳統的軟體開發方式,撰寫程式之前,一定要先做『需求分析』,然後產出一本厚厚的『需求分析書』(路人甲:人家的需求分析書怎麼只有薄薄的幾張 A4 紙,而且還是用 double spaces  排版過的...XD)。假設這本分析書是用 use cases 格式撰寫,裡面包含 100 個 use cases,此時這本分析書就是『尚未被實做的需求文件』,屬於 Partially Done Work 的一種。假設開發團隊每一個 iteration (兩週) 可以實做完成 3 個 use cases ,經過半年後也才完成 36 個 use cases。剩下的 64 個 use cases,經過這半年後,還有多少是屬於『值得信賴』的 use cases 呢(不需要修改依然有效)?

開發過軟體的人應該都知道,『需求一直在變』是軟體專案唯一不變的真理,所以,從這個角度來看,太早把需求寫完』並不是一件好事,因為太早寫完之後如果沒有足夠的資源能在短時間內實做完成,那麼這些沒實做完的需求,放久之後是會『壞掉』滴(feedback loop 太長,時間拖太久)。

東西放著讓它壞掉,你說這是不是一種浪費?

所以,在 Scrum 中,希望開發團隊要為每一項 task 與每一個 story 定義完成條件 (the definition of done),以避免這種 Partially Done Work 的現象,這就是一種消除浪費的手段

***

友藏內心獨白:有沒有數位冰箱可以存放尚未實做完成的文件和程式碼?



2010年10月4日 星期一

0 與 1 的距離

Oct. 04 20:17~23:42

幾年前 XP (eXtreme Programming) 正在流行的時候,其中一個經常被問到的問題:導入 XP 是不是一定要全盤採用 XP 的 12 的 practices(the planning game, small releases, metaphor, simple design, testing, refactoring, pair programming, collective ownership, continuous integration, 40-hour week, on-site customer, coding standards)?


在當年,軟體開發團隊掛上 XP 可是很酷的一件事,所以,有些團隊可能不了解 XP 到底是什麼,只是隨便寫寫 test case 或是做做 refactoring 就宣稱『我們團隊採用 XP』,感覺走在時代尖端。為了刷掉這些名不符實的團隊,XP 的虔誠信徒會告訴你:『要買就要買整套的,缺一不可』(Teddy 內心獨白:這還真不容易,感覺有點像是在收集小丸子文具組... 救人啊,怎麼 Teddy 拿到的都是『野口』!)。但是,務實派的人會說:『只拿對你有幫助的就可以了(就算是拿到『野口』也 OK)』。此時 XP 的虔誠信徒會說:『這不是肯德基 如果不全盤採用,就不要對別人說你是 華山派 XP 門下子』。

這種『派系之爭』的歷史一再重演,這幾年 Scrum 竄起,很多人又想跟 Scrum 沾上邊。因此,Scrum 大師們怕大家沒事往自己臉上貼金,或是利用這個噱頭到處騙錢,信口開河說自己或是團隊擁有 Scrum 的經驗,因此也要時時提醒,哪些情況是真正符合 Scrum 的精神,哪些是濫竽充數


Teddy 曾經因為這種『血統之爭議(正港的 Scrum 或是冒牌的 Scrum)』 困擾了一陣子,為什麼呢?因為咱們寶島台灣,要找到一家公司可以完完全全,徹徹底底的實踐『理想中的 Scrum』相信是不太容易滴(也許用一雙手可以數的完),那麼其他廣大開發軟體的人,難道就因為『無法達到理想的條件』不可以親近 Scrum 嗎?

舉個例子,一個 5~6 人的小公司,準備開發 iPhone 軟體,他們可以找人扮演 Scrum Master,開發團隊成員也沒問題,但是沒有『專門的 Product Owner』 。怎麼辦?最後決定由最有經驗的人 (扮演 Scrum Master 的那個人) 同時扮演 Product Owner。完了,Scrum 的書上說,Scrum Master 和 Product Owner 不可以是同一個人啊?那怎麼辦?

再舉個例子,在 Scrum 中『績效考核』是以看『整個團隊』的績效,而不是看個人。但是,如果公司打考績的時候,你跑去跟老闆說:『因為我們採用 Scrum,所以每個團隊成員的考績都一樣』,Teddy 相信首先陣亡的人應該是你。


再來,Scrum 的目的希望能營造出一個『自我管理的團隊』... 理想很好,但是這些『刁民(team members)跟牛一樣,進一步退兩步,要維持好不容易已經改善的一點點現況都很難了,別談什麼自我管理。

最後,雖然 Scrum 沒有硬性規定『不可以加班』,不過 agile methods 的精神應該都還是以『不加班為原則』。光是這一點全台灣可能 95% 以上的『高科技』公司就不符合了,那不是沒搞頭了。
***

實際上,日子還是要過下去。不完美的環境,並不能阻止我們追求更好的工作方法與生活品質。舉個例子,Teddy 住在『艋舺』一棟 30 幾年的四層樓老公寓,Teddy 到國外旅行時,看到法國,瑞士,日本,美國的超優生活環境,回國之後難道要把自己家裡『炸掉』重蓋(不可能,因為口袋不夠深,而且不合法)或是繼續『苟且偷生』不做任何改變?在這兩個極端的選擇當中,還是有其他的選項。
  • 老屋拉皮。
  • 重新油漆。
  • 更新照明。
  • 種花。
  • 掛畫。
  • 貼明星海報 ... XD。
Teddy 之前介紹過的 『The Quality Without A Name (QWAN)』這個概念,導入 agile methods,CMMI 也罷,要追求的是軟體開發的 QWAN。認清自己的現況,了解軟體開發的 QWAN(軟體開發的本質),兩者相減就是自己可以努力的空間


改善的過程並不是 0 或 1 的問題(要嘛什麼都不做,要做就一步到位),而是 0 慢慢地,慢慢地往 1 靠攏的過程。0 與 1 之間,還是有很廣大發揮的空間。

***

友藏內心獨白:那一天才能夠爬到 1 的那一端?

2010年10月1日 星期五

傳福音

Oct. 01 19:12~20:04


今天搭 307 公車的時候,坐在 Teddy  身旁的陌生人 A 君,在公車快到了華中橋時突然開口。


A 君:請問這公車有到車站嗎?

Teddy:有。

在反射性的回答『有』之後,Teddy  心想由於 307 公車有經過『台北車站』和『板橋車站』,因此好心的 Teddy 就問 A 君。

Teddy:你是要到『台北車站』嗎?


A 君:對啊,到台北車站轉搭捷運到龍山寺

身為『艋舺』在地人的 Teddy,忍不住告訴 A 君。


Teddy:你要到龍山寺,在西門町下車搭捷運比較快,不用到台北車站。

A 君:在西門町下車喔,那要搭那一線捷運?

Teddy:板南線。
 
A 君:到站的時候你可以告訴我嗎?

Teddy:好啊,我也要去西門站

A 君:你該不會也要去龍山寺

Teddy:沒那麼巧啦。

過度熱心的 Teddy 不小心開啟了 A 君的話匣子。


A 君:你是學生,還在唸書吧?

Teddy:沒有啦,早就畢業了。

A 君:結婚了嗎?

Teddy:沒有。


A 君:你有信仰嗎?

Teddy:沒有。


A 君:我是信基督教的,有人跟你傳過福音嗎?

Teddy:沒有(此時心中出現三條線)。


A 君:沒有?

Teddy:應該說,我沒有興趣。


A 君:我告訴你,耶穌(還是上帝,Teddy 有點忘了)就像空氣一樣,到處存在,隨時都可以取用,幫助你。

Teddy:點頭傻笑...


A 君:我以前曾經在大陸工作,遇到搶匪拿刀,拿槍搶劫,差點沒命。後來是靠禱告,把自己交給上帝,才渡過難關。

Teddy:點頭傻笑...


之後 A 君又繼續他的傳福音工作,Teddy 繼續點頭傻笑(因為 Teddy 坐在公車最後面靠窗的位置,想跑也跑不掉啊!

轉眼間公車已經到了『西藏路口』,前面停了一輛 62 路公車,此時 Teddy 靈機一動。

Teddy:如果你是要去『龍山寺』,可以在下一站『萬大路口』下車,轉搭前面的 62 路公車,這樣比較快。或是可以走路,大概 800 公尺左右。


A 君:喔,那我走一下路好了,順便看看路上有沒有賣水果的。

Teddy:(內心獨白) YES。

***


Teddy 講上面這個故事不是要取笑 A 君,事實上 Teddy 還滿佩服他的。年輕的時候,Teddy 對於這種『侵略式 』或是說『主動式』傳福音的人的確有點反感,直到有一次 Teddy 在跟指導教授聊天時,指導教授說:『其實要去推廣 Scrum (或是其他軟工實務作法),就好像是傳教一樣,你自己認為有好東西要告訴別人,希望別人也能受益,但是想想看如果你在路上遠遠看到摩門教徒,你的第一個反應一定是趕快繞路逃開,以免他們來煩你』。

啊,說得真是太對了。其實人都是活在習慣中,對於未知與陌生的環境都多多少少都會有點『不安』或是『排斥』感,要打破這種『慣性定律』是很難的。A 君信基督教,他相信這是很好的,所以想把『福音』傳給 Teddy,而 Teddy 的內心卻是抱持著『我不需要,不要煩我』的心態。相同的,Teddy 相信 Scrum 與軟工,也想把這種『福音』傳給身邊的人,但卻也是困難重重。


洪蘭在她的書中說過,當年她要去美國留學時,她爸爸告訴她:『妳到國外,對當地人而言就是外國人,被人家歧視,受委屈是理所當然的,不要怨天尤人,要靠自己努力證明給別人看』(大意大概是這樣)。改變現況,從來都不是一件容易的事,別人不接受,抗拒,搞破壞,都是正常的。所以在公司內要嘗試導入 Scrum (或是任何新制度)的人,最好要有『傳教士』的精神,傳福音沒什麼好氣餒的,永遠保持正面的力量。


西門站,陽光普照,嘴角一抹微笑。


***


友藏內心獨白:不要變成『電視名嘴』,光說不練。