不太懂為什麼硬體不能跑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 功能時並不這麼認為。
:

雖然你講的很有道理 但人都被砍了 不要這樣

小公司能有很多選擇喔..有個人來都不錯了Zzz

cto看起來是自幹魔人 但是都是重造輪子

觸

推測工具這塊

不顧品質與成本當然沒問題。硬體一堆電性測試，製造成本，完全不測試，完全不考慮製造成本，當然可以。你家的產品，都不用製造？產線製程隨時在變不用成本嗎。看了你的內文，也是軟體在迭代而已啊，也不是硬體規格與功能在Scrum啊。

看公司規模，若您待的也是新創同等規模才有辦法比較

Scrum討論那麼認真結果那家公司直接拔掉Jira改用實體便利貼

硬體牽涉到製造時，下單給產線，難道兩個星期重新NPI調產線？不可能吧，成本超高。

後期軟體迭代是沒問題，但前期硬體本身開發時程長，且成本高

找硬體的當CTO 八成是創辦人軟體公司出來賣硬體時才發現問題那麼多 需要一個懂硬體的來cover吧

你要不要看看自己在寫什麼？想證明硬體能跑scrum，結果前提是硬體已經量產了？

人家就硬體專家 但看起來是人不多 所以什麼都要會吧

策略問題，寫軟體的都想要擴充。硬體都想底層現實面是，做產品往往就是跟時間賽跑。這個很難討論硬體成本遠比軟體高，從設計，打樣到製成到處都是錢跟時間。以沒有政府補助，又有金流壓力情況下，真的難

"不太懂為什麼硬體不能跑scrum" 你要討論這個，就專注在硬體上說明, 不是拿軟體的部分來講.

新創來說，我相信應該是錢的問題佔多數，不然也不會搞到要一個不懂後端的重學。直接花錢找人是最快的。

說白一點，硬體要做scrum也是有方法，但不是像這樣指東打西

為什麼要找他 不就他專業是做攝影機嗎？沒他去打磨硬體跟硬體廠打交道，你要找ㄧ個BE出身的去做硬體？

最簡單的，prototype能不能用模組，甚至麵包板來做？能不能用arduino 來試誤降低迗代成本?這些都不講，結果舉例子舉到整合跟軟體上?

不太行耶 Arduino 那就是玩具而已

所以為什麼一開始不舉這個例子?而以硬體已經量產當前提?

撇除scrum的部分,省錢的例子跟我想的類似,不過小公司什麼都包,其實也難為他了

小公司而已 有這種人不得了了

樹莓派跟非樹梅派的差別是很大的

壞一點的情況是 你認知的scrum 不是他遇上的好一點的情況是 他們還不是在一個硬體規格或軟體方向完全定調的階段 變動一個終端功能可能往回牽涉的範圍不好劃定

從CTO的文，我會覺得他們連新一代硬體開發都在小步快跑另外一直疊feature表示沒有人力回頭fine tune 體驗的部分

感覺比較像是希望一套軟體同時兼容新舊硬體規格 新版還在打樣階段 卻不斷讓已量產舊版出bug 加上新創又很燒錢

我的看法跟你差不多，我覺得CEO請他來管軟體就是錯誤的決定，他硬體的能力可能很強，但需要花一年時間熟悉nodejs，就不應該讓他來領導軟體前後端但是CEO根本不尊重專業，怎麼會把Jira拿掉用便利貼，乾脆git也拿掉用SVN好了

我還真的遇過把git拿掉用SVN....

svn 有比較差嗎？

所以現在比爛,nodejs newbie vs 連jira都覺得難以學習大家都是局外人(還是有人在裝?),如果 newbie 真的不夠好,為什麼有人也要跟著撤退? 另一邊的各種人品問題及現成的證據都已經癱在那邊了還用比嗎? 還是有人要拿新事證來帶風向其實也是蠻歡迎的啦

真的是笑死，沒固定開發周期，沒production，甚至沒有真實用戶的狀況，也叫Scrum… 。那麼water fall也可以叫做scrum啊。大家Scrum定義不同，意見不同正常啦。哭聲辨識的研發，一天可以改很多參數，照原PO定義，一天都跑幾十次Scrum了啦。笑死。其實也沒什麼，就你的Scrum定義太特別而已。機器學習模型，訓練一次iteration，更新一次權重，也可以說你們產品做了一次Scrum對吧，一天要幾萬次Scrum都可以。所謂的Scrum開發專案，不是有短期改過參數或程式碼一次，驗證一次效果，就叫做Scrum吧。真的是笑死。你的言論 "只要能配合需求快速修改，這為什麼不能 算是Scrum？" 真的是笑死人。真的不是 "配合需求，快速修改" 就叫做Scrum好嗎。照你的定義，waterfall模式，每天快速改多個需求，對你來說也是Scrum對吧。

