研究与问题界定 · 2025 · 硕士论文 → 会议论文 · KIT IPEK
以创业者身份开发 CPS：初创公司与中小企业中的敏捷开发
在卡尔斯鲁厄理工学院（KIT）IPEK 研究所完成的硕士论文，经研究所遴选，发表于第 20 届欧洲创新与创业会议（ECIE 2025）。
研究问题
敏捷方法真的适用于智能硬件吗？答案会因组织类型而不同吗？
信息物理系统（CPS）将软件与物理组件紧密绑定。开发这类智能硬件系统面临严格的物理约束。硬件改版没有完成测试，产品冲刺就无法收尾。
敏捷框架主要面向纯软件产品，但做智能硬件的从业者会非正式地改造这些方法，以消化不断变化的需求。本研究记录了这些改造在敏捷初创公司与传统企业中的实际表现。
两个研究问题贯穿全篇：
- RQ1：不同类型的组织如何在 CPS 工程流程中应用敏捷方法论？
- RQ2：在 CPS 开发中，成熟企业与初创公司的敏捷实践有哪些关键异同？
研究方法
系统性文献综述，辅以 AI 数据提取
本研究采用系统性文献综述（SLR）方法。一条覆盖五个维度的结构化布尔检索式，在四个学术数据库中执行：Scopus、Web of Science、IEEE Xplore 与 ACM Digital Library。
检索返回 1,929 篇文献。靠人工逐篇筛选并做结构化提取，一致性会漂移，人也会疲劳。为此我搭建了一套 AI 辅助提取工作流：LLM 负责大规模、重复性的结构化摘要，每条输出都由人工对照原文核验。
1. 策略性检索与系统化筛选
依据预先定义的纳入与排除标准，通过标题与摘要筛选，将最初的 1,929 条结果收窄到 145 篇候选文献。
2. 确立提取维度
在给 LLM 写提示词之前，先定义了五个交付类别，确保 145 篇文献产出的结构化数据统一且可比较：
3. AI 负责提取的规模，人工把关质量
145 篇文献都要按上述维度做结构化提取。纯手工做要花几周。我改用基于 Perplexity Deep Research 的 LLM 辅助协议，逐篇单独处理，避免信息混淆。
一条严谨、细致的提示词强制执行这些约束，要求每个提取的数据点都附带页码，以便追溯：
你是一名研究者，正在就 CPS 工程中的敏捷方法论开展系统性文献综述。请依据下方研究背景分析给定文献。每个提取的数据点都要给出页码，确保可核验。
- 识别文献中的每一个案例研究
- 行业领域：如汽车、医疗、制造业
- 项目规模：小型 / 中型 / 大型
- 组织详情：名称（如有）、规模、国家
- 组织类型：大型企业 / 中小企业 / 初创公司 / 学术机构
- 硬件范围：机电一体化或其他
- 软件范围：连接类型（Wi-Fi、BLE、LoRa、5G、Zigbee 等）
- 系统焦点：系统的主要功能
- CPS 层级：子系统、系统或系统之系统（SoS）
- 方法：敏捷 / 混合 / 传统
- 具体实践：Scrum、Kanban、XP、精益创业等
- 敏捷程度：高 / 中 / 低
- 技术洞察：与敏捷开发相关的发现
- 流程洞察：采用敏捷的动机、遇到的障碍
- 组织洞察：正面或负面的发现
- 每个案例研究的每个维度输出一张带标签的表格
- 每个数据点旁标注页码
4. 每条 AI 输出都经过人工核验
六项质量评估标准采用评分量表（−1 / 0 / +1），让排除决策有统一尺度：
| 标准 | 问题 | 排除规则 |
|---|---|---|
| QA1 ★ | 科学观点是否经过验证？（+1 = 经案例研究/调查/访谈验证；0 = 仅实验室/学生项目；−1 = 纯理论/提案） | −1 则排除 |
| QA2 ★ | 案例研究是否确属 CPS 工程？（+1 = 细节完整；0 = 部分机电一体化+IoT；−1 = 缺少系统） | −1 则排除 |
| QA3 | 文献是否聚焦产品开发？（+1 = 流程详尽；0 = 工具/框架；−1 = 超出范围） | 仅供参考 |
| QA4 ★ | 是否提及任何敏捷方法？（+1 = 有实施细节；0 = 隐含敏捷原则；−1 = 无） | −1 则排除 |
| QA5 | 文献是否属于个人观点性文章？（−1 = 是；0 = 部分；+1 = 否，基于研究） | 仅供参考 |
| QA6 | 文献是否被引用过？（+1 = 引用 >5 次；0 = 1–5 次；−1 = 未被引用） | 仅供参考 |
★ 排除标准：未通过 QA1、QA2 或 QA4 的文献被排除。结果：QA1 排除 1 篇，QA2 排除 21 篇，QA4 排除 2 篇 → 最终纳入 29 篇。
核心发现 1
组织类型不仅决定敏捷怎么用，还决定解决哪些 CPS 问题
53 个案例研究呈现出一致的规律：CPS 系统复杂度随组织成熟度递增。初创公司集中在子系统层级；中小企业主要在系统层级；大型企业则承担系统与系统之系统（SoS）层级的 CPS。这并非偶然。SoS 层级集成所需的协调、流程与资源能力，超出了初创团队所能维持的范围。
各 CPS 层级的组织案例分布
各公司类型内部案例研究占比（%）
行业领域分布
各公司类型内部案例研究占比（%）
各公司类型内部案例研究占比（%）
这带来一个结构性推论：初创公司的子系统 CPS，通常要接入中小企业或大型企业搭建的更大框架，才能成为可用、可部署的产品。层与层之间相互依存。
运作在子系统 CPS 层级。优先追求速度与概念验证，常用 3D 打印、CAD 模型和开源 IoT 平台压缩成本与周期。敏捷方式非正式、由团队自发驱动：简化版 Scrum、临时拼装的方法、随硬件供应节奏拉长的冲刺周期。为了快速验证想法，技术债被默认接受。只采用部分 Scrum 很常见，但会削弱效果。一个农业科技案例每次迭代只完成 50% 的任务。
聚焦系统层级的 CPS 集成。客户驱动的开发排在纯粹速度之前。Scrum 是最常见的框架，项目按领域拆分，以协同的短冲刺推进。混合模式（Agile-Stage-Gate、敏捷 V 模型）在灵活性与按单研发（Make-to-Order）场景所需的结构之间取得平衡。可复用平台与 AI 增强的决策工具支撑效率。
参与系统及 SoS 层级的 CPS，常与高校合作。敏捷在团队层面运转，计划驱动模式负责宏观层面的合规治理。常见方法：Scrum、Kanban、设计思维、DevOps。技术导向的实践（数字孪生、CI/CD、微服务、AI/ML）远比小型组织普遍。安全框架（FMEA）用于管理法规合规。
核心发现 2
不同组织类型面临的挑战本质上不同
研究从 29 篇文献中归纳出 CPS 敏捷实施的九类挑战。它们的分布并不均匀，任何为这些团队设计工具或流程的人都该在意这一点。
关键差异：敏捷采用的挑战
提及该挑战的研究占比（%）
纵轴上限：50% · 悬停柱形查看具体数值
硬件约束是初创公司的头号挑战
快速迭代是敏捷的根基，但硬件改版又慢又贵。初创公司感受最深：既没有大型企业的资金缓冲，也没有中小企业的流程成熟度。冲刺计划一旦忽略物理交付周期，摩擦立刻出现。
规模越大，流程与复杂度挑战越突出
中小企业与大型企业较少把硬件约束列为首要障碍，更多挑战来自流程/工作流错配、系统复杂度（IoT 集成、多领域协调）以及组织重构。把敏捷扩展到跨职能硬件团队，会带来纯软件团队从未遇到的同步问题。
安全与合规同敏捷的灵活性存在结构性张力
对受监管的 CPS（医疗设备、汽车、航空航天）而言，敏捷的迭代理念与监管框架的文档和可追溯性要求相冲突。大型企业用混合模式应对；这些领域的初创公司往往连应对这种张力的知识储备都没有。
初创公司无意识地用敏捷，成熟企业结构化地用敏捷
研究揭示的一个标志性差异：初创公司的敏捷方式往往缺乏结构，哪里急用就用在哪里。成熟企业则更严格、更有章法，把敏捷当作更大治理模型中的一个明确层级。两者没有绝对优劣，适配与否取决于 CPS 层级和组织情境。
核心发现 3
差异之外，三类组织都收敛到适应性与 Scrum
无论组织类型，采用敏捷的首要动机都一样：消化不断变化的需求与硬件的不确定性。不分公司规模，Scrum 都是主导框架。
首要动机：适应性
采用敏捷实践的动机（%）
共同框架：Scrum
各组织类型中提及 Scrum 的案例占比（%）
各组织类型中提及 Scrum 的案例占比（%）
启示
给初创公司与中小企业的 CPS 敏捷开发建议
没有“一刀切”的敏捷方法。实践必须适配情境。
靠开放与合作换速度
利用开源硬件与软件组件快速做原型。与已接入 CPS 基础设施或生态的成熟企业合作。用 MVP 快速获取市场反馈。
在结构中保持敏捷
通过敏捷、可扩展的系统架构实现 MVP 快速交付。在结构化的高层规划与治理之内融入敏捷。
展望
未来研究：特定领域的 CPS 生态与敏捷度量
深入研究 CPS 生态系统
构建可复用的生态蓝图，弥合从子系统到 SoS 的断层。
为敏捷成效定义清晰指标
从轶事证据走向可量化的敏捷绩效数据。