l

2011年3月28日 星期一

都市游擊隊

March 28 20:06~21:13

看到標題不要以為這一篇是要談 online game 或是恐怖份子,今天要談的還是 Scrum。

不知道鄉民們有沒有這種經驗,學習了 Scrum ,任何軟體工程的方法或是所謂的 best practices,想要在自己的團隊中大展長才,好好地應用一番,但是卻不時遇到亂流,地震,甚至是海嘯:
  • 在硬體公司中軟體開發不受重視。
  • 沒有資源,要什麼沒什麼。要 tester... 自己測;要 technical writer...自己寫;要測試...沒設備...
  • 人力都已經極端不足了,還被抽調人手去支援其他專案。
  • 計畫比不上老闆的一句話... 時程和需求一直變更。
  • 隔 team 如隔山,而且還是喜馬拉雅山。所有工作只要牽扯到其他 team (同部門或不同部門)就變得窒礙難行。
  • 三姑六婆與鄉民們總是在該講話的時候不講話,不該講話的時候亂放炮。
  • 有些鄉民一時興起想要教你如何『用嘴巴開發軟體』。
  • 另外有些鄉民想要『靠不停的轉寄 email』來了解客戶的需求。
  • 還有些大爺們希望你帶領著『九條好漢』在一年內完成反攻大陸的偉業。
遇到這種情況,請問單兵該如何處置?

請鄰兵以火力掩護我....

很抱歉,鄰兵不是老早就已經『投共』,就是正在以『省電模式』運行中,哪來的火力支持你。

Scrum 告訴我們,要改善團隊,改善產品,改善公司...拜託,人家都可以用飛彈去攻擊示威的民眾了,還是『趴著,趴著,卡賣中槍』。

***

無論你是 Scrum Master,Product Owner 或是 Development Team,是不是也曾幾何時感到空虛,感到寂寞,感到冷,想找一個不是那麼臭的男人 想找一家不是那麼臭的公司來混一混....

請看『建築家 安藤忠雄』這本書,學學他的『都市游擊隊』哲學。

『住吉長屋』是安藤忠雄的出道作品,該建築的特色是:
  • 房屋四面都被牆包圍,沒有對外的窗戶。除了入口以外,沒有別的開口。
  • 整個房屋都是清水混凝土的表面。
  • 把已經很狹小的長方形建地再切成三等分,中間當作露天中庭。
有興趣的鄉民們 google 一下『住吉長屋』就可以找到一些照片。當 Teddy 讀到這邊的時候,也覺得很奇怪,哪有人蓋房子不開窗戶的,這是哪根經不對了才設計出這種封閉的建築?!

簡而言之,安藤忠雄認為(以下是 Teddy 的解讀):
  • 大環境不好(窗戶打開不是看到隔壁正在晒太陽的內衣褲,就是面對別人的抽油煙機或是冷氣機)。
  • 在不好的大環境中,如何創造自己的小宇宙?
  • 結論:
    • 把自己封閉起來,不要看到外面的醜陋(房屋四面都被牆包圍,沒有對外的窗戶)。
    • 將外部空間包覆於住家之中(把屋子切成三等份,中間當作露天中庭)。
安藤忠雄沒有能力(至少在當年)去改變整個大環境,只好以『都市游擊隊』的形式,將自己隔離於世,蓋起自我封閉的碉堡。

***

Scrum 說,要管理階層的支持。問題是,要是管理階層沒有意願支持怎麼辦?

Scrum 說,要有 Product Owner 代表客戶與團隊溝通。問題是,要是 Product Owner 是個馬屁精,只會轉寄 email 與壓榨 Development Team 該怎麼辦?

Scrum 說,Development Team 應該要『自我管理』。問題是,developers 都還是『化外之民』該如何自我管理?


你,不幸剛好是這個 team 的 Scrum Master,在心灰意冷之際,不小心看到『建築家 安藤忠雄』這本書,豁然開朗。既然整個城市不可能打掉重練,那就只能先蓋個『都市游擊隊住宅』。換句古人的話,先『修身』 --> 『修 team』--> 『修 Product』--> 『修公司』。無論環境再惡劣,第一關『修身』還是可做的到的。沒事多看『搞笑談軟工』就算是一種修身了。感恩啊...


