大陸河北談生意

那是我第一次到達河北，中國河北省石家庄火車站。

先來講講中國的城鄉差距好了。中國大陸，有五個一線城市，分別是北京、上海、廣州、深圳，其他二線如南京、武漢、天津、河北，然後更鄉下的就不用講了，在古代來說，那就是所謂的荒郊野嶺。那身為一個二線城市的河北省省會石家庄又如何呢？

大陸北方的沙塵暴一點也不意外的侵襲到距離北京西南300公里的石家庄，不打緊，出車站時早就有心理準備，沒有心理準備的是車站的公共廁所。你妹阿！只有四個字可以形容："屎尿橫飛"，沒錯！廁所裡有小便斗，問題是，大便的地方沒有門...沒有門就算了，他是直接大到木桶裡面，沒錯！是木桶！然後滿地、牆上全都是屎尿，進廁所需要憋氣、躡手躡腳找著可以踩下去的地板走...這是我對河北省的首都、市中心石家庄的第一個印象：屎跟尿。

離題了，今天是要來講講我們去拜訪河北客戶的故事。故事大概發生在2011年。

不嘴砲！敏捷式(Agile)開發玩真的

敏捷式開發的流程圖大致上會長成這樣，很簡單，但問題是該如何執行?

繼日前介紹的每日站立會議執行心得，時光飛逝，一晃眼2014來了，中國新年也要到了(請不要問版主今年貴庚...)，也是再給個交代的時候了。

實際執行過的軟工方法 What we did ?

• 每日站立會議 Daily Standing Meeting
• WBS(Work Breakdown Structure)
• 持續性整合 Continuous Integration(CI)
• 自動化測試 Auto Testing
• 視覺化工作進程追蹤 Kanban
• 使用議題追蹤系統 Using issue tracking system with Microsoft Team Foundation Server(TFS)

敏捷式(Agile)開發到底是什麼鬼 What the hell is AGILE ?

以下完全是個人對敏捷式開發下的定義，不代表任何一個出處。

• 敏捷式開發不是軟工方法，敏捷只是一種心理狀態的描述、一種工作環境的意念，如果公司文化沒有敏捷的意圖或是想法存在，導入任何方法都沒有用。但軟體開發總是需要方法來協助執行，下一節會針對上述個人所使用過的軟體工程方法來成果分析。
• 敏捷注重的是大量的重複迭代(Iterator)，簡單的說，就是你的任何工作不要做完了才拿出來，千萬不要做完了才拿出來，而是時間到了就要拿出來檢視、拿出來討論、拿出來DEMO。老師在講你有沒有在聽？老師在講有沒有在聽？這可不是跳針，是強調！
• 所以敏捷團隊執行狀態比較會像是：在專案開發初期，所有成員一起制定目標，這個系統要呈現使用者什麼樣的功能、什麼樣的感覺，不一定要馬上有既定的結論，但必須把工作項目(backlog)內容及時程制定下來，然後由成員各自認養。
• 不是認養回去就算了，還得繼續把目標切割(item)透過不斷的執行、驗證、根據驗證後的感覺進行討論然後修改、再執行，這樣每次的執行、驗證、再修改、再執行就是一個 iteration。老實說這種思維很難跟沒有執行過的人、不夠經驗的開發者、長官等等解釋，沒有實際執行過真的永遠只會理解教條上那套。

那這樣一直反覆迭代，難道你心中沒有一個疑問？事情一直重複做、重複修改，哪來這樣的美國時間？這樣真的有敏捷到嗎？恭喜你，你開始要有點懂敏捷式開發了。

軟體主管的喃喃自語：領導原則

圖片來源：www.nipic.com

大方向：

不是很喜歡主管這個詞彙，主管感覺只是在管人、管事，但其實在管理階層要做的事情不能只是管理，要能找出團隊未來的方向，雖然對台灣人來說會很反感，個人倒是覺得用"領導"才是比較洽當的詞彙。


