功能安全与敏捷开发
在《功能安全量产落地的三座大山》系列文章中，笔者曾预言敏捷开发将逐渐成为汽车软件开发的主流方式，也将逐渐成为功能安全软件开发的主流方式。本文就功能安全与敏捷开发的问题进行一些初步探讨，抛砖引玉，以飨读者。
长期以来，敏捷开发方式在互联网行业比较普遍，而在汽车行业基本上很少见到。主要是因为传统的汽车研发周期通常在2年以上，而且需求比较明确，在项目过程中很少变化，不需要快速迭代。
但到了现在，市场环境已经完全不同。产品需要快速交付，硬件需要提前做好预留，而软件则通过OTA不断升级优化，这在电动汽车领域尤为明显。功能安全作为产品的一部分，同样也需要快速交付。传统的“V”模型开发方式，由于太过死板，已经越来越难以适应需要快速交付的市场了。
敏捷开发简介
敏捷开发强调关注用户痛点，拥抱需求变化，通过快速迭代来持续交付软件。精简流程，精简文档，在团队内部通过高效沟通来实现分工与合作。
敏捷开发的核心是迭代开发和增量开发，将一个大任务分解成多次的、渐进的小任务，每轮开发都会发布一个有效版本，每轮开发都会比上一轮增加更多的功能，逐步改进，最终形成完善的产品。敏捷开发的每一轮迭代都是一个完整的软件开发周期，包括需求分析、设计、编码、测试、评估等环节。
Scrum简介
敏捷开发的方法很多，国内最流行的应属Scrum。Scrum里的角色分工包括：
Product Owner：产品经理，负责把控项目走向及产品需求；
Scrum Master：技术经理，负责把控技术细节，推进项目；
Agile Team：具体的实施人员，包括开发、测试等。
在项目的实施过程中，由Product Owner负责维护Backlog（需求池），包括待开发任务列表和任务优先级；在定义好迭代周期（月/旬/周）后，本轮迭代（本次Sprint）需要实现的需求也就基本确定了；接下来由Product Owner和Scrum Master共同完成本轮迭代的需求分解，再组织全员进行讨论（Scrum Meeting），包括需求讨论、技术讨论以及完成任务所需时间讨论，Scrum Master在讨论过程中负责技术决策。
接下来，通过小纸条进行任务分工和开发计划制定，启动软件开发。
通过Story Board（故事板）进行任务管理。项目组每天召开短会（站会），更新任务状态，讨论技术问题和解决方案，评估计划完成情况，并通过Burn Down Chart（燃尽图）可视化的向所有人呈现目前的工作进展。周而复始，本轮迭代周期结束后，开始下一轮迭代。
虽然敏捷开发强调精简文档，但根据实践经验，关键性的技术文档仍然需要制定并维护：
需求和方案：由Product Owner制定并维护；
架构和接口：由Scrum Master制定并维护。
其它相对次要的文档，比如开发计划、详细设计、测试报告等一般不作要求。
基于Scrum的功能安全开发
需要解决的关键问题点是：如何使得Scrum符合ISO26262标准的要求？笔者认为，主要包括流程和技术两个方面：
流程方面：仍然可以通过Functional Safety Audit来保证。由于独立性要求，需要增加一名专职QA来实施检查，尤其是确认ISO 26262标准里要求采用的方法与技术是否落实到位；
技术方面：如果Product Owner和Scrum Master对ISO 26262标准非常熟悉的话，他们完全可以在Scrum活动中将标准里的要求贯彻实施。当然由于标准的系统性和复杂性，更大的可能性还是需要一名专职功能安全工程师参与进来。他的工作内容主要包括：
在Backlog（需求池）补充功能安全相关的内容并进行需求分解；
在Scrum Meeting（全员讨论）时负责功能安全相关的技术决策；
通过Story Board（故事板）管理功能安全相关的工作任务；
制定并维护需求、方案、架构、接口等关键文档里的功能安全内容。
某种程度上而言，他就是专门负责功能安全的Product Owner + Scrum Master。如果做不到，起码要做到Product Owner的程度。
从整体框架而言，只要运作得当，Agile and Safe是可能的，这也符合行业发展趋势。当然，敏捷开发主要适用于软件，对于系统开发和硬件开发，不能直接套用。另外，敏捷开发对项目组成员的素质要求很高，比如功能安全工程师，需要懂产品、懂技术、懂功能安全，还必须适应快速迭代、不断变化的项目节奏，随时做出应对和调整，这样才能保证敏捷开发的产品符合功能安全的要求。
The End
说明：
* 文章仅代表作者个人观点，不代表'仨人谈起'立场