***
 友藏內心獨白:本篇有點玄。

2011年3月25日 星期五

電子化比不上一通電話

March 25 22:00~23:22

兩,三個禮拜前,Teddy 要購買長榮航空的機票,因為發現用『花旗長榮聯名卡』去買機票,可以便宜 1000 元,此時 Teddy 貪小便宜的心態又復發,因此就想申請一張花旗長榮聯名卡。說來好笑,去年花旗銀行的人還打電話給 Teddy 推銷這張卡,Teddy  還說之前 Kay 要用這張卡上網買機票,結果便宜的機票老早就沒有了,所以沒什麼 用,還要繳 1200 元的年費,因此就沒辦。沒想到現在卻自己送上門。

由於 Teddy 因故需要趕快買到機票,因此 Teddy 就想利用花旗銀行的『網路申請信用卡功能』來申辦信用卡。透過網路應該都會比較快吧,不是嗎?結果卻是一連串的慘劇的開始。首先,在花旗銀行的網站上填了一堆資料,之後網站會產生一份 pdf 檔案,將 pdf 檔案下載之後,有一張需要簽名,另外還需要附上身份證正反面和第二證件的影本,以及財力證明等資料。

好不容易填完資料後,將下載的 pdf 印出來之後發現有兩個地方的資料填錯了。好,沒關係,用立可白塗掉再用手寫一次。OK,Teddy 把資料都準備好之後,可以選擇傳真或是直接將資料掃描後上載。身為一個資訊人,當然是選擇直接上載啊,況且當時已經是晚上 11 點多了,這時候傳真過去萬一被不相干的人給拿走那 Teddy 的資料不是外洩了。好,先把資料掃描好,再轉成一份 pdf,這難不倒 Teddy。等要上載的時候才發現,...仔細一點,居然最多只能上載四個檔案,而且每個檔案不能超過 1 MB。這是什麼爛系統啊,設計這個系統的人倒底自己也沒有用過?剛剛掃描的資料就算是分成四份也會有一個檔案超過 1 MB 啊,都什麼時代了,還限制一個檔案不能超過 1 MB。

這..... Teddy 有個人的堅持,剛剛因為有三筆資料不小心打錯,所以要多掃描兩頁,因此檔案大了點,再重填一次小心一點不要打錯就好了,這樣可以把檔案控制在 1 MB 裡面。經過一番折騰之後,總於又產生一份新的 pdf 檔案。我......進一點看清楚,居然還是有兩筆資料是錯的,此時 Teddy 才意會到,這個系統有 bugs。天啊,難道 Teddy 每天上班 debug 還不夠,老天爺還要懲罰 Teddy 下班之後繼續幫別人 debug... 算了,不想理他了,直接上載。

***

隔天 Teddy 一直注意手機的鈴聲有沒有響起,想說銀行的人應該會聯絡 Teddy。結果,等了一天除了一通打錯電話的以外,連個屁聲也沒有。好吧,隔天自己打到花旗銀行去問,結果:

Teddy:您好,我昨天在網路上申辦信用卡,想請問一下進度。

花旗小姐:請問您的資料是用傳真的嗎?

Teddy:不是耶,我是直接網路上載。

花旗小姐:請問有人跟您聯絡過了嗎?

Teddy:沒有耶(Teddy 內心獨白:有我還打電話來幹嗎....)

花旗小姐:敝姓 X,很高興為您服務(花旗小姐內心獨白:心中暗爽,自己送上門... 設計對白...)。

花旗小姐:因為網路上載的資料不是隨時都有人去看,我給您一個我們主管的 e-mail,您把資料寄到這個 e-mail 這樣比較快。

Teddy 內心獨白:網路上載的資料不是隨時都有人去看...這是什麼邏輯...難道是 Teddy 在 PxHome 24 HR 上面買太多東西了,形成一種『網路比較快』的錯覺。

Teddy :那要請你等一下,我去找紙筆。

花旗小姐:我直接把 e-mail 用簡訊傳給您就好了。

Teddy :好的,謝謝。不過因為我急著要用信用卡買機票,想請問有什麼辦法可以加速核卡速度嗎?

