.NET Walker

我得說，打從2000年以來，我從來沒有那麼期待某一個PowerPoint的新功能。也幾乎沒有為了某個新功能而安裝新版的Office，但…Morph讓我破例了… 最早看到這個功能是在底下這支影片: https://www.youtube.com/watch?v=FeUolRLacCw 時間是去年(2015)的11月，那時候MS就釋出此功能的介紹，但讓人引頸期盼很久，遲遲不出現，而且，還 說了 是要先是釋出給 Office Insider participants，然後才給consumer and commercial Office 365 subscribers。簡單的說，就是你必須是 O365訂戶 才行。(O365訂戶開始有特權了?) 這功能有何特別? 讓我為了他先加入了 Office Insider ，後來又安裝了O365版本的Office 2016，並且一天到晚按下更新鈕，看看MS推送新功能了沒。 終於，在上面這個版本，我們看到了MS推送了此更新。更新後，你可以看到轉場選單中有個轉化功能，英文版叫做Morph: 這功能有什麼用呢? 他可以幫助我們很輕鬆的完成類似Prezi那種在兩張投影片之間自動放大縮小的動畫。 而且操作簡單，例如： 上面這是的圖片例子。你會看到我只在投影片頁面中增加一個圖片，接著複製該頁面，然後在新的頁面中調整同一張圖片的大小與位置，出現的就是非常類似Prezi的轉場效果。 那如果是圖形或文字呢? 不難發現，基本上轉化這個轉場特效，作法就是幫你把某一個物件(不管是圖片、文字、圖形)，在前後兩頁之間，自動產生過場動畫，有點像是當年Flash和Silverlight的Storyboard。透過這個特效，你可以很輕鬆地做出非常炫麗的PPT動態效果。 喔? 還沒有安裝O365的Office 2016 ?! 不要急，慢慢來，我就先不等你了。

最近這幾年，我都在ALM和Agile/Scrum與DevOps上努力，也針對這幾個議題有所著墨。 一次，碰到朋友間討論到敏捷開發這個話題，朋友問到，開發產品或專案時，面對客戶端，客戶真的或願意(或希望)一直改版嗎? 因為改版的過程中總是有機會帶來不穩定，實際上很多客戶本身自己也不希望改版，更不希望廠商三五不時就更新一下… 的確，最近這一兩年，有些人可能真的受夠了，各種不同 Level的產品，小自手機上的App、大到底層的作業系統，這種三天兩頭改版的情況幾乎已經是常態，但改版帶出的不穩定，常常讓用戶苦不堪言。 面對這個問題，我是這麼說的： 『有一個非常大的前提，首先，需求變更不是客戶決定的，是客戶的客戶，也就是說，如果客戶可以決定不要變更，那當然就不變更，但現今真實世界的狀況是，客戶被客戶的客戶(或市場)逼著要變更，因此， 敏捷只是回應客戶的需求，並非鼓勵客戶沒事情就變更一下...』 記得嗎?我們在上課時，我的投影片上總是寫著，我們歡迎變更(而不是寫，我們鼓勵變更)，我知道，變更就隱含著風險，即便風險再低，如果可以，我們當然還是盡可能避免，不去變更，但現實世界持續地告訴我們，這不可能。 因為現在環境的挑戰和過去不同，十年前沒有iPhone，FaceBook至今也才不到15歲，這世界變化太快，因為變化快，我們才(被迫)需要去面對。 因此，需要去面對事物的本質，當我們去面對，發現變更是必然，變更是不可或缺，這時候，才帶出了另一個事實。 因此我接著說： 『另外一個前提是，我們所要實現的CI/CD，所希望達成的效果，絕不是變更後好了這邊壞那邊，或是提供客戶一個半成品(改好一半的東西)。我們必須先理解，變更，是必然，而控管變更後產品的品質，也是必須的...，因此才衍生出後面一堆的自動化測試和驗證機制...』 最近這一年大家談的DevOps，也是一樣的道理，真實世界（情境）中有這個需要，我們面對，接著找出解決方案。反過來說，你(的環境)還沒有這個需要，確實也不一定要這麼去做。 最近interview一些工程師，這十年，台灣的開發人員依舊維持維持一個普遍的現象，就是常常系統是一個人單打獨鬥完成的，這沒什麼不好，某些情況下甚至可能是優點，這是市場和規模使然，沒有對錯。但這讓我們的開發人員，並不習慣與別人合作，也不習慣團隊和溝通，我前幾天跟客戶說：並非你把一堆程式設計師集合在...