硬體scrum喔 htc算嗎? 當年手機記得旗艦機壽命超短

我也是做卡美拉的，雲端費用持平，如果說是流量費用，我腦中有畫面可以省阿靠腰，你這個情境是溫控 sensor沒變啊。噢你用樹梅派驗證，那沒事了。

太多假設啦，實際產品問題只有內部的人才知道，也可能是底層或外包甚麼功能挖坑導致修不了，不是軟體面最佳實踐能解的。而且花一年學後端學node.js，會很多嗎？如果標準是"CTO level"的語言和框架理解程度，說實話一年難度沒很低耶，要稱之為"XX領域的CTO"只花一年時間其實蠻猛的說，只能說局外人的資訊量不夠，我們的所有猜測跟假設錯誤的機率太高了，就聊聊天的程度吧

講一堆軟的部分幹嘛

這裡軟工板啊。講這個不是正常？

agree

第一句問不懂為何 scrum不能跑硬體 然後後面整篇大談軟體迭代= =?

CTO本來就不用什麼都要會 你拿他不會後端來檢討也蠻好笑的

你問為什麼找他來當 CTO，因為上一任離職了，他接下來扛的

1. 你這不是大家認知的scrum2. 你開頭説硬體後面卻提軟體為例..舉例不行3. CTO 原始信中提到的 APP 重構和抱怨硬體跑 scrum 和軟硬整合是三件事，而現在大家看的是硬體跑 scrum 問題，你還一直提軟硬整合？

他們公司產品是攝影機 所以找個這項專精的來當cto很合理吧？ 不合理的是要他學程式自幹這邊才對吧？ 套你回推文的說法 這是賣整合 硬體部分是這cto 的權責範圍還行 但軟體部分 你要cto兼著「管」還行 但要他跳下去做 這就小叮噹了吧？ 賣整合軟硬體的產品 其中「可能」包含要求到軟體品質甚至ui 的情況 這你不給錢找專業來組隊 而是要cto 去學寫程式自幹 這怎看都小叮噹了吧？ ==

詭異的點太多可吐槽了。CTO管理程式，直接管理基層工程師，其他經理管理者在做什麼角色。Bird的發文也完全不鳥中間管理者。

新創有可能啦 某上市AI獨角獸以前就這樣

不是CTO不能寫程式。而是寫關鍵程式沒問題。但跳下來學Python，yolo 真的是讓人覺得CTO也不信任他人的程式碼。CTO，CEO兩人彼此不信任，CTO與CTO兩人還不信任底下團隊，也非常明顯。離職信寫：好的教練不會上場打球，但卻可以激發出每個球員。討厭微管理。但內容卻是充滿了自己拼命上場打球的狀態，這樣心也太累了。行為與自己的期望差太多。

你硬體快速迭代 軟體要維護幾個版本客戶買了新機器 兩個禮拜迭代就變舊機器 客戶怎麼想

樓上 D 大，你的猜測是錯的。公司的 AI 開發只有一個工程師，而且量能不足，高層也不想補人，所以 CTO 才會跳下去幫忙，不然他可以都不管，也不用幾乎每天熬夜自學 AI 了。

樓上是該公司的員工嗎？不然怎麼猜測網路上單方面說的是真的？人手不夠CTO就要跳去做？其他經理，工程師在幹嘛？還是把其他工程師，經理忽略管理？CTO跳下去未必是唯一解法啊。好的教練不上場打球也不是我說的，上場打球當然可以。但CTO不傳球給其他球員，自己從基本運球練起，一直自干，是唯一解嗎？CTO真的太累。一個球隊，需要CTO練球，上場打球，把"其他工程師"當空氣。這叫正常喔？ 不補人，正常資源調度也真的不是這樣幹啊。

新創公司人少 CTO也下來幫忙開發不是很常見的事嗎

可以啊，但CTO自己商場，不要矛盾的說：好的教練不用上場打球，然後到處批評別人管理模式啊。別誤會，CTO自己上場打球，沒問題。自己一直上場打球。然後一直說好的教練不該上場打球，然後一直批評其他教練。不是很矛盾嗎。我是用"矛盾"，累，而不是錯喔，別誤會。

你不懂硬體 END

有沒有可能他知道他身為教練自己要上場很不對勁但他還是得上場的情況呢？也不是他造成的只是他沒辦法去改變？畢竟都一點一點的被架空了我感覺他就是被控制指哪打哪沒啥權力只有頭銜的CTO不是質疑CTO的能力，只是也待過這種老闆特喜歡親自下場指手畫腳搞得下面主管難以管理或做決策的垃圾公司

