2016年1月31日 星期日

PowerPoint 2016的『轉化(Morph)』場景功能

我得說,打從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推送新功能了沒。

SNAGHTML9412e7f

終於,在上面這個版本,我們看到了MS推送了此更新。更新後,你可以看到轉場選單中有個轉化功能,英文版叫做Morph:

SNAGHTML94285e1

這功能有什麼用呢?

他可以幫助我們很輕鬆的完成類似Prezi那種在兩張投影片之間自動放大縮小的動畫。

而且操作簡單,例如:

上面這是的圖片例子。你會看到我只在投影片頁面中增加一個圖片,接著複製該頁面,然後在新的頁面中調整同一張圖片的大小與位置,出現的就是非常類似Prezi的轉場效果。

那如果是圖形或文字呢?

不難發現,基本上轉化這個轉場特效,作法就是幫你把某一個物件(不管是圖片、文字、圖形),在前後兩頁之間,自動產生過場動畫,有點像是當年Flash和Silverlight的Storyboard。透過這個特效,你可以很輕鬆地做出非常炫麗的PPT動態效果。

喔? 還沒有安裝O365的Office 2016 ?! 不要急,慢慢來,我就先不等你了。Smile

2016年1月1日 星期五

面對事物的本質

01-144832-58860ea7-c866-4b08-b580-b26f296380a4

最近這幾年,我都在ALM和Agile/Scrum與DevOps上努力,也針對這幾個議題有所著墨。

一次,碰到朋友間討論到敏捷開發這個話題,朋友問到,開發產品或專案時,面對客戶端,客戶真的或願意(或希望)一直改版嗎? 因為改版的過程中總是有機會帶來不穩定,實際上很多客戶本身自己也不希望改版,更不希望廠商三五不時就更新一下…

的確,最近這一兩年,有些人可能真的受夠了,各種不同 Level的產品,小自手機上的App、大到底層的作業系統,這種三天兩頭改版的情況幾乎已經是常態,但改版帶出的不穩定,常常讓用戶苦不堪言。

面對這個問題,我是這麼說的:

『有一個非常大的前提,首先,需求變更不是客戶決定的,是客戶的客戶,也就是說,如果客戶可以決定不要變更,那當然就不變更,但現今真實世界的狀況是,客戶被客戶的客戶(或市場)逼著要變更,因此,敏捷只是回應客戶的需求,並非鼓勵客戶沒事情就變更一下...』

記得嗎?我們在上課時,我的投影片上總是寫著,我們歡迎變更(而不是寫,我們鼓勵變更),我知道,變更就隱含著風險,即便風險再低,如果可以,我們當然還是盡可能避免,不去變更,但現實世界持續地告訴我們,這不可能。

因為現在環境的挑戰和過去不同,十年前沒有iPhone,FaceBook至今也才不到15歲,這世界變化太快,因為變化快,我們才(被迫)需要去面對。

因此,需要去面對事物的本質,當我們去面對,發現變更是必然,變更是不可或缺,這時候,才帶出了另一個事實。

因此我接著說:
『另外一個前提是,我們所要實現的CI/CD,所希望達成的效果,絕不是變更後好了這邊壞那邊,或是提供客戶一個半成品(改好一半的東西)。我們必須先理解,變更,是必然,而控管變更後產品的品質,也是必須的...,因此才衍生出後面一堆的自動化測試和驗證機制...』

最近這一年大家談的DevOps,也是一樣的道理,真實世界(情境)中有這個需要,我們面對,接著找出解決方案。反過來說,你(的環境)還沒有這個需要,確實也不一定要這麼去做。

最近interview一些工程師,這十年,台灣的開發人員依舊維持維持一個普遍的現象,就是常常系統是一個人單打獨鬥完成的,這沒什麼不好,某些情況下甚至可能是優點,這是市場和規模使然,沒有對錯。但這讓我們的開發人員,並不習慣與別人合作,也不習慣團隊和溝通,我前幾天跟客戶說:並非你把一堆程式設計師集合在一起,它們就是一個團隊,他們充其量只能說是一群工作夥伴,而團隊,則不只是這樣子的。

而如果你不在『團隊』當中,有時候很難體會為何Scrum要這麼做。一群『獨立』的開發人員,是無法接受(也不需要)Scrum、DevOps的,因為自始自終,這一群人中的每一個人都是『一個人』,而非一個團隊。

前幾天看馬雲的一個演講,提到:『天下太多免費的產品,免費不是重點,你要為客戶創造價值才有意義,如果沒有價值,免費只會讓你送命…』

我聽到這裡突然發現,我們談的MVP(minimum viable product)和 potentially shippable product increment不就是同樣的意思?

事實上,軟體開發徹頭徹尾只有一件事,就是為客戶(用戶)創造價值。

原諒我這麼說,你寫程式寫得很有熱情,做出了很多功能、寫了很多模塊、設計了很完美的架構…但…沒有為客戶創造出價值,一切都是浮雲。

(這常常也是領薪水和付薪水的人之間的差別,有時候你在意的,和老闆在意的渾然不同,原因可能就藏在上面這幾個字裡面了)

變更,是為客戶(用戶)創造價值,不變更,是為客戶(用戶)保護現有的價值。而我們在CI/CD/DevOps中努力的,就是透過我們的技術、能力、流程、方法,好讓為客戶創造新價值的同時,也能保護既有的價值不會有一絲一毫的損失。

今天,是2016的第一天,文章寫到這,我想回頭提兩個跟開發人員有關的議題,一個學習,一個是工具。

很多人知道資訊技術變化很快,學習很不容易,每天有太多需要學習的新東西,工具更是變化莫測,現在,我們常常一本書還沒寫完,就必須重頭開始寫,因為功能更新了、UI改變了…

這樣下去,豈不是永無止盡的一天?

2016的第一天,我想跟一些朋友說。如果你開始意識到自己人生有限、自己的時間有限,那你必須和我一起回頭思考一件事情,技術的學習、工具(包含實體和非實體的,例如程式語言)的使用,其本質的意義到底是什麼?技術到底為你彰顯了什麼價值?工具解決了你的問題?還是為你製造出(帶來了)了更多的問題?

學習本身是一種樂趣,但我們學的技術究竟是真正重要的,還是如同過眼雲煙一般,隨時會消逝不見?我們所使用的工具,究竟是為我們節省更多的時間,達成更多的效益,還是你學了半天,學會很多指令,但發現能做的事情卻越來越少? 越來越不值錢? 卻越來越需要學更多的工具與指令?

2016的開始,這是我給自己思考的問題,如果你也有興趣,不妨一起想想,關於事物本質,這個對你來說可能更重要的問題。