分類: 書

我讀 «走進我的交易室» – 上

這本書的作者是 Dr. Alexander Elder, 他原本是一位心理醫師, 後來成為專業的投資人. 而這本書是他的第二部作品, 前一本書 “操作生涯不是夢" 似乎也很有名. 至於這本書裡面講甚麼呢? 我想大概要分好幾次才能整理完.

首先, 我介紹最近曾經提到過的 “權證"! 作者認為, 權證不是一個好的投資標的. 因為權證比股票還要複雜, 連專業交易人都不太想去碰, 反倒是很多交易新手對它有興趣.

附帶一提, 作者把長期投資者稱為投資人, 而以炒股為生的則稱為交易人. 作者自認是交易人, 所以他很少談基本面. 他認為基本面是必要的, 搞清基本面之後, 就應該用技術面等等來操作.

專業的交易人只有在行情大反轉的時候才會買權證, 當他們認為行情即將大跌, 交易人會考慮買入賣權. 為什麼呢? 因為行情即將轉折之時, 難免出現震盪. 此時不論把停損點設在哪裡都不保險! 不如先買入賣權", 等到真正大跌之後, 再高價賣出此一賣權.

假如交易人果真看錯方向, 行情並沒有大跌, 購買權證的損失比較少, 而且他們會設停損點, 而不是等權證失效. 另外, 作者認為不應該買入快要到期的賣權 (權證), 至少離到期日要有兩個月的時間, 才能發揮避險的效果.

另一方面, 由於股票下跌的速度是上漲時期的兩倍左右, 如果握有買權, 往往在權證的有效期間都等不到理想的價格而它變成廢紙! 所以作者認為看漲的時候應該買入的是股票, 而不是權證. 只有看到大跌在望才會買入賣權.

如果交易人沒有把握判斷股價會上漲或是下跌? 唯一的投資機會在於 “非常便宜的遠價外賣權" (far out of the money). 這是什麼東西呢? 首先它是賣權, 再來它非常便宜, 就像彩券一樣. 它能夠變得非常便宜的關鍵在於: 它的履約價低到似乎不可能兌現, 所以乏人問津.

比方說股價 100 元, 但是賣權在 50 元, 這個賣權看來沒有多少價值, 只能以最低面額 0.01 元交易. 不過當股票已經大跌到 75 元, 那麼半年一年後再跌到 50 元也不無可能, 此時原本的遠價外賣權就突然變得有交易 (避險) 價值了.

除了看壞買權證這項投機事業, 作者也認為賣權證有一定的風險. 如果賣方出售的是有抵押的認購權證, 那麼最差的情況下不外乎是賣方把手上既有的股票賣給權證的認購人.

至於沒有抵押品的權證賣方 (裸發售人) 風險基本上無上限, 因為他們發售認購權證時, 自己手上也沒有股票. 萬一認購權證的標的股票大漲, 賣方勢必承受巨大的虧損. 不過發生這種衰事的機會很低, 使得賣方往往都是最後贏家. 畢竟連賣方都賺不到錢的話, 這個產業早就消失了. 

從機率上來看, 股價在短期內大起大落的機會有限, 故買方可能會發現快到期的選擇權始終賣不到好價錢 – 每個買方都在求售買權, 而沒有人會買. 最後擁有買權的人只能按比例換成股票.

作者也提醒權證的賣方若已經獲利, 可以直接買回權證而平安出場, 無須面對未來的風險. 看來美國人好像很容易就可以當權證的買方, 不需要是法人才能發行. 

作者對於期貨也很悲觀. 他認為絕大多數的期貨玩家都是輸家. 真正的贏家是那些消耗大量原物料或是商品的買方或賣方, 期貨減少了他們的風險, 而企圖從期貨交易發跡的交易人則不然.

為什麼這樣說呢? 主要是期貨的起伏比股票還要大, 雖然理論上看對期貨的方向可以發財, 但是只要中間發生了逆向的雜音, 玩家的保證金就被斷頭了, 遑論能夠享受看對方向的暴利.

