正好是六個月前參加了 Daniel 的開腦課程，這次非常感謝 Daniel、91、老闆可以讓我有機會再次的參加。不僅僅是希望能夠用不同的角度再次學習，也希望透過這次的複習，檢視自己過去半年來都做了些什麼。這們課對我的意義已經幾乎不在 SCRUM 與否了，更聚焦的是成年與否。在第一晚 Daniel 主講的「切肤之痛」活動加持下，第二天的課程結束後，有一種很強烈的愧疚感。這半年沒有產生強烈的記憶點，我並沒有轉化為成年人，依然只是庸庸碌碌的活著。
今天分享的是在《敏捷回顧：團隊從優秀到卓越之道》之中學到的「三個五」的活動。書中歸類在「收集數據」的章節，也就是 ORID 之中的 O（Objective ），但我覺得也很適合用在 brainstorming 的情境。
前一陣子閱讀了 Ed Catmull 的《創意電力公司 ― 我如何打造皮克斯動畫》，這本書讓我非常有共鳴，特別撰寫這篇文章，記錄並梳理我的心得，也同時分享給各位。
整本書裡頭，壓根沒有提到任何「敏捷（Agile）」的概念或字眼，但完全就是敏捷文化的形狀。這就是我內心敏捷的最高境界，叫什麼名字、跑什麼框架並不重要，重要的是團隊一同實現的文化內涵。除此之外，我們也熟悉迪士尼和皮克斯的一些作品，所以閱讀中就像穿插了一些小彩蛋一般，比起一般的商業管理書籍，又多增添了點趣味。
最近閱讀了《Soft Skills 軟實力：軟體開發人員的生存手冊》一書，裡頭的第 20 章「打造吸睛品牌 - 打造個人品牌」，提到了 Fiverr 這個網站，只要 $5 美金就可以客製化一個個人專屬 logo，好奇心摧使下，我試著做了一個屬於自己的 logo，以下簡單分享一下心得。
最近發現原先寫好的 Python 自動化程式「send_keys」部份出現異常，會吐出「selenium.common.exceptions.WebDriverException: Message: unknown error: call function result missing 'value'」的錯誤訊息，經查發現是因為 Chrome 自動更新後導致與 chromedriver 版本不匹配所衍生的問題，這邊簡單記錄一下解決方式。
我的手機 Zenfone 4（ZE554KL）前一陣子以一個頭下腳上完美的姿勢落入了馬桶中... 沒錯，是馬桶。還在保固內，所以走了一遭華碩皇家維修中心搶救無效後，就自己土砲嘗試維修，竟然奇蹟似的修好了！！以下是這一切經歷的全紀錄，希望可以幫上有類似情況的朋友。
現在下音量鍵仍是故障的、電源按鍵些微接觸不良，除此之外一切功能正常。
之前讀過《學得快才會想學!：黃金20小時學習法》，也利用過這個方法提昇英打速度，有相當顯著的成效，20小時從 28 word/min 提昇到 45 word/min。使我更確信這樣的學習方式是有效的，講求密集、重複的刻意練習，更進一步利用睡眠前的時間學習以提昇效益（睡眠是腦袋將新技能存檔的時刻）。這次我也利用這個方式嘗試學習 VsVim，打算每天練習 30 分鐘，持續不間斷的 40 天。直到今天，用個人最佳紀錄 16：45 劃下了完美的句點。
全紀錄影片：https://www.youtube.com/playlist?list=PLsZcGsUwoam_q_tHYqstz_1_UgmV94ibJ
敏捷開發講求團隊合作，往往有很多事情需要大家共同決議，最常見的不外乎圓點貼紙（dot voting），用投票的方式快速找出共識。然而，在我閱讀《失控的多數決》後，對於簡單多數決，有了些微不同的看法。彙整記錄，提醒自己別輕易把多數決與共識劃上等號。
昨天在公司帶了一場約莫 20人四個小時的需求探索 workshop，算是上完 David大「敏捷需求探索入門工作坊」的一個分享，憑藉著自己這一點點司機的知識就上場了。主要是將比較「敏捷」色彩比較重的部份去除（時間不夠，就先不談敏捷了...），讓大家簡單體驗一下需求探索中的各種工具、框架，希望在未來有相關需求時，至少有個關鍵字可以去深究。這是我第一次在公司舉辦這樣的型式的活動，算是邁進了一步，特別記錄、省思，希望未來能夠更好。
身為一枚 Scrum Master，我明白自己的角色職掌，也努力學習了不少 SM 的相關知識；現在的我也參與開發，所以也略懂身為 member 該有的技能與姿態，唯獨 PO 這個角色，我僅僅明白該承擔什麼責任、扮演著什麼樣的角色，對於 PO 的工作該怎麼進行，絲毫沒有頭緒。
所以我希望自己不僅明白 PO 的角色職掌，還能給予 PO 更棒的協助，甚至是引導。所以我報名了 David 大的「敏捷需求探索工作坊」，希望能夠有所助益。這天的 workshop 真的很有收穫，記錄一下我滿滿的心得！先說結論，這門課完完全全符合我的需求與期待，讓我在需求探索這塊領域讓我有了一個非常棒的入門，期望自己真的能夠給予 PO 足夠的協助。
職人之道就是每天重複一件事。
身為一枚軟體工程師，「寫」程式就是我每天重複的那一件事。若能不斷精進此道，把最細微的事情也處理的更有效率，我想這就是一種職人精神吧。
在經過 91 大「Visual Studio 極速開發」課程的洗禮後，發現自己在「寫」程式這件事上，真的有很多不自覺的低效率動作，渾然沒有察覺。藉著這篇文章，連同之前已知修正的問題一併羅列出來，希望可以分享給一樣靠 coding 維生的朋友們參考，檢視一下自己是不是也有這些瓶頸，慣用的 IDE 是不是能夠提供類似的快捷鍵？
老實說，在參加課程前，這幾個字分開大略是什麼意思都知道，但無論哪兩個合在一起我都沒聽過。XD 就這樣懵懵懂懂的去參加了這個體驗 workshop。這邊記錄一下我自己的感想與心得，Workshop 細節就等著大家有機會自行體驗才會更有感覺～
在十月底的某個半夜一點左右，睡前在床上滑著手機，突然在 FB 看到 Joey 竟然在這大半夜時刻發布開課的消息，立馬詢問相關資訊、填單報名。果不其然，當天中午前就額滿了，還好睡得晚。XD
今天讓整個軟硬團隊練習需求切割的過程中，感受到一些有趣的現象，記錄下來與各位分享。這是一個真實存在的需求，但不是實際的時程，藉由這個需求讓團隊練習，也或者說趁此機會同步一下大家的想法。
最近上完了 Bill 大叔的 Design Pattern 課程，受益良多，簡單分享一下學習心得。此篇聊聊 Pattern 的形狀。
在學習 Design Pattern 時，免不了會從 class diagram 開始下手，但有時候太過在意「形狀」反倒會忽略 Pattern 真正的意涵。Pattern 真正的用途是為了解決問題，而不是炫技或面試。
又到了一年的尾聲，來做個自己 2017 年的 Retrospective 吧～
今年是自己職涯中最突飛猛進的一年，進步的不是薪資，更不是職稱，也沒有換工作。卻是我學習成長最豐碩的一個年頭。
從三月左右開始，覺得需要一些方法來管理團隊工作，對於敏捷開發還似懂非懂，只翻了幾本書查了一些文章，感覺相當時尚，決定先做了再說，就這樣跌跌撞撞的導入了 SCRUM，而我擔任了 Scrum Master 這個角色，一切就從這個看似辦家家酒的故事開始。
最近上完了 Bill 老師的 Design Pattern 課程，對於 Design Pattern 有了更進一步的體悟。
回想當初我藉由《深入淺出設計模式》一書初次接觸 Design Pattern，看完之後，完全就是「手上有鎚子，看什麼都像釘子」的狀態，實做專案第一個想的就是要套用什麼 Pattern，希望一次把 Pattern 搞對之後就能高枕無憂，也覺得好像套上了 Pattern，一切就感覺高大上了起來。但這完全是錯誤至極的思維，上完這門課之後，對於 Design Pattern 有了更明確的一個輪廓。
實行敏捷開發以來，慢慢體悟到很多文化、思維與傳統模式（瀑布）上的差異。逐漸感受到這不只是一種方法論，而是一種文化及信仰的力量。一個失敗的產品，可能的原因很多。先不論外在資源、環境等因素，單單就團隊內部能量是否能夠完全展現，就是一個很值得討論的問題。
繼 [軟體開發] 淺談軟體開發 再接著聊聊軟體工程師如何面對這一片困境，從一個最小的面向談起 ― 自己。
這次煞費苦心，終於透過自售的方式把愛車給出售了。做了不少功課，學習了不少，特別紀錄下來，希望能提供給有自售或是購買二手車（中古車）需求的朋友。
