关于 Navya
Navya 专门从事自动驾驶系统的开发。公司成立于 2014 年，总部位于法国里昂，在法国和美国设有多个办事处，员工数超过 280 名，其中约 140 人是工程师和技术专家。Navya 率先推出商用自动驾驶班车。公司于 2015 年 9 月率先推出完全自主式、无人驾驶的电动车 AUTONOM® SHUTTLE，作为首公里和末公里客运解决方案。
问题：敏捷和 ISO 26262 合规性
2018 年初，Navya 面临的主要挑战是在快速增长的组织中处理产品开发的复杂性。他们需要一种方法，在敏捷方法的灵活性与 V 模型的严格性之间取得平衡，同时确保符合安全要求。
这是该公司的初创时期：开发团队手头没有合适的系统来管理产品规范，而且开发过程中的需求并非固定不变。各个软件团队使用敏捷方法，并分别负责自己的待办事项表。团队之间缺乏信息同步，没有可遵循的程序，也无法洞察开发流程。上述这些都必然会与管理交通出行业功能安全的严格监管要求相冲突。
在转为采用 Codebeamer 之前，Navya 的开发团队混合使用各种工具，与其他组织使用的工具集类似。他们使用 Git 对代码进行版本控制，并依靠手动更新的电子表格、Jira 和不断扩大的文档信息库来了解开发活动。
随着 Navya 团队的不断壮大，产品的复杂性濒临失控，团队注意到了这些会对开发效率产生不良影响的风险。该团队没有坐视情况进一步恶化以至于影响到运营。显然，此时需要对方法进行变革。
自动驾驶开发中的安全性与合规性
Navya 开发的自动驾驶产品具有多个安全关键型子系统。由于管理机构在制定自动驾驶系统法规方面落后于产品开发商，ISO 26262 仍然是 Navya 为确保功能安全而需要遵守的重要法规要求。
从流程的角度来看，开发团队基于产品用例进行高层次的风险分析。这些分析的结果逐级分解成系统要求，随之传播到所需的子系统和组件。为了验证在功能正常和功能异常方面的需求，团队先在功能或仿真级别进行测试，在受控环境中对软件系统施加压力，然后在代表性环境中进行系统级别的测试。
通过上述这些测试后，产品就得到了验证并可以部署，但即便如此，Navya 团队也会从规模较小、更可控的部署开始，部署的客户数量有限。在这些部署成功后，再将新开发的解决方案部署到车队剩余人员。
在评估 ALM 工具时要考虑到灵活性
2018 年 7 月，Navya 启动了采购流程，以选择应用程序生命周期管理解决方案。由于实现开发流程规范化的需求日益迫切，因此寻找解决方案的过程相当快。为了做出明智的决策，团队分析了多个工具的功能，并开始与多家供应商进行讨论。
在评估的过程中，Navya 团队需要了解的主要因素包括：
- 能够自定义配置各种类型的对象，并在它们之间建立关联，以实现端到端的可追溯性
- 易于在快速发展、不断创新的敏捷环境中使用
- 协同支持和用户在工具内进行交互的能力
- 灵活性，以及不断演进和调整系统以支持持续改进的能力
- 易于配置，因为团队的需求会随着流程改进而不断变化
- 优化投资回报率的定价模型
与软件开发本身一样，Navya 的开发团队在构建 ALM 环境时采用了敏捷方法。他们希望循序渐进，遵循流程中的基本敏捷模式，以确保解决方案适合他们不断发展的需求。该团队通过不断改进工作环境来大幅提高效率。因此，灵活性是 Navya 的一项关键要求：他们选择的工具需要能够适应和支持完全敏捷的思维方式。
完成评估后，Navya 将搜索范围缩小到包括西门子 Polarion 和其他工具在内的入围者候选名单。最终，正是这种对灵活性的关键需求使天平向 Codebeamer 倾斜。
Navya 在 2018 年 8 月购买了少量许可证，并不断增加其许可证数量。2019 年，Navya 有 120 名 Codebeamer 用户，并计划来年达到 200 名。
自主式推广和培训
Navya 之前没有大规模部署开发工具的经验，据 Navya 产品开发主管 说，他们也没有预料到 Codebeamer 所取得的成功和不断增长的需求。总体而言，Navya 报告说该工具的采用速度很快，并且用户培训需要花费的精力很少。
他们最初的目标是将该平台用于软件错误管理，不久之后，软件团队便将目标扩大到用户故事和 EPIC 管理。在采用该系统的过程中，令 Navya 出乎意料的一点是居然硬件团队也采用了该工具。
在使用 Codebeamer 一段时间后，产品团队自然而然地将该工具的使用扩展到硬件开发领域，但管理层遇到了一些阻力，因为硬件工程师认为该平台只是一种纯软件工具。但是，硬件团队很快就发现，Codebeamer 能够管理硬件问题并降低复杂性，因此它获得了硬件团队的广泛认可。
在培训方面，Navya 采用了混合方法：他们也开展了正式培训，然而却发现，让工程师“玩”这个工具会更有价值。在发现配置 Codebeamer 有多么简单后，Navya 决定将管理权限分发给多个团队，从而有组织地推广该工具的使用。
这种方法被证明是一把双刃剑：一方面，工程师们确实能够熟练地使用和配置该平台，但 Navya 的开发团队最终发现大量未经维护的异构对象无法协同工作。为了解决这个问题，他们成立了一个团队，其任务是确保以系统性的方法来使用该平台，削减对象数量，并将它们重新集成到一个共享的框架下。
集成式 ALM 的优势
改用 Codebeamer 后，Navya 主要受益于其流程的透明度、清晰度和一致性。
在实施 Codebeamer 之前，Navya 的不同团队各行其是，针对产品的不同功能方面进行开发。他们对活动的可见性有限，并且很难在系统的层面创建视图，这让团队无法应对整体的复杂性。
借助 Codebeamer，他们可以端到端地查看开发活动，并在从需求到验证的各种工件之间建立联系。依赖关系易于跟踪，共同基础策略有助于规范编码质量。团队可以轻松地监控进度和各种高级指标，以衡量重点领域的表现。这有助于发现问题所在，促进持续改进。
ALM 帮助 Navya 顺利完成了开发工作的合规性内容，实现了从高级需求到整体体系结构、再到最终测试的可追溯链接。这有助于 Navya 团队执行必要的验证步骤和合规性检查。在改用 Codebeamer 之前，这些流程并未实现工具化，Navya 反映，该平台的使用提升了团队的效率。
考虑到该平台的灵活性及其提供的各种优势，Navya 正在研究在组织中采用 Codebeamer 的新方法，这一点也不奇怪：