接續同系列文章《Agile Tour Taipei 2015 筆記與心得》，本文繼續記錄 Agile Tour Taipei 2015 上午第三場議程「從Agile到Lean Startup：趨勢的軟體開發之旅 - Jason L Lin」的筆記與心得。
從Agile到Lean Startup：趨勢的軟體開發之旅 - Jason L Lin
講師的簡報已經釋出，可以由此瀏覽。
第三場議程是由趨勢科技 SQA/SEPG 部門的林立仁為大家分享。講者在自我介紹時特別強調了 SQA/SEPG 部門，根據講者所言趨勢科技很重視軟體開發方法，因此 SEPG 部門的工作之一就是將一些優良的軟體開發實踐帶入公司之中。
趨勢科技推動這些實踐主要是由 Bottom-up 的方式進行，企業文化鼓勵員工做中學並勇敢嘗試錯誤。這種鼓勵學習、容許犯錯的企業文化不知道會戳中多少困在傳統企業文化的開發者？據說趨勢仍然有在徵人，有興趣者不妨可以考慮看看。
（提供一個對照組，上次在 iThome DevOps 2015 研討會中，Yahoo 就提到 Yahoo 推動 CD 時的方式就是 Top-down。）
簡報的前面兩頁是公司簡介，不過講者在提到「經營理念」時，特別強調了「自我提升、保持創新領先地位」，用這一點呼應為何趨勢會在企業內部大力推動導入 Agile 與 Lean statup及前面自我介紹提到企業內部會成立 SEPG 部門。一再的強調趨勢實在是一間鼓勵學習、創新的公司。
接著作為前情提要，講者先快速地介紹趨勢科技導入 Agile 的歷史，主要有幾個重點：
從 2007 年開始嘗試導入。 接著 Bottom-up 遍地開花。 目前已正式成為公司開發者的必讀準則。（但非強制遵守） 現在全公司約 60% 的專案有採用 Agile。 既然趨勢科技已經大幅度的導入 Agile 了，那麼是什麼原因導致趨勢科技仍需要接著導入 Lean startup 呢？主要是因為有下面幾個新的問題與挑戰：...
接續上篇文章《Agile Tour Taipei 2015 筆記與心得 (一)》，本文繼續記錄 Agile Tour Taipei 2015 上午第二場議程的筆記與心得：
如何在組織內有效引領敏捷變革 - Richard Hsiao, 蕭存喻
這場議程是屬於「經驗分享型」的內容，講者將過去的經驗歸納重點後，將過程中遭遇的狀況與經驗談一一向大家分享。整場簡報的主軸即是講者所處的團隊如何逐步引入 Agile 的心路歷程。
講師的簡報已經公佈上網，可以直接線上瀏覽。 同時 Agile Tour Taipei 2015 已經釋出錄影。
首先講者用一個問題及一張圖作為開場帶出主題「組織在引入敏捷時常見的阻礙爲何？」
這問題的答案有很多，有來自上層或下層的不同的阻礙，例如常見的阻礙有「如何說服老闆接受 Agile？」或「如何說服工程師開始寫測試？」⋯⋯，當然還有更複雜的阻礙。講師則利用簡報 P.3 的圖片作為說明。
圖片中的 X 軸代表的是 Autonomy 由低至高、Y 軸代表的是 Alignment 一樣是低至高。
那麼你的團隊是屬於哪一個象限呢？是左上角的象限，需要由上層下達明確的指令，團隊才能準確的依據指令行動；或是右上角的象限，同時具備高度 Alignment 與 Autonomy，上層只要提需出問題，團隊即能展現高度自治完成任務。又不幸的是左下角，上層與團隊是一整個渾沌的狀態？
以此開場之後，講師延伸提到了當年他有了一個機會可以開始在團隊中引入 Agile，而這個經驗帶來的第一個心得是「危機就是轉機」，但有一個重要前提是「你需要證明給其他人看」。
「危機就是轉機」這句話大家都能朗朗上口，可是現實社會並沒有這麼簡單。「轉機」來到不等於後面全都會一帆風順，等著看你落水的人比比皆是。所以「轉機」只是一個開始，讓你有機會能取得權責來解決問題。只有在你真正解決了問題，你才能贏得別人的信任，為自己開創新局。
接著講師開始分享過去團隊引入 Agile 的實際經歷，共分成三個階段。細節我就不多描述，因為閱讀簡報就足以說明其中 7~8 成的內容。
第一階段：
這是滿常聽見的一種團隊窘境。團隊處於將要發展並力求表現之時，卻遇到專案進展不順及新主管的介入干擾，面對此窘境想要有所突破，因此決定引入 Agile 嘗試帶來新的火花。
當然團隊不可能立馬全面 Agile，所以在此階段先從可運行的最小實踐開始，先嘗試在團隊中導入了一個 Scrum 看版與 Daily Scrum 會議。
而第一階段最寶貴的經驗是「透明度」！
Scrum 不是萬靈丹，不會因為導入 Scrum 就能讓已經延期的專案忽然變得準時。重要的是導入 Scrum 之後讓一切的資訊變得「透明」，在資訊公開且交流順暢的狀況之下，團隊都能了解明白目前的現狀，這有助建立團隊彼此（包含上層與下層之間）的信任。
第二階段：...
這次特別報名參加了 Agile Tour Taipei 2015，要來補充一下 Agile 與 Lean 相關知識，兩天的活動包含了議程與 Workshop。不過因為 Workshop 正好辦在週日，雖然有幾個感興趣的活動，最後也只能放棄無法參加。
議程從上午 9 點直到下午 4 點半，上午只有一條 Track，但下午則分為兩條 Track。偏偏下午兩條 Track 都有想聽的題目，被迫要有所取捨，導致在中午午餐時間，我在內心演了好久的內心戲，掙扎許久最後選擇了 Track 2。
首先是第一場議程的筆記與心得：
從敏捷與精實看軟體開發的未來 - 李智樺 Ruddy Lee
講師簡報已經釋出，強烈建議務必要閱讀學習。(立即瀏覽) 同時 Agile Tour Taipei 2015 已經釋出本議程的錄影。
首場議程是由金牌講師 Ruddy Lee 擔任，在議程正式開始之前，講師就已經提前開始與聽眾們有著許多的互動，講師一開始就直接開始在白板上畫出「看板」，並請工作人員拿出便利貼開始整場傳遞，邀請聽眾可以寫下任何與 Scrum 相關的問題貼在白板上。
老實說在那個當下，我一度覺得自己是不是走錯場子？今天不是來聽議程的嗎？怎麼彷彿走到 Scrum Master 教育訓練場。而事實上講師所有的舉動，其實都是在默默的鋪梗，當簡報進行到後半之時，就會恍然大悟，原來白板上的「看板」就是簡報內提到的「Q &A 看板」。
在開場中講師有提到一個我覺得很重要的觀念，意思大約如下：
「敏捷其實並不是一個強調『快速』的開發方法，它是用來處理複雜問題的方法，因為它是一個務實的方法。而正因為它能有效地處理複雜的問題，彷彿很快就能解決問題，因此造成大家覺得它很快！」
我覺得這一個觀念的重要性在於讓人對於「敏捷」建立正確的態度，因為真正重要的需求是什麼？應該是「解決問題」，而敏捷提供你一套方法來有效的「解決複雜的問題」。當你可以一再地「務實且有效地解決複雜的問題」，並且定期不斷的「持續改善」，那麼自然你的效率也就越來越「快」！
接著進入議程的主軸，整場議程主要環繞在「看見」這兩個字。首先講師連續用了幾個範例來讓聽眾體會「看見」，強調人們經常需要看見，看了之後才有感覺，才會產生聯想。
例如單車登山的照片，往往你會看見的照片有兩種，一種是車手順利上山，在山頂上的勝利姿勢，另一種是車隊在半路中努力克服陡坡的奮鬥過程。但實際上的情況卻不是如此美好，事實是山頂或山路上可能是車滿為患，車手在登山過程中經常被卡在車陣之中。你所看到照片不過是一個過度美化的結果，所以「看見」不只是看表象，更要能看見「真諦」。
繼續更多「看見」的例子。
同樣是飛機窗外的景致，但是去程與回程帶給人的聯想是不同的。你若在去程飛機上，看到窗外的景色，恐怕你的聯想是：
「下飛機後要先去哪邊 checkin，接著要去哪邊與客戶碰面，然後⋯⋯」
若是回程飛機，恐怕你所想的則是：
「終於可以放鬆休息了，想念家中的妻小⋯⋯」
同樣類似的景致，但能產生的聯想卻是大不同。
飛機的舉例還延伸講到另一個重點，就是「抽象化」。當面對問題時我們要將問題「抽象化」，就像飛機越飛向高空，則地表物體顯得越來越小，你就能看到更多的「全貌」；這就如同由「極度明確」往「極度抽象」的方向前進，當飛到一定高度之後，你會發現問題就只是地表上的一個小點而已。
接著下一個「看見」的範例是一段影片。
講師播放了這幾天被許多內容農場瘋傳的影片《CANAL+ Football - Cameramen》 不過這裡當然不只是為了博君一笑，講師其實是要借用影片中表現的「因為有賣力的攝影師所以我們才能在電視上看到精彩的足球轉播。」這個概念，來類比「看板與專案」之間的關係。
不同於影片，下一個「看見」的範例是一個故事。
講師提到他曾收過一封 E-mail，有位年輕人請他看一下某個網站，但當年的他並沒有任何的感覺，因此遲遲沒有回覆對方，然而多年之後現在這個網站是人人都在用的 Google。...
不曉得該怎麼替本篇內容命名文章標題，所以最後索性直接拿關鍵字當作標題，就讓我偷懶一回吧。
最後還是改了一個標題，因為之後寫的文章可有能會提到這一篇。
公司新添購了一台 Synology NAS 型號為 DS1515+，明眼人一看這型號應該就明白，這是一台可以運行 Docker 的 Synology NAS。Synology NAS 其實原本就已經可以安裝各種套件，讓使用者享受一機多用的好處。現在變本加厲能直接運行 Docker，這根本是意圖叫人不要把 NAS 當成純粹的 NAS 來使用。 （若想要查詢哪些 Synology NAS 可以運行 Docker 可以參閱 Synology 網站。）
既然廠商如此用心良苦，意圖叫人惡搞善用他們家的產品，我們當然恭敬不如從命。基本上既然可以運行 Docker，那麼其實大部分 Server 能做的事情都有機會可以轉移至 NAS 上，所以首先我便打算在上面運行一個 Container 來取代既有的 Raspberry pi。
預定的使用情境大概如下，我們有一檯 Raspberry pi 在運行 cron，它會替我們定時定期執行一些工作，工作的程式是用 php 編寫，透過 php cli 來執行。由此若要轉移這個工作，所需最簡單的環境就是一個有 php cli + cron 的 Container 即可。
因為已經有許多人分享如何在 Synology NAS 上安裝 Docker，因此本文就不再重述，只能說安裝流程非常簡單，只要滑鼠點幾下即可，沒有任何難度可言。使用 Docker 也與安裝一樣簡單，只要透過管理界面點幾下，很容易就能下載 Images，並運行 Container。
如此一來剩下的麻煩事就只有該如何做出一個有 php cli + cron 的 Container 呢？...
故事是這樣演的，接續上一篇文章《幾個圖片無損的壓縮方案》的研究之後，我們開始在專案之中採用 mozjpeg 來做圖片無損壓縮，從正式採用到現在其實也已經過了數個月，忽然某一天客戶回報了一個奇特的異常狀態。
客戶：「你們的網站圖片載入的時候，會先出現灰階圖片，最後才變成彩色圖片！可以修理一下這個 Bug 嗎！！」
聽見這樣的描述，老實說還真是一頭霧水，霎時間不知道該從何處下手，是瀏覽器問題嗎？是引入某個 javascript 的問題？還是 Server 傳輸？還是圖片本身的問題呢？
當然在文章標題我已經揭曉答案，是 mozjpeg 壓縮造成的問題，不過更正確來說這是 mozjpeg 壓縮的 option 設定不當所導致的問題。
在正常安裝完 mozjpeg 之後，你就會多出一個 cjpeg 的指令可以使用，而我們所採用的 option 如下：
cjpeg -optimize -quality 95
這是讓 mozjpeg 進行圖片最佳化 (-optimize)，並且圖片品質設為 95 (-quality 95)，在這樣的設定之下，可以獲得多大的果效呢？下圖是一個實驗的數據，可以看到檔案容量由 4667854 bytes 壓縮成 1403752 bytes，等於壓縮後圖片只占用原圖約三成的檔案容量，可以說是相當不錯的結果。 可惜這美妙的結果，透過瀏覽器檢閱時，卻會出現灰階圖片的問題。
下圖即是異常狀態的螢幕截圖。當在網路速度較差的時候，瀏覽器還在逐步載入圖片，在視覺上會出現先載入灰階，再載入其他顏色，最後才形成彩色圖片的過程。而這樣的狀況即便改用其他的瀏覽器也會出現。 最後該如何解決呢？其實很簡單，只要在壓縮時補上 -baseline 這個 option 即可：
cjpeg -baseline -optimize -quality 95
這樣壓縮後的圖片，雖然檔案容量比較大一些，但是其實也大沒多少，我們用同樣的圖片當作範例，各位可以看到下圖，也不過就是從 1403752 bytes 變成 1472331 bytes，我想這多出來的些微檔案容量，能用來解決客戶眼中的 Bug，可以說是相當划算。 以上就是本次的「獵奇」案件，報告完畢！
因為專案需求，需要盡可能地降低圖片的檔案容量，可是一旦過度壓縮客戶又會哀哀叫說圖片變得好醜，只好來協尋是否有優質的無損壓縮方案，畢竟人的肉眼分辨能力有限，在壓縮比率、檔案容量與肉眼識別度三者中應該能找到一個平衡點。
在詢問過 Google 大神之後得到了幾個比較多人推薦的方案：
mozjpeg jpegoptim OptiPNG 前兩項是針對 JPG 圖檔壓縮，第三項是針對 PNG 圖檔壓縮，最後選擇了 mozjpeg 與 OptiPNG 運用於專案中。
選擇的原因很直覺，因為 mozjpeg 是由 mozilla 所推出且 Facebook 也有贊助並使用於 FB 上，感覺上比較有保障，至於 PNG 圖檔，找來找去總是先看到 OptiPNG 的參考資料，就先選擇它了。
安裝與使用 OptiPNG 先從簡單的開始講，如果是 ubuntu 使用者，只要透過 apt-get 即可安裝 OptiPNG。
apt-get install optipng
基本用法為「指令 檔案」（注意：它會覆蓋原圖檔）
optipng test.png
進階一點的用法，你可加上一些參數設定：
像是 -o 來設定不同的 optimization level
optipng -o 5 test.png
optipng -o 7 test.png
安裝與使用 mozjpeg mozjpeg 的安裝我採用的是先 make 出一個 .deb，再透過 .deb 安裝，這樣做的原因是為了方便後續可以快速轉移到各台不同的 ubuntu 上安裝。
首先找一檯乾淨的 ubuntu 的 VM（個人潔癖問題），安裝好 bulid 所需的基本軟體（參考官方文件）...
第二天的心得與筆記做得比較少，一方面是連續兩天的大會實在很累，另一方面則是因為下午輪到自己要上場，很難一邊聽講的同時一邊思考並修改簡報，例如我的簡報最前面 DevOpsTaiwan 社群的介紹其實就是現場才新增進去，另外也現場增減了一些簡報內容。
DevOps：IT人的新技能、新文化 - 王宏仁 / iThome 新聞主編
第二天開場的重點就是 2014 State of DevOps Report，所以直接去看報告吧！另一個重點就是選對工具很重要！(但別忘了 DevOps 的重點是人與文化！)
DevOps in the Cloud - Ian Lewis / Google 雲端平臺Developer Advocate 基本上整場的內容就是在推銷 Google Cloud Platform，其中有聽到幾個功能稍微有一點興趣，有機會可以研究一下與其他雲端平台有何不同。
instance group manager Cloud Monitoring dashboard 與 Metrics 廚師與伺服器 - 蔡宗城 / 趨勢科技 資深工程師 感想就是講者應該是 Chef 大師，但實在可惜因為場地的網路問題，導致無法順利的 Live Demo。
Yahoo 行動 App 開發在持續整合與持續交付的經驗分享 - 李卿澄 / Yahoo 亞太區產品研發工程部 軟體工程師 講者提到重點在於「workflow of tasks」，另外兩個重點則是要：
過程全部自動化 盡可能將東西放進版本控制之中 在流程上則有以下幾個步驟： Before Commit (要先做 Code Review) Commit (人工 code review 有時候還是會有錯誤，所以還是要透過 CI 自動化的測試再一次把關，然後才能 Merge) Commit stage (同時會檢驗一些指標，例如：測試覆蓋率…) testing (會做 smoke test 、functional test) non-functional testing ( 效能、穩定性 stability test, Monkey test, performance test…) 中間有時候還會有人工測試 (少數案例，例如：結賬與金流相關功能。) production release (如果上線之後還發現問題，就要修改 testing 流程，增加新的測試項目避免再次發生同樣的問題。) 另外講者也有稍微提到 APP 與一般軟體在 CI / CD 上的差異。 Ansible 實戰：Top-down 觀點 - 葉秉哲 / Gogolook 架構師 又是葉大的場，果然一樣精彩，對於 Ansible 又更認識了一些，再加上葉大的實戰講題都會附上簡報與 github，因此聽完之後還可以自己回家慢慢練一次，實在是太好心了！...