• 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框架
硬件敏捷之我见

从事很多年的产品开发,有移动互联网的,有设备固件的,有大型工业物联网的,有纯上位机软件的,虽然没有直接介入硬件开发过程中,但通过敏捷在软件活动中的实践,我认为硬件开发是能够做敏捷的,至少有方法去实践敏捷思想所期望的一些益处,当然,绝非照搬软件敏捷开发。软件开发相对于硬件开发来说,试错成本相对较低,这种特性差异延伸出来的优势,反映到了快速迭代,算是发挥的比较淋漓尽致,从最初的功能验证,到敏捷所追求的商业价值验证,处处都体现出迭代带来的好处。

但是迭代的目的只有试错吗?较于硬件,软件重工(优化或重构)的较高可行性以及较好的成本是否会让试错变得过分随意?硬件试错成本高,是否就不能有迭代的概念呢?

让我们回归优化流程的初衷,保障过程有效,高效,且最终可靠地交付价值。迭代的目的也是如此,是为了交付价值,软件的目标是交付有商业价值的产出物,那么软件敏捷在执行过程中是否每个迭代都严格做到了这一点?是否user story都能够找到对应的business value(BV)去支撑,如果没有,在迭代结束这些工作产出是不能计入point交付,但是这部分团队工作中有价值的产出,属于半制品价值,是有可能放入未来的迭代中对价值交付做贡献的。因此单纯看这部分产出的价值,特点就是交付周期拉长了,最终贡献了BV。如果不拘泥1~2周的迭代周期,把迭代周期拉长到一定程度适应硬件产出的阶段点或者子里程碑,让硬件研发半制品价值尽量靠近商业价值,我认为就可以用point去估算,关联,衡量,和用增量交付来统计。

其实并不是只有软件有优势,有些特性属于硬件的天生优势,这是软件不具备的。

硬件在设计之初就可以对功能扩展性有考虑和布局,就像基础建设,修一条很宽很平很结实的公路,平时走人,赶驴,骑自行车,跑汽车卡车都行,关键的时候可以做飞机跑道也没问题。但跑在硬件上面的软件,就好比使用马路的这些主体,能够随意在动物,人和机器之间随意切换形态吗?基因构造都完全不同啊,必须是多种形态的存在,所以说硬件的平台性,这种极具宽性的单一存在形态,要比软件有优势。优势有二,一,面临市场需求变化的时候,一些预留给模块的孔位和pin脚可以很可靠的堆叠上去,迭代增量价值的作用更容易发挥出来;二,经过对新需求或需求变更做评估,判断出如果预留资源不足支撑新功能模块,硬件开发是否有阶段性成果可以继承,结合回滚成本和市场预期,可以快速直接的做出决策,这比软件的风险评估要容易得多。

从仿真工具到3D打样让硬件功能开始“软”化,“软”化度越高的部分越利于敏捷实践。

很多硬件相关的测试和开发是有原型模拟软件工具支持的,这类开发设计工作就比较容易用迭代的方式快速验证,而电路出板,硬件打样成型这类工序,现在专业供应商的响应也越来越快,一旦要做产品重大缺陷修复或者根据市场做产品调整,在整个产品释放发布之前都是有挽回的余地的。通过仿真,如果意识到某部分硬件涉及的风险,有针对性的将能检测这部分的软件功能需求提升优先级,在敏捷开发中是支持的,因为NFR(非功能需求)如果是产品战略侧的,反而要比有BV的需求更高优先级。战略侧需求恰恰是重中之重,如果能模块化和“软”化,产品开发周期内的灵活性和市场优势将是敏捷开发发挥优势的战场。

产品的敏捷开发,当硬件也有了2倍或者3倍于软件的迭代周期可以和软件迭代同步的时候,及时纠错的流程产生了优势,但无论软硬件,都要遵循设计慎重原则。

尽管有了仿真,但依旧存在仿真覆盖不到的地方,有很多场景是只有现实中才有的,甚至不同国家和地区的场景会大不相同,如果硬件性能达不到预期,开发中通常会选择让软件尽力去优化或者更改设计和需求,因此对于软硬件协同开发的产品,不同阶段中,软件会产生出各种来自硬件的依赖,但这些依赖也是可以用敏捷思想和方法去管理的,譬如通过价值流的清晰化可以识别一部分潜在的依赖,随着团队的成熟可以识别出更多的依赖,从而在计划中解决和同步掉。然而依赖并不是最主要的,设计慎重原则才是。

