2014-07-15

研發主管職秘辛


圖片來源:http://s1.djyimg.com/

一些心得分享。

所謂團隊:自主運作、團隊產出與人力(數)成正比、隨時可以增添或拆解人力。
現在的團隊已經處於一個穩定狀態,透過兩週固定一次的例行會議,或是臨時性任務的E-Mail電子郵件交代,設定好人員、目標、時間,成員就能自行準時完成並且回報進度,以公司經營來說有點算是達成人力與目標的break even。雖說團隊規模還不大,但依照這樣的模式要擴大、因應新任務承接根本不成問題,並且依照人力的增補可以獲得相對應的工作產出,才是真正的團隊!這時候我就不需要注意細節部分的領導,可以把時間分配並專注於新領域的技術、市場導向研發。

個人領導原則:
個人其實在接下職務以前,早就對自己有所目標設定,兢兢業業不忘自己的領導原則

自主型的團隊運作:
由於團隊是全新成立,為了讓大家及早進入狀況,採用敏捷式開發每日站立會議方式提高成員間的溝通互動、大家對產品技術熟悉度。個人覺得強迫性導入敏捷的精神:時常溝通、不斷檢視是團隊現在能自主運作的最大成功因素,大家在需要的時候就迅速集合、快速討論、立刻下決定的處理方式,個人引以為傲。

除了滿足上級需求,更要培養菁英團隊:
一個主管的成功,如果只成功自己,個人不覺得是個成功領導。成功領導應是團隊性。怎麼培養真的是門藝術,要讓底下的人成長,成長到足以取代自己的位置,這樣自己才有基礎往更高的階梯上爬。
    至於如何滿足上級需求,這又是另一門學問了,簡單的說就是要用老闆的角度來思考事情,這裡不多述。

如何幫團隊擬定執行策略:
個人覺得這是件相當困難的事情,莫非定律表示:事情永遠在你很忙的時候,會冒出更多事情,所以幫團隊擬定最好的執行策略是當一個主管或領導最重要的任務:
  1. 找出最適合的人來負責事情,但要記得賦予權責:這裡講的是最適合,而非最好,大家都知道每個人專長都不一樣,有些人適合處理人際關係、有些人研發能力很強但可能文筆不是很好、有些人統御能力很強、有些人測試規劃很強,這些都是需要長期觀察並且試著去交辦任務才能發現,絕對不是把所有的事情往最強最厲害的人身上丟就沒事,那要你這個主管幹嘛?在強在厲害的人一天跟其他人一樣都只有24小時,主管要做的事就是去找出最適合的人選。找出人選後,要懂得授權,負責人有權利去調度人力或安排資源,不能讓他覺得綁手綁腳,最好也不要給其太多限制(除非觀念有所偏差,但這樣就不應該是你挑出來的人選),讓成員有機會成長。
  2. 給訂明確的目標

2014-06-24

當Mac OS遇上VMware Workstation


謎之聲:"個人喜歡Apple Inc.,也有iPhone、Mac Air...這篇純粹是秉著程序員求新的態度孕育而生~"

Apple Inc.在WWDC 2014橫空出世發表了新的programming language: Swift,以下是Apple自己給Swift的簡介:Swift is Apple's brand-new programming language for writing great iOS and OS X apps. Learn the basics of the language. See how to declare variables, use the fundamental data types, declare functions, and implement classes. Explore some of the great features that make Swift a safe, modern, and extremely powerful language. 簡單來說,Apple要將為人詬病已久不易上手的Object-C換到新語言Swift上,其支援近年流行的Lambda語法Script隨寫隨編隨跑等特性,直教人想趕快玩一玩;但要用Swift可真是讓小弟費煞了一番苦心,沒有Mac怎麼辦?沒關係,Virtualization的第一名VMware真的很厲害~以下介紹如何在Windows上用VMware Workstation安裝Mac OS

個人測試環境需求:

  1. VMware Workstaion 10 (以上),才能支援最新版的Mac OS
  2. VMware unlock tool (v120 以上),得以解鎖Workstaion原本對Mac系列OS的屏蔽
  3. Mac OS X Mountain Lion 10.8.3.iso or Mac OS X Mountain Lion 10.8.3.dmg
  4. xcode6 beta.dmg
[VMWare Workstaion安裝Mac OS X步驟]

2014-04-25

[OpenStack]使用DevStack快速部署OpenStack



OpenStack是一套雲計算 IaaS 的管理平台開源專案,相關的敘述不再多說,請自行上Google搜尋。鑑於陸陸續續聽到不少聲音說OpenStack相當難於建置部署,但發展至今,其實網路上的鄉民高手們已經提供很多強大的一鍵式安裝包,以下要介紹的是利用DevStack快速建置OpenStack。

個人部署環境說明:
  • 虛擬化平台:VMware WorkStation 8 (免費的VirtualBox大家也相當推薦)
  • OS:CentOS 6.5 64bits Eng.
  • devstack Github:git clone git://github.com/openstack-dev/devstack.git
  • 用VMware把CentOS 6.5裝起來,網路記得要打通,個人是用VM的虛擬網卡eth0 採bridge方式至手機的3G,在Virtual Network Editor選項可以對網路設定做修改
  • 需要的指令,以藍字標註。
安裝步驟如下:

[建立OpenStack原始碼的下載目錄]
  • 這裡先放在/tmp底下,請自行選擇
  • $mkdir /tmp/devstack
[從Github拉最新的OpenStack原始碼]
  • $cd /tmp/devstack
  • $git clone https://github.com/openstack-dev/devstack.git

