硬件Scrum与软件的不同

2018年9月开始历时一年多我辅导过一个硬件Scrum的项目， 我的专业背景是发动机，后来又学习电子控制系统（机电一体化专业），在国外我的第一份工作又是制造业生产系统（MES）, 所以对硬件Scrum的领域非常有兴趣，总结出来，与大家一起探讨：

1. 硬件Scrum的迭代周期相对要长一些，软件大部分企业两周的迭代，硬件Scrum通常从四周开始，随着团队的成熟和对Scrum的实践，可能会缩短到三周。相应“纠错”周期也缩短了。

2. 虽然用户故事不是Scrum的内容，但用户故事已成为一个好的敏捷实践。软件与用户交互很多，但硬件的用户（Actor）可能会不一样，用户故事在硬件可能会写成系统故事 （system story）或者用job story的形式来表述需求，特别是why part 不能忽略。

3. 外部依赖管理是Scrum 硬件开发的一个挑战。在Adapted Scrum framework 中加入了一个Artifact 和设计了两个event。high level plan (HLP) 可以帮助我们提前识别风险和节点。包括有些节点是无法谈判的。HLP 是持续进行的，动态的，可视化的，有点像一个release plan, 但不需要包括太多的细节，但要包括必须的东西。Commitment Point （CP）， 硬件涉及不同的技能，不是所有的技能都在开发团队中涵盖，开发团队需要check团队之外的依赖交付的东西， 但在Sprint 计划会上不可能把相关技能的人员都保证出席，为保证Sprint计划会议顺畅，会后设计有一个承诺点，计划会议识别依赖，团队成员有一个跟踪事项的行动列表。Focus Point (FP), 就像一个safety net, PO和开发团队成员就当前Sprint的条目一起看看是否能完成以实现迭代的目标，让团队工作更聚焦（focus），那些方面可能要牺牲和妥协， PO 心中有数。 4. Lead time 相对比较长，在软件开发方面这个问题不突出，按传统的思维，供应商在模具上或PCB的供货周期是固定的, 如果我们尝试找不同的供应商，有时会发现供应商的时间由于市场竞争压力也缩短了。Scrum 团队以外包括供应商没有使用敏捷开发模式是一个挑战，lead time 可能会大于6周，但我们不一定追求是最终的产品（final product），样品开发也是可能的。最终我们还要去影响和教育供应商，让他们尝试敏捷的益处，能成为真正合作伙伴的关系。

5. 技能多样和交叉。Scrum 的开发团队是跨职能的， 实现端到端的交付，在硬件开发中可能会涉及不同领域， 比如电子的，机械的，材料的，跨度较大，建立“T” 型的技能成为不可能。硬件的做法是首先是识别团队技能的瓶颈，做类似的Matrix, 团队有一个清晰的现状图。鼓励相互学习和交叉结对开发，上下游要一起工作。建立one product (ownership of final product) 和 one team （技能的交叉） 的思维。 Scrum 框架把大家绑在一起。80%的工作我们希望在团队内部搞定。团队交叉跨职能越多，浪费和信息传递会越少。不像过去，临时“抓人”来， 丈二和尚摸不着头脑。

6. PI, 软件两周迭代会出来一个可用的软件，硬件开发可能不是一个可用的产品增量。 一般我们定义为 outcome(成果物)。比如知识的获取，研究报告，这些也是有价值的，同时HLP 的建立和跟踪会支持这些价值的输出。重要的是迭代结束节点展示我们达成一致的劳动成果。例如确认设计，迭代增量滚动式开发，验证假设。减少了项目后期的巨大变更和风险。

7. DoD 定义在软件开发方面是一个通用的标准。在硬件开发中对不同的用户故事边界有可能是不一样的，同样的用户故事因为DoD的不同可能在不同的Sprint的重复出现。但我们还是需要用DoD来设定我们的范围，期望和成果物。

8. 硬件工程实践方面的探索永无止境。建模分析，预先定义物理界面（规格），使用不同的材料，Rapid Prototyping, 迭代增量开发思维是核心。 XM(极限制造)，MVP （比如试验模）（跨职能团队有利于MVP的产出），HAST and DFM， 持续集成（CI），有些供应商会提供一些工具帮助自动化测试，分解工作（slicing）的技巧（适当的颗粒度增加了清晰度降低风险），大而化之，“不像过去自己知道就行了”，有助于完成任务; Concurrent Engineering 等。

一句话，硬件也是Scrum， 与软件没有本质的区别。10多年前当我们尝试用Scrum做软件开发，也面临我们今天做硬件Scrum 相似的困惑，这些年我们通过尝试和实践，已经认可了Scrum对软件开发的益处。我们正走入一个敏捷的新时代（包括Scrum硬件开发），这一次的旅程，可能用不了Scrum软件开发走那么多的时间，而且我们已有好多成功的案例。对硬件Scrum 唯一的告诫：do not go blindly by the book，就是说： 不要“僵硬”地“套用”Scrum，“胶柱鼓瑟”，脱离硬件研发的本质。