花旗小姐:請問你要辦的是什麼卡?

Teddy:花旗長榮聯名卡。

花旗小姐:是花旗長榮航空聯名遨遊卡嗎?

Teddy:不是,我要辦花旗長榮航空聯名白金卡。

花旗小姐:那您有任何一家銀行,使用超過一年的信用卡,信用額度在 6 萬(還是 8 萬,有點忘了)以上的嗎?

Teddy:有啊。

花旗小姐:那這樣就可以了,你附上雙證件,把簽名的資料 e-mail 給我的主管這樣就可以了。我趕著明天早上 10 點那一批幫您送急件。

Teddy:好的,謝謝。 

***

明天過後...

花旗小姐:陳先生,我收到您的資料了。在此跟您核對一下資料內容。

Teddy:好的。

......... 資料核對中...........

花旗小姐:那我就幫您送急件,如果核卡成功的話,大概 5-7 天內會把卡片寄到你的帳單地址。

Teddy:好的,謝謝。

Teddy 內心獨白:『急件』還要 5-7 天.... 真是.... 急死人的案件...簡稱『急件』。

***

更扯的是,就在 Teddy 上載完檔案的第二天早上,終於接到一通遲來的電話。

花旗小姐 2:陳先生,請問您是否有在網路上申請花旗信用卡?

Teddy :是滴。

花旗小姐 2:請問有人跟您聯絡過了嗎?

Teddy :有的,她已經幫我把申請資料送出了。

花旗小姐 2:好的,那我幫您把這筆資料取消。

Teddy :謝謝....再聯絡....XD


***

等了 N 天之後終於拿到信用卡了,還好來得及買到原本要買的票。如此的電子化,不禁讓 Teddy 想起之前寫的『需求分析書中最重要的資訊是什麼? 』:

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

咳,再怎麼『電子化』,最終還是比不上一個電話號碼來的實在。

這 1000 塊還真是不好賺啊。

***

友藏內心獨白:申請之後發現這張卡原本的很多優惠都要被取消了,難道當初不申請這一張信用卡的直覺才是對的啊!

2011年3月23日 星期三

同誰,九陰真經不是這樣子練滴

March 23 20:44~22:11

上一篇寫了『Scrum 之逆練九陰真經』,希望鄉民們不要以為 Teddy 鼓勵大家『假 Scrum 之名,行亂搞之實』。上一篇的重點是,就算你是『逆練九陰真經』,好歹練功的內容還是和『九陰真經』相關連,總不能說當年郭靖給歐陽峰一本『瑜伽大全』或是『第一次學有氧舞蹈就上手』然後騙他說這是『九陰真經』,這樣就『騙太大了』。

幾個禮拜前在某個 sprint demo meeting 中,某人用很認真的表情說了一句對 Scrum『大逆不道』的話,令 Teddy 印象深刻:


因為這個 story 太大了,在這個 sprint 中做不完。接下來我打算不要開始下一個新的 sprint,等我繼續把這個 story 做完再說。

這好比你去參加超市所舉辦的 『1 分鐘大搬家』活動,在限時 1 分鐘內隨你搬任何超市內的東西。就在時間截止的時候,你跳出來說『等一下.... 我還沒搬完,等我搬到爽之後你們才可以換下一組人馬』。
***

Teddy 還曾經看過一個類似這樣的 story:

身為程式設計師,我可以設計一個具有擴充性的軟體架構。

不要笑,地球上就是有這種 story,說不定鄉民們不經意也會寫出類似的 story。這種 story 要怎麼施工,要如何 demo?Teddy 也可以舉一反三寫出類似的 stories:
  • 身為食神,我可以做出宇宙無敵好吃的飯菜。
  • 身為歌神,我可以舉辦場場爆滿的演唱會。
  • 身為唬神,我可以寫出超級賣的企劃案。
  • 身為員工,我可以月入數十萬
反正 Scrum 說要把需求寫成 story 啊,好啊,你要 story,我就給你 story,誰怕誰啊,反正吹牛又不用繳稅!於是產生了上述的 stories....Scrum 的『形式』是有了,但是卻沒有抓到重點。這樣的練功方法,不要說『逆練』,就算是學小龍女躺在『寒冰床』上練,甚至是跑到『火星去練』,練的再久都沒用。

