目前我們研發團隊已經跑了兩個 Sprint，想要陸續來了解一些跟 Scrum 有關的定義和規則。
原本以為【敏捷開發】可以加速開發，畢竟叫做【敏捷】，但查了網路文章，有經驗人士分享，結果根本就不是啊⋯⋯🤪
這讓我對敏捷開發幻滅，身為我這種生產力極高的工程師說，實際跑才兩個 Sprint 就發現，此模式是會拖慢我開發效率的⋯⋯不過還是希望習慣此開發模式之後，會逐漸加快吧～
這次就來理解什麼是 Scrum 團隊？
看了這張圖，就能了解 Scrum 團隊包含哪些角色，目前看起來 Scrum Master 和 Product Owner 相當重要，我們團隊是由有三年跑 Scrum 研發經驗的工程師翔所領導。趁這時候聽話照著做，肯定能學到許多！😎
我們工程師有 Web、iOS、Android、Flutter、Backend、Architect、DevOps 等。而設計師、需求者（市場、業務、產品等）等不在我們 Scrum 團隊中。
（繼續閱讀…）工作多年，一直有聽說跑 Scrum 與跑 Sprint，但一直不曉得真正的規則是什麼？覺得新創公司的開發步調就是種跑 Scrum，但好像又相差甚遠。🤔
終於，這次新創團隊，某位翔大在前公司有跑 Scrum 的經驗，從無到有建立起來整套流程，據說他為了履行 Scrum 的真實義，甚至還因此讓上司覺得跑 Scrum 是個阻礙⋯⋯
我想，引進新的管理辦法，確實會讓原本順暢的工作流程受到干擾，也就是原本跑得流暢的工作程序，會出現窒礙難行的狀況。除非公司能夠承受變動過程的成本，如此推動跑 Scrum 才有機會成功～
我認為，須根據公司成長階段來實施 Scrum，初步可分為
比較適合的是 1-10 階段，為什麼呢？介於混亂與穩定之間，可有效率發散與收斂研發效能！🤠
（繼續閱讀…）這次執行的區塊鏈平台產品，沒有足夠時間可以完整進行：分析、設計、實作、測試、釋出。
看到下方這張時程圖－專案計畫與實際，發覺我們正面臨的狀況，正好只有兩個月的時間，就要釋出給大眾使用，全部時程都擠在一起，這樣成果品質是不會太好的⋯⋯
我想主要原因在於，我們接手前人所寫的解決方案，尚未了解此 Code Base 架構與品質，就率先決定產品推出日期。
當我們人力陸續到位，能夠開始部署，才陸續遇到問題，光是要將缺陷給修正就要花點時間，再來還要新增需求。時間有限之下，需要有所取捨，如此就會造成混亂，每次局部測試一直遇到狀況，修正後還是會偶發狀況，表示整個系統是相當不穩定。
我主要心力放在 App 開發，我所在乎的後端，就是期待 API 能正確運作。於是我要先走一步，提早研究將來會使用到的技術。
期待接下來的時程能順利囉～🤪
又到了一年一度更新推播憑證的時候！因為先前僅有初次產出推播憑證經驗，但沒有更新推播憑證的經驗，以為會有多難，沒想到就跟初次一樣的步驟。🧐
發現舊有的憑證無法更新期限，那麼就如同第一次建立新的推播憑證吧！此次推播憑證更新：2020/10/05，期限：2021/11/04，有效期間為13個月。
一如往常，在Apple釋出iOS 14後不久，身為開發者的我就會更新Xcode 12（每年更新一個版本號），不過這次遇到奇妙的問題，明明筆電的可用空間大於軟體容量，安裝時居然還會跳出「空間不足」，而且也沒說不足多少，使得我必須不斷清理出空間，像是移除鮮少使用的軟體，甚至刪除前同事帳號裡的非必要的檔案，來下載Xcode 12。🧐
在App Store上看Xcode 12容量有11.2G，我騰出15G可用空間應該就足夠了才是，不過就是提示空間不足。
直到我硬擠出30G可用空間，還是給我裝傻空間不足⋯⋯😭
最近要一口氣地將所有產品做完支援Layout API的功能，我特別善用Git的Branch (分支)功能，也就是把每一個開發目標都開個Branch，單純只記錄一個開發目標的變更，如圖：
Source Tree真是個好工具，可以將Branch以不同的顏色表達！
當每個開發目標都完成增修後，就可以開始一步一步來Merge (合併)，如圖：
儘管我是一個人在開發產品，然而我不馬乎地開Branch，就有機會碰到Conflict (衝突)，此時可來練習如何排除此問題，之後再遇多人協同合作的開發模式，就不必手忙腳亂囉～
使用指令也相當簡單：
傳統在軟體開發上會用到瀑布流開發、敏捷開發，這時候又有人自創「閃電式開發」⋯⋯這是一本書的名字，作者是位連續創業家，僅管在網路上的風評噓聲多於讚聲，但總不能完全鄙視人家的成就與想法。其實「她」是個女生，不過大家已習慣把她當男生看（咦？）我欣賞她實踐的能力，若讀得懂她所說的內容，就容易明白她的做法在當時狀況真的是命中關鍵，要一言以蔽之的話，就是面對目標要快、狠、準。
八月趁著公司放我一個月假期，我拿著「閃電式開發」去隔壁小七喝下午茶：）～
當然也要看讀者是怎樣的人，有人偏好穩定的工作，有人喜歡亦步亦趨的工作，有人愛好驚險刺激的工作，有人把危機當轉機為工作，若你是想要在網路上創業，我會推薦Xdite的閃電式開發。此外，上個月介紹我欽佩的周品均「創新態度與思維」也可以參考。
註：其實還有更猛的開發，文章最底下會介紹：Ｐ～
最近陸續有新人來公司報到，我跟一位很年輕成功轉型工程師的同事（原本是教小學生課輔，網路看影片自學寫程式）聊週末去哪玩，他提到自己想要還技術債 (Technical Debt)，我以為他要改前人留下來的專案，他說因為很多技術還沒有熟悉，所以想要更用功在鑽研技術上。
突然我想到小英總統2018年底變成辣台妹，因為人家說她「撿到槍」。原本的意思是貶義，拿到不屬於自己的東西（也就是贓物），就說那是撿來的。對於小英勇敢回應強勢的對岸，就變成褒義，表示拿到神級武器，可以從挨打的份逆轉成反擊！不過扯遠啦ＸＤ～
後來他表明不曉得技術債真實意義，我便簡單解釋，因為急著要完工，難免會以不周全的寫法完成程式功能，之後若要增修專案，就會面臨之前的「遺毒」。下圖可以明白技術債的陰影面積ＸＤ～
製圖的作者很神奇，使用我非常喜歡的動畫獵人，拿酷戮的念能力可以來做解釋，胖娃隨著時間債會越滾越大，最後破產就會讓敵人無法使用念能力。若拿來比喻軟體工程，技術債若隨著時間累積，到一定的程度使人難以再做增修，此時專案就要宣告「打掉重練」！
要快又要好，實在不是很容易！除非專案只是一次性，若要長期維護的話，還是要有品質地實作呀～
註：拿酷戮的念能力「天上不知唯我獨損」（推測是放出系的念獸）另外十分擅長於逃跑。「天上不知唯我獨損」是將念借給對方並以複利計算的高利貸，由胖娃娃「波克里林」計算，在借貸內攻防皆不會受到傷害，借貸額數超過對方念的最大值就會破產，「討債魔」出現強制對方進入絕的狀態30天。
參考：Scrum Estimation－Scrum Estimation Model、獵人WiKi – 拿酷戮•拜因、有效面對技術債、專案中的隱形殺手：技術債。
我們開發軟體會透過Jira來記錄細節，像是新增功能或修正錯誤，甚至還有概念驗證 (Proof of Concepts)。
概念驗證（英語：Proof of concept，簡稱POC）是對某些想法的一個較短而不完整的實現，以證明其可行性，示範其原理，其目的是為了驗證一些概念或理論。
逍遙文工作室 
HappyMan・迴響