PTT職涯區 / Soft_Job (軟體人)

Re: [討論] 故 CTO 對於 Scrum 的看法

看板Soft_Job (軟體人)作者 (lan)時間1天前 (2025/03/08 20:18), 1天前編輯推噓23(33推 10噓 132→)
留言175則, 46人參與, 6小時前最新討論串2/2 (看更多)
不太懂為什麼硬體不能跑scrum 我之前的工作就是做寶寶攝影機，但是是在另外一家 先把前提定義好 這是一個iot專案，包含硬體、後台、app 硬體規格經過evt dvt pvt 已經是量產了 提供的介面與傳輸規格都訂好 而這邊提到的scrum，本質是根據使用者需求快速迭代 我不太懂為什麼這樣的需求做不到 舉個例子 機器本體有個溫控sensor，PM希望可以在溫度超過警示值的時候報警 但不知道是每分鐘報一次，還是只報一次但通知含拍照 像這樣的功能，不能跑scrum嗎？ 這台攝影機，支援的協定不是http，不然就是udp(走tutk) 從量產出來之後，這台機器的下一代出來之前，大概有三到四年 硬體的能力與支援協定就是不會動了 我不懂新增功能為什麼不能滿足"快速迭代"這個需求 如果因為硬體比較複雜，扣除hotfix，每個功能版本抓一個月，應該是可以的吧 有問題的是不是當初在做的時候，根本就沒考慮到未來會擴展 就像文章提到要做app 重構 如果大家有看cubo在store上大家抱怨最多的問題 無非就是串流容易當掉，動不動就看不到影像 但這是重構能解決的嗎？ 這問題應該是第三方在做p2p 的udp hold puching有問題 與其重構，不如先提供一個測試工具，可以讓想買的人先下載測測看 然後也把這個工具整合進去，不能連線的時候把這個跑起來 至少讓使用者知道發生什麼事，而不是一直轉圈圈 從文章的前後去推敲 他的測試都還要手動去按，大概就知道app在開發階段就沒做到依賴注入 核心功能都跟那堆串流，事件紀錄，硬體功能的side effect綁一起 這樣的狀況下，你期待怎樣的重構，重構要多久 整個重做嗎？我以為只有新進工程師才會想這樣做 如果硬體功能就是那樣，第三方也綁死在那家廠商 重構也不會讓看不到影像的狀況變成看得到 那不如就是先從使用者經驗著手，不要只是顯示一個連不上 然後要重構也是先把那堆萬年callback hell先換成async|await 因為一堆行為都是一環扣一環，中間一個爆了，用回呼你也很難做try-catch 而這些需求，不管是硬體還是軟體，為什麼不能走scrum 然後看很多人討論 我自己覺得最大的問題是 為什麼ceo去找一個進來以後要花一年學後端學nodejs的人當CTO 然後讓他去掌控整個技術團隊的方向 然後還一堆人說這個cto技術很強很負責 這才是這個團隊跟產品最大的問題吧 然後還有很多人推文說 他的裝置數量成長很多，但雲端費用卻持平 這個我沒看到細節，所以我也是保留問號 但我推論有很大的機率 是他的原本的app，在類似像調整攝影機設定的功能 使用者拖曳slider的時候，就會對iot hub送出一次請求 沒有去做debounce & throttle 或是在照片列表的地方，沒有去做快取的機制 使用者每進一次頁面，就重拉一次 像這樣一些小細節 一開始沒處理，那後來加上去了 這樣你要說他很強，還是60分，我覺得就見仁見智 ※ 引述《JasperChang (PeterChou)》之銘言： : Scrum 造不出車、造不出火箭、做不出 IC，可能甚至連台電視都做不出來。 : 但我也同意在某些情境下 Scrum 是很好的工具， : 特斯拉車上有三套電腦， : 車控和自駕電腦完全符合 ISO16949 和 ISO26262 的嚴格規範， : 每一行程式碼都經過嚴格的靜態分析和解析、測試才能 deploy； : 負責 UI 的 MCU 電腦 : 就真的是沒事一直更新一直打 patch 一直有新 feature 一直有 bug 一直給人驚喜。 : 但我認為我們的攝影機凡是牽涉到串流的軟體， : 都是核心功能，不應該走得太激進。 : 但你在處理 PIP 和 SS 功能時並不這麼認為。 : ------ : 小弟剛接觸軟工只聽說 Scrum 強無敵只是你不會用用不好 : 上面資深技術長的看法是不是有修正餘地? -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.216.28.179 (日本) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1741436331.A.052.html
推
03/08 20:20, 1天前 , 1F
雖然你講的很有道理 但人都被砍了 不要這樣
03/08 20:20, 1F
這個真的是對當事人很抱歉 我覺得他真的很無辜，因為不管怎樣他都不應該被這樣對待 我對他本人真的是覺得很難過 但跳過人這件事，我覺得還是可以從技術面去看這個專案 畢竟這是軟體版 所以還是要很認真的說，如果有當事人的朋友看到 先說聲抱歉 我不是要批評人，只是從流程去看這個專案的問題 ※ 編輯: langrisser19 (111.216.28.179 日本), 03/08/2025 20:26:23
噓
03/08 20:27, 1天前 , 2F
小公司能有很多選擇喔..有個人來都不錯了Zzz
03/08 20:27, 2F
推
03/08 20:28, 1天前 , 3F
cto看起來是自幹魔人 但是都是重造輪子
03/08 20:28, 3F
推
03/08 20:30, 1天前 , 4F
觸
03/08 20:30, 4F
推
03/08 20:38, 1天前 , 5F
推測工具這塊
03/08 20:38, 5F
※ 編輯: langrisser19 (111.216.28.179 日本), 03/08/2025 20:47:47
推
03/08 20:46, 1天前 , 6F
不顧品質與成本當然沒問題。硬體一堆電性測試，製造成本，
03/08 20:46, 6F
→
03/08 20:46, 1天前 , 7F
完全不測試，完全不考慮製造成本，當然可以。
03/08 20:46, 7F
→
03/08 20:47, 1天前 , 8F
你家的產品，都不用製造？產線製程隨時在變不用成本嗎。
03/08 20:47, 8F
→
03/08 20:48, 1天前 , 9F
看了你的內文，也是軟體在迭代而已啊，也不是硬體規格與功
03/08 20:48, 9F
→
03/08 20:48, 1天前 , 10F
能在Scrum啊。
03/08 20:48, 10F
所以這邊就知道你不熟啊 你有仔細看他的文章嗎 他就是說再加新功能，你以為是沒藍牙加藍牙嗎 cubo2代跟一代中間隔多久你知道嗎？ 硬體加ai視覺辨識，你覺得這算軟體還硬體 加哭聲辨識你覺得這算軟體還硬體
推
03/08 20:48, 1天前 , 11F
看公司規模，若您待的也是新創同等規模才有辦法比較
03/08 20:48, 11F
推
03/08 20:49, 1天前 , 12F
Scrum討論那麼認真
03/08 20:49, 12F
→
03/08 20:49, 1天前 , 13F
結果那家公司直接拔掉Jira改用實體便利貼
03/08 20:49, 13F
※ 編輯: langrisser19 (111.216.28.179 日本), 03/08/2025 20:56:31
→
03/08 20:49, 1天前 , 14F
硬體牽涉到製造時，下單給產線，難道兩個星期重新NPI調產
03/08 20:49, 14F
→
03/08 20:49, 1天前 , 15F
線？不可能吧，成本超高。
03/08 20:49, 15F
→
03/08 20:50, 1天前 , 16F
後期軟體迭代是沒問題，但前期硬體本身開發時程長，且成本
03/08 20:50, 16F
→
03/08 20:50, 1天前 , 17F
高
03/08 20:50, 17F
推
03/08 20:51, 1天前 , 18F
找硬體的當CTO 八成是創辦人軟體公司出來賣硬體時才發現問題
03/08 20:51, 18F
→
03/08 20:51, 1天前 , 19F
那麼多 需要一個懂硬體的來cover吧
03/08 20:51, 19F
→
03/08 20:51, 1天前 , 20F
你要不要看看自己在寫什麼？想證明硬體能跑scrum，結果前
03/08 20:51, 20F
→
03/08 20:51, 1天前 , 21F
提是硬體已經量產了？
03/08 20:51, 21F
所以你的想法是什麼？ 我覺得台灣就是很多人不知道變通 如果scrum本質是要根據使用者需求快速迭代 那一個iot專案到底可以不可以做到 硬體製造當然不行，就算我遇到很笨的主管想搞快速 一次打樣失敗他下次就知道了 那其他的東西到底可不可以基於快速迭代這個需求去做 還是一定要等到所有的wireframe架構圖都確定才開始 如果今天要加一個哭聲辨識 聲學那邊一開始就已經考量過降噪還有收音範圍了 硬體的菜就是那樣，那辨識的功能要怎樣開發才符合大家所說不會浪費生產成本 如果辨識率就是80% 這樣要不要上 如果上了以後發現，就是只能在某個範圍內收音，那軟體app可以怎樣輔助去解決 還是照你們說的，像這種狀況就是請聲學來重新設計硬體
推
03/08 21:02, 1天前 , 22F
人家就硬體專家 但看起來是人不多 所以什麼都要會吧
03/08 21:02, 22F
※ 編輯: langrisser19 (111.216.28.179 日本), 03/08/2025 21:15:06
推
03/08 21:11, 1天前 , 23F
策略問題，寫軟體的都想要擴充。硬體都想底層
03/08 21:11, 23F
→
03/08 21:12, 1天前 , 24F
現實面是，做產品往往就是跟時間賽跑。這個很難討論
03/08 21:12, 24F
→
03/08 21:14, 1天前 , 25F
硬體成本遠比軟體高，從設計，打樣到製成到處都是錢跟
03/08 21:14, 25F
→
03/08 21:14, 1天前 , 26F
時間。
03/08 21:14, 26F
推
03/08 21:18, 1天前 , 27F
以沒有政府補助，又有金流壓力情況下，真的難
03/08 21:18, 27F
→
03/08 21:21, 1天前 , 28F
"不太懂為什麼硬體不能跑scrum" 你要討論這個，就專注在硬
03/08 21:21, 28F
→
03/08 21:23, 1天前 , 29F
體上說明, 不是拿軟體的部分來講.
03/08 21:23, 29F
我以前的主管就會這樣用文字來把概念覆蓋掉 你量產前跟量產後就是不同的做法 就以我說的哭聲辨識 前面在硬體設計的時候我們就是用樹莓派加上麥克風搭配角度治具去測試 去驗證要幾顆麥克風，然後要在什麼角度 搭配機構id去驗證後續可以怎樣安裝與設計 中間每一次驗證也都是一週出頭 我不知道這算不算是scrum 還是又要到量產才算 所以我才說很多人都用固有的概念與想法 只要能夠配合需求快速修改，這為什麼不能算是scrum 還是要加個站立會議才算？
推
03/08 21:23, 1天前 , 30F
新創來說，我相信應該是錢的問題佔多數，不然也不會搞
03/08 21:23, 30F
→
03/08 21:23, 1天前 , 31F
到要一個不懂後端的重學。直接花錢找人是最快的。
03/08 21:23, 31F
→
03/08 21:24, 1天前 , 32F
說白一點，硬體要做scrum也是有方法，但不是像這樣指東打西
03/08 21:24, 32F
還有 103 則推文
還有 5 段內文
→
03/09 14:47, 12小時前 , 136F
啊。
03/09 14:47, 136F
→
03/09 14:49, 12小時前 , 137F
好的教練不上場打球也不是我說的，上場打球當然可以。但CT
03/09 14:49, 137F
→
03/09 14:49, 12小時前 , 138F
O不傳球給其他球員，自己從基本運球練起，一直自干，是唯
03/09 14:49, 138F
→
03/09 14:49, 12小時前 , 139F
一解嗎？CTO真的太累。
03/09 14:49, 139F
推
03/09 14:53, 12小時前 , 140F
一個球隊，需要CTO練球，上場打球，把"其他工程師"當空氣
03/09 14:53, 140F
→
03/09 14:53, 12小時前 , 141F
。這叫正常喔？ 不補人，正常資源調度也真的不是這樣幹啊
03/09 14:53, 141F
→
03/09 14:53, 12小時前 , 142F
。
03/09 14:53, 142F
→
03/09 14:53, 12小時前 , 143F
新創公司人少 CTO也下來幫忙開發不是很常見的事嗎
03/09 14:53, 143F
→
03/09 15:12, 12小時前 , 144F
可以啊，但CTO自己商場，不要矛盾的說：好的教練不用上場
03/09 15:12, 144F
→
03/09 15:12, 12小時前 , 145F
打球，然後到處批評別人管理模式啊。
03/09 15:12, 145F
→
03/09 15:14, 12小時前 , 146F
別誤會，CTO自己上場打球，沒問題。自己一直上場打球。然
03/09 15:14, 146F
→
03/09 15:14, 12小時前 , 147F
後一直說好的教練不該上場打球，然後一直批評其他教練。不
03/09 15:14, 147F
→
03/09 15:14, 12小時前 , 148F
是很矛盾嗎。
03/09 15:14, 148F
→
03/09 15:15, 12小時前 , 149F
我是用"矛盾"，累，而不是錯喔，別誤會。
03/09 15:15, 149F
→
03/09 15:29, 11小時前 , 150F
你不懂硬體 END
03/09 15:29, 150F
推
03/09 15:48, 11小時前 , 151F
有沒有可能他知道他身為教練自己要上場很不對勁
03/09 15:48, 151F
→
03/09 15:48, 11小時前 , 152F
但他還是得上場的情況呢？也不是他造成的
03/09 15:48, 152F
→
03/09 15:48, 11小時前 , 153F
只是他沒辦法去改變？畢竟都一點一點的被架空了
03/09 15:48, 153F
→
03/09 15:48, 11小時前 , 154F
我感覺他就是被控制指哪打哪沒啥權力只有頭銜的CTO
03/09 15:48, 154F
→
03/09 15:50, 11小時前 , 155F
不是質疑CTO的能力，只是也待過這種老闆
03/09 15:50, 155F
→
03/09 15:50, 11小時前 , 156F
特喜歡親自下場指手畫腳搞得下面主管難以管理
03/09 15:50, 156F
→
03/09 15:50, 11小時前 , 157F
或做決策的垃圾公司
03/09 15:50, 157F
→
03/09 16:04, 11小時前 , 158F
你舉的例子都不是硬體啊 老兄
03/09 16:04, 158F
噓
03/09 17:19, 10小時前 , 159F
講了一堆，有講出硬體怎麼跑scrum嗎？你的第一句大前提
03/09 17:19, 159F
噓
03/09 18:40, 8小時前 , 160F
這篇是在哈囉
03/09 18:40, 160F
噓
03/09 19:33, 7小時前 , 161F
帶風向？
03/09 19:33, 161F
→
03/09 19:45, 7小時前 , 162F
A是一種專案管理手段，管理這個事情就沒有行不行，只有
03/09 19:45, 162F
→
03/09 19:45, 7小時前 , 163F
適不適合，牽扯到更多的是人的問題，還有能力的問題，
03/09 19:45, 163F
→
03/09 19:45, 7小時前 , 164F
你就很聰明能取其有價值的部分，有些人沒辦法變通。但
03/09 19:45, 164F
→
03/09 19:45, 7小時前 , 165F
很多時候是組織管理的問題，現實上要考慮很多組織因素
03/09 19:45, 165F
→
03/09 19:45, 7小時前 , 166F
，很多人沒辦法看透這部分
03/09 19:45, 166F
→
03/09 20:09, 7小時前 , 167F
你不懂硬體+1
03/09 20:09, 167F
→
03/09 20:45, 6小時前 , 168F
個人不懂硬體 但就軟體來說scrum本身就很不可能的了
03/09 20:45, 168F
→
03/09 20:46, 6小時前 , 169F
不覺得硬體靈活過軟體
03/09 20:46, 169F
→
03/09 20:47, 6小時前 , 170F
至於軟體上為何scrum多半不可行 因為人性 我相信多
03/09 20:47, 170F
→
03/09 20:49, 6小時前 , 171F
數人並不想被用完即丟 scrum如果基於爛架構上是不行
03/09 20:49, 171F
→
03/09 20:51, 6小時前 , 172F
的 然而架構有價值 沒有人會自己壓搾自己
03/09 20:51, 172F
→
03/09 20:55, 6小時前 , 173F
這世界理想上應該沒草台班子 然而因現實上你我利益
03/09 20:55, 173F
→
03/09 20:56, 6小時前 , 174F
相背產生 這就是資本主義
03/09 20:56, 174F
→
03/09 21:10, 6小時前 , 175F
弄的不錯都算善意爆棚了 而且就這樣來看就是吃虧
03/09 21:10, 175F
‣ 更多 langrisser19 的文章
文章代碼(AID): #1dp3Mh1I (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 2 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共2篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 langrisser19 的文章
文章代碼(AID): #1dp3Mh1I (Soft_Job)