關於自動化的兩三事 - 後話

這篇是關於自動化的兩三事的後續，而自動化流程這件事到今天也完全沒有進展。主要原因大概是某些人只是想做產品，而不是想把產品做好。所以我在卸任產品的負責人之前，也都沒有主動提起自動化流程了。

一部份原因是被需求壓得喘不過氣，另一部份原因是失去了熱情

某一天突然發覺，這次的失敗打擊超乎我的想像！在無意識中我不願想起這個專案，自然也從沒有思考或和其它人討論這個專案失敗的原因。我明白如果不去思考失敗的原因，那麼未來就還會再度發生類似的情況；但我不知道的是…原來承認失敗真的不是一件容易的事

我要先澄清一件事，這個專案目前還活著。只是暫停開發與維護，未來會重啟的可能性也不低。所以我才會更訝異我的內心如此地草莓…(我不承認)

接下來談談在管理這個專案時，所發現到的問題或是瓶頸、推行的改進方案、遇到的阻礙、以及之後的結果與反省

1. 過份依賴 IDE 進行開發

我並不總是用 vim 進行軟體開發，畢竟 IDE 很方便嘛。但是如果不使用特定的 IDE 就無法進行開發的話，那就令人頭痛了。令人感到挫折的是，在這個專案中就有兩個…

1-1. MyEclipse

我不是在打商業廣告，你可以把它想像成付費版的 Eclipse，提供了很多方便的功能。

• 發現到的問題
• License 限制了開發人數
• 沒有考慮過多人協作的情況。使用 Eclipse 專案，編譯環境受限 MyEclipse 提供的 Libraries，導致使用其它 IDE 編譯困難
• 提出解決方案
• 改用 Maven 專案
• 遇到的阻礙
• 沒有獲得主管支持
• 開發能量不固定。當時有兩個專案在跑，但寫前後端的只有兩個人。大概是三到四個月過來幫我，然後時間到就會離開。
• 結果
• 失敗

1-2. Sencha Architect

我不是在打商業廣告，Sencha ExtJS 整合了 HTML5、Javascript 和 CSS3，而 Sencha Architect 提供視覺化功能，像是可以拖拉元件等等的功能。Sencha Architect 存檔時是存放在 METADATA，然後再動態產生出 Javascript 檔案，最終是用 Javascript 檔案建置出結果。

• 發現到的問題
• IDE 有 BUG，常常 Crash。就算是新版的 IDE，BUG 仍然沒解決
• License 限制了開發人數
• 沒有考慮過多人協作的情況
• 當 METADATA 發生 Conflict 時，不容易解決
• 解決 Conflict 之後，仍然需要 IDE 針對 Merge 後的 METADATA 再進行一次存檔，才能保證 Javascript 檔案是正確的。
• (你可以想像當 Conflict 10 個 METADATA 檔案，好不容易解決完了，還得在會一直 Crash 的 IDE 存檔 10 次)
• 提出解決方案
• 捨棄 IDE
• 遇到的阻礙
• 沒有獲得主管支持
• 開發能量不固定。
• 寫前端的第一個 M 大沒有經驗，先讓他熟悉一陣子。過一段時間之後離職了
• 寫前端的第二個 S 大沒有經驗，先讓他熟悉一陣子。在我卸任幾個月後離職了
• 結果
• 失敗

2. 軟體的編譯需要人力介入

編譯中需不需要人力介入，這一部份牽涉到未來能不能做 CI。

2-1. Backend

後端是使用 MyEclipse 進行開發的，屬於 Fat Project。從第一個產品開始，全部都在相同的 Eclipse project 進行開發。

當某一天用 MyEclipse 打開專案，發現記憶體已經不夠用的程度時，才決定將不同的專案模組化，各自模組有自已的 git repository。不知道是執行不夠徹底，還是提出這架構的人根本(腦子有洞)沒想清楚…最終自動化的可能性是完全沒有。

• 發現到的問題
• 只有 T 大可以編譯，因為他還留著最初的 Fat project。我曾嘗試過用目前架構進行編譯，最終結論是無法使用。(當這個人請假的那一天，原則上那天就無法 Release)
• 當開發完成之後，單向同步到各自模組的 git repository (簡單來說就是 Copy & Paste)，然後再進行 git commit & push。
• 當編譯完成之後，再手動複製 UI、Tools 等所需檔案。基本上，包含 UI、Tools 等檔案，全部都會上 git server … 
• 當編譯完成之後，再手動刪除其它用不到的模組…
• 提出解決方案
• 改用 Maven 專案
• 遇到的阻礙
• 沒有獲得主管支持。(架構是他設計的，他不認為是個問題)
• 開發能量不固定。
• 結果
• 失敗

3. 聽說我們跑的叫 SCRUM

我過去所接觸到的軟體開發流程是 Waterfall，當 2016 年底主管說要導入 SCRUM 時，事實上是完全不懂。主管擁有 SCRUM MASTER 的證照，開始講 SCRUM 的大概流程，然後用他的經驗刪去那些不重要又浪費時間會議。

原本也是以學習的心態去接觸，但那一段時間沒享受到 SCRUM 的優點，缺點倒是全包了。幾乎每天都有幾小時的會議要開，每個人累得要死，產品做得不怎麼樣，品質也不怎麼樣。

現在回想起來，當時的合作方式是有問題的。產品需求、開發時程都是由主管決定，我比較像是專案經理或是 RD Leader。

結果需求講不明白，出事了就叫我負責，原來是這種產品"負責人"啊

在這種權責不明的狀況下，自然衝突就少不了。在 2018 年過年後，我就被拔掉負責人的頭銜
調到另一個產品線，回到小 RD 的日子。

在那裡跟幾位同事一起學習敏捷開發、研究 Scrum，才發現我們之前跑的根本不是 SCRUM。

• Daily Scrum 是報告進度大會

• 拿掉浪費時間的 Planning Meeting，因為所有需求都是最高優先

• Retrospective Meeting 是要你反省為什麼東西做不完也不加班。

4. 結語

後來跟同事們合作，把 SCRUM 角色、會議都定義清楚。目前的主管也跑去上 SCRUM 課程，大家一起跑了半年，也有點樣子了。不過如果還要再提升效率的話，還是卡在老問題…

這個產品也沒有自動化流程，而且軟體是相同架構，上面列的問題都有 XD