.NET Walker

最近越來越多朋友們開始使用Azure VM，比起自己搭建一個Hyper-V的服務器環境，Azure VM使用起來方便很多，你隨時可以建立或移除一台VM，而且在線上還有現成的範本(例如下圖中MSDN中的Win10搭配VS2015RC環境)讓你直接測試使用。 也開始有一些朋友聽了我的建議，用VM當作正式的工作環境，這有幾個好處，首先，你只需要一台輕便的surface pro 3，不再需要扛著厚重的超級筆電，只要有網路，你可以同時開好幾個開發環境，在不同的專案工作中切換遊走，這對於我們這種身兼多職的工作者來說，相當實際好用。 此外，再也不需要為了安裝而傷腦筋，不喜歡隨時可以砍掉重練（當然不是重新從頭，而是從儲存好的ＶＭ範本開始）。 不過，用VM當作工作環境，我自己的經驗，最少需要開到3.5G RAM的大小，本錢雄厚一點7G RAM的大小才能讓專業人士工作效率更加提升。 然而，參考了底下的 定價 之後，你可能會發現，我們這種市井小民若真想要靠azure VM渡日，恐怕會覺得稍稍有一點點的奢侈:   但我曾經說過，我們長時間以來，一直都是直接開立azure VM給外包或海外的開發人員，難道微軟有給我們特別的優惠或折扣嗎? 還是我們有什麼撇步可以省錢呢?   這，是當然的，用雲就是為了省錢，透過底下介紹的方式，可以當場讓您常開型的VM每個月下來節省一半的費用。   秘訣只有一個，就是：VM沒用的時候不要開。   VM用到的時候才開，每逢假日或下班時間，自動關起來，如此一來，立即省了超過一半的時間(費用)，雲時代，時間就是金錢。除此之外，對於安全也更有掌控，不僅僅隨時可以看到委外人員的進度和操作狀況，也可以避免外包人員知道太多(我們會把相關安全性已組件的方式是先安裝好，避免委外開發人員接觸)，我們也可以更便利的搭建CI/CD環境，以及標準的開發套件。同時，這也可以鼓勵委外開發人員時間到了就下班，不要加班(我們是良心企業)。   因此，定時開關VM有著眾多好處，要實現這件事情，有很多種作法，我們的做法如下: 撰寫powershell script，自動開啟或關閉VM。 建立一個azure automation，自動執行上述的script。 為了能夠在...

前陣子幫一些單位上課，聊到Scrum中的需求訪談。 Scrum採用user story，所以和傳統的Function List有些不同，典型的User Story 長成底下這樣： As a 〈type of user〉, I want 〈some goal〉 so that 〈some reason〉 例如 As an Administrator, I want to be able to create User Accounts so that I can grant users access to the system. 你會發現和過去最大的不同是，User Story採用很簡潔的方式，不僅描述出要做什麼(WHAT)，還包含了誰(WHO)需要這個功能，以及目的(WHY)為何? 關於User Story的寫法，在網路上可以找到很多參考資訊。 我讓學員做了一些練習後，學員們似乎還想了解更多，其中一位學員問到，需求訪談有甚麼技巧? 或是要點? 這是一個很抽象也很大的問題，但，我請同學們在紙上寫下，『談需求，不要談功能』。 一開始學員們有點疑惑，需求不就是功能嗎? 談需求的過程，不就是協助用戶釐清要做哪些功能嗎? 我說：不是的。 Scrum和敏捷開發，讓我們專注於建立出客戶真正需要的軟體。過去，我們可能以為，所謂的軟體產品就是一堆功能的集合。這是一個很大的迷思。 一但我們認為，軟體就是功能的集合，那就衍生出底下幾個問題: 功能越多的產品價值(或價格)越高 但仔細回想，軟體真的是這樣嗎? 好用的軟體(對我們工作真正幫上忙的軟體)，有時候用到的功能根本不多。甚至，許多功能點很多的軟體，其實一點都不好用。不僅複雜，更讓用戶在還沒能掌握或發揮軟體價值前，得投資一堆的時間來學習怎麼使用。 只有真正幫得上用戶忙的軟體，才有價值，而不是功能很多的軟體。 談需求時，我們得把功能都談清楚才行 這導致需求訪談的時候，大家都關注在某個功能點上，卻忘了這個功能對用戶而言到底有什麼意義。我參加過很多需求訪談的會議，看到雙方PM和相關人員，為了一個功能如何實作，以及衍生出哪些相關功能爭執得面紅耳赤，會議開了一整天，function List上功能點一個都還沒談定，搞得買賣雙方大家精疲力盡卻一無所獲。 結果，在隔壁開會的end-...