書上很有趣的一段話說: 農民和工程師是期貨市場上的兩大投機客群體. 農民理應對於商品的價格掌握有優勢, 但是他們可能跑去投機 S&P 500. 相對地, 比較懂得科技的工程師, 卻自認可以掌握黃小玉 (黃豆小麥玉米) 的價格趨勢. 這些都是讓他們賺不到錢的原因.

對沖基金喜歡做空, 投機客許歡做多. 但真正賺錢的期貨交易人往往以 “價差交易" 為主. 也就是說, 他們買入一個月份期貨, 又賣出一個月的期貨, 靠著兩個月份的價差來討生活. 這個方法據說獲利不錯, 保證金的要求又更低, 所以您買不到任何與此有關的好書. 圈內人並不想把它和門外漢分享.

以上大致涵蓋了本書的第六章 “交易" 的一小半, 其他的部分我有空再慢慢補上.

軟體開發中的七種浪費

Teddy 大的 "敏捷開發法的逆襲" 我還沒有看完, 不過裡面提到的七種浪費行為已經可以整理出來了. 所謂的 "七宗罪", 本來是針對豐田汽車生產過程中的品管. 但是拿來套用在軟體上確實也並無不可.

1. 半成品 (Partially Done Work)

很多功能我們做到一半, 說打通了嗎? 還沒有. 不過可以 demo 喔, 看著都會動, 要圖有圖, 要數據有數據. 這些半成品其實是不能量產的! 如果不能一口氣把半成品推向成品, 久了就會變成廢物. 後來不是規格改了, 就是人改了, 公司投進去的資本就在無形中被浪費掉.

2. 多餘功能 (Extra Feature)

基本上, 沒有主管的要求, 很少人會寫出多餘的功能. 具有要五毛給一塊性格的工程師非常罕見, 雖然他們有時候會被批評為想太多, 進度太慢. 但是比起想太少, bug 很多的人, 我還是比較喜歡前者.

如果說是多餘的或是無效率的代碼倒是很常見, 可以很精簡做完的一件事, 有些時候也會被很囉嗦的方法來達成. 像是我以前 trace GPS 的組合語言時, 就發現這邊的 sin(x) 代碼用泰勒展開式與查表法強化計算速度, 順便把泰勒展開式很接近的 atan(x) 也寫在同一函式節省 code size ; 那邊的 cos(x) 卻是用 sqrt(1-sinx(x)2) 暴力達成, 大吃 sin(x) 的豆腐. 可見不同的工程師自我要求也不相同, 主管的功能在這個地方也可以有所發揮.

[註] 講到豆腐, 我不得不推薦一下中華豆腐 (4205 的恆義), 它不錯.

3.  重複學習 (Relearning / Rework)

所謂的重複學習重點在於重複是個浪費, 但學習不是. 大家各寫各的 code, 為何會重複呢? Teddy 大比較著眼於測試的部分, 因為測試的人要學習如何測試. 如果把 test 做成自動化, 就可以減少測試人員學習的時間.

不過我感觸比較深的部分在於系統整合的階段. 如果我需要一個與使用者互動的功能, 上面包括 UI 的呈現, 中間牽涉 framework 的實施, 底層要把資訊 parsing 出來. 那麼誰要負責 study? 如果大家都去看 spec., 絕對是一種浪費. 若是指定某人去 study, 而他沒辦法把架構從上到下講清楚 (這也點有強人所難), 導致其他人必須在更短的時間內自行搞懂, 這也是重複學習. 雖然此時連一行 code 都還沒開始, 浪費在其中矣.

如何消除這種浪費呢? 我們想想今年的紐約尼克隊. 它需要一個能兼顧得分和助攻, 兩者都還不錯的後衛. 如果沒有這樣的人才, 教練只好要求得分主力偶而也幫忙助攻, …接著就會一團亂. 所以我覺得重點在於人才, 甚至是板凳深度.

4. 交接 (Handoff)

不用說, 交接一定是浪費. 大家都不希望有交接, 不管是主管或是工程師都一樣. 交接的接收人通常想完全沿用舊 code 不要去動它, 或是全部砍掉重練. 很少聽到接收人稱讚他收到的 code 完美無比, 通常將它評價為 "能用" 就很偷笑了. 畢竟就算是被接收人吐槽為很爛, 不能用, 主管也只好買單這種說法, 不然難道要找一個懂得欣賞的人來交接?

