目前我們研發團隊已經跑了兩個 Sprint，想要陸續來了解一些跟 Scrum 有關的定義和規則。
原本以為【敏捷開發】可以加速開發，畢竟叫做【敏捷】，但查了網路文章，有經驗人士分享，結果根本就不是啊⋯⋯🤪
這讓我對敏捷開發幻滅，身為我這種生產力極高的工程師說，實際跑才兩個 Sprint 就發現，此模式是會拖慢我開發效率的⋯⋯不過還是希望習慣此開發模式之後，會逐漸加快吧～
這次就來理解什麼是 Scrum 團隊？
看了這張圖，就能了解 Scrum 團隊包含哪些角色，目前看起來 Scrum Master 和 Product Owner 相當重要，我們團隊是由有三年跑 Scrum 研發經驗的工程師翔所領導。趁這時候聽話照著做，肯定能學到許多！😎
我們工程師有 Web、iOS、Android、Flutter、Backend、Architect、DevOps 等。而設計師、需求者（市場、業務、產品等）等不在我們 Scrum 團隊中。
繼續閱讀文章 »由於市場業務部不斷提出新的需求，迫使我們設計研發部必須加速實現，但當前人力有限，勢必得尋找新的人力資源，有兩種方式：
當下狀況是，來不及招募到合適人才，而市場業務部恰好有認識的外包團隊（中國與台灣各一），長官們決定嘗試接洽，然因為長官不熟開發知識與技術，於是就請我來當窗口，向兩個外包團隊說明我們想要使用的技術與達成的結果。🤔
人有失足，馬有亂蹄，總是會在日常生活中，不經意發生。
曾經以為我幾乎不可能會弄丟任何卡片，但就總會有那萬分之一（因為是幾乎），突然就發生了。🥲
事情的開始是這樣，一如往常，我在家門前搭公車，要前往中山區上班，這班公車剛好乘客很多，上車時我先刷卡，然後把卡片放進我褲子口袋中。
快到了目的地候車站，我從口袋卻摸不著我的卡片，公車就快停靠，該怎麼辦呢？我沒卡可刷⋯⋯只好先默默地下車，心裡跟司機大哥說聲抱歉⋯⋯😅
繼續閱讀文章 »2022 年初，想嘗試新的穿著，首先由腳步開始，特地去蘆洲總店買了洞洞鞋。之所以有這個動機想買，是因為 2021 年蜜月環島旅行，看到朋友嘉芳一行人，在下雨天騎公路車時，有換穿洞洞鞋，這讓我好奇它好穿在哪？🤔
必須說人生在世，要有強烈的好奇心，去嘗試各種尚未接觸過的人事物，如此能快速理解世界是如何變化，甚至可以預測變化的趨勢走向！
繼續閱讀文章 »現在製作 App，很多時候需要嵌入 WebView，如此能快速開發與更新。既然 App 與 Web 互動頻繁，那麼就需要來了解如何讓 WKWebView 與 Native 互通資料。
多年前我也有寫過 Objective C與Javascript的溝通，然而那時還能使用 UIWebView，現在已經被棄用，所以我們就直接使用 WKWebView 吧！
繼續閱讀文章 »工作多年，一直有聽說跑 Scrum 與跑 Sprint，但一直不曉得真正的規則是什麼？覺得新創公司的開發步調就是種跑 Scrum，但好像又相差甚遠。🤔
終於，這次新創團隊，某位翔大在前公司有跑 Scrum 的經驗，從無到有建立起來整套流程，據說他為了履行 Scrum 的真實義，甚至還因此讓上司覺得跑 Scrum 是個阻礙⋯⋯
我想，引進新的管理辦法，確實會讓原本順暢的工作流程受到干擾，也就是原本跑得流暢的工作程序，會出現窒礙難行的狀況。除非公司能夠承受變動過程的成本，如此推動跑 Scrum 才有機會成功～
我認為，須根據公司成長階段來實施 Scrum，初步可分為
比較適合的是 1-10 階段，為什麼呢？介於混亂與穩定之間，可有效率發散與收斂研發效能！🤠
繼續閱讀文章 »身為資深高級工程師，一直很好奇，檯面上頂尖的科技公司，一年可以賺多少錢，裡頭有多少跟我一樣的角色。剛好看到讓我眼睛為之一亮的圖表，這次就直接看圖，就能知道它在哪項目賺多少賠多少囉～
剛好 2022 年下半年，這些頂尖科技公司，不約而同，陸續大量裁員，在各大社群平台，多少能看到跟我一樣角色的網友緊張兮兮。笑說若沒經歷過裁員，那肯定沒真正當過工程師。😜
首先來看一下 Apple，近十年以來，我的工作離不開它，感覺就好像在 Apple 工作似的。事實上，我就只是個 iOS App 工程師，從 iOS 6 寫到 iOS 16，而且這個職涯故事，還會繼續下去呢～🙃
繼續閱讀文章 »今年又經歷一次職涯轉換，身為 App 開發領導者，我的生活顯得相當忙碌，差一點就沒空記錄一年一度的「祝我生日快樂」。
轉眼間邁入人生第 36 個年頭，心境逐漸朝想要穩定的方向前進，身為人夫也即將當爸爸，許多事情的安排考量眾多。世間沒有什麼事物不會改變，依然會遇到困難與挑戰，那就要打要閃繼續前進吧！😎
繼續閱讀文章 »2022年九月，有三次地震讓我印象深刻，震央都在台東或花蓮，在遙遠台北的我還是感受到地震搖晃，但手機卻沒有收到地震國家級警報，一直在想是什麼原因？難道我是邊緣人嗎？🥲
看了下列這張圖的說明後，確實很可能是這幾個原因，那之後就不必大驚小怪囉～
萬年老系統是非常誇張的說法，我寫 iOS App 是從 iOS 6 開始，至今 2022 年已邁入 iOS 16，若說是老系統，應該頂多 16 年啦～😀
實際上現在公司的產品，是從 2016 年開始（看程式檔案有年份），還是使用 Objective C 開發，至今邁入第七年，我發現是有四個工程師陸續接手研發，因為有看到作者名字和程式風格。
因為我一直是開發 iOS App，所以一個月內我就對大部分的功能流程熟悉，包含串接後端 API 部分，只要有使用到的 API，一定給他測個成功和失敗案例。
目前公司後端工程師數量遠超過前端，畢竟後端模組至少有 10 個吧～假如 iOS 和 Android 勉強算兩個模組，可見後端複雜度之高～🤪
稍微了解 API 後，我明白後段相依性很大，想要在舊有錯綜複雜邏輯下往上加功能，肯定會有一些出乎意料之外的狀況。讓我想起萬年老系統那張圖～很是貼切呢！
總之，且戰且走，我們採滾動式開發～盡可能不要讓前端拿到有問題的 API 就好啦！😜
若有朋友需要開發 App，歡迎來找我喔～
逍遙文工作室 
HappyMan・迴響