什么是敏捷软件开发？

敏捷的定义通常与瀑布形成对比，瀑布将需求收集、设计、编码和测试分离开来。相反，敏捷倾向于集成测试的快速迭代，以及早期和增量的发布周期。2001年的《宣言》列出了优先事项，如自我组织和活力而非规划，合作而非合同谈判，以及专注于开发工作软件而非文档。

敏捷经常被初创企业和小公司采用，但对于它是否适合大公司和既定项目，仍有一些疑问。虽然敏捷在较小规模上有明显的效率增强，但对于更复杂的设置，它可能会产生相反的效果，因为切换的成本更高。

毫无疑问，敏捷已经引起了热议，但它并不是灵丹妙药。在实践中，许多公司和开发团队使用某种混合框架，希望在不抛弃设计原则的情况下获得活力。

深入ASPICE

自2005年以来，汽车软件开发人员越来越多地使用ASPICE（汽车软件过程改进能力终止），这是该领域最佳实践的国际标准。

ASPICE与敏捷相结合的好处

ASPICE在合规性方面显然有好处，但它也会导致项目更加繁琐和昂贵，这是转向敏捷的常见原因。那么，有没有办法将这两种做法结合起来呢？

时间线规划：长期ASPICE与短期敏捷

ASPICE通常被理解为需要一个顺序过程。它使用验证和确认模型（V模型），这意味着每个开发阶段都有一个特定的相应测试阶段。同样隐含的是从一开始就需要明确的需求。这需要很长的开发周期，因为任何测试和反馈都会在过程的后期出现，然后需要恢复到早期阶段才能解决。

相比之下，敏捷允许在任何阶段进行更改，通过使用连续的测试方法，验证不需要推迟到后期。

在规划汽车项目的长期里程碑（通常持续几年以上）时，可以借用ASPICE框架，但当我们谈论短期（6个月）规划时，其中定义的产品增量和相应的迭代开发提供了提供有竞争力的软件的流动性。其结果是更快的周转和更动态的流程。然而，这种反差不必如此强烈。

敏捷与ASPICE的相似之处

ASPICE不确定特定的开发生命周期，只确定正确的目标。如果抛开严格的顺序不谈，相应开发和测试的V模型实际上可以很好地与敏捷过程集成。因此，像这样的敏捷实践是可能的，前提是在结果方面坚持最佳实践。

此外，ASPICE没有指定任何需要使用的特定工具，而是列出了预期结果。同样，在敏捷方法论中，工具也是次要关注的问题，重点是有效的工作实践和关系。这意味着ASPICE中规定的总体目标仍然可以得到遵守，但不必严格规定每个开发过程应该如何以及何时进行。