UNECE 呼吁进行端到端的网络安全管理
2021-08-25
为什么要关注工具？
2021-10-19敏捷与SPICE是如何结合的？
编辑：Achim Gerber, Rüdiger Bayer, Gerald Harris
敏捷和ASPICE的关系就像油和水的关系吗？水和油在混合后又会分离。但是敏捷和ASPICE的关系不是这么简单的。
敏捷开发的纯粹形式经常创建于动态增长的软件项目中。银行的网络平台是不断变化的，初次发布时，平台的发展路线还不清晰，会有功能的添加或缩减。产品周期往往很短。
车辆部件有着完全不同的生命周期。随着开发的进行，改变会越来越少。这两者看起来是完全不同的。
Automotive SPICE®并不仅局限于一种开发方法。汽车行业的大多数项目建立在经典的瀑布模型和敏捷方法或框架的纯粹应用之间的连续统一体之中。
敏捷联盟（Agile Alliance）所定义的敏捷原则实际上可以在Automotive SPICE®所提供的框架内得到非常好的实施。
在本文中，我们将重点探讨 敏捷联盟（Agile Alliance）的前两条原则：
敏捷原则
1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
在敏捷开发中，产品所有者的任务是在积压中对需求进行分组排序，以便将他们分解成连贯的交付。
这里的技能点是将任务分解到足够细的程度，使开发团队可以接受并予以完善，将其安排到迭代周期中，并实现成熟的交付。
纯软件的交付比复杂的机电系统更容易管理。机电系统的原型是非常昂贵的。频繁的交付很快就会导致失去效益。在这方面，业界已经找到了解决方案。硬件在环（HIL）和软件在环（SIL）在较小的周期内缓解了开发增量，这使我们得以在交付中测试功能。不是每一个产品都会被安装在车辆上，但它肯定会进行模拟测试。
Knüvener Mackert ASPICE 指南 – Automotive SPICE 与敏捷性
我们的ASPICE 指南中的图表显示了这种积压的结构。它说明了V模型中的系统和领域过程的顺序不是只在一次迭代中就完成的，而是针对每个功能增量（未解决点）。项目管理部门负责处理各种积压。右图中显示的已验证的未解决点在这里对应增量的交付。
2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
许多成功的ASPICE项目的项目经理都感到惊慌失措。想象一下，在批量生产启动（SOP）前不久出现一个变更要求，且在最后的发布中还需要进行充分验证。但是，如果客户想要进行且为此付费……
在敏捷领域，项目开始时，哪些需求会被实施并不清晰。举个形象的例子，一艘帆船在多次迭代后可以最终变成一艘集装箱船。这意味着，有意识地接受早期开发步骤已经被抛弃。
为什么不直接建造集装箱船呢？
在此过程中，积攒了重要的经验，且这些经验已经在增量交付中被测试过了（例如，A-样本，B-样本，……）。在项目过程中，与其他系统的接口可能会发生变化，或者因为竞争不得不进行调整。因此，这关乎贴近客户和对重要趋势的灵活应对。
在上图中，左边的积压写着 “批准利益相关方的变更请求”。第二个敏捷原则是SUP.10的一部分，即变更请求管理过程。必须对每个变更请求的影响进行分析，并估算其工作量。必须对实施进行现实的规划，并批准成本的变化。在敏捷环境中，必须实施SUP.10，从而使过程不过于繁琐。对SUP.10变更请求管理与MAN.3项目管理的整合是至关重要的。
利益相关者通过产品所有者这一角色，成为开发过程的一部分。
敏捷和SPICE的关系是水与油的关系吗？
敏捷原则可以很好地在Automotive SPICE®中进行实施。传统的企业文化很可能是敏捷和ASPICE结合的最大阻碍。
敏捷SPICE®被intacs的同名工作组设计成一座桥梁。术语得到了澄清，各个过程的基本实践（BP）以敏捷的方式得到了解释。敏捷SPICE®的第一个预览版已经发布，供改进试用。
我们期待助您在项目中引入敏捷方法。