• A-CSM 国际Scrum联盟认证 ScrumMaster
  • 敏捷思维 领导力 企业培训 国际Scrum联盟认证
  • 敏捷开发课程
  • CSM A-CSM Scrum敏捷实践
  • 敏捷领导力认证培训  CAL认证培训 CST CSP
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • Scrum硬件敏捷产品开发 国际Scrum联盟认证
  • 30天软件开发 敏捷规模化实践 Scrum精髓 敏捷文化
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • 认证csm cspo cst
  • Scrum敏捷培训 Scrum敏捷企业内训
  • Scrum敏捷软件开发管理 企业内训 Scrum转型
  • Scrum框架
硬件Scrum指南

译者序:

视角是个很神奇的东西,当站在敏捷的立场重新审视传统串行开发流程中的种种活动时会发现,我们一直在硬件开发中苦苦探求和实践的工作并行化,功能模块化,接口冗余化,测试模拟仿真化等都是不知不觉中在往解耦交付,缩短反馈,所见即所得,降低风险的道路上迈进,而敏捷开发也正是沿着这个方向开枝散叶,且率先在软件领域积累了大量的经验逐渐走向成熟,这给其它领域在敏捷道路上提供了足够多的参考和启发。经验不可复制,但可以借鉴,如今很多团队在硬件研发灵活度方面越做越好,是时候通过Scrum的思想将其有机的组织结合起来,你会发现当视角转变后原有的东西都活了。

原文作者顺着这个思路给大家捋了一下,将Scrum优势里的关键点映射到硬件开发中,推荐阅读。(预计阅读时间4分钟)同时译者有篇原创关于硬件敏捷的思考,欢迎评论反馈:“敏捷硬件之我见(点击即可阅读)”。

原文:

这本《Scrum硬件指南》是由Joe Justice撰写的。Joe是Scrum Inc.的硬件总裁,也是Team WIKSIPEED的创始人和首席执行官。Joe的工作包括与博世(Bosch)、微软(Microsoft)、丰田(Toyota)、亚马逊(Amazon)、3M、福特(Ford)、波士顿科学公司(Boston Scientific)、QuintilesIMS、雪佛兰(Chevrolet)、麻省理工学院(MIT)、惠普实验室(HP Labs)、施乐帕洛阿尔托研究中心(Xerox PARC)创始人等数百家公司合作,旨在以一周或更短时间的迭代方式交付产品和服务。Joe还在世界各地讲授课程,介绍Scrum在硬件行业的应用。本指南是早期版本的草稿。请在评论中添加任何改进建议。

 

硬件Scrum指南的目标

本指南旨在通过具体的技术实践和模式来定义硬件中的Scrum,从而实现硬件开发的快速发布和短迭代。这是一部持续更新的文件,未来还会从该领域的社区反馈和学习中不断进化。任何公司都可以利用这个指南,确认他们在硬件上对Scrum的实施,以及明确的改进步骤。本文档引用Scrum指南中对Scrum的定义,没有做另外的裁剪或修改。敏捷项目关注于尽早和频繁地发布,并从客户的利益最大化的角度利用变更,哪怕开发进入到后期也是如此。我们真有可能在硬件上做到这一点吗?该指南完全由产品项目和团队实践组成,其中不乏一些高约束的行业。因此该指南可用于设计或重组组织架构。

 

硬件项目中的不确定因素

硬件项目涉及更多的材料成本,且往往有更高的沉没成本和变更成本风险。这些风险在项目的生命周期随着时间而增长,又与项目中的不确定性成反比。通过模块化、灵活的大规模生产工具、少数几种适用于最快和最灵活工具的原材料,以及极简(优雅)的设计,即使在项目开发的后期,我们也可以做到降低变更成本。

 

桩代码和原型

原型能帮助团队获得对产品的全面理解,处理接口和验证假设。原型包含了关于产品目标接口的初版,尽早使用原型可以最大限度地提高学习效率和降低风险。我们建议团队在第一个迭代构建每个模块互相连接的桩代码。


模块化

最终产品应该在一周内生产出来。任何感兴趣的利益相关者和合规检查官可以通过每周的检查来减少风险,因此也就没有必要通过把硬件项目拆分为几个阶段来降低风险。在团队还不具备这样做的技术的情况下,我们可以将产品分解为模块,以隔离周期长的、复杂的、或管制程度高的部分。硬件项目“切片”的划分方式很重要。每个团队都应该能够验证关于他们模块的假设,而不依赖于其他团队。例如,当一个团队可以独占汽车外部件时候,汽车风阻的测试就会做得更好。使用模块还可以分隔测试和认证周期最长的区域,以便其它的部分能够更快地迭代和获批。

 

持续集成

一个模块只有被接入到包含其他模块的系统中,且通过了所有测试才能被交付。就像软件项目通过自动化集成来加速一样,如果硬件团队也能在多个团队工作中实现自动化集成,那么他们在速度上就有巨大的优势。这可能意味着自动化机器人,也可能意味着一个灵活的工匠团队准备好将不同团队的输出接通在一起,并运行准备好的集成测试检查表。

 

接口设计

接口在设计的时候应当尽量考虑重用。脆弱的、或是那种需要很多步骤才能连接或断开的精心设计的接口都阻碍了实验。此外,它们的规划应该至少是所需容量的10倍。这的确加重和加大了模块之间的边界。但作为交换,迭代整个系统的速度会提高。快速迭代不仅允许我们可以弥补重量和尺寸的增加,更加创造了对成品改善的空间,而恰恰这块的变更才是最昂贵的。

 

测试和数据驱动开发

开发应该按照验证假设的方式进行设计(测试驱动开发)。即,编写硬件测试用例。随着物联网(IoT)和传感器技术的发展,几乎所有硬件部件行为的数据都可以被测量出来,并且应该被用来持续改进。

 

团队

团队成员应该协作,至少同一个模块下面的成员是在一起且结对工作的。我们观察到的最快的团队对于要通过的测试有清晰的计划,有非常快速的反馈循环来验证针对那些测试的新想法,并且愿意在他们的核心专业知识之外进行协作。

 

每个Sprint完成都有可工作的产品

在硬件开发中能否真正做到Scrum的终极考察,就是看在每个迭代结束后是否有一个可用的产品。

 

关于作者

Joe Justice是Scrum Inc.的总裁,也是Team WIKSIPEED的创始人和首席执行官。Joe曾与博世(Bosch)、微软(Microsoft)、丰田(Toyota)、亚马逊(Amazon)、3M、福特(Ford)、波士顿科学公司(Boston Scientific)、QuintilesIMS、雪佛兰(Chevrolet)、麻省理工学院(MIT)、惠普实验室(HP Labs)、施乐帕洛阿尔托研究中心(Xerox PARC)创始人等数百家公司合作,旨在帮助对方使用在一周或更短时间的迭代方式交付产品和服务。


作者:Joe Justice

译者:Adam An

校对:Suzzi Su


参考资料:The Scrum in Hardware Guide