5. 工作切換 (Task Switching)

如果 assign 太多工作給同一個人, 對方幾乎都會抱怨的. 就算是努力做事不抱怨的人, 也很難在許多八竿子打不著的工作中迅速切換. 這就像是把許多工作同時丟給電腦, 最好的作業系統也只能保證優先級最高的工作先完成, 其他的…再說啦.

Scrum 的每日站立會議就用來確保大家所做的是都是最優先的.

6. 延遲 (Delay)

延遲的浪費在於導致下游的工作無法展開. 後手的人不得不撥一點心思來 polling 上游的狀況, 並且導致他/她的下游也跟著延遲.

7. 缺陷 (Defect / Bug)

有嚴重缺陷的成品或是半成品都會對下游造成不遜於延遲的傷害. 一個有問題的 commit 導致全 team 的人都編不出新版, 這個代價真是不小. 更不用說 bug 流落到客戶那邊後, 甚至可能造成退貨的危機. 據說某名牌 IC 設計公司的產品就是因為連續開機一萬小時後會自動關機而導致全部退貨. 追究其原因, 也不過就是設計者的觀念瑕疵而已 – 把測試休眠的時間參數寫成一萬小時, 反正客戶也不可能用那麼久不關機, code 就留著以後還可以回收 – 後來真的整個產品都回收了.

我個人也遇到過一個好笑的 bug. 當年做翻譯機的時候, 我自認已經交接完了, 大陸的同事忽然慌慌張張地打電話給我, 說這個 bug 他們解不了, 一定要我去現場看一下. 據說我們的翻譯機很怕遇到快譯通和女生, 只要是女生去試用或是和快譯通放在一起 demo 就會當機, 但是和它牌的同時 demo 倒是沒事.

我過去看了 code 之後, 發現 silence detection 的 zero crossing 寫在 share memory, 但用完後沒有清掉. Co-processer 以為這是 main chip 的 command code, 一執行當然就瘋掉了. 至於為何最怕快譯通呢? 原來快譯通為了聲音好聽, 特別提高輸出的 pitch. Pitch 高, zero crossing 就大到和 command code 剛好值一樣, 才會發生這個 bug. 這兩個故事告訴我們, QA 要找女生. 測試用的 code 一定要用 define 包起來, 這樣就不會導致把測試 code 變成量產版本的問題.

我讀 «真夏方程式»

這本書是東野圭吾先生的中篇作品, 它是以虛擬人物 – 帝都大學物理學教授湯川學為主角的推理小說. 說到推理, 難免就會死人了, 這次死了兩個. 有兇殺案就有兇手, 主角和警方經過抽絲剝繭地偵查, 最後兇手終於被繩之以法….呃, 並沒有, 兇手逍遙法外, 頂罪的人蒙受不能自白之冤才是這本書的結局. 至於為何法網恢恢, 又疏又漏呢? 大家就要好好地看看這本書了.

看完這本書, 覺得還滿精采的. 雖然它的缺點也不少, 我卻可以同意男主角對兇手的縱容. 完美破案的湯川學教授畢竟不是警察, 甚至連偵探也不是. 所以他雖然看穿了真相, 卻順勢為真兇隱瞞. 難度太高的案件, 連警察也有其極限. 為了避免某人的生涯受到扭曲, 湯川學決定放他們一馬, 並沒有強迫自己扮演上帝. 有趣的是, 裡面的兩大主角竟然是以 “公平" (恭平) 和 “誠實" (誠實) 為諧音呢! 結果恭平的處置不見得公平, 成實的態度也未必誠實. 只不過…, 沒有必要再追究下去了.

[註] 恭平讀 きょうへい, 公平讀 こうへい. 成實當作名字讀 なるみ, 但一個字一個字分開, 成也可以讀せい, 例如成立 (せいりつ), 誠實讀 せいじつ.

本來只是參加玻璃浦環境開發溝通協調會的湯川教授, 因為不想住進開發商為他訂的飯店, 而恰好搬到發生兇案的 “綠岩莊" 旅館. 和湯川搭同一班車來到這裡的小學生恭平恰好是店主人的姪子. 而反對開發海底礦床的居民成實則是恭平的表姊. 看似平淡無奇的開始, 頂多關係到要環保還是要開發, 壓根也想不到能出什麼樣的大事, 但最後卻牽扯出了新舊兩件命案. 