2014-03-18

你在做,主管怎麼看


暨寫完軟體主管的喃喃自語:領導原則,這是給自己看的,藉以提醒自己不要走失了方向。領導團隊一陣子了,看到了一些現象,也有些心得與感想。

主管要幫你沒錯,但不是你的管家:
    每間公司都有既定的體制與規則,當然部門與部門之間也享有或是管理不同資源的責任,舉例來說,今天你的團隊明天要出外景,然後你發現自己沒有攝影機,臨時採購當然來不急,這時候就要去跟別的部門商借,這時候可能就要動到主管去跟其他部門交涉攝影機的使用資源(只是舉例)。但接下來的工作,包含借攝影機可能需要填什麼表單、是不是還要借電源線、是不是需要借鏡頭、機器的使用方法等等,就應該你要自己處理了,而不是還要主管幫你換這些工作層級的尿布。
    也許你會問,那到底什麼時候可以請主管來幫我?很簡單,就是這件事情你自己喬不動的時候,需要有權力的人來推一下除此之外,個人建議盡量就別動用到主管,畢竟主管真的很忙。
    怎麼說忙,你又會問,我看主管都沒在做事情阿?有帶過團隊的人應該都能體會,當成員有問題來找你,假設光是一個對話(成員說明、內容對話、情境了解、給定決策)需要10分鐘就好,然後你每次打斷主管思緒後要讓他在回到原有思緒,總共算15分鐘好了,假設你的團隊有10個成員,大家每天都來問一件事情就好,主管就要花兩個半小時跟團隊周旋... ...這樣的算法還沒算到跟主管的主管、還有別的團隊的主管周旋。

工作分配下去,團隊都有定期開會,我還需不需要另外回報進度?

2014-03-12

OSGi簡易實作於Eclipse



某些因緣際會,最近稍微研究一下OSGi Framework,但對於這個技術,網路上較多的都是一些框架概念,實作分享不多,就連Eclipse本身直接拿內建的Plug-in建立專案也沒辦法跑(奇怪...Eclipse不是基於OSGi去開發的嗎?) 以下是個人簡易實作分享。

什麼是OSGi:
網路上很多介紹,這裡僅做簡介:OSGi是一個Framework(框架)、是一個概念,框架往往就是好幾個Design pattern構成,用來幫助開發者統一建構系統的標準架構;面臨一個大型系統建置,絕對不會把所有程式碼都放在同一個Project(專案),因為這樣不好維護、分包撰寫,所以OSGi提供一個切割子Project的方法,每一個子專案在OSGi之上視為一個Bundle,每個Bundle可以擁有自我獨立的生命週期,如果撇開Dependency(相依性)不管,每個Bundle可以自由地透過OSGi統一的Command line進行管理(啟動/關閉/重啟...等等),而不影響其他Bundle的運作。
    換句話說,假設,假設今天你開了一台基於OSGi框架製造出來的車子上路,你開到路上車子還在跑,但是你卻突然發現路旁有家新開的輪胎行,德國H牌輪胎之類的,看起來很厲害,然後你臨時想換個輪胎但又不想停下來,只要今天你的輪子也是基於OSGi製造,轉動輪子的軸承也是,那你就可以在車子還在跑的情況之下把輪胎換成心愛的H牌輪胎(什麼爛比喻?!)

先來提提Eclipse內建的OSGi專案:(這個實作並沒有完全成功,網路上找到的bug shooting也沒什麼用)
  1. 下載並安裝Eclipse,https://www.eclipse.org/downloads/
  2. 建立workspace,點選File -> New -> Other -> Plug-in Project
  3. 進入對話框Plug-in Project,記得把下面的Target Plateform換成an OSGi framework,點選Next
  4. 進入對話框Content,Execution Environment不要動,記得還是選JavaSE即可,不要換成OSGi/Minimum,否則等專案跑起來會沒有osgi.jar檔,然後Next
  5. 進入對話框Templates,點選Hello OSGi Bundle,然後Finish. 專案應該就建立完成了。(Eclipse好棒啊)
  6. 執行專案,沒有問題可以執行,Console很開心的跟你說Hello World! 
  7. 悲劇來了,接著馬上噴出一堆錯誤訊息...一句話,別花時間去解了,聽說是專案自己initial其他沒用的jar,然後那一拖拉庫的jar也不知道要關掉哪些才有用,因為關了一些,又噴出其他的錯誤訊息...
那我們該怎麼辦

2014-02-24

大陸河北談生意



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

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

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

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

2014-01-27

不嘴砲!敏捷式(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。老實說這種思維很難跟沒有執行過的人、不夠經驗的開發者、長官等等解釋,沒有實際執行過真的永遠只會理解教條上那套。
那這樣一直反覆迭代,難道你心中沒有一個疑問?事情一直重複做、重複修改,哪來這樣的美國時間?這樣真的有敏捷到嗎?恭喜你,你開始要有點懂敏捷式開發了。

2014-01-11

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


圖片來源:www.nipic.com

大方向:

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


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

2013-12-27

不負責任之IT大未來預測


圖片來源:Federico Ciccarese

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

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

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

2013-09-22

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


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

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

到約旦機場囉

搭乘約旦當地巴士

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

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

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

跨龍謀的電梯按鈕

2013-09-16

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


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

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

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

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

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

所謂的每日站立會議有幾項原則:
  • 時間不能太長,因為腳會痠。
  • 主席減少發言,最好是

2013-09-10

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


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

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

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

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

2013-08-28

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



奧茲法則

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

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