---

不太懂為什麼硬體不能跑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 (日本)
※ 作者: langrisser19 2025-03-08 20:18:49
※ 文章代碼(AID): #1dp3Mh1I (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1741436331.A.052.html