你舉的例子都不是硬體啊 老兄

講了一堆，有講出硬體怎麼跑scrum嗎？你的第一句大前提

這篇是在哈囉

帶風向？

A是一種專案管理手段，管理這個事情就沒有行不行，只有適不適合，牽扯到更多的是人的問題，還有能力的問題，你就很聰明能取其有價值的部分，有些人沒辦法變通。但很多時候是組織管理的問題，現實上要考慮很多組織因素，很多人沒辦法看透這部分

你不懂硬體+1

個人不懂硬體 但就軟體來說scrum本身就很不可能的了不覺得硬體靈活過軟體至於軟體上為何scrum多半不可行 因為人性 我相信多數人並不想被用完即丟 scrum如果基於爛架構上是不行的 然而架構有價值 沒有人會自己壓搾自己這世界理想上應該沒草台班子 然而因現實上你我利益相背產生 這就是資本主義弄的不錯都算善意爆棚了 而且就這樣來看就是吃虧

這篇文的存在就說明了為什麼 scrum 不行

以台場尿性硬體做不到就是軟體改 夠scrum直接變scum XD

沒看到code整篇都是猜的

你484就是員工 好像你最懂：）

如果產品主要靠硬體，Scrum行不通，而且不只硬體，傳統套裝軟體一年release一次那種，Scrum也跑不太起來，Scrum適合release週期短的產品而且release成本的產品成本低

人家要上市 要省成本一次到位 財報才會好看好嗎

「硬體為什麼不能跑」『上面的軟體叭啦叭啦』

所有產品的開發都能套scrum 但其他產業要付出的代價太大了

有時候不能跑Scrum不一定是工程團隊的問題同樣要跑及格程度 waterfall比較容易些, 導入也是但現實是連waterfall都跑不好的一堆 不是嗎...

因為cto是攝影機硬體的是他們主力，你要去找後端去學硬體還是找硬體學後端哪個容易？嘴別人能力前先看看自己吧

你想要硬體跑Scrum，那也要全部人聽你的阿！不可能

有錢當然兩個都找阿，阿沒錢新創只能取捨，你會怎麼取捨？

硬體要跑Scrum，你先去問生管怎麼說，問候你祖宗18代會被生管心裡問候你

軟體跑scrum都死一堆了 硬體你要跑scrum？ 我看連FW都跑不起來了

可以去看Scrum的最初論文 裡面的moving the scrum downfield 第一點是built in instability如果已經知道要開發的產品是什麼 根本不用套scrum

奴性夠就是內捲，奴性不夠就是內耗

閉嘴好好幹到cto去證明自己吧

這就跟我遇到白癡VP一樣，說為何server板子不能EVT一版就量產

說真的別臭scrum了 我前前公司做醫療iot 曾經就有推過一個家用看護版的產品 waterfall下來快要一整年 好不容易把產品給開發好丟到市場上 發現根本沒人買= = 好像賣出10而已 好在老闆夠有錢才沒倒掉.... 可以的話盡量把週期縮短盡量早點觸及到市場觸及到相關利益人士 提早作出修改 大步難邁 小步飛快才是正途 很多時候你一個大瀑布下來才發現全部搞錯了那改變的成本就會很高是說硬體的話可能真的不行 改動成本相對就是比起軟體高是說我懷疑大家認知的waterfall可能也不一樣？ 就我理解waterfall 就是把所有想得到的所有功能詳列出來 開發週期非常長 最後的最後才把產品推到客戶手中 結果客戶可能要的不是這樣的東西 方向全錯這樣

人家都說了regression至少要跑3天，那老闆兼TPM壓時程發佈時不給測試時間，出事了在談要懲處QA還RD比較公平，這叫做跑scrum嗎? 顯然比較可能是跑殞石開發吧waterfall的重點不是詳列功能，是不能中途變更，只有一個小需求的waterfall一樣是waterfall，關鍵是需求設計開發測試每一階段都是完整完成才往下，中間要改就是從需求階段重來

硬體也是可以做POC，怎麼會做到完才知道沒需求。

作者你不懂硬體，你有去工廠、打件廠盯進度嗎？你解決過良率問題嗎？你有焊過板子嗎？你解決過通訊的遮蔽效應問題嗎？你做過poc和量產後的硬體產品嗎？你有做過各國安規認證嗎？

那是成本的問題 跑scrum本來就要多付出代價

有點腦補太多惹

推CCben, 樓主超自以為是

Scrum 目標以固定短週期，持續改善終端產品。pr tomaster and release. 硬體開發 固定短週期打樣都很難。 短不了，自然不那麼合適，也不需要 做敏捷。