***

請問哪個程式設計師不想設計出『具有擴充性的軟體架構』,那個廚師不想做出『宇宙無敵好吃的飯菜』,那個歌手不想『舉辦場場爆滿的演唱會』,那個企劃人員不想『寫出超級賣的企劃案』?問題是,把『幻想 願望』以 story 的形式寫出來不表示這個願望就可以實現。


那麼『具有擴充性的軟體架構』要怎麼達成?很簡單,利用『完成若干個功能性的 story 來達成』。這樣講沒人聽得懂,舉例說明,假設你要開發一個『具有擴充性的會計系統』,stories 可以這樣寫:
  • 身為使用者,我可以安裝新的會計模組-->這樣這個 story 又太大了,繼續細分:
    • 身為使用者,我可以安裝薪資模組
    • 身為使用者,我可以安裝進貨模組
    • 身為使用者,我可以安裝 xx 模組
       上面這幾個 stories 完成後,系統就具備了『功能模組擴充性』,接下來

  • 身為使用者,我可以設定薪資規則 --> 一樣可以繼續細分:
    • 身為使用者,我可以計算全職人員的薪資
      • 身為使用者,我可以計算全職人員的國內出差費
      • 身為使用者,我可以計算全職人員的國外出差費
      • 身為使用者,我可以計算全職人員的加班出差費
      • .....
    • 身為使用者,我可以計算兼差人員的薪資
    • 身為使用者,我可以計算派遣人員的薪資
以此類推,可以一直寫下去。『具有擴充性的軟體架構』是一個很抽象的非功能需求(non-functional requirements or quality attribute),要達到此需求,首先先定義『什麼東西需要被擴充』。藉由將『需要被擴充的功能寫成 stories 』並『逐一完成這些 stories』,一個具有擴充性的軟體架構就完成了。這些 stories 給『具有擴充性的軟體架構』規範了一個 context,在此 context 底下去實現此軟體架構才有意義。有點類似 UP (Unified Process)談的 use case driven 的概念,只是在 Scrum 中改成 story driven。

至於第一個問題,一個 story 如果太大在 sprint 快結尾時才發現做不完該怎麼辦?幾個比較可行的方法包含:
  • 將這個 story 移到下一個 sprint 繼續做(在目前的 sprint 中,這個 story 就不算完成,也不用 demo)。
  • 如果這個 story 就只有這個 story 那怎麼辦?
    • 承認這個 sprint 失敗,並檢討原因,是因為 sprint planning meeting 將 story 估的太大,還是 sprint 進行中發生什麼意外(bugs 太多,員工被抓去開會,支援其他案子等等)...
    • 如果這個 story 可以被細分,那麼看看這個 sprint 完成的內容可否完整的自成一個 story,如果可以那麼沒做完的另外寫一個 story 到下一個 sprint 繼續。
  • 就算是這個 sprint 有很多 stories,而你認為這個未完成的 story 可以被切割,你還是可以 demo 已經完成的內容,並且將沒做完的需求另外寫一個 story 到下一個 sprint 繼續。
理想上 story 沒做完就是沒做完,應該移到下一個 sprint 繼續做。但是有時候這個 story 已經完成的部份的確是可以被單獨 demo 的,那麼倒不一定要強制整個 story 移到下個 sprint。例如,某個 story 原本要同時支援 Windows 與 Linux 平台,但是 sprint 快結束時 Linux 平台的支援還有一點問題。你可以選擇把整個 story 都不要 demo,也可以選擇把這個 story 切割成 (1) for Windows  平台, (2) for Linux  平台,這個 sprint 就可以先 demo 已經完成的 Windows 平台功能(請不要說為什麼一開始的時候不直接把這個 story 拆成兩個...千金難買早知道啊...)。


***

採用 Scrum 遇到『問題』的時後,不是說『老子(老娘)想怎麼樣,就怎麼樣』,Teddy 建議可以視情況所需偷偷地『逆練九陰真經』,但是不是鼓勵鄉民們『亂練九陰真經』,到時候練壞身體不要怪 Teddy... 只好善用你的健保卡...XD

