PTT職涯區 / Soft_Job (軟體人)

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

看板Soft_Job (軟體人)作者 (lan)時間1月前 (2025/03/08 20:18), 1月前編輯推噓26(40推 14噓 179→)
留言233則, 66人參與, 2周前最新討論串2/3 (看更多)
不太懂為什麼硬體不能跑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
還有 161 則推文
還有 5 段內文
噓
03/10 20:38, 1月前 , 194F
你想要硬體跑Scrum，那也要全部人聽你的阿！不可能
03/10 20:38, 194F
→
03/10 20:38, 1月前 , 195F
有錢當然兩個都找阿，阿沒錢新創只能取捨，你會怎麼取捨
03/10 20:38, 195F
→
03/10 20:38, 1月前 , 196F
？
03/10 20:38, 196F
→
03/10 20:40, 1月前 , 197F
硬體要跑Scrum，你先去問生管怎麼說，問候你祖宗18代
03/10 20:40, 197F
→
03/10 21:37, 1月前 , 198F
會被生管心裡問候你
03/10 21:37, 198F
→
03/10 23:53, 1月前 , 199F
軟體跑scrum都死一堆了 硬體你要跑scrum？ 我看連FW
03/10 23:53, 199F
→
03/10 23:53, 1月前 , 200F
都跑不起來了
03/10 23:53, 200F
→
03/11 08:40, 1月前 , 201F
可以去看Scrum的最初論文 裡面的moving the scrum do
03/11 08:40, 201F
→
03/11 08:40, 1月前 , 202F
wnfield 第一點是built in instability
03/11 08:40, 202F
→
03/11 08:42, 1月前 , 203F
如果已經知道要開發的產品是什麼 根本不用套scrum
03/11 08:42, 203F
推
03/11 14:04, 1月前 , 204F
奴性夠就是內捲，奴性不夠就是內耗
03/11 14:04, 204F
噓
03/11 15:24, 1月前 , 205F
閉嘴好好幹到cto去證明自己吧
03/11 15:24, 205F
推
03/11 17:34, 1月前 , 206F
這就跟我遇到白癡VP一樣，說為何server板子不能EVT一
03/11 17:34, 206F
→
03/11 17:34, 1月前 , 207F
版就量產
03/11 17:34, 207F
推
03/12 00:14, 1月前 , 208F
說真的別臭scrum了 我前前公司做醫療iot 曾經就有推過一個
03/12 00:14, 208F
→
03/12 00:15, 1月前 , 209F
家用看護版的產品 waterfall下來快要一整年 好不容易把產品
03/12 00:15, 209F
→
03/12 00:15, 1月前 , 210F
給開發好丟到市場上 發現根本沒人買= = 好像賣出10而已 好
03/12 00:15, 210F
→
03/12 00:15, 1月前 , 211F
在老闆夠有錢才沒倒掉.... 可以的話盡量把週期縮短盡量早點
03/12 00:15, 211F
→
03/12 00:15, 1月前 , 212F
觸及到市場觸及到相關利益人士 提早作出修改 大步難邁 小步
03/12 00:15, 212F
→
03/12 00:15, 1月前 , 213F
飛快才是正途 很多時候你一個大瀑布下來才發現全部搞錯了
03/12 00:15, 213F
→
03/12 00:15, 1月前 , 214F
那改變的成本就會很高
03/12 00:15, 214F
推
03/12 00:22, 1月前 , 215F
是說硬體的話可能真的不行 改動成本相對就是比起軟體高
03/12 00:22, 215F
→
03/12 00:25, 1月前 , 216F
是說我懷疑大家認知的waterfall可能也不一樣？ 就我理解wat
03/12 00:25, 216F
→
03/12 00:25, 1月前 , 217F
erfall 就是把所有想得到的所有功能詳列出來 開發週期非常
03/12 00:25, 217F
→
03/12 00:25, 1月前 , 218F
長 最後的最後才把產品推到客戶手中 結果客戶可能要的不是
03/12 00:25, 218F
→
03/12 00:25, 1月前 , 219F
這樣的東西 方向全錯這樣
03/12 00:25, 219F
→
03/12 19:16, 1月前 , 220F
人家都說了regression至少要跑3天，那老闆兼TPM壓時程發佈
03/12 19:16, 220F
→
03/12 19:17, 1月前 , 221F
時不給測試時間，出事了在談要懲處QA還RD比較公平，這叫做
03/12 19:17, 221F
→
03/12 19:18, 1月前 , 222F
跑scrum嗎? 顯然比較可能是跑殞石開發吧
03/12 19:18, 222F
→
03/12 19:19, 1月前 , 223F
waterfall的重點不是詳列功能，是不能中途變更，只有一個小
03/12 19:19, 223F
→
03/12 19:20, 1月前 , 224F
需求的waterfall一樣是waterfall，關鍵是需求設計開發測試
03/12 19:20, 224F
→
03/12 19:20, 1月前 , 225F
每一階段都是完整完成才往下，中間要改就是從需求階段重來
03/12 19:20, 225F
→
03/12 22:56, 1月前 , 226F
硬體也是可以做POC，怎麼會做到完才知道沒需求。
03/12 22:56, 226F
噓
03/13 00:54, 1月前 , 227F
作者你不懂硬體，你有去工廠、打件廠盯進度嗎？你解決過良
03/13 00:54, 227F
→
03/13 00:54, 1月前 , 228F
率問題嗎？你有焊過板子嗎？你解決過通訊的遮蔽效應問題嗎
03/13 00:54, 228F
→
03/13 00:54, 1月前 , 229F
？你做過poc和量產後的硬體產品嗎？你有做過各國安規認證嗎
03/13 00:54, 229F
→
03/13 00:54, 1月前 , 230F
？
03/13 00:54, 230F
→
03/13 08:08, 1月前 , 231F
那是成本的問題 跑scrum本來就要多付出代價
03/13 08:08, 231F
→
03/13 09:12, 1月前 , 232F
有點腦補太多惹
03/13 09:12, 232F
→
03/28 18:13, 2周前 , 233F
推CCben, 樓主超自以為是
03/28 18:13, 233F
‣ 更多 langrisser19 的文章
文章代碼(AID): #1dp3Mh1I (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 3 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共3篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 langrisser19 的文章
文章代碼(AID): #1dp3Mh1I (Soft_Job)