不太懂为什么硬件不能跑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. 硬件开发 固定短周期打样都很难。 短不了，自然不那么合适，也不需要 做敏捷。