• CSPO+A-CSPO直通车
  • 敏捷领导力(CAL E+O / ALJ)认证培训
  • Five_reasons_three
  • Hardware-agile-practice-20231012
  • Clp_20220108
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • CSM A-CSM一站式培训
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • ShineScrum捷行出版书籍
Scrum硬件教学体会点滴
最近给几家企业做了Scrum 硬件内训,包括控制板,机械设计和嵌入式软件集成的产品,在不涉及客户商业机密和敏感信息的前提下,分享一下硬件Scrum 与软件开发课程教学的相似点和不同。
课程还是从传统开发模式和流程入手,比如汽车行业的 V 模型,我们对客户问题需求的假设,对解决方案假设。而现实情况是,着重提到一个关键词“涌现”(emergent),需求和解决方案也是涌现的。前期Scoping 或把范围100%全部锁定,在大多情况下是一个伪命题。Stacey 模型和Cynefin 框架都是好的工具帮助我们理解当下的VUCA 时代,one-size-fits-all 的思维模式必须抛弃,实验性过程控制是我们解决复杂问题的理论基础之一。
敏捷的价值观和原则尽管是基于软件开发,但对硬件开发大多是适用的,当然一些术语要小心取代,比如 “working software”。讲师单独分享了硬件开发和系统设计的15条原则。一句话,Agile is eating the world。精益(Lean thinking)解决效率和成本问题,敏捷(agile)重在速度(speed)和效能。


课堂上的“需求和开发”的敏捷游戏,加深了大家对瀑布和敏捷开发的对比和讨论。

Scrum 框架的练习容易些,新版的Scrum 指南已经把软件的专业术语都过滤掉了,通用易懂。Scrum 框架的练习如下:


我们重点把时间花在硬件开发挑战的讨论上。
● 成本、功能及性能的平衡
● 易用性,可靠性及安全性
● 模块化划分,可测试性设计
● 如何实现快速迭代增量式开发
● 架构的未充分验证
● 模具的时间长
然后讨论Scrum 敏捷硬件产品开发的挑战,比如:
● 涉及的材料成本高
● 硬件架构设计的灵活性比软件架构低
● 产生的沉没成本(sunk cost)、变更成本的风险高
● 硬件产品涉及的领域多,组建跨职能团队比软件产品难,需要高度协作的组件团队
● 设计(Design)和制造(manufacturing)易脱节
● 测试周期长,最后集成和最后测试现象严重
● 外部采购或外协周期长
● 实现潜在的可交付产品增量难
只有应对这些挑战,我们才能获取Scrum 带来的益处,一方面我们从文化理念方面入手,比如Scrum 的价值观指导我们做事情的方式、方法和行为:

另一方面,硬件Scrum 也是Scrum,不能照搬照抄软件的东西,需要我们一起来探索硬件敏捷实践,比如:
(1) 模块化的设计,定义好接口(interface),尽量把依赖度高的组成团队(Drive by Coupling)
(2) 结对工作减少信息的传递
(3) 定义每个Sprint 结束时的交付物价值(不一定像软件产出产品特性和功能的增量)
(4) 尽管受到外部依赖性或长的测试周期影响,建议Sprint 长度2-3周,充分拆分产品待办列表
(5)在硬件开发中,往往以技术故事(Technical Story)为主,不一定是user story
(6) 建议有技术背景,熟悉产品的人员担任PO
(7) 软模具,虚拟仿真工具, 替换材料
(8) 3D printed prototype
(9) set-based design for growth


Scrum 的双规制,特别是运用敏捷去探索新产品的开发。课堂上我们结合客户的产品特点和行业背景,敏捷产品的探索工具一起演练:

Vision box 和摩尔(More)模板练习如下:

实验画布和MVP

特别是MVP 概念的澄清,build-measure-learn loop。MVP 与MMF 和MMP 的关系。MVP 是一个持续学习和验证假设的最精益成本最低,获取真实反馈的机制和实验。
基于一个具体的产品“机顶盒的设计和应用”,我们尝试用户故事练习,来体会从具体用户的角度,使用有效的大家容易理解的语言来描述对产品的价值建立(value creation)和影响(impact),同时鼓励以用户故事作为一个提示符(token)开展对话来理解需求的who,what,why。这个例子我们也可梳理出一些技术性的story 和系统story。
产品质量的保证,开发人员做正确的事情,符合产品的各种规范和标准。我们介绍了完成的定义(DoD)概念,硬件DoD 与软件的不同。
结合客户的产品,我们从硬件(PCB),测试和法规,机械(ME),软件,设计和文档五个维度,分组梳理出必须要走的流程和规范,比如机械设计和制造:
Scrum 团队的产品负责人(PO),ScrumMaster 开发人员的担责是一样的。
Sprint 计划会议,Daily Scrum,Sprint 评审会和回顾会的结构没有改变。
只是授课中加入硬件敏捷实践的分享:比如团队的能力(competencies)map 以鼓励更多的 T 型人才,结对和共享Kanban 等等。

案例分享:
团队的组建,high-level 需求的建立,细节拆分,产品结构的设计,发布计划活动,法规合约的讨论。


最后,通过两天的学习和体验,小组为单位头脑风暴马上落地行动计划,比如:
站会,日常工作task drive ,工作透明,物理白板的使用,拆分细节些,团队承诺(而非个人),PBI 的优先级排序,planning 的参与度,相对估算,故事地图,回顾会。
讲师介绍

Jim Wang王军

国际Scrum联盟认证培训师CST、Path to CSP Educator、LeSS-friendly Scrum Trainer、MBA、

敏捷软硬件开发专家