深度解析：敏捷硬件开发底层的奥秘

为什么说软硬协同是敏捷硬件开发的第一个抓手？因为在这个领域定下了整个设计开发交付的节奏，是一次性交付还是迭代开发增量交付。如果是软硬分离的，芯片团队不需要向软件交付早期原型或建模，而是直接流片后才开始软件开发的工作。那还谈不上敏捷开发。但是，大部分芯片开发，系统开发，目前都不是这个模式。整个行业已经过了完全的软硬分离的发展阶段，只是软硬协同的成熟度在不同团队有差别。

软硬协同的目标从经济意义上，是降低软件开发的成本，提升一美元可购买的算力和能效比。在软件和硬件紧耦合的地方需要双方并行开发，能够快速提供可执行可验收的交付物以及快速反馈，如果反馈链过长，则导致开发成本和对问题的改进修复成本指数暴涨。

芯片开发是否正在采纳软硬协同，这不是一个正确的问题，正确的问题是，芯片的交付节奏能否满足软件开发的需求？如何更好的满足这一需求？该需求可划分为特性驱动的从软件到硬件的垂直整合，以及全系统包含软硬件的架构探索两个方向。在两个方向上，需求还会被进一步细化，拆分，形成工程管理维度的任务排优，什么事情先做，什么事情后做。按照这个节奏来构建工程维度的流水线，按软件和系统的需求交付功能，你就获得了一个持续交付。为了获得后端快速反馈，后端环节也要左移，跟前端并行开发。当后道工序都在左移的时候，你就获得了一个工程维度的并行流水线。管理这个流水线的逻辑比传统管理串行流水线的逻辑会更复杂。走到这里，你已经是敏捷开发了。无论你有没有把你的工程实践概念化。敏捷只是一个概念，这些实践在多数的工程团队都在不同程度的转型。这里讲的是技术维度，但是如果你接触过产品管理运营的话，你应该听过PPT模型（people-process-technology）这三者是紧耦合的，需要像一个太极图一样保持内在逻辑的一致性，如果只有技术升级了，过程左移了，但是管理范式没有跟上，整体还是低效的。

你的管理，过程，技术三者之间会有巨大的gap，这些gap就是浪费，就是工程熵增，就是低效。提升效率不是只在技术维度谈，更大的优化空间发生在process/people维度。组织的管理效率才是产品交付的第一效率。这一点不难理解，你对比一下这三个维度的人的薪酬就知道了。敏捷开发就是将这三个维度的有机整合，而不是割裂。从管理，到工程，到技术，到代码优化有100多项实践。单测，重构，TDD，设计思维，CICD，管理3.0，Scrum，这些都是敏捷体系下的内容，没有哪个团队一个都没采纳过。

在严肃的软件工程领域，是否正在采纳敏捷不是一个正确的问题，正确的问题是，产品开发交付是否有提示效率的需求，如何更好的提升效率。咨询师从来不对团队是否采纳敏捷做yes or no的评估，而是做多维度的成熟度的评估，来分析效率瓶颈和可行的优化空间。

无论是软硬协同还是敏捷，它都是基于现实需求逐步演化转型的过程，概念仅仅是把实践过程概念化方便行业交流而已。并不存在一个时间节点，我们昨天还在用verilog做设计，今天统一切换到c++, sc. 也并不存在一个时间点，我们忽然从软硬特别不协同跳变到了软硬特别协同。敏捷同理。任何技术发展都是有连续性的，都是基于实际需要逐步演化。