領導(主管)認知：(個人立場)

1. 謀定而後定，避免朝令夕改：要認知主管的一舉一動、下達指令都是成員們的圭臬，要是今天主管請你研發A，後天跟你說改成研發B，再過幾天又跟你說要研發C，想必大家都會無所適從，專案進度永遠都在歸零。所以個人在下每個命令或指導棋之前，絕對不會脫口而出，都是在腦海中沙盤推演這個命令下去後會讓多少人投入資源，投入資源後會獲得哪些產出，再藉由這些產出能不能達到目的才會下這道決策。要知道主管的話語對下屬來說就是指南針，今天你自己都抓不準方向，又要如何讓事情獲得成功？
2. 必須有扛責任的覺悟：團隊成敗與否絕對是在主管身上，別想怪罪到下屬上；要是主管老是以"員工不認真"、"員工能力不足"來搪塞失敗，那上級長官又何必賦與你主管職，一個主管存在價值就是在於領導團隊的成功。
3. 不是只為上司負責，更要為成員的未來負責：設想一個情形 - "如果今天你所在這間公司突然倒閉了，你的成員都有辦法、有能力找到別的工作嗎？"主管的任務不僅是要完成上面長官交代的事情，同時間你應該要為下屬的能力培養盡到責任(除非你的下屬就是沒有心思學習，另當別論)，今天你交辦給他的任務應該是要有技能性、學習可能、有競爭力的。

不負責任之IT大未來預測

圖片來源：Federico Ciccarese

個人投入IT領域已有一段不算短的時間，來來去去看了許多IT服務、產品，下面是個人預估十年後、甚至十五年後的IT未來願景。

先點出最重要的關鍵：什麼技術都別談了，對用戶來說，IT就是一個小型的行動裝置

想像一個用戶情境："每個人透過生物辨識裝置，利用自己的行動裝置(可能是手機)透過網際網路登入遠端的虛擬作業系統、操作各式各樣的APP(已經不管iOS、Android)，所有的運算、資料都在雲端；今天不管

[埃及、約旦] 流浪隨筆 - 約旦死海 Deadsea

死海(Deadsea)，記得在懵懂幼年就已經在書籍上閱讀到：死海不是海，其實是一座鹽水湖泊，由於身處幾乎無雨的沙漠地帶，加上水分被太陽烹曬不斷蒸發的結果，讓湖水鹹度越來越高，變成世界鹽度一番的湖泊。顧名思義，因為鹽分相當高根本沒有任何生物可以生存在死海中；而人體在這座湖上能自己浮起來。

這次的埃及行其實原本沒有約旦這個景點，因為某些因緣際會，我們再碰到兩個台灣旅遊全世界的背包客，意識到一個這麼趣的地點，立馬改行程然後上網買了廉價航空飛了過去。真是不虛此行。

到約旦機場囉

搭乘約旦當地巴士

約旦的市區街道，滿街都是豪華轎車，不愧是石油輸出國之一

約旦即將大選，路上全都是競選人的宣傳海報(原來東西方搞選舉也沒什麼新的花樣，說回來，個人也在泰國的蘇美島碰過選舉的造勢晚會)

又是因為某些因緣際會，拖了某個傻蛋的福我們多買一張用不到的機票，所以我們直奔到約旦航空公司的辦公室，結果用很破的英文盧了半天也沒用：航空公司表示因為我們不是直接跟他們買(類似你在台灣用易遊網買長榮的機票)，他們不負責，請我們找代理人。(後來回台灣是透過skype打電話到英國的代理人網站進行退訂費，但由於是廉價航空機制，大概只退了五成費用，這是某人第一次用電話跟歪國人聊天談正事...)但還是有一些特別的收穫~

我們明明就在一樓怎麼會寫0 ?

跨龍謀的電梯按鈕

Note of daily stand-up review 每日站立會議執行心得

圖片來源：http://martinfowler.com/articles