某种程度上讲,硬件开发应用敏捷会比在软件领域更容易上手,即更容易看到效果。

 换个角度观察软硬件的开发,对于纯软件,往往是打造某种虚拟场景或操作流程,来直接服务于某种商业策略,但是新产品问世后发现商业策略失效,该怎么办?先要修改商业策略,再去修改甚至重新设计软件。那是否有办法提前验证商业策略呢?有些可以,但是那些特别复杂的商业策略或者极具创新思维的商业策略是很难提前验证的,加上诸多因子和环境变数,即便前期验证没问题,谁又能保证完美的产品设计投产面世后就一击即中呢?你看,这种担心像不像对待硬件开发的担心?但细想下来硬件产品项目相比那些探索性的软件产品项目实际上要更简单,因为其对接的需求更直接,更可视化,更容易和客户去做产品形态的勾画,而需求阶段的风险正是这两者最近似的点。某种程度上,硬件项目对需求的把控更容易,能产生回报的可能性因此也要大于那些新颖的商业策略。交付投产前的迭代试错的效用也是大于那些新颖策略的软件项目,一个错得起一个错不起,故其试错的成本是低于商业策略的。对于真正面向VUCA的开发,硬件敏捷比软件敏捷实践起来更容易。

把握好需求在产品价值流中的切割和流动是敏捷硬件开发敏捷的管理重点。

说了这么多硬件开发到底怎么管理呢?有些点供参考:对硬件性能的需求定义为Epic,围绕这些performance做的设计都是有商业价值的story,硬件模块化程度其实比软件更高,更好切割,更容易做验证。甚至设备集成商都可以让配件供应商提供模块的性能报告和相关配套驱动的和开发接口的软件测试报告。因此,这些story就可以用来评估。配合软件计划,降低硬件开发带来的dependencies,和重要性能指标的原型以及验证,这些作为高优先级故事。迭代周期可以数倍于软件迭代周期,但一是要固定,不能每个迭代长度不同,二是当成熟度足够的时候和软件的汇聚点一定是可以集成到一起进行验证和演示的。硬件的敏捷问题根本不是开发问题,而是需求的设计拆解和计划问题。一个能够有节奏的,可验证的,甚至可视的,增量稳定的产品迭代,只要能反应价值的增量输出,就是在实践敏捷。如果能够将客户或市场潜在客户引入到模块的性能评估中,有了市场或者目标客户的反馈,有了持续改进,带来的好处激励了组织,培养了团队的自组织能力,形成了一套积极的文化,那组织的敏捷度就很高了。

不因硬件开发走上了敏捷之路就降低了设计慎重原则的执行标准。

那些探索新商业模式的软件同样需要在需求阶段反复论证,因为通常条件下没有给客户试错的可能,所以目前所采用比较通用的做法之一就是在需求设计环节一定是慎之又慎。迭代提供给团队改错的机会,但不代表研发工作就变得从此安全了。有时候改正错误的代价确是很大,有些软件在临近交付的时候才发现重大需求理解错误或者架构设计错误,都是致命的,而这些在敏捷方法中虽然极力的去提前发现和避免,但难免受限于团队的能力和人的知识能力,甚至企业文化,还是在最后时刻才爆发出来。软件开发如此,硬件开发亦如此。设计永远是要严谨的,迭代开发也好,并行开发也罢,金钱换时间,换的是商业机会的时间窗口,而不是设计粗心和开发质量低下来修复产品的时间。


最后

 敏捷追求的不是短期的快,而是面对变化的灵活和适应,相对于各个工件自己的最大化灵活度,但有灵活就要有统一,有节奏的增量不论对客户还是团队本身都是很良性的反馈,也是一种激励。本着服务于最终的商业价值,研发领域几乎没有一招鲜吃遍天的,秉承敏捷价值观,在实践中持续改进,一定能收获属于自己团队的敏捷硬件开发方式。


——Adam AN 安衡