ASPICE VDA Guideline解读（4）：敏捷开发环境（Agile Environment

编者按：原文发表于2018年4月24日，阅读量1303。现因内容勘误的目的，再次编辑。

敏捷(Agile)是基于敏捷宣言的一些轻量级开发方法的集合，包括比如：Scrum、KANBAN、eXtreme Programming等方法。

科普一下：敏捷不是一个标准，不是一个方法，而是所有遵从敏捷宣言的方法集合。

业界有很多大咖都写文章来讨论敏捷与CMMI及ASPICE的关系。从理论上来说，ASPICE和CMMI是What层面的，而Agile是How层面的。采用Agile方法是完全可以满足ASPICE的要求的。

对待敏捷方法的态度，笔者有如下的建议：

1）每个敏捷方法都是为了解决在某种场景下的某类问题，是否需要在汽车电子软件中采用敏捷方法，要case by case的具体分析，分析你所处的场景、所遇到的问题，再去分析你所想要采用的敏捷方法是否可以适用

2）敏捷不是没有文档

3）任何方法、流程或工具的引入，也都需要有文化的支持。（比如：Scrum所要求的客户投入、团队成员的主人翁精神和人员能力是否适合于你的组织呢？）

在实施敏捷方法时，考虑ASPICE的要求，VDA Guideline中给出了如下的考虑：

(1)计划

[AGE.RC.1]If evidence from project planning (e.g.backlog, burn down chart, and/or sprint planning) show gaps regarding the release planning and this aspect is significant in the context of MAN.3.BP4, MAN.3.BP9 and SPL.2.BP1, the indicators MAN.3.BP4, MAN.3.BP9 and SPL.2.BP1 should be downrated.

老杨解读：如果从项目计划（例如：backlog、燃尽图及Sprint计划）中能获得证据表明发布计划是有差距的，并且该差距在MAN.3 BP4, MAN.3 BP9及SPL.2 BP1的上下文环境中是显著的，则应降低MAN.3 BP4, MAN.3 BP9及SPL.2 BP1的打分。

注：敏捷开发环境下，也要保证发布计划是受管理的（可控的）。

(2)项目生命周期

[AGE.RC.2]If the defined project life cycle does not fit to project scope, requirements, deliveries, etc., the base practice MAN.3.BP2 should be downrated.

老杨解读：如果项目生命周期不能与项目范围、需求、交付物等匹配，则应降低MAN.3 BP2的打分。

注：比如客户要求提交的成果物中包括有需求、架构设计等，但由于采用了某种敏捷方法无法交付这些成果物，则是不行的。

(3)需求管理

[AGE.RC.3]If the project development is based on change management without a complete and consistent overview of all project requirements and this aspect is significant in the context of SWE.1.BP3 (for software) and SYS.2.BP3 (for system), the base practices SWE.1.BP3 (for software) and SS.2.BP3 (for system) should be downrated.

老杨解读：如果是基于变更管理进行的开发，缺少对项目需求整体的完整性和一致性的把握。并且这个问题在SWE.1.BP3 (软件)和SYS.2.BP3(系统)的上下文环境下是显著的，则应降低SWE.1.BP3 (软件)和SYS.2.BP3(系统)的打分。

(4)风险管理

[AGE.RC.4]If risk management is required for the project but not integrated in the agile project, the base practices MAN.3.BP5 and MAN.5.BP1 should be downrated.

老杨解读：如果在采用敏捷方法的项目中，缺失必要的风险管理，则应降低MAN.3.BP5和MAN.5.BP1的打分

(5)软件架构

[AGE.RC.5]If no software architecture is developed and maintained, the base practice SWE.2.BP1 should be downrated.

老杨解读：如果没有开发和维护软件架构，则应降低SW.2.BP1的打分。

[AGE.RC.6]If the software architecture is modified incrementally including impact analysis, this should not be used to downrate the indicator SWE.2.BP1

老杨解读：如果软件架构是增量式地更改（包括影响分析），这种情况下不应降低SW.2.BP1的打分。

(6)软件测试

[AGE.RC.7]If the test level Software Unit Verification is not consistently integrated in the agile life cycle, the base practice SWE.4.BP1 should be downrated.

老杨解读：如果敏捷项目生命周期中没有考虑软件单元层面的验证，则应降低SWE.4.BP1的打分。

[AGE.RC.8]If the test level Software Integration Test is not consistently integrated in the agile life cycle, the base practice SWE.5.BP1 should be downrated.

老杨解读：如果敏捷项目生命周期中没有考虑软件集成测试层面的测试，则应降低SWE.5.BP1的打分。

[AGE.RC.9]If the test level Software Qualification Test is not consistently integrated in the agile life cycle, the base practice SWE.6.BP1 should be downrated.

老杨解读：如果敏捷项目生命周期中没有考虑软件认可测试层面的测试，则应降低SWE.6.BP1的打分。

(7)独立的质量保证(QA)

[AGE.RC.10]If the project does not ensure that work product and process quality assurance is performed at project level independently and objectively without conflicts of interest, the base practice SUP.1.BP1 should be downrated.

老杨解读：如果不能保证在项目层面独立、客观的（没有利益冲突的）实施工作产品和过程的质量保证活动，则应降低SUP.1.BP1的打分。

(8)结对编程

[AGE.RC.11]If the used pair programming method is not in conflict with code review requirements (e.g. inspection is required due to safety context), the base practices SUP.1.BP2 and SWE.4.BP3 should not be downrated.

老杨解读：如果所采用的结对编程方法与代码评审要求不冲突（例如：功能安全场合要求采用Inspection的评审方法），则不应降低SUP.1.BP2和SWE.4.BP3的打分。