滾石不生苔的法則，適用於惡劣不斷學習的職場、男女之間的感情維持、朋友的交際應酬，當然軟體工程也不例外。

問題在於，要怎麼讓石頭滾起來呢？又要怎麼判斷有沒有滾起來呢？所以某人堅持要搞執行每日站立會議(Daily stand-up review)。

目前團隊跑了剛好一個多月，執行方式：

• 每日早上九點初準時開始，全員參與，因為開得很快，在其他團隊要用會議室前就結束了，連會議室都不用借。
• 站著開會，因為乳酸會在站立的姿勢下快速積累於雙腳，能有效加快會議速率。
• 用google doc進行條列式追蹤，追蹤項目只寫三件事情：昨天我做了什麼、今天我要做什麼、我需要什麼幫助。
• 在大家報告完後，再行同步其他資訊(某些情況這件事情可以當作熱場用)。

在這裡先澄清一件事情，並不是所有的開發團隊都適用於每日站立會議，首先有幾個條件要滿足：

• 人不能太少，四人以下團隊基本上就免了吧，因為整天就是這幾個人在你看我、我看你，幹嘛還花時間開會。
• 人不能太多，雖然目前個人團隊還沒超過十個人，但依現在的負荷量來說，超過十人來開每日會議就會浪費太多時間，每個人報告個3分鐘，全部人報告完就要半小時，還沒有加上其他議題的討論時間。
• 主席(可能是PM或SA)要有一定的技術能力，否則開了也沒意思，直接用功能完成度來追進度就好了。最好是能當場就決定某些技術環節要如何解決、誰來解決、何時解決，否則議而不決真的沒意義。

所謂的每日站立會議有幾項原則：

• 時間不能太長，因為腳會痠。
• 主席減少發言，最好是

[Weinberg - Quality Software Management][Book 4][Ch 12] 流程原則

個人看書喜歡跳來跳去，這次直接跳到第四冊啦！

軟體工程大師溫伯格在談軟體管理學的前三本書，內容主要都是在導引如何建置優良的軟體開發，直到第四本書他開始談要如何在一個發展規模龐大組織及舊環境的體制下，我們該如何進行變革。

第十二章講述的是流程原則，目的在於用方法論來克服人的惰性，關鍵在於任何環節都需要被掌握，然後怎樣的情況算是有所掌握，以下是摘要：

Note：

• 專案中的每樣東西必須是顯而易見的，包含程式碼、計畫、需求、設計、測試計劃、測試結果、進展、所有的書面資料...
• 當你發現任何一件成果看不到，或"無法接受檢驗"，一定要停掉那件事情，並開始進行矯正。要避免"吉米是唯一知道那裏面有什麼東西的人"這類情況，先派人協助吉米，然後請吉米把事情記載於文中，如果吉米拒絕，就拿掉他。看不見的事情絕對不會安頓下來。
• 通過獨立審查前，沒有一樣東西是真實的。
• 你不做評量的東西，絕對會不受你控制。

陪你讀冊 | 當責，從停止抱怨開始

奧茲法則

當責(Accountability)一詞，是今年過年父親給我的一本管理教科書看到的，但當時書籍內容過於偏向理論、教條式解說，個人就沒仔細閱讀。而這次筆記書籍則是用全球著名小說綠野仙蹤桃樂絲的故事做為破題，舉了許多實際案例，採取引導式發問、問卷自我檢視等實作面向說明如何做好當責這件事情，以下是重點的心得筆記。

一、個人當責
[當責秘笈]如何辨識自己落在水平線下，落入水平線下被害者循環的18個警訊

