核电行业敏捷实践

在核电行业，安全是生命线。《核电厂质量保证安全规定》及其一系列相关法规，对我国核电建设的质量保证提出了必须满足的要求，其中所有涉及核安全的产品，均必须实现“双向可追溯，全程可监控”。因此，为了拿到民用核安全设备设计、制造许可证，核电行业的控制保护系统往往采用瀑布模型作为系统研发模型，并引入质量控制（QC）、质量保证（QA）、验证与确认（V&V）等多种角色确保质量。那么，核电行业又是因何与敏捷开发方法结缘的呢？

本文从中国某核电公司（下称“公司”）在将科研与开发分离时面临的困惑谈起，介绍了该公司在科研项目中引入敏捷开发方法的做法，以供业界参考。

科研与开发的分离

某核电公司是一家专业从事核电站仪控系统研发的公司。2010年以前，公司的项目大致可分为工程项目、研究项目和开发项目。其中，工程项目直接面向核电站最终用户，需要利用核电站大修换料期的短短一个多月的时间完成安装、调试并实施，时间紧、任务重、质量要求极高，而每耽误一天造成的核电站停机损失数以千万元；研究项目和开发项目的成果则直接为工程项目服务。由于公司有面向核岛、面向常规岛及面向生产管理层的多条产品线在同时进行研发并配合工程实施，由此产生了大量的定制版本。随着项目的增多，实施及产品维护困难凸显。

为了更好地平衡质量、时间与人员投入等之间的矛盾，基于各产品线存在技术相似性的特点，公司按照“统筹规划、兼顾长远”的原则，对研发与工程实施体系自下向上进行了重构，并把其划分为技术平台、产品平台、解决方案三个层级（见表1）。

通过将技术平台独立切割，公司将现有产品中技术难度或风险较高的部分分离出来，利用单独的科研活动进行处理，在技术平台研究未取得成果时，也可以将第三方成熟稳定的技术或组件等应用于产品平台，有效避免了工程项目实施期间可能遇到的重大技术问题。而在当前技术问题解决后，科研活动可以转向更先进的技术开展预研，确保公司“研究一代、开发一代、实施一代”的战略规划得以落地。

此外，通过技术平台、产品平台及解决方案的划分，公司避免了大量针对工程项目的定制产品的出现，事实上节省了公司的实施及运维成本，使得核电数字化仪控系统的研发顺利进行。

科研活动带来的新问题

2010年，公司成立研发中心，主要从事核电站数字化仪控系统技术平台的管理，以及利用研究室和实验室为主体的强大的科研能力进行科学研究（含硬件、软件、结构件等）。

在成立之初，基于以往的行业经验，研发中心科学研究采用的多是产品研发的瀑布模型，但经过近半年的实践发现，瀑布模型过于“笨重”，不适合“需求难以锁定、技术边学边用”的快速变化的科研项目。

为了解决这个问题，研发中心尝试在科学研究的管理环节引入敏捷开发方法，但这又带来了新的问题。

（1）公司已通过软件能力成熟度集成模型（CMMI）3级（已定义级），正处在向CMMI 4级（量化管理级）的转变过程中。原有的产品研发体系要求，需求不锁定就首先解决需求问题，技术不明确就先完成技术知识的储备，否则不能进入下一阶段。同时，所有的相关技术文档、人员角色安排也是基于CMMI体系，因此引入敏捷开发方法相当于引入一套新的体系，需要重新梳理相关流程。

（2）核电行业“全程可控”的思想与敏捷开发方法的“小步快跑、快速迭代”的理念之间存在着一定的矛盾。因此，研发中心需要统一大家的思想，尤其是领导层的思想。同时，研发人员还需要掌握敏捷开发方法的技巧，适应新的工具，而这些都需要一个过程。

敏捷开发方法的引入与改进

对现有研发体系的影响

引入敏捷开发方法的第一步，就是要考虑如何与公司现有产品研发与工程实施体系相融合。

对于公司来说，通过划定解决方案、产品平台与技术平台的层级，切分了工程实施、开发活动及科研活动的边界。但边界的切分不代表要求的降低，科研活动同样要以满足核安全质量要求为前提。敏捷开发方法引入科研活动，首先要考虑的是流程的改进如何满足质量的要求，要能够保证科研活动输出成果的质量，并能够提供相应的度量方法（见图1）。

另外，由于科研活动成果服务于产品平台的开发，在采取了敏捷开发方法后，科研团队的开发节奏与产品平台开发团队的瀑布式开发节奏产生了差异。从最终用户优先的角度出发，科研团队的迭代成果必须服从和服务于产品平台的开发周期，不论其处于什么阶段。

制定策略与目标

由于敏捷开发方法的引入与公司现有管理思路、管理体系存在较大差异，研发中心制定了“分阶段、分步骤，先试点、后推广”的引入策略，并通过实施过程中取得的效果逐步统一大家对敏捷开发方法的认知。

第一阶段，研发中心目前有软件、硬件及结构件三大类工作，从便于引入及实施的角度考虑，首先选取1～2个软件类科研课题进行试用，分析试用过程中遇到的问题，总结经验，建立流程、模板、规范，从而具备基本推广条件。

第二阶段，扩大试点范围，推广至研发中心其他软件类项目，积累更多经验，完善流程、模板、规范，具备进一步推广条件。

第三阶段，推广到研发中心所有项目，并适应性调整流程、模板、规范，修改研发中心规章制度。

