消除浪費 (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 的現象，這就是一種消除浪費的手段。

***

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

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 的那一端？

傳福音

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 （或是任何新制度）的人，最好要有『傳教士』的精神，傳福音沒什麼好氣餒的，永遠保持正面的力量。


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

***

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

過勞死之軟工無用論

Sept. 28 22:20~ Sept. 29 00:08

這幾天有一則新聞，某 29 歲任職於『南邊來了個 亞 啞巴』之高科技公司員工『疑似』加班過度而過勞死，公司的反應卻是極力想撇清關係。據水果日報報導：『南邊來了個啞巴科技副總白培霖說，公司對較有能力工程師及主管採責任制，上班時間由員工自己判定，也積極宣導員工盡量休假、上下班時間正常。 』

這種說法是不是說：

• 『公司對較有能力工程師及主管採責任制』，這麼說起來責任制是一種光榮耶。不用懷疑，當年日本『神風特攻隊』一定也是採取『責任制』。
• 不屬於責任制的員工們，立正站好，好好反省一下，這表示你們『比較沒有能力』。不過別難過，老子云：柔弱生之徒。恭禧各位沒能力的非責任制員工得以僥倖存活下來（Teddy 內心獨白：學生算不算責任制？）。
• 『上班時間由員工自己判定』，這種說法好比說『釣魚台是日本 故有 固有領土』一樣唬爛。

Teddy 內心有種感覺，台灣公司老闆普遍存著『加班就是好員工，不加班就是 不孝 不認真』的心態。反正：『別人的孩子死不了』，離職再找人就好。反正老子有錢，叫你作你就做，做不完，反正『上班時間由員工自己判定』，你就好好地『自己判定』一下。

***

Teddy 從事軟體業（ㄟ... 在硬體公司寫程式算軟體業嗎？），常常聽到其他人說：『啊，軟體工程在業界行不通啦』，『兩天的訓練課程要一萬塊，這麼貴（Teddy 內心獨白：那請問多少錢您老大才覺的合理？）』。這種打從心底認為『開發軟體沒什麼學問』的心態，當然會做出『沒什麼學問的軟體』出來。偏偏這些老闆們又認為這些開發軟體的員工屬於『有能力工程師』（這不是自相矛盾嗎？沒學問的事情應該不需要有能力的人來處理吧。），反正只要員工們好好的『自己判定一下上班時間』，任何問題都可以搞定，Yes，you can。

軟體工程到底有沒有用，Teddy 舉的例子。軟體工程裡面有一種軟體設計的方法，稱作 Design By Contract （DBC），DBC 的原則十分簡單，但威力卻很強大。基本上寫程式就是『我 call 你的 code (API or method)，你  call 我的 code』。在這種 『彼此互相 call 來 call 去』，的互動當中，程式可以區分為兩種不同的角色：『caller』和『callee』。

• Caller：呼叫別人以獲得服務的人（有點繞口），在 DBC 中稱為 client。例如，我去銀行請行員幫我開戶，我就是 client。
• Callee ：被別人呼叫並提供服務的人，在 DBC 中稱為 supplier。例如，我去銀行請行員幫我開戶，行員就是 supplier。

有了這個觀念之後，接下來的規則就很簡單了。每個程式（姑且就先想成一個 method 好了）都應該有它自己的 precondition 與 postcondition。

• Precondition：想要執行這個 method，那麼這個 method 的 precondition 必須要成立才可以。 這就好比日劇『大和拜金女』裡面松島菜菜子對於擇偶條件一定要是『好野人』一樣，這就是『要跟大和拜金女交往的 precondition』。
• Postcondition：執行這個  method 之後，該 method 保證一定會成立的條件。例如『大和拜金女』為了吸引『好野人』跟她交往，可能訂出『聯誼一次可獲得香吻一枚』這種 postcondition。

鄉民甲：這和程式設計有何關係？

問的好，今天先談一下 precondition 的好處。 在開發軟體的時候，其實 programmers 經常做了很多『大膽的假設』與『小心的檢查』：

• 這個傳進來的參數會不會是 null 呢...ㄟ，不知道，那就 if (str != null) {do something}。
• 讀取一個由其他程式所產生的檔案，萬一檔案格式不對怎麼辦？

很多人直覺的反應就是『既然不知道別人傳進來的資料是否正確，那就自己再多檢查一遍啊，反正多檢查一次也不會怎樣』，這種作法就叫做『defensive programming』，看起來很不錯啊，但這卻很可能是一種造成加班的原因。為什麼？想像一下，如果你是銀行行員，有人拿『黃金』來『存錢』，你需要先幫顧客把黃金換算成現金，然後再把這些現金存到顧客的戶頭嗎？。大部分的銀行應該沒有提供這麼感恩的服務吧，所以，關於存款這個服務，應該會有類似的  preconditions：

• 必須是（新台幣）現金（其他貨幣或是有價物品一概不收）
• 必須是真鈔（否則報警）
• 必須是現行流通的版本（拿舊版的新台幣就可以不用處理）
• 貨幣本身必須完整可辨識（被火燒過或是被蟲蛀的紙鈔請先找調查局鑑定）

有了這些 preconditions 之後，這個 supplier 的實做 (行員的服務內容) 就變得很明確，講成白話文就是，如果需要寫一隻支援行員的程式，那麼這隻程式的『輸入』就很明確，也就不需在程式裡面做一些有的沒的檢查，需要寫的 code 自然也變少了 (大體上是這個味道，想了解細節還是要看一下 Object-Oriented Software Construction 這本書)。

***

扯了這麼一大段，回到主題。記得 Teddy 曾經看過某本書，書中提到有效率跟沒效率的 programmers 其生產力好壞可以差到 10 倍。如果企業文化就是『開發軟體沒什麼學問』，『軟工無用』，『加班萬歲』，在這種環境的 programmers 那可能去管什麼『DBC，Exception Handling，Refactoring，Agile，SCRUM，Design Pattern，Unit Testing...』(就算 Teddy 雞婆想要去教免錢可能還被對方嫌沒空)。反正，這一堆『沒什麼學問的東西』老闆，主管也不懂啊，只有『程式能動才是王道』，其他的任何事都不要來煩我，因為我是『較有能力』的工程師，我只需要『上班時間自己判定』這個萬能的武器就夠了。

感覺好像現代版的『神風特攻隊』。

***

友藏內心獨白：DBC 之前不是已經介紹過了嗎？！

出差照片 (2)：蠟像館

Sept. 23 23:36~ Sept. 24 00:16

接續昨天沒貼完的照片（上載圖片有點慢）。

去參觀中國戲院旁邊的蠟像館，一進門就是 歐買尬 歐巴馬總統在白宮前歡迎您。

蠟像館中的人物實在太多了，在裡面待了快 2.5 小時，以下隨便挑幾張鄉民們任意瞧一下。

有總統，當然也要有州長。

追殺比爾 蓋茲 （想必是常常看到藍底白字的畫面... XD）。

金痞子凱瑞先生

企業號前後任艦長（怎麼沒有航海家號的 seven of nine？）

人生就像一盒巧克力之阿甘等公車

亂世佳人男主角

亂世佳人女主角

常常傻傻講錯話的大鼻子成龍

最後以鋼鐵人結尾 (這不是蠟像啊！)

***

友藏內心獨白：沒想到在蠟像館拍照能有這麼好玩。

出差照片 (1)

Sept. 22 23:31~ Sept. 23 00:11

今天中秋節，貼幾張 Teddy 出差時所拍攝，覺的有趣的照片。

Teddy 出差的最後一個禮拜剛好遇到美國勞動節，包含六日一有三天連假，Teddy 和幾位美國同事到 LA 玩了一趟。下面這張照片是在某地下停車場所拍攝，注意每個停車位上方都有一個小燈，綠燈表示車位是空的，紅燈表示車位有人使用。這樣在找停車位的時候，遠遠就可以看到哪裡有車位，還滿方便的說。

Apple 專賣店所展示的超大 iPad，橫的擺都可以當作電視機使用了。

在飯店不小心轉到海綿寶寶的節目，這一集 Teddy 在台灣已經看過了。

飯店房間有一台有趣的泡咖啡機器，之前沒見過長這樣子的。

這是咖啡粉，有不同『口味』。什麼，你問 Teddy 泡出來的咖啡好不好喝... 這... 因為不是免費的，所以 Teddy 無福享用。

這是『星光 大道 人行道』

好長的車子，上面還有辣妹（這不是電視影集才有的畫面嗎，居然活生生出現在 Teddy眼前）。

路邊有超人和蝙蝠俠跟遊客拍照賺小費。

夜深了，明天還要上班，先這樣。

友藏內心獨白：親愛的鄰居，怎麼還在烤肉？

需求分析書中最重要的資訊是什麼？

Sept. 21 23:04~ Sept. 22 00:14

Teddy 這次到美國出差，利用 Amazon 在美國國內買書不用運費的優惠，一不小心買了 10 本書（標準的貪小便宜心態），等要回台灣打包行李時才發現，這還真有點快放不下（要不是幫剛做完月子沒多久的同事帶了六個奶瓶回來，可能會買更多書... XD）。不過這不是重點，今天的主題是 Teddy 要介紹一本此行出差所買的書：Bridging the Communication Cap: Specification by example and agile acceptance testing。

當初會買這本書是因為被書名副標題『Specification by example and agile acceptance testing』所吸引。記得當年 Teddy 還在念博速班的時候，看過 Phillip G. Armour 所寫的一篇 paper，叫做 The Case for a New Business Model: Is software a product or a medium?, Communications of the ACM, pp. 19-22, August. 2000。這篇  paper 提到有五種儲存知識的媒介：

• DNA
• Brains
• Hardware
• Books
• Software

Paper 細節就容 Teddy 偷個懶，請鄉民們自行發掘。當年 Teddy 看完的感想是，一般的軟體需求都是以『文件』形式存在，屬於上述第四種知識儲存媒介（book）。但是軟體開發的最終產品卻是以第五種知識儲存媒介（software）存在（這算是所謂的『阻抗不匹配嗎？』）。所以，問題來了，軟體開發人員就需要確保這兩種不同的知識儲存媒介（想表達相同的事情---軟體功能或需求）是否同步（軟體工程裡面所謂的  traceability）。相信大家都知道軟體開發人員都很忙，沒有那個美國時間去更新需求文件，因此需求文件所記載的內容與程式碼實際完成的功能經常有所出入也是很『正常』的現象。所以，到底要相信文件還是要相信程式碼，便成為許多軟體開發人員心中的痛（鄉民甲：其實... 兩者都不可信...XD）。

所以，Teddy 當時就在想，如果能夠將軟體需以 software 的形式表達，那麼需求與產品都是以第五種知識儲存媒介（software）來紀錄，是不是就可以減少『阻抗不匹配』的問題？此外，由於軟體具有『可執行』的這個特性，因此就有可能自動驗證『需求』與『軟體系統』是否『同步』。

講了這麼多，還沒轉台的鄉民們，再看一次這本書的副標題：『Specification by example and agile acceptance testing』，其實是有類似的味道。許多做 agile testing 的人都知道所謂的 agile acceptance testing，在開發一個 story 的時候，先幫這個 story 寫一個 acceptance test case （當然此時這個 test case 一定會失敗，因為程式碼都還沒出生啊），中間經過一連串開發過程（細節跳過），最後如果這個 acceptance test case 通過，就代表這個 story 完成。從另一個角度來看，我們可以說這個 acceptance test case 紀錄著它所代表（測試）的那個story 的知識。

***

講了這麼多，其實這全部都不是重點，回到本篇的重點：『需求分析書中最重要的資訊是什麼？』

答案：寫這本需求分析書的那個人的電話號碼。

來源請參考本書第 25 頁：

Ron Jeffries said, during his session on the natural laws of software development at Agile 2008, that the most important information in a requirements document are not the requirements, but the phone number of the person who wrote it.

這本書目前只看了 20％ 左右，有機會看完的話再跟鄉民們報告。

*** 

友藏內心獨白：親愛的鄰居們，夜深了，烤肉用具可以收起來了。搞得空氣中都是烤肉味道，怎麼睡覺啊。