四月底，VSO又悄悄的更新了看板(board)功能: https://www.visualstudio.com/news/2015-apr-27-vso 這就是SaaS有趣的地方，每隔一段時間，你總是能夠優先(比起TFS Server)享受新的功能，讓用戶有著像是拿到新玩具的快感。 這次改版的集中在Kanban(看板、board)身上，坦白說，過去VSO的board雖然不算難用，但大概不會有人說它很優。主要是除了能夠顯示backlogs和tasks等workitem之外，也就只能夠讓work item在不同的status間移動來移動去，僅此而已。 不過隨著看板方法愈受重視，MS這次一口氣新增了不少功能。對於board的客製化作了不算小幅度的增強。 過去，我們比較習慣在Backlogs畫面新增Backlog，不僅僅是因為Board的編輯功能不是很完整，且網頁時常需要refresh也讓人覺得有點不好用。     這次改版之後，你大可直接在Board畫面輸入PBI(Product Backlog Items)或bug，整個AJAX操作更順了：     所有你需要的編輯功能這次估計都支援了，而且effort欄位還很貼心的給你下拉的費氏數列:    別以為只有1-13，如果你想更大或更寫，試著先選13(或是key一個數字)之後，再點下拉筐會出現更大或更小的數字。    如果你覺得Card上的欄位顯示得不夠完整，右上角的設定給他按下去，你會看到可以自訂顯示欄位:    Cards選項可以讓你自己決定那些欄位要顯示：     Columns選項則可以讓你自訂work items要區分那些Status，以及WIP(work in process)的限制警示數量設置:     當然，Sprint中的Board也支援類似的功能，可以新增、可以編輯、可以指派、可以設定remaining works:       甚至，還加上了 by People 做Group:   更一目...

Chrome更新後不支援 NPAPI 了  >_< 雖然這也不是一天兩天前就知道的事情，Chromium Blog去年就有提到這件事情，主要是宣稱是為了安全性與速度以及穩定性的問題: http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html http://www.infoq.com/news/2015/04/chrome-42-npapi http://www.infoq.com/cn/news/2015/04/chrome-42-npapi 從我的角度來看這不一定是全部的原因，Chrome這幾年變成吃記憶體最兇，以及被攻擊比例相當高的瀏覽器之一，慢慢步上IE的後塵。停止NPAPI的支援，確實會讓開發與維護變的省事和容易，不過我始終認為所有的技術決策背後，商業因素才是最主要的考量。 不管如何，這導致一堆功能被disable了，包含Java, Silverlight, Unity...etc. 目前，用戶可以透過在Chrome網址列輸入    chrome://flags/#enable-npapi     接著把 NPAPI 啟動:       啟用後，關閉瀏覽器重新開啟，應該會看到熟悉的畫面又出現了。   不過，這估計只能用到Q3底，後面會怎樣，讓我們繼續觀察下去... 

  2015/4/2很高興今天有機會和大家介紹了如何透過Scrum與TFS進行團隊開發的一些心得分享。相關的資料可以參考底下網址:   https://www.mentortrust.com/History/Seminar2015 

[研討會] 2015 MVP Open Day 微軟課程實戰日 順利完成，當天我那個場次的開場影片，在底下這邊: 現場的 錄影 也整理好囉，雖然刪掉了不少，但有興趣的朋友們還是可以看看:

因為最近看到些年輕朋友的遭遇，頗有感觸，整理一下心得。 適逢年終尾牙，不知道是不是明年的景氣大好，各種管道很多徵才的消息。也有些年輕朋友詢問我的意見，諸如要不要換工作，或是未來發展的方向云云。 不少朋友因為年終領到的獎金不如預期，或是明年度沒有依照自己的期待加薪升遷，產生了不如歸去的念頭，特別是最近徵才啟事滿天飛，所以頗有躍躍欲試的心動。 年輕的時候，我也是這樣的。在同一個單位待久了，總覺得老闆沒看到自己的努力，未來可以發展的機會不多OOXXOOXX，有時候對於公司的感激遠低於抱怨。 二十年下來，才知道完全不需要如此。忘了是哪一個人說的(卡內基?)：除非你願意，否則沒有人可以傷害你。同樣的，在這個世界上， 除非你願意，否則沒有人可以讓你受委屈 。 畢竟台灣還算是個自由世界，工作的選擇與取捨絕對是自己衡量後的結果，除了你自己，沒有人能夠讓你受氣。 我想說的第一件事情是，既然選擇待在某個環境，就要認清楚事實。事實就是，這是自己的選擇。你有很多外在因素，助學貸款沒還完，信用卡透支，房屋要貸款，孩子奶粉錢....不管有那些問題，這份工作...終究是自己思考後的選擇。重點在，你有沒有認真思考過，然後做個選擇? 還是，其實你一直讓環境幫你決定? 如果你是讓環境幫你選擇，你很容易會覺得自己是『被迫』做決定的，迫於無奈，迫於眼前的現實，所以...這樣的人生，會很不快樂。反過來說，如果你認真想過利弊得失，知道自己屈身在目前這家公司，是為了更好的將來，這是一個過渡階段，撐過去，在這段時間裡面，盡可能取得(學到、搶到、爭取到)自己想要的，有委屈是必然，但撐過去，把技術學好，把人脈建立好，把貸款還清，把小孩養大...然後，後面還有更好的未來等著你...如果，換了一種心情，知道自己的目標和目的，即便在同樣的環境，人生依舊會苦但你會覺得苦的有價值。 待著還是離開，都是自己的選擇，思考後，給自己設定好時間，一年?兩年?還是半年? 決定了，這段時間就全力以赴。時間到了，就認真的重新評估。 如果要走，不要猶豫，有時候離職就只是一種衝動。『離職』兩字絕不輕易出口(跟同事、跟老闆，都是)，一但說出口，就絕對不要接受慰留。 如果設定的時間到了，自己評估後，還是決定繼續待下來，那接下來的問題就是，這段時間如何待的精采。 年終也是績效考核的時候，是人，都會比較...

這是一篇欠了很久的文章。不寫，是因為我覺得這主題要寫的好著實不容易，但偏偏『溝通』這件事情，是專案管理當中非常重要的一環，也是工程師想要蛻變或升級的一個必學功課。(因此這一篇讀起來要有點耐心) 在溝通這件事情上，身為開發人員或PM的你，理論上應該要非常有經驗。從專案一開始(甚至說還沒開始)『溝通』就持續在發生。在presale介紹產品時，在SA洽談規格時，在UAT面對客戶的挑剔時，在專案延遲面對客戶的責難時... 你肯定會發現，需要『溝通力』的場合真是無所不在。 既然需要溝通的場合天天發生，那表示，大部分的PM或工程師，都能夠順利的做好『溝通』這件事嗎? 完全沒有，甚至可以說，大部分的專案都是敗在溝通上面的。特別是工程背景的技術人員，在面對溝通上，總是常常犯著有形無形的錯，卻始終不自知。然而，這是個性和訓練背景的不同使然，可能真的是非戰之罪。 但只要有機會，工程師必須調整自己，才能夠往另一個層次的方向邁進。 備註：上面所說的，正好就是資深技術人員不一定能夠成為好的PM的原因，雖然我自己找的PM，都堅持必須要有技術背景，但我也非常清楚，對於有技術背景的專業人員，由於受的訓練與思考模式的不同，其實相當不容易跳過這個gap。 接著，我們就來談談溝通這件事情。 首先，你第一個你必須注意的事情是， 溝通是一件需要花時間的工作 。大多數的工程師喜歡思考、也喜歡動手、甚至喜歡談技術，但不喜歡說話，特別是不喜歡耐心的聽別人說話。 『不喜歡耐心的聽別人說話』，是溝通的第一個致命傷。(你認為自己算是很有耐心? 或覺得這應該是個容易克服的問題? 請先往下看再說...) 你必須知道一件事情(這是一個心態的調整)，所謂的溝通，並非是想盡辦法(透過技術或是專業)說服對方，而是給對方一個說服自己的機會。意思是，當你想要和對方溝通，如果你的潛在目的是只想讓對方照你的意思做，那不叫溝通，基本上那就是談判(或是說服)。 溝通是，你必須抽離自己的角色和立場，從一個第三者的角度來看，你自己所在意的，和對方所在意的，兩者之間有多大的距離，為了讓雙方都滿意，該如何找出具有創造性的第三選擇，而非只執著在自己要的結果或對方想要的結果上面。(想深入了解這個概念，可以參考柯維的『第三選擇』一書) 柯維在 『 第三選擇 』 中說：「溝通中的傾聽是你讓對方充分表達並且了解...