***


友藏內心獨白:為什麼開會的時候常常想學電視上表演那種『從椅子上跌下來』的橋段。

2011年3月22日 星期二

Scrum 之逆練九陰真經

March 21 22:42~ March 22 00:21

話說 Teddy 兩個多禮拜前因為多嘴在 Facebook 上和某人多聊了兩句,最後居然糊里糊塗的答應要去某個活動分享 Scrum 導入經驗...今天沒什麼料,就來談一下 Teddy 準備分享的某個 topic --『逆練九陰真經:不完美的 Scrum』。

鄉民們應該都看過『射鵰英雄傳』,話說郭靖與洪七公被 吸毒 西毒歐陽峰困在一艘船上,歐陽峰逼郭靖把九陰真經默寫出來,郭靖當然是不肯,但礙於形勢所逼,最後洪七公想到一個辦法,要郭靖寫一本『九陰假經』給歐陽峰。由於世界上只有郭靖懂九陰真經,所以他把經書裡面的招式亂寫,歐陽峰也看不出來。

最後歐陽峰練了郭靖所寫的『九陰假經』,雖然是『九陰假經』,但是歐陽峰的武功還是大有進步,只不過代價是走火入魔,整個人變得神智不清。

以上所說和 Scrum 有何關係?鄉民們如果看過 Scrum 相關書籍,應該會注意到 Scrum 有提到『Product Owner 和 Scrum Master 絕對不可以是同一人』這一點規範。其他 Scrum 團隊不應有的現象還包含『某個團隊宣稱採用 Scrum 但實際上在 daily scrum 時還是每一個 team member 都向 Scrum Master 報告』或是『採行 Scrum 一定 最好要有高層支持』等等。有些人甚至會很嚴格的說,如果沒有遵循 Scrum 的精神或規範,那你不可以說你的團隊採用 Scrum,只能說是 『Scrum minus』 或是『死窟窿』。

要求 Scrum 團隊要嚴格依循 Scrum 或是 agile 精神的原意應該是怕很多人『掛羊頭賣狗肉』,好比某些國家,明啊明是獨裁統治,卻偏偏要說自己是民主國家,這樣可不行。但是,如果標準放得太高,一定要做到『美國』或是『西歐』那種程度才算是民主國家,那很多國家就只能算是『民主 minus 國家』。

Teddy 相信在台灣很多聽過 Scrum 的鄉民們可能都曾經有一股想要在自己的專案中採用 Scrum 的衝動,但是,一開始可能先卡在 Scrum 框架所要求的『基本條件』上面。試想一下你在一家硬體公司開發軟體(寫驅動程式或是搭配硬體的應用軟體),公司的主管幾乎都是硬體出身的,也不懂軟體開發。有一天你這個小蘿菠頭興沖沖的跑去跟老闆講『我們來 rum Scrum 吧』!下場會是(請選擇...):

  1. 巴林與利比亞:二話不說,直接派兵亂槍打死。
  2. 中國:連想的機會都沒有...至少保住性命...XD。
  3. 埃及:抗議-->亂槍-->沒死算你命大-->改變。
  4. 突尼西亞:抗議-->抗議-->改變。
  5. Teddy 共和國:不用等鄉民開口,已經採用 Scrum。
Teddy 大膽猜測一下,大概前三者的比例比較會高一點,但是,鄉民們因此就要放棄 民主制度 Scrum 嗎?ㄟ... 要看你有多不怕死,總之,明的不行,咱們可以來暗的。民國成立之後,不是有所謂的『軍政,訓政,憲政,扁政』分三個時期來實施民主制度嗎?鄉民們比歐陽峰還要有優勢,因為歐陽峰不知道什麼是『九陰真經』,只能傻傻的『逆練九陰真經』。鄉民們則是在『知道什麼是九陰真經(了解 Scrum 與 agile 精神)』的情況下,暫時逼不得已『逆練九陰真經』,所以走火入魔的風險稍微小了那麼一咪咪(路人甲:最後還不是走火入魔...XD)。

***

舉個例子,Product Owner 是 Scrum 裡面相當重要的一個角色,負責定義product backlog item優先順序,以及整個產品的成敗。但是,如果一個專案沒有 Product Owner 怎麼辦?

