SERIES ・系列

工程師血淚史

Engineering War Stories

系統開發現場的真實踩坑紀錄：需求變更、工作流程、文件與團隊分工，問題是怎麼發生的，又該怎麼避免。

共 6 篇文章

團隊在系統開發上遇到了哪些問題 —

「我們學了很多方法，但在實務上卻各種出包。」我想這應該是很多開發團隊的心裡話，儘管大家都能看見問題，也嘗試導入各種方法試圖解決；但很多時候別說進步，有時甚至還會走回頭路，筆者剛好透過這個主題整理團隊過往遇到的問題；不過解決方案是否有效、會不會衍生新的問題，就看之後的連載了😅

PART 01 2022.05.27 8 分鐘

有些 PM 覺得跟工程師溝通很痛苦，甚至大腦會不時冒出這樣的想法：「明明只是修改一個小地方，為什麼總有各式各樣的理由拒絕跟拖延，就算答應修改，做起來也是一副心不甘情不願的樣子。」

PART 02 2022.07.07 6 分鐘

在過去的文章中有提到，為了提高團隊成員在 Scrum 的參與度，我們改成輪流擔任 Scrum Master 的機制，但這樣真的有效果嗎？而且 Scrum Master 跟 PM 的工作高度重疊，要如何區分兩者的權力與責任呢？

PART 03 2022.07.12 4 分鐘

在流程不明確的狀態下，團隊成員只能憑藉自己的直覺做事；如果彼此對一件事的認知不同就容易造成誤會，甚至爆發不必要的衝突。

PART 04 2022.07.29 6 分鐘

如果公司的專案很多，README.md 又沒有寫好，那後續接手的人會非常痛苦；如果公司專案的規模很大，README.md 又缺乏維護，那這個專案已經半隻腳踏進棺材。

PART 05 2022.08.05 5 分鐘

在工程師的職涯中，「修改文字」應該是我遇過最多次的需求變更。

PART 06 2024.02.22 3 分鐘