1. 感到自己為際遇所困。
2. 覺得無法控制現況。
3. 當別人告訴你可以更努力更出色的完成結果時，卻是一場忠言逆耳。
4. 發覺自己在怪罪他人。
5. 討論問題時，越來越集中在自己做不到的事情，而非自己能做的事。
6. 無法面對艱難的問題。
7. 發現自己成為某些人的取暖對象，這些人告訴你，別人這回又對你如何不仁不義。
8. 發現自己不願提出深入的問題，以了解自己是否有能力當責。
9. 認為自己遭受不公平待遇，而且無能為力。
10. 不斷發現自己採取防禦的姿態。
11. 花許多時間談論無法改變的事情(例如：職場、股東、政府、景氣)
12. 發覺自己茫然失措，但

如何不用root就可以擷取android手機銀幕畫面

從iPhone陣營跳回Android後，一直有個問題困擾某人，就是Android手機竟然不能擷取銀幕畫面啊，莫大的杯具。尋尋覓覓，大概有六種方式可以擷取手機銀幕，但基本上要能支援擷取功能都要被root過，也就是會喪失保固，以下提供不用root擷取手機銀幕畫面到個人電腦PC的方法。

自動傳送簡訊抽獎懶人法

圖片來源：hifree

Bill Gates曾說："他只雇用最懶的工程師，因為懶，就會懂得用腦筋想方設法找出最好的方法來做事情"

相信大家一定有收過類似的活動抽獎簡訊，內容大概是"XX邀您於O/O前輸入數字回覆本簡訊完成闖關就抽機皇"

但一封封回傳浪費的已經不只是金錢，更還有時間。如果，這裡是說如果，你跟某人一樣電信月租費預設較高，每個月都還打不完，可以考慮多寄送這些抽獎簡訊來增加中獎機會。

懶人做法如下，以Android平台為例：

[埃及、約旦] 流浪隨筆 - 金字塔 Pyramids

金字塔 Pyramids - 堪稱人類文明史上最不可思議建築之最，即使以今日文明仍無法精確了解其建造目的、建築方法。

眾說紛紜，最廣泛的大眾認知金字塔是法老王的陵墓，很合理，就像秦始皇也搞了一個地下陵墓；但人類的幻想總是喜歡加值未知事物，就有學者發現，金字塔高度乘上十億倍剛好是地球到太陽的距離，是一份早在古埃及時代(距今七千年)古埃及人就能精準計算出地球到太陽距離的證據。

為了讓自己更快速融入古文明，某人出發前還去買了本《築夢金字塔》，內容主要講述吉薩金字塔群的法老王歷史、詳細介紹、觀測現象、建築方法推論，而其主推的建築方法是外部、內部坡道建築理論，簡單的說，作者認為石塊搬移的方式是由坡道搬運，如此才可能把偌大的石塊從低處搬到高處，並且放置在合適的位置，至於托運的方式根據石塊落點則分別採用內部坡道或是外部坡道兩種方式。有興趣的朋友歡迎借閱。

埃及人一定覺得其他國家的人有毛病，這麼大老遠風塵僕僕、頂著大太陽只為了看那個大土堆，因為如果天氣許可，在開羅市區的任何角落都可以直接看到金字塔建築物，這樣敘述就可以了解這個土堆有多大了吧!

回到旅遊話題

[埃及、約旦] 流浪隨筆 - 旅之初

 實際走訪埃及後，發現真正令人神往的不是那封存已久的不可能建築古文明，而是那熱情的沙漠民族精神阿

最近埃及動亂頻繁，不少朋友問過曾去過該地背包旅行的在下，現在去自助旅行到底安不安全？一句話："'放心吧！"，剩下的故事，聽小的娓娓到來。


所有行程：

[troubleshooting] HTC Butterfly 音樂app滑動檔案清單直接跳出

Question：用HTC Butterfly發生一個狀況，在進入原生官方app "音樂"，進行瀏覽檔案的時候，直接因不明原因馬上跳出app.

Answer：砍掉擴充SD卡裡Download目錄下的檔案即可。

原因研判：

• 下載的檔案裡可能有些格式損毀，因為某人喜歡抓到一半懶得等就不抓了
• 檔案太多，超過index索引範圍