路人甲:怎麼可能沒有?

ㄟ,沒有去找一個不就得了(老梗內心獨白:身份證掉了怎麼辦?撿起來不就好了...),應該是說,沒有『專任的 Product Owner』或是說『沒有對於 problem domain 很有經驗的 Product Owner』。講這樣鄉民們應該就懂了。很多軟體開發,都是『老闆有個念頭』—> 『員工做到禿頭』。也就是說,很多所謂『新產品開發』不見得公司都可以找到『有經驗的 Product Owner』來帶領。那怎辦辦,案子還是要做啊,薪水還是要照領啊,總不能跟老闆說『找不到 Product Owner 請換題目』,或是『等你找到 Product Owner 我再來開工』。

那怎麼辦?說實話,很難辦,最後只能使出以下幾個爛招:
  • 別人的需求,就是最好的需求:一字曰之
  • 在爛蘋果裡面挑一個比較不爛的:找一個團隊中最有 sense 的人來當 Product Owner,加上。
  • 三個臭皮匠:專案一開始的時候把大家找來一起研究要『抄』的對象並研究從何抄起。
這樣能做出好產品嗎?Teddy 不保證,但是至少能讓你暫時繼續有薪水可領...XD

***

總之,逆練九陰真經是很危險滴,非不得已不要輕易嘗試。君不見,很多獨裁者年輕的時候也是改革派,也做了很多對國家有益的事,只不過掌握權力久了之後不免就腐敗了(走火入魔)。記得,暫時『逆練九陰真經』或可增加功力,等情況好轉就要想辦法改邪歸正,以免有傷身體。


***
友藏內心獨白:這算是哪門子的 Scrum...

2011年3月17日 星期四

Toolmaker

March 17 22:01~22:51

Teddy 當年還在唸書的時候,雖然主要的研究題目從 e-learning pattern languages (不要問這是什麼....)--> design by contract --> exception handling ,但是在這個過程中,Teddy 不小心接觸到到 Eclipse 與 continuous integration 這兩個領域,又不小心和好幾屆的學弟妹們,在 Eclipse 上面開發了好幾個 plug-ins 以及一個原本叫做 JCIS (Java Continuous Integration System)的持續整合工具(最近改名叫做 ezIntegrate)。

剛開始有些學生會覺的,念研究所『只是』開發工具而不是做什麼『艱深的研究』,好像有點遜掉了。此時 Teddy 博學的指導教授講了一個激勵人心的故事:

在遠古部落時代,人類社會中有三種重要的角色:
  • 巫師(shaman or wizard):在科學還不發達的時代,巫師的身份絕對是在部落中排名第一的『大當家』(酋長除外)。巫師可以卜卦,算命,治病,功能無可取代。
  • 護火者(Firekeeper): 人類懂得用火之後,生活型態因此改變,例如吃熟食,夜晚可以行動。此外,火還可以用來取暖與防止野獸接近,也可以作為攻擊武器,用途多多。因此,在部落中 firekeeper 的重要性使其成為『二當家』。
  • 工具製造者(Toolmaker):人類開始製造工具之後,漸漸拉大了人類與野獸間的差距。赤手空拳打不贏老虎(PS:又不是每一個人都是武松),沒關係,找 toolmaker 做一把箭遠遠地射死你。要喝水,住在河邊又不安全,怎麼辦?沒關係,爸爸買給你 找 toolmaker 做一個陶罐拿來裝水。Toolmaker 的重要性使其成為『三當家』。 
鄉民們,你說『開發工具』重不重要?

***

關於上面這個故事 Teddy 不知道學弟妹們聽進去了多少,不過 Teddy 倒是獲益不少。為了在 Eclipse 上開發 plug-ins,Teddy 學了許多 Eclipse plug-ins architecture 與 patterns(請參考 Contributing to eclipse: Principles, Patterns, and Plug-Ins),有沒有用?非常有用,了解了 Eclipse 的設計之後,嘿..嘿..嘿...興之所至,要當『海盜』也好,要當『山寨』也罷,誰也攔不了你 (Teddy 內心獨白:別人的設計,就是最好的設計)。