書中說得好, 就算是要反對, 也要先理解對方才能反對. 光是摀住耳朵的反對並不能解決問題 (我想 “快閃式的反對" 就更加不能了吧!). 對環保如此, 對人性問題也是如此. 真正了解了背後的原因, 站在同樣的立場來思考的話, 連對方是殺人兇手這一點也能夠諒解.  

這本書雖然算是推理小說, 但是湯川對待恭平的方式真得很有愛心. 表面上只是帶他做物理實驗, 和暑期作業. 但是既帶出了兇案的真相和手法, 又客觀地展現了玻璃浦的海洋之美. 這樣的寫作技巧真是令人佩服. 先前讀他的三笑小說 (黑笑, 怪笑, 毒笑) 時就感覺到作者的思路細膩, 但能夠把情節安排到這個程度, 真是天才才能做得到.

當然, 本書也是有缺點的. 那就是為了製造懸疑氣氛, 讓讀者猜不中真兇; 作者把殺人動機寫得非常微妙. 既然殺人動機那麼薄弱, 兇手的表現那麼正常, 幫兇又那麼義不容辭, 讀者當然不可能猜出什麼結果啦! 這點是本書最弱的地方, 如果能讓背黑鍋的人幫忙加油添醋, 我想這本書的戲劇性會更高些. 總之, 與其說是讀了一本推理小說, 不如說是讓我們對於人性關懷和環保都多了一點認識吧!

Scrum 小檔案

Scrum 這個名詞我高一的時候就聽過, 不過當時的用法是在打橄欖球. 為了發揚 "建橄" 的精神, 學長 "無差別" 地鼓吹瘦弱的我們上場拼搏, 聽到 "scrum" 就知道要爭球啦! 喔, 扯遠了, 這次我講的 scrum 是另外一套東西, 它指的是一種軟體開發的流程, 以及管理的方法. 我們先跳過名詞的定義, 直接看看怎麼開工.

既然是一個 project, 當然要先 kick off. 此時計畫的負責人是 PO (project owner) 或是 PM (product manager). PM 負責聽取客戶或是老闆的產品概念 (或稱之為 vision), 然號把產品的性質搞清楚, 寫成需求清單 (requirement list) 或者稱之為 product backlog. 接著由工程團隊的 project  manager (或者稱之為 scrum master) 來帶領團隊.

Scrum Master 把 product backlog 裡面的 use case (或者稱之為 story)  整理為 sprint backlog (衝刺清單). 為何已經有了 product backlog 還需要有 sprint backlog 呢? 因為 sprint backlog 是以 sprint 為單位來執行的. 一個 sprint 可能是一週兩週三週或四週之類的 (OS: 如果寫成 "若一週若二週若三週若四週", 感覺像是在抄襲 "阿彌陀經"), 每個 sprint 自成一個單元, 每個單元都會檢討, 而不是來個期中報告, 和一個期末報告就結案了那麼簡單.

Sprint 要做什麼呢? 當然還是完成那些 story, 只不過我們需要把 story 再細分成 task, 每個 task 可能包括寫測試程式, 寫 UI, 設計 data structure  等等. 既然已經以 sprint 為單位了, sprint 就會有自己的 sprint planning meeting. 並且把這些待執行的 story 依據重要程度來執行.  Sprint 結束的時候, 難免會需要檢討, 此時也會有一個 sprint review meeting. 既然要 meeting 就要有 agenda, 開完會要有報告, 因此 sprint review agenda 和 sprint summary report 就是少不了的文件.

嗯, 講到這裡不就是把大事切小, 小事切無? 類似 waterfall 的開發理念都是老套了, RUP (Rational Unified Process) 曾領一代風騷, scrum 有什麼特別了不起的呢?  關於這個問題, 由於我只是在今天回家後匆匆翻了 50 頁書, 所以很難完整回答, 就先順便補充一下實務上的特色吧!

1. 雙回饋系統: 除了 review meeting, 還有自省會議 (retrospective meeting). 後面這個會的用意專門討論開發流程如何善. 具有自我監督與改善的意義. 否則方法錯了, 再拼也沒有用.

2. 每日站立會議 (daily scrum): 這是更微型的小會議, 只關心昨天做了什麼? 今天要做什麼? 有沒有遇到什麼問題? 因為目標微型化了, 所以每次改動也不致影響深遠, 很快就可以換個手段, 甚至調整短程目標.

3.  永遠可執行的軟體: sprint 結束時, 馬上就產生一份潛在可發佈的軟體, 並且可以 demo. 如果每個團隊都能保持軟體持續健康長大, 這樣聽起來挺不錯的. 

[註1] 以上參考 "笑談軟體工程 – 敏捷開發法的逆襲" page 1~52.

[註2] http://en.wikipedia.org/wiki/Scrum_(development)

我讀 «平民股神教你不蝕本投資術»

這本書算是蘇松萍先生的自傳, 除了有兩篇第三人的文章穿插其中外, 大致上都在反覆介紹他在股市賺錢的原理.

由於作者出身貧寒, 所以沒有閒錢可以長期投資. 最早起家的時候還是盜賣親友的股票才籌到第一桶金. 原來作者的父親在早年個人還不能開證券戶的時候, 就當別人的人頭戶而 “擁有" 不少股票. 作者發現這些股票都相當弱勢 (民國 64 年), 就把這些紡織股換成塑化股, 然後短線進出, 經過 11 年的時間, 終於還掉兩百萬的負債. 而那些借用的股票則是從紅極一時變為水餃股或者下市, 所以作者幾乎不用把錢還回去.

由於這樣的機緣, 作者不相信長抱, 也不迷信類股, 總之甚麼強勢就做甚麼. 並且短進短出, 發揮只用 500~1,000 萬本金, 卻可以一年交易十億元的效果. 他說到台灣的上市上櫃股票, 他大概 9 成都做過.

在實務上, 作者同時會擁有大量的股票, 而每種股票都只買寥寥的幾張. 他的說法也很有道理, 如果重壓 100 張在同一股票上, 難免患得患失. 如果股價跌掉 3 成, 大概人都不想活了. 可是他把股票分散成 20 個 5 張之後, 就比較不容易遇到這種事. 某幾支股票的上漲可能就彌補掉了下跌股票的損失.

此外, 作者買股票也不是用射飛鏢的, 所以出錯的機率不是那麼高. 蘇先生早年在林場上班, 山上沒有人其他人可以交談, 卻可以聽到收音機廣播. 早年的股市的確是由一位小姐從頭到尾把每支股票的行情都唸一遍的, 直到我上班一陣子之後, 才因為股票數目暴增而取消這個服務. 作者在山上大概聽了有 6 年廣播之久, 所以他對於每支股票的的起伏和壓力之稱都了然於胸, 這就是他選股的本錢, 一般人是學不來的. 

(如果大家有看過 “漫步華爾街", 應該記得那位超級作手也是讀股市打孔帶出身的.)  

在買股方面, 作者可以說是斤斤計較. 他說買股一定要掛低檔買進, 買不到都沒關係, 就是不能買貴. 甚麼是貴呢? 假如收盤價再漲停都不能突破前高, 那麼作者就會認為它轉弱了. 很有趣的是, 作者很喜歡買前一天漲停的股票, 而跌停的股票他絕對不碰. 其中的道理也很簡單, 作者都快沒錢吃飯了, 如果買到弱勢股不能脫手怎麼辦!? 所以他只買大家搶著要的, 然後從中賺取微利. 很多微粒就累積成大利. 如果股價一直漲停, 作者也不會輕易賣出. 他會設法取回本金, 只留下純粹賺來的部分 (成本為零的股票), 再把本金拿去買別的強勢股, 以增加周轉率.

書上還講到很多不錯的觀點和某些很迷信 – 沒有依據的看法. 但是整體而言, 這本書挺不錯的. 如果我們把自己的投資看成一家公司, 我們也應該關心自己的本益比, 流動比, 速動比, 股東權益報酬率啊! 所以作者這種一旦虧損就換股操作的積極精神, 還是比長抱等解套的態度要正面多了!