是這樣的，我一直用Blogger的blog，本來也都是徒手張貼blog，後來有人跟我說，Windows Live Writer(WLW)很好用，所以我就從善如流的用了，發現還不錯用，但好日子過了沒多久，前幾天，它突然無法登入Blogger了! 原因是，Google把登入機制改成 oAuth 2.0，但為何要改呢? 因為它們早就想改了( 前情提要 )。 而等到現在，是因為MS終於把WLW給open source了( 參考 )。 所以，Live Writer以後就由廣大的社群&善心人士共同維護了，名稱從此變為OLW(Open Live Writer)從11號等到17號，終於，善心人士釋出了新版的OLW(可以從 這邊 下載)，所以現在你又可以用OLW登入並撰寫Blogger的文章了(如果先前有安裝，要記得移除)。 這一篇，就是用OLW寫的，對於廣大社群與善心人士的孜孜不倦，無以為報，謹以此文紀念。

我是沒甚麼看影劇節目的人，但今天在網上看到一篇文章，描述今年角逐金馬獎的宋芸樺，被主辦單位臨時邀請代替Hebe演唱<小幸運>，只猶豫了兩天，就決定上陣。上網看了一下影片，發現唱的還真不錯，但重點是，一位演員有這個勇氣和實力，很讓人敬佩。 或許，她平時就有練習，甚至，其實她打算同時朝歌手發展，但在這一個關鍵場合的良好呈現，肯定為自己未來的路擴展了更多的機會。 讓我不免回憶起，過去在擔任各種角色時，自己真的碰到很多需要硬著頭皮上的場合，大多時候表現得還可以，當然也有因為硬著頭皮上結果不是很理想的時候。但，我幾乎沒有放棄過任何一次關鍵場合上場的機會。在當開發人員的時候，常被抓去兼任PM、在當講師的時候，常常被找去做顧問服務、許多次臨時被找去代課…回想過去，其實很多工作，都是在沒有預先通知的狀況下被臨時賦予的。 這時，就是考驗平時的準備與臨場功力的時候了，在一個有充分時間準備的場合展現，多半看不出你的實力，但臨時上場的考驗，往往立刻淬鍊出你的真實程度。 過去，在職場上，很多技術人員常常跟我說，想要往顧問或是PM的角色發展，但苦無機會，其實我覺得，機會，多半都是被我們自己放棄掉的。 下一次，碰到關鍵時刻，被臨時叫上台簡報、被突然間賦予自己不擅長的任務、被緊急抓去救火，千萬別因為自己不擅長或是膽怯而說NO了。用力把握每一次展現自己的時刻，把這個場合當作一個機會，日後更多的機會自然就會主動找上你，不論在你準備好還是沒準備好的時候。 至於『準備』，就看你平時是怎麼過每一天的了。我常說：『你的時間在哪裡，你的成就就在哪裡。』 ref: http://www.setn.com/News.aspx?NewsID=107676 ref: https://www.facebook.com/sungyuhua/photos/a.441771815951334.1073741828.440923442702838/787757738019405/?type=3&theater 宋芸樺現場演唱(從1:45開始): 平時的準備就很重要:

