不太懂為什麼硬體不能跑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分，我覺得就見仁見智
: 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.htmlOyodoKai1樓雖然你講的很有道理 但人都被砍了 不要這樣 03/08 20:20
這個真的是對當事人很抱歉
我覺得他真的很無辜，因為不管怎樣他都不應該被這樣對待
我對他本人真的是覺得很難過
但跳過人這件事，我覺得還是可以從技術面去看這個專案
畢竟這是軟體版
所以還是要很認真的說，如果有當事人的朋友看到
先說聲抱歉
我不是要批評人，只是從流程去看這個專案的問題
xxtuoo2樓小公司能有很多選擇喔..有個人來都不錯了Zzz 03/08 20:27
gofigure3樓cto看起來是自幹魔人 但是都是重造輪子 03/08 20:28
yamakazi4樓觸 03/08 20:30
neo52775樓推測工具這塊 03/08 20:38
DrTech6樓不顧品質與成本當然沒問題。硬體一堆電性測試，製造成本， 03/08 20:46
→ DrTech7樓完全不測試，完全不考慮製造成本，當然可以。 03/08 20:46
→ DrTech8樓你家的產品，都不用製造？產線製程隨時在變不用成本嗎。 03/08 20:47
→ DrTech9樓看了你的內文，也是軟體在迭代而已啊，也不是硬體規格與功 03/08 20:48
→ DrTech10樓能在Scrum啊。 03/08 20:48
所以這邊就知道你不熟啊
你有仔細看他的文章嗎
他就是說再加新功能，你以為是沒藍牙加藍牙嗎
cubo2代跟一代中間隔多久你知道嗎？
硬體加ai視覺辨識，你覺得這算軟體還硬體
加哭聲辨識你覺得這算軟體還硬體
nmop11樓看公司規模，若您待的也是新創同等規模才有辦法比較 03/08 20:48
gary86122612樓Scrum討論那麼認真 03/08 20:49
→ gary86122613樓結果那家公司直接拔掉Jira改用實體便利貼 03/08 20:49
→ DrTech14樓硬體牽涉到製造時，下單給產線，難道兩個星期重新NPI調產 03/08 20:49
→ DrTech15樓線？不可能吧，成本超高。 03/08 20:49
→ nmop16樓後期軟體迭代是沒問題，但前期硬體本身開發時程長，且成本 03/08 20:50
→ nmop17樓高 03/08 20:50
Eos18樓找硬體的當CTO 八成是創辦人軟體公司出來賣硬體時才發現問題 03/08 20:51
→ Eos19樓那麼多 需要一個懂硬體的來cover吧 03/08 20:51
→ atst220樓你要不要看看自己在寫什麼？想證明硬體能跑scrum，結果前 03/08 20:51
→ atst221樓提是硬體已經量產了？ 03/08 20:51
所以你的想法是什麼？
我覺得台灣就是很多人不知道變通
如果scrum本質是要根據使用者需求快速迭代
那一個iot專案到底可以不可以做到
硬體製造當然不行，就算我遇到很笨的主管想搞快速
一次打樣失敗他下次就知道了
那其他的東西到底可不可以基於快速迭代這個需求去做
還是一定要等到所有的wireframe架構圖都確定才開始
如果今天要加一個哭聲辨識
聲學那邊一開始就已經考量過降噪還有收音範圍了
硬體的菜就是那樣，那辨識的功能要怎樣開發才符合大家所說不會浪費生產成本
如果辨識率就是80%
這樣要不要上
如果上了以後發現，就是只能在某個範圍內收音，那軟體app可以怎樣輔助去解決
還是照你們說的，像這種狀況就是請聲學來重新設計硬體
ricky6032422樓人家就硬體專家 但看起來是人不多 所以什麼都要會吧 03/08 21:02
moon251923樓策略問題，寫軟體的都想要擴充。硬體都想底層 03/08 21:11
→ moon251924樓現實面是，做產品往往就是跟時間賽跑。這個很難討論 03/08 21:12
→ moon251925樓硬體成本遠比軟體高，從設計，打樣到製成到處都是錢跟 03/08 21:14
→ moon251926樓時間。 03/08 21:14
moon251927樓以沒有政府補助，又有金流壓力情況下，真的難 03/08 21:18
→ atst228樓"不太懂為什麼硬體不能跑scrum" 你要討論這個，就專注在硬 03/08 21:21
→ atst229樓體上說明, 不是拿軟體的部分來講. 03/08 21:23
我以前的主管就會這樣用文字來把概念覆蓋掉
你量產前跟量產後就是不同的做法
就以我說的哭聲辨識
前面在硬體設計的時候我們就是用樹莓派加上麥克風搭配角度治具去測試
去驗證要幾顆麥克風，然後要在什麼角度
搭配機構id去驗證後續可以怎樣安裝與設計
中間每一次驗證也都是一週出頭
我不知道這算不算是scrum
還是又要到量產才算
所以我才說很多人都用固有的概念與想法
只要能夠配合需求快速修改，這為什麼不能算是scrum
還是要加個站立會議才算？
moon251930樓新創來說，我相信應該是錢的問題佔多數，不然也不會搞 03/08 21:23