2018年11月4日 星期日

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

這篇是關於自動化的兩三事的後續,而自動化流程這件事到今天也完全沒有進展。主要原因大概是某些人只是想做產品,而不是想把產品做好。所以我在卸任產品的負責人之前,也都沒有主動提起自動化流程了。
一部份原因是被需求壓得喘不過氣,另一部份原因是失去了熱情

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

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

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


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

沒有留言:

張貼留言