2015/11月底，微軟在Connect();大會，正式公布了大幅度改版的線上TFS，也就是變了新名字的VSTS(Visual Studio Team Services，從前叫VSO)。 VSTS可視為線上版的TFS，讓開發人員可以對軟體的生命週期做非常良好的管理，是一套ALM軟體服務。翻成白話一點，就是軟體專案的統籌管理軟體。 更新後的VSTS，除了原本的版控、自動化建置、測試，以及工作項目管理之外，加上了眾人期待已久的數位儀表板功能： 這個討喜的功能，讓團隊以及PM/PO可以一目了然的看到整個專案的整體狀況，當然，這個儀表板是可以客製化的，有各式各樣的組件，可供專案管理人員選擇應用，您也可以為專案建立多組儀表板，分門別類的以視覺化方式來呈現所有資訊。 我們接著就來看，如何客製化這個數位儀表板。 (等等，你竟然還沒申請免費的VSTS專案管理服務? 請參考 這裡 。) 如果你有管理員權限，現在，進入VSTS專案之後，你會看到overview頁面上，右下角有一個『+』符號： 按下上圖右下角的按鈕，會出現一堆的Widget供你選擇，你可以隨意用滑鼠選擇一個或多個，佈置在預設的數位儀表板上： 類似像上圖這樣，可以點選幾個widget(被點選的會打勾)，按下新增(add)之後，即可加入: 這很簡單，但重點是，這些圖表有何用途? 如果熟悉TFS/VSTS使用或和我們一樣採用Scrum開發框架的朋友們，應該很熟悉了，你可以在畫面上看到底下這些: 這些都是從library直接抓取出來的Widget，當然，你也可自行建立不同的查詢(Query)，以呈現想要的結果。 例如，我們可以在work底下的Queries中，建立一個Query: 我們查詢專案中所有的Backlogs，儲存完成後，移入Shared Queries： 接著，建立一個新的Chart: 有各種圖表可以選擇，我們選擇Pie圖，並設定Group by “state” 欄位: 我們設計好圖表之後，可以透過圖表右上角的選單，把圖表釘選到數位儀表板上: 我們看看: 成功的在數位儀表板上，把Backlogs的狀態顯示出來囉。如此一來，一目了然的呈現出整個專案的狀況，老闆、客戶和PM還能說專案不夠透明嗎? 不僅如此，還有個好玩的功能，Query Tile讓你可以針對某一個數字設定紅綠燈警示看板，你可以點選Q...

