对话Paolo直播回顾：破解硬件和AI敏捷（下）

Paolo对这个问题的回答简直让人难以置信，他说他在和 Joe Justice（《The Scrum in Hardware Guide》作者，特斯拉的硬件敏捷专家）一起在特斯拉做一款参赛车的时候，一个Sprint的周期是3个小时！真是天下武功，唯快不破！

Paolo用Sprint的概念解释这个问题：我们在做计划的时候，会设定一个时间盒，并对这个时间和的产出设定一个预期，然后在这个时间盒结束时，评审产出是否满足预期。

评审后，我们会再回顾看看哪里可以改进的，哪里需要调整，然后我们再开始重新一轮Sprint。在Sprint结束的时候，我们可能会发现，产出的预期与原计划的并不一样。所以，如果我们设定的Sprint周期是10天，那么我们就会10天发现预期与计划的不同，接下来就需要改变这10天的变化。当我们把Sprint周期的长度变短，实际上减少了我们为变化付出的成本。这个变化的成本在硬件上会更高，如果我们在软件行业能够接受10天的变化成本，在硬件上，可能就要翻倍或者更高。现在的行业竞争优势，包括软件、硬件和AI，都在于如何缩短反馈回路，在更短的时间内拿到反馈回路的验证。

因此，J oe Justice在特斯拉在管理的关键，是缩短他的整个的反馈回路，不仅是在产品研发这个阶段，也包括生产这个阶段。真是让人茅塞顿开。

在硬件上，也是要有Product Backlog，也是有大有小，远粗近细。每个待办项PBI（Product Backlog Item）都要有产出。PBI分为两种，一种是用户可以直接交互的，一种仅是系统功能。用户可以交互的，就用用户故事来描述，让用户体验并做出反馈。因而很重要的就是要把What和How分开，用What去和业务部门更好的达成一致。

Paolo有强大的案例库，实践案例信手拈来，他举了一个铁路公司做待办项估算的例子，从建铁轨到整个火车站，纯硬件的待办项估算：

Paolo对于何谓Modularity（模块化），解释特别精彩：

何谓集成呢，就是在设计时，会有A+B+C+…可能一直加到N，那A和B、或者B和C、或者A和N之间很自然就会有接口，接口在开始的时候就要定义好。而所谓的Modularity（模块化），就是已知的稳定的接口。就像拼插乐高玩具一样，两个拼接模块之间会有接口，接口的凸起是圆的还是方的，已经是定义好的，那么我们就可以基于这个接口去设计要拼插的模块。

所以，在开发之前，我们要先把这个接口定义好，事先预定好接口的契约。（比如咱们去买电器，要先去看电源的插座接头是两个头还是三个头的。如果需要在国外使用，还要去看看是欧洲的，还是美国的。）

所以Paolo的回答是，不管跑不跑Scrum，在设计之初，都应该有模块化的思维。就是说，接口是What，而怎么去执行这个What，是How的问题。

1）与供应商之间，首先要定义好的就是接口（契约第一）和验收标准（提前和供应商达成一致，各自确保各自的部分和最后接口都是合适的）。

2）引申开来，供应商在自己的领域应该是专家，所以只要说what，这和po做法一致，相当于把供应商拉进来当做自己团队的一员，大家更容易形成一致，朝一个目标努力。

3）要开发适配器，当我们公布适配器后，就可以在多个供应商之间选择合适的合作伙伴。Paolo又随手从他庞大的案例库里，举了一个汽车悬挂的例子：

我们不可能在一开始的时候就把所有需求，全部都罗列出来，我们一定是用增量的方式不断的去演化。用户故事，假如定12个月的开发，那么定好这12个月开发的产出，只能做到尽善尽美，因为不可能先创造出完美的用户故事。上述所说的知识问答机器人，本身的算法也是需要一层一层演化迭代的，这个机器人也会越来越聪明。

我们先不要从现在的现状出发去说解决我们现在的问题，应该换一个思考问题的思维，例如：Paolo要和Lisa老师和伍老师一起开个公司，希望这个工作更快的做出产品，那么一定会有办法可以更快的开发出产品。而不是一定要遵循任何的Model。严格按一个一个阶段执行，然后再去验证。

如果能在1天内拿到反馈，是V-model还是其他方式都无所谓。最关键的问题，是要不要选择一个更有战斗力的方法。

1天反馈，真是1秒破局，小编在这里也特意截取了Paolo的视频，给大家奉上。

还需要查看更多内容的小伙伴，可以看完整的直播回放视频：

觉得2小时还远远不够的小伙伴，还有惊喜哟：

由Paolo Sammicheli 和 Lisa(王蕾）老师联袂开讲的RSM硬件敏捷国际官方认证特训班即将开课！