消除浪費 (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。

消除浪費 (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 的訊息。

敏捷式例外處理設計 (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）

***

友藏內心獨白：這一篇是抱怨文嗎？

這甘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 另一個瞎掰靈感。

消除浪費 (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 所造成的浪費。

*** 

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

消除浪費 (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：師徒制是傳遞知識最好的方法之一，雖然過程辛苦了點。

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

***

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


 

消除浪費 (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 HD，HTC Desire ，Nokia N8...，每一款都好想買。於是，Teddy 心中的小惡魔就不斷地找理由說服 Teddy，『智慧型手機好棒，可以為你的生活帶來極大的便利，趕快買一隻，趕快買一隻』

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

***

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


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


長話短說，把握幾個 agile 精神：

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

講完收功。

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