從工業革命開始，工作被分成了幾種類型，為了量化生產，以供給滿足客戶大量的需求，所以生產實體產品這樣的工作，被拿到生產線上進行最佳化，目標是在最短的時間，最低的資源投入與成本耗費之下，做出一樣品質的產品。 從這個概念開始，很多管理技巧衍生出來，例如我們熟悉的SOP，我們過去常用的甘特圖，計算績效的KPI…凡此種種，都是從這種基礎概念產生的理論。 但，有一種類型的工作很難被SOP規範、很難用KPI管理、也幾乎無法被甘特圖預測，那就是創意工作，諸如，藝術品、歌曲、文章…的生產。而我得說，程式設計，其實也是其中之一，但往往被忽略的很徹底。 為何這類的創意工作不能被傳統管理工具有效管理，本質原因很簡單，因為能透過標準作業程序管理的生產行為，大多是追求著產出"完全一樣"的"實體成果"，小到一顆螺絲釘，大到一台BMW汽車、在生產規劃的那一刻，其目標就是希望生產出一模一樣的東西，沒有人希望這類產品的產線在生產的時候，出來的每一個成品都有自己獨一無二的特色，如果是，哪怕只是多了一兩克重量，都會讓人難以接受。 但創意工作不是，沒有一首曲子100%完全一樣，如果有，就變成了抄襲，藝術品、創意工作所產出的成果，之所以有其價值，就是在那95%類似的元素之外，那5%的一點差異。 藝術品和創意工作，容或製作生產的流程相同、投入的資源類似，但一旦落入模仿或臨摹，其價值就一落千丈，和這市場上其他的商品不同，其差異就在於對價值的認定。 很不幸的是，電腦軟體也是如此。天下沒有兩套完全一樣的軟體，因為不需要，如果完全一樣，你copy一分就可以了。電腦"可程式化"的目的就在於面對變化，面對差異，然而麻煩的地方就在那5%的差異。這5%的差異，讓程式設計從工業工作變成了創意工作，而”人”在其中就變成了一個很大的變數。(如果完全一樣，就不會有問題，也不需要額外寫程式，就是因為不完全一樣，才需要再次撰寫程式碼) 過去20年，軟體工業一直企圖把程式設計（軟體開發）變成一個標準化的動作，我們夢想著用OOP，就可以讓一切變的組件化、好讓程式的組成變得容易。我們從工業管理生產線上學來SOP、KPI、Gantt Chart，想要用一樣的方式管理程式設計師的產出，用同樣的方式提高產量，但努力了20年，卻發現離理想越來越遠(早期軟體生命周期很長，半年才一...

第三天的Office Add-Ins介紹也順利的完成囉，我後續會把影片、投影片和相關的範例逐步整理到blog上，謝謝當天留到最後的學員們，以及每一位參與學員的支持。 先前已經有整理好的幾篇blog，連結如下: http://studyhost.blogspot.tw/search/label/Office%20Add-Ins 可提供各位先參考。 updated: 投影片位於 這裡 ，現場影片位於 這裡

很高興今天在會場有機會看到許多老朋友，並且和大家分享了我們在CI/CD以及Scrum上的一些心得，場次[實現 End to End 的雲端敏捷開發流程]的投影片可由底下連結 下載 。 希望對大家有幫助。 20150930: [TechDays現場錄影] 今年，現場video好快就上架了，沒有來現場的朋友們，也可以聽一下我們在CI/CD這個主題上的分享囉，聽的時候千萬別怪我囉嗦，前面講了一堆有的沒的，如果你長期關注我們的FB/blog，相信你可以理解為何我們會有感而發…不論如何，謝謝大家的包容與支持。有一點小遺憾，現場的錄音把講員的聲音錄的很清楚，但卻錄不到現場學員的笑聲，現場其實充滿了歡笑和樂趣，而會後和學員們的討論，也讓我自己收穫很多，下次來現場吧，希望有機會碰到大家。 https://channel9.msdn.com/events/TechDays/TechDays-Taiwan-2015/DEV302

前幾天，看了一篇 文章 ，看完之後我立即在FB上分享，原因不僅僅是因為文章中描述的雖然以設計界為主體，但根本120%符合台灣軟體專案外包的現況。我本來想節錄其中讓我很感慨的幾句話，但我回頭再看一次 文章 ，發現我不用節錄什麼，我推薦讀者整篇重頭到尾讀一遍就對了。 接著，我想說說我的感受。 最近十年，我剛好身兼文中所說的幾種工作，資訊軟體開發的教育訓練、雜誌專欄文章撰寫、書籍出版、同時也在業界接案、甚至擔任顧問，台灣軟體專案發包的低價、浮濫…等問題，跟文中說的完全一樣，我們非常明白這件事情。(因此看完之後，我沉思良久) 但如果說，我們在接案時跟其他人一樣，必須被迫用較低的價格來接案，這只說明了一件事情，就是『客戶覺得我們不夠專業』，我們不夠優秀到讓客戶願意用比別人更高的價格，來聘請我們為他服務。簡單的說，就是如此而已。 你說市場行情，沒錯，市場行情是一回事，但對於追求專業的我們來說，我們總是期許(要求)自己所做的每一項工作，都有著比他人高的品質和效率，這意味著，我們期許自己比其他同業要來的專業，果真如此，那在價格上應該要比一般"行情"要來的高一些才對。 如果客戶不願意用比市場行情高的價格，來聘請我們，那顯然該檢討的不是客戶，而是我們自己。我們是否曾在客戶面前彰顯了自己的能力? 我們是否讓客戶感受到十足的值得信任? 客戶和我們溝通的過程中，是否就能夠體會到所謂的專業? 是否與我們對談本身，對客戶來說就已經是一種收穫? 如果不是，那表示我們還必須努力。 當然，容或有一些客戶 對專業沒興趣 ，只希望用最低的價格拿到堪用的成品，但這本來也就不是我們想要爭取的對象。 最近十年，軟體或網站開發比起過去容易非常多，隨便一個學生或是上過職訓的SOHO，都能夠拿起開發工具寫code(沒什麼好怨的，我們自己都帶過這樣的教育訓練課程，也都在台上跟學員說，你看，你看，就這樣，很簡單吧…)。 但，如果只是把程式碼寫出來，讓網站可以動，那顯然無法彰顯你的專業。 在這個業界待了五年、十年、甚至二十年，和剛畢業的學生有何差別? 當破壞行情的份子在業界用極低的價格承接專案的同時，我們能否清楚地跟客戶說明，為何我們值得比較高的報價? 軟體開發或網站設計為何不僅僅只是寫代碼? 一個優秀的系統還包含了哪些要素? (穩定性? 延展性? 安全性?) 好的專案管理該如何凸...

前一陣子到某家公司進行教育訓練，談的是專案管理與ALM。席間，有位學員問到：『Scrum鼓勵溝通，但要怎樣才能夠讓成員凝聚出團隊氣氛，讓大家真的進行溝通，並且引導同仁往持續改善的方向前進呢?』 我很能理解這個問題，因為卓越的工程師普遍喜歡自己一個人埋頭寫code，對解決技術問題都有自己的一套想法，但要習慣性地跟其他人一起合作，有時似乎還挺困難。這位提問者是公司的主管，他嘗試過讓這些團隊成員到外面上溝通的課程、訓練團隊成員溝通的技巧，甚至把溝通這件事情當作績效指標，結果…不出你的預料，完全沒效。團隊成員好像更不喜歡講話了。 回答這個學員的問題前，我先跟這位學員說了一個我最近在一本書上(關鍵18分鐘)看到的一段故事。 書籍的作者有次造訪一座部落平原，搭乘著老舊的火車，乘車過程中，他看到有一頭雄偉的獅子 · 蹲伏在山丘頂的岩石上，看得清楚極了。 作者問列車上的管理員：『這麼巧，竟然能夠遇到獅子出來 · 這樣算是相當幸運的吧?』 『那頭獅子一向都在那裡，牠總是坐在岩石上。』對方這麼回答。 『真的? 你們用什麼辦法 · 讓牠一直待在那裡???』作者問。 管理員笑而不答。 學員們疑惑的同時，我接著說了書上的另一個故事： 『曾經有一位主管向HR顧問抱怨他們公司的接待人員不夠熱情，看到有人走進服務櫃台卻沒有表現出友善的態度。顧問實際上瞭解了狀況之後，發現根本不需要讓接待人員接受任何額外的教育訓練，也不需要複雜的績效制度，只需要把接待檯前面像是郵局櫃台一樣的那個售票窗口的玻璃移除，同時降低櫃檯的高度，服務人員的態度立即有了明顯的改善。』 真的有用? 是的，因為人們非常容易受到環境的引導和暗示。 接著，我把我們某個專案團隊的照片開給他看，並且問：有沒有發現，和一般的辦公室比起來，位子和位子之間少了什麼? 沒錯，少了隔板。 如果你一邊鼓勵團隊溝通，一邊卻讓每一個團隊成員都坐在像是城堡一樣高度的Office Partition座位中，那溝通是不容易發生的。反之，把隔板拿掉，讓team member面對面，眼神可以隨時看到對方，如此一來，團隊成員之間的交流會自然而然的形成，不需要額外的教育訓練與獎勵制度，不需要導入績效管理。事實上，最有效的方式，就只是一個環境的改變而已。 同樣的，在實施敏捷開發的許許多多做法當中，最不需要的就是導入KPI之類的績效制...