另外,為了開發這個 JCIS,Teddy 從原本完全不知道什麼是『持續整合』,慢慢也變成了半個持續整合專家了(雖然 Teddy 還是沒寫過什麼偉大的 ant scripts... XD)。有沒有用?非常有用。

對於做軟體的人來講,有機會『開發支援軟體開發的工具』(有點繞口),是一個了解『軟體開發領域(software development domain)』的好機會。你可能在修『軟體工程』課程的時候學到很多軟體開發領域的知識,但是課程時間有限,為了涵蓋廣度難免就犧牲了深度,而且學生通常『忘性比記性好』,上完課之後很快就忘記了。如果是需要開發支援軟體開發的工具那就不同喔,就和一般的軟體專案一樣,非得從『需求分析』開始做起。等軟體開發出來了,就應該要成為那個領域的 domain expert。念個碩士班如果能夠成為某個領域的專家也算是 C/P 值很高的投資了。

***

友藏內心獨白:講是這樣講,不過自己人開發出來的工具送給你用你敢用嗎...XD

2011年3月16日 星期三

Redundancy

March 16 22:42~23:45

這次日本福島第一核電廠發生爆炸與輻射線外洩事件,引起了全世界的關切。台電急忙出來說明,台灣的核電廠比福島第一核電廠多一部緊急柴油發電機(每部核能機組配備兩台柴油發電機,外加一部備用機,一共五台,10 秒內可供電),2 部氣渦輪發電機(10 分鐘可供電)。此外,核一廠還有 10 萬噸,核二廠有 4 萬噸深水池,可經用來降溫或滅火。

容錯(fault tolerance)的一個最基本的方法就是 redundancy,A 計畫失敗換 B 計畫, B 計畫失敗換 C 計畫,C 計畫再失敗就...雙腳開開,準備投胎...XD。總之,設計一個容錯系統必須依據人們對於『錯誤發生的機率,嚴重性,與可承受性』的不同,來決定要準備多少套『備案』。

講到這邊鄉民們會想,噯呀,當初福島第一核電廠如果設計成『可以防止 10 級地震』那就 OK 了啊,因為地球上還沒有紀錄過超過 10 級的地震...或是準備個 10 台緊急柴油發電機,外加一個翡翠水庫大小的深水池,以及『原子能研究所』所使用的『防護罩』,就不會有今天的問題發生了。姑且不論這樣的『設計』是否有可能被實做出來。就算可以,蓋一座這樣的核電廠可能需要 100 兆新台幣...你出錢嗎?

***

鏡頭轉到軟體開發,從 software process 的角度來看,一個軟體專案會『失敗』有很多原因,好的 process 會想辦法從多種角度來避免這些錯誤發生。例如,defects (或是 bugs)對於軟體開發而言是最直接可被觀察到的錯誤,一個 defects 太多的專案要成功也很難,光是接客戶抱怨的電話就什麼事都不用做了。Agile methods,像是 XP 就採取多重手段來避免 defects 的發生(Extreme Programming Explained, 2nd, p. 31),例如:
  • Pair programming:簡單的數學:兩個腦袋 + 四隻眼睛 > 一個腦袋 + 兩隻眼睛。採用 pair programming 通常可以的到較佳的設計與較低的錯誤率。
  • Continuous integration:衛生署提醒您:定期做健康檢查,早期發現,早期治療。Kent Beck 提醒您:導入持續整合,早期發現整合錯誤,早期修復。
  • Sitting together:開發人員都坐在一起(在同一個房間),萬一有一個 defect 你沒看到,可能會『不小心』被你的同事找出來。
  • Real customer involvement:開發軟體最可悲的一件事情,莫過於軟體做好了,設計的很漂亮,品質也很好,但是卻不是客戶要的。把錯誤的需求做的很漂亮,還是錯誤的需求,白搭。所以讓 real customer 參與軟體的開發,或是至少和開發團隊有很密切的互動,將可大幅減少這個問題。
  • Daily deployment:平常家裡亂的跟豬窩一樣,突然明天有客人要來家裡,今天晚上才熬夜打掃也來不及。平常都把家裡整理得很乾淨,便可隨時都歡迎朋友到訪。軟體也是一樣,如果是在準備 release 之前才開始考慮『軟體佈署』的問題,那麼很多 defects 此時才會出現而且時間很緊迫可能會來不及在 release 之前修復完成。如果可以『每天都讓開發中的軟體保持可佈署的狀態』,那麼就可以將軟體的品質保持在一定的水準。