最近在新聞上，又有政治人物談起一個有些古老的議題，也就是OO共識。不過一直以來，這個名詞總給人一種虛無飄渺的感覺。有人說OO共識根本不存在，有人說確有這個共識，但實質內容為何? 也不一定人人都可以說的上來… 這種國家大事，可能不是身為市井小民的我們，能夠深入剖析和探討的，但有一個極為類似的問題，則是我們在進行專案管理中，時常發生的狀況。也就是『規格的刻意模糊化』。 很多專案團隊，在驗收時碰到爭議，很大比例的原因，是因為規格不清，或是規格的認知有所差距。我們最常聽到的例子，就是客戶指著規格書中的某一條說：『OO功能 當然 是包含在這條規格裡面的，現在怎麼沒有呢?』或是：『這個機制怎麼可能沒有XX功能? 這 想當然 應該要有的啊，不然怎麼用呢?』從客戶的角度來說，這些OO和XX，本來就是系統該出現的內容， 但對於專案團隊來說，這則是規格書中所沒有的『規格外』的『需求變更』 ，為何兩者之間會有那麼大的落差? 其中一個最主要的原因是，當時談規格的時候『沒談清楚』。但，為什麼會沒談清楚呢? 可能是時間不夠，可能是系統分析師素養不足，也可能是甲乙雙方溝通或表達能力不好，但這些不是我想談的問題(因為以上原因都可以透過訓練來改善)，我想談的是另一個看似不該存在，但卻十分常見的原因，就是…甲乙雙方刻意讓規格保持模糊。 這種情況你或許以為不該發生，但實際上卻是最常發生的狀況。 雙方PM為何要刻意讓規格模糊? 理由很簡單，因為雙方都想成案。而模糊化的規格書，最有助於成案(是了，因為可以各自解讀)。有時候靠著一兩張A4的SOW工作範圍說明書，PM和Sale就想把價格和時程談下來，甲方PM可能經歷了漫長的選商和詢價，早已面對(答應上頭老闆)的時程壓力，而乙方Sale正好業績缺的緊，雙方一看對眼，你情我願之下，交易立刻談定，PO馬上開出，接下來的後面一個月皆大歡喜。 甲方PM開始熱鬧的安排Kick-off，乙方Sale本季績效達成，乙方PM接到燙手山芋其實也不太擔心，反正kick-off之後還有半年時間，年底才要驗收。有時候乙方Sale甚至會給PM(人情)壓力，PM也知道規格不清楚會有風險，但不接案難道喝西北風嗎? 先前已經推掉兩三個案子了，總不能Sale拉進來的每個案子都被自己擋掉吧? 如此這般，在沒有詳細規格之前，Deal就談定了。至於工作範圍，人力預估…等...

再上一篇我們談過了Task的建立之後，接著，我們來看看延伸出的圖表。 在VS Online當中，有兩個比較關鍵的圖表，是與工作進度有關的。一個是先前提過的燃盡圖(BurnDown Chart)，另一個則是累計流量圖(Cumulative Flow Diagram)。 由於我們先前看過了燃盡圖，因此我們先來看一下累計流量圖。 累計流量圖(Cumulative Flow Diagram) 累計流量圖主要呈現出專案中每一個Backlog在時間軸上狀態的變化，外觀大致讓如下： 你會看到圖表右邊的四種狀態分別是New、Approved、Committed、與Done。如果你還記得，這四個狀態是Backlog的狀態，可以從Backlog的維護畫面中設定： 但更多的時候，其實我們比較喜歡在Backlog的看板(Board)當中用拖曳的方式來設置(改變)狀態： 一般來說，我讓PO/Scrum Master建立Backlog(剛建立的Backlog狀態為New)，但我只讓PO把Backlog從New改為Approved ，一但開發完成，Tester/QA測試無誤，則讓Scrum Master將該Backlog從Approved狀態改為Committed ，PO(或客戶)驗證無誤後，則由PO將Backlog從Committed改為done。 而你看到的累計流量圖，則是這個狀態在時間軸上的變化狀況。也就是說，從圖上看起來，如果綠色的done面積佔有的比例越來越大，則表示這個專案逐漸完成，反之如果灰色的New佔有的範圍越來越大，則表示這個專案的新需求持續增加。 從累計流量圖當中，很容易可以看出整個專案的健康程度，以及完成的比例。 燃盡圖(BurnDown Chart) 燃盡圖我們在前面討論『剩餘時數 與 燃盡圖』討論過，從燃盡圖上我們可以看到在Sprint中所有工作項目(Tasks)的完成度。 某種程度上來說，燃盡圖用以表現出特定Sprint的剩餘工作量(藉此預估是否能夠如期完成)，而累計流量圖則可以看出整個專案的整體工作進度(也包含了新需求的成長速度)。 透過這兩張圖表，PO或Scrum Master、Stakeholders可以很清楚的知道整個專案的健康狀況，也能夠反映出專案能夠準時完成的可能性。在管理上是相當好用的...