1. 目的
本指南旨在通过应用特定的技术实践和工作模式,来定义Scrum在硬件中应用方法,以在硬件中实现短迭代开发和快速发布。
本指南是一份“活”文档,将根据社区以及现场经验反馈而持续演进。为了能让大家以清晰的过程在硬件中更好地实施Scrum,允许任何公司应用本指南。
本文档引用的术语“Scrum”来自于《Scrum指南》,未做任何裁剪或修改。
敏捷项目的首要目标是尽早和频密的发布,并利用变更来为客户带来收益,即便在开发后期仍是如此。
然而,我们怎么做,才能在硬件开发中负担得起变更的成本呢?!
该指南完全由产品工程和团队实践组成,可应用于有着严格监管要求的行业,也可用于组织结构的设计或重组。
2. 硬件项目中的不确定性
图1 硬件项目中的不确定性
由于硬件项目会涉及更多的物料成本,因而往往有着更高的沉没成本和变更成本风险。这些风险随着项目生命周期的演进而上升,这一点恰好与项目中不确定性的情况相反。
我们通过模块化、柔性量产工装、兼容最快最柔性工装的少量物料以及极简(优雅)设计,来降低变更成本,即便在开发后期仍是如此。
3. 桩和实体模型
原型能帮助团队全面了解产品,处理接口和验证假设。尽早使用带有原型的产品意图接口草案,能最大程度地提高学习效果,并将风险降至最低。
我们建议团队为每个模块都构建桩,并在第一个Sprint中就将其连接起来。
4. 模块化
图2 硬件Scrum中的模块化硬件开发
最终产品应当能在一周内生产出来。这就能让任何感兴趣的相关干系人及合规性检查人员每周确认以降低风险,从而不再需要将硬件项目分成多个阶段以降低风险。
如果某些技术领域或者团队做不到这一点,那么可以通过划分模块,来隔离那些有着很长前置时间的、复杂的或者需要进行严格地合规性检查的领域。
硬件项目“切片”的分解方式很重要——应该让每个团队都能在不依赖其他团队的情况下,验证其模块的假设。
例如,对于汽车外形的风阻测试,固定由一个团队来负责外形设计工作,效果会更好。模块也可以用于分离那些需要长时间进行测试和认证的领域,这样就能让其他领域得到更快地迭代和确认。
5. 持续集成
图3 硬件Scrum的持续集成加工设施
如果一个模块能插入到系统中与其他所有模块顺利互连并通过所有测试,那么我们就能单独发布这个模块。
正如同软件项目能够通过自动化集成来加速工作进程一样,如果硬件团队能够自动化集成多个团队开发的产品,也能带来惊人的速度优势。
这可能意味着需要一个自动化机器人,或者一个由能工巧匠组成的柔性团队,以准备将不同团队的产物安装到一起,并运行一个预先准备好的集成测试检查清单。
6. 接口设计
图4 硬件Scrum中的接口设计
接口应当以可重用的方式设计。如果接口需要诸多步骤才能完成连接或断开,就会由于太脆弱或复杂,而令人丧失试验的欲望。
此外,应该以超出所需容量十倍以上的裕量来规划它们。这么做虽然会增加模块间接口的重量和尺寸,但却能换来系统整体的迭代速度增加。这使我们不仅能弥补在重量和尺寸上的增加,同时还能为成品的改进提供空间——这方面的变更才是最昂贵的。
7. 测试和数据驱动开发
开发应该被设计成以验证假设的方式进行(即测试驱动开发)。
可以编写硬件测试用例。通过物联网(IOT)和传感器技术,几乎所有硬件部件的行为数据都能被测量,并应用于持续改进。
8. 团队
图5 硬件Scrum中的团队划分
至少在每个模块上,团队成员应该相互协作,在同一地点办公,并结对开发。
我们所观察到的最快团队,会针对新想法制定明确的测试内容,并非常快速的反馈环、基于测试结果来对其进行验证。并且,团队成员们乐于在其核心专业知识领域以外开展协作。
9. 在每个Sprint结束时都得到可工作的产品
在硬件工作中应用Scrum的终极考验是,您能否在每个Sprint结束时都得到一个可工作的产品。