有些軟體開發人員終其一生在尋找『銀子彈』,希望能有某種單一方法能夠將 defects 一槍斃命,很可惜這種特效藥還沒被發明。Kent Beck 說:

You can't solve the defect problem with a single practice. It is too complex, with too many facets, and it will never be solved completely. What you hope to achieve is few enough defects to maintain trust both within the team and with the customer.

***

友藏內心獨白:『小三』算不算是一種 redundancy ?



2011年3月15日 星期二

改行寫網路小說算了 (2)

March 15 22:31~23:15

故事一

在某次產品即將發表前的會議當中:

聖上:咱們的『雲端殺豬系統』客戶試用後反應如何啊?

產品經理:啟奏萬歲,有台灣的客戶反應,既然能夠在『雲端殺豬』,何不利用已經殺好的豬,順便加上『雲端燉東坡肉』與『雲端煮滷肉飯』功能,這樣一定大賣的啦。

行銷經理:皇上聖明,根據微臣的調查,『東坡肉』與『滷肉飯』不只在台灣,在中國都有很大的市場,的確是不可忽視的兩項功能。

聖上:看起來這兩項功能真的是不可少喔....工部侍郎 九品工程師,這兩個功能要多久才能加到『雲端殺豬系統』中?

九品工程師:如果『東坡肉』要燉的嫩,『滷肉飯』煮的香,依奴才看要最少也要 6 個月的時間。

聖上:大膽,六個月後那些番邦們早就 打過來了 推出類似產品了... 朕限你 2 個月之內完成,否則依軍法處置。

九品工程師:奴才領旨,吾皇萬歲,萬歲,萬萬歲。

聖上:退朝。

眾臣:吾皇萬歲,萬歲,萬萬歲歲歲歲歲歲歲歲歲歲歲歲歲歲歲歲歲.......

***

九品工程師:喂,『醫靈肆』人力銀行嗎,請幫我找 1~2 個會煮『東坡肉』與『滷肉飯』的廚師,這是急件,請在 2 周內找到合適的人才。

醫靈肆:請問該工作的職稱是?

九品工程師:資深雲端廚師。

***
故事二

在某次產品即將發表前的會議當中:

聖上:咱們的『超級柴油汽車』客戶試用後反應如何啊?

產品經理:啟奏萬歲,咱們的『超級柴油汽車』扭力大,爬坡強,客戶反應非常好。但是現在因為『節能減碳』的意識高漲,有很多客戶反應,如果我們的『超級柴油汽車』可以具備『純電力發動』的功能的話,這樣一定 打騙 打遍天下無敵手的啦。

行銷經理:皇上聖明,根據微臣的調查,『純電動車』已經是世界趨勢,在世界各國都有很大的市場,的確是不可忽視的一項功能。


聖上:看起來這一項功能真的是不可少喔....九品工程師,把咱們的『超級柴油汽車』加上『純電力發動』這個功能要多久才時間啊?

九品工程師:啟奏聖上,14 天便可辦成。

聖上:啊,14 天?!好,若能如期完成後朕升你為工部尚書。

九品工程師:奴才領旨,吾皇萬歲,萬歲,萬萬歲。

聖上:退朝。

眾臣:吾皇萬歲,萬歲,萬萬歲歲歲歲歲歲歲歲歲歲歲歲歲歲歲歲歲.......

***

九品工程師:喂,『瘋甜汽車』嗎?我要買一台 XXX ...有現貨嗎?

瘋甜汽車:很抱歉,因為日本工廠遭遇地震與海嘯,暫時停工,所以沒有現貨。

九品工程師:頑皮,頑皮,推一推....XD

九品工程師:喂,『醫靈肆』人力銀行嗎,我要應徵 YY 公司的『資深雲端廚師』工作。.

***
友藏內心獨白:http://teddy-chen-tw.blogspot.com/2010/06/blog-post_12.html