在具体实施目标方面，第一阶段主要为梳理出符合研发中心软件方面的科研流程，使得平台、产品的研发与科研能够更好地配合。此阶段的具体工作如下：①思想方面，通过多次培训，统一相关人员的思想，掌握敏捷开发方法和技巧；②流程方面，结合当前公司流程、模板、规范与敏捷开发方法的特点，建立起一套符合试点项目类型的敏捷项目实施管理流程；③組织方面，具备基本的推广条件，如培养出敏捷教练、提出组织敏捷转型建议等。

基于严格的行业规定、公司整体对敏捷开发方法了解程度欠佳等因素，在第一阶段，研发中心采取了以Scrum框架为主、结合使用XP极限编程的最佳实践的方式，以便于扩展和改进。

统一认识

对于核电行业来说，标准的符合性是非常重要和严肃的问题。以安全软件研发为例，为了证明研发出来的软件是安全的，研发机构必须严格按照IEEE 1228或者IEC 61508等标准中规定的每一步来执行，任何删减都会影响软件安全的认定。

但对于敏捷开发方法来说，是否也是这样？是否必须完全按照Scrum或者XP等来做，才可以称之为敏捷开发方法？

在开始时，大家对于这个问题争论不休，每个人都有自己的看法。研发中心最终采取“搁置争议，摸索前行”的方式，在实践中解决问题。在进行最终总结时，大家取得了共识：对于公司来说，敏捷开发方法不是某种特定的框架，不能局限在Scrum或XP中，符合敏捷宣言核心价值的实践才是敏捷。在表现形式上，敏捷开发方法是符合公司实际情况的最佳实践的集合。

团队角色再定义

在组建敏捷开发团队时，研发中心首先面对的就是相关角色的定义。

一个标准的敏捷开发团队通常包括产品负责人（Product Owner，PO）、敏捷教练（Scrum Master，SM）、团队成员，分别负责需求管理、敏捷开发过程管理及具体的开发工作。但按照研发中心现有流程，每个科研项目仅有一个项目经理，负责整体管理项目，协调处理各类汇报及各种关系。在试点开始阶段，试点项目按照要求分别确定了PO、SM与团队成员，将原项目经理根据业务能力的特点分别归入PO或SM的角色。

但随着试点开展，大家发现，研发中心领导往往习惯与原项目经理沟通一切，而原项目经理在与PO或SM发生争论时，也往往习惯用行政权威解决问题。因此，在试点后期，研发中心将PO与SM的角色合一，并由原项目经理统一扮演，能力上的不足则通过培训来解决。经过这样调整，试点项目运转更加流畅。

精简低效的会议

按照Scrum结合XP的框架，试点项目开始阶段分别定义了迭代计划会议、每日站会、产品列表休整会、迭代评审会议、迭代回顾会议、发布计划会议等多种形式，这也同样遇到了问题。

科研项目的用户，由通常意义上的最终用户变为了产品平台的开发团队，而产品平台的开发团队首先需要满足工程项目所确定的里程碑，自身业务较为繁忙。另外，产品平台开发团队的业务范围与科研团队不同，对于科研团队具体研究过程并不关注，往往提出时间与应用的要求以后，就不愿过多地参与讨论过程。因此，本应全部会议都参加的用户，逐步演变至在迭代计划会议结束后，就不再出现。基于此，试点项目最终整合了迭代计划会议、迭代评审会议、迭代回顾会议、发布计划会议，将相关工作在每个迭代的开始阶段进行。只是保留了产品列表休整会和每日站会，在每周和每天开始时对工作进行讨论与调整。

找准用户，讲好“故事”

由于用户的变化，科研项目的用户故事事实上下沉到了软件和硬件的需求层面，而研发中心赋予科研团队技术攻关的要求，也使得用户故事的范围进一步扩大，扩展至了设计、编码、测试等产品开发各个阶段。由于产品平台开发团队面向工程项目，其应用科研成果过程中出现的影响工程项目里程碑的关键技术问题，也必须同样紧急追加至用户故事列表中。

此外，在实际工作中，科研团队认识到，研究型的用户故事的工作量估算非常困难。科研团队成员的分工较为明确，而每个人通常只对自己熟悉的业务领域擅长，导致采用计划扑克牌进行工作量的估算形同虚设，每个迭代周期的任务量往往不饱满或者超负荷。

为了解决上述问题，试点项目将迭代周期调整为一周、两周甚至三周可选；加粗了用户故事的颗粒度，不再追求每一项都清晰可控；给团队预留在研究过程中的动态调整时间，并通过每日站会及每周的产品列表休整会有针对性地调整用户故事列表，允许产品团队临时增加紧急任务。但敏捷扑克作为一种沟通工具仍然保留下来，因为它使得大家对于任务的认识趋于一致。

经过上述调整，敏捷开发方法终于能够应用于软件科研项目管理过程中，并初步与公司现有流程体系融合在一起。

结语

公司在成长过程中，会有很多转变。作为一家核电行业的传统研发企业，公司如何平衡科研与开发的关系，在实践过程中既能满足监管的要求，又能满足公司研发的需要，一直困扰着管理层。敏捷开发方法尽管诞生于互联网行业，但同样可以应用于传统行业。正如敏捷宣言所说“个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划”，只要其中有一项应用场景是符合公司需求的，那就可以考虑引入敏捷开发方法，在实践中加以吸收和转化，设计出符合自身实际情况的流程，这也是推动公司不断进步的动力。

由玉伟，高级工程师，曾就职于北京某核电公司，现就職于国家药品监督管理局信息中心，从事信息化规划、设计及开发相关工作。