看板
[ Soft_Job ]
討論串[心得] 我在科技業遇到的鬼故事之一
共 17 篇文章
內容預覽:
1. 有點訝異滿多人會想一直討論責任歸屬的問題，這其實軟體開發常見的狀況，問題在於流程而不是人。比起究責，專注在完善流程，看下次怎麼做的更好的團隊，會更人想待。有興趣可以 Google 看看 blameless culture。. 2. 撇除專案本身，B 的發言可能表示他沒有客戶優先的 mindse
(還有146個字)
內容預覽:
CPO issue被關閉後在客戶端炸開這種事情太常見了. 這件事情可以要分成兩個部分來討論. 1. 事件. 流程的部分應該是最重要的,大家前面討論很多. 其實元po的公司這事情流程上沒有太大問題. CPO issue 被關掉 就submit feature 是理所當然的. 最多就是關issue要多人
(還有291個字)
內容預覽:
針對上一篇還是有人在追殺B我就閒來無事重申一下問題點在哪裡. 很多人一直糾結於B有沒有複測、B有沒有去追這個Issue，我跟你說跨組合作不是這樣搞滴. 首先要先搞懂這個Ownership的問題. 原Po是Feature Owner. A是原Po組的寫出有問題Code的Dev. QA在原Po組. B的
(還有584個字)
內容預覽:
單純經驗交流一下. 我遇到正常的軟體UT與品質驗證流程吧：. 1.開發者寫完程式碼與UT。. 2.在自己電腦上跑UT。. 在自己電腦上跑UT，是部門不認的UT。. 沒人知道你自己電腦的環境與有沒有動手腳。. 3. Commit and push 到 repository 開發分支。. 4. 啟動 C
(還有971個字)
內容預覽:
閒閒沒事來回第三篇繼續捍衛一下B. 我拿我自身經驗分享一下，我在亞麻在Amazon模改的Android OS底下開發過Android Application，雖然不完全一樣但是應該有點相似. 首先是討論開Ticket關Ticket的問題，如果今天用新的OS版本炸掉過一次我開Ticket給OS組，OS
(還有663個字)