GXP环境下，对敏捷开发及验证的思考

Posted 2021-04-25 CIO发展中心

▲

关注并标星【CIO发展中心】 

与更多CIO 一路同行

▲

   

制药行业，我们大多采用的是瀑布式的软件开发方法，对应的验证方法论中是V模型。软件开发的框架还有其它的类型，比如敏捷开发（Agile)下的极限编程（Extreme Programming）和Scrum等。制药行业内也一直讨论和实践Agile和验证的结合，或者采用Agile的方法对软件进行验证。有些协会组织给出了一些指南和意见，但目前看来，并没有多少真实成功的Agile及对应验证的案例。造成这个局面的因素有很多，从企业内部到供应商再到监管的态度，都有一些关系。我们可以先看下两者特点，再思考下这一现状。

 

首先，瀑布式的开发方法，讲究的是整体的层层推进，也就是为了实现软件系统的功能，必须有按照先后顺序逐步实行，环环相扣，就像多层的瀑布一样流动：

• 第一步详尽的计划，能够把项目的生命周期中的各项工作安排地明明白白，清清楚楚

• 第二步则是进行充分地分析以形成完整和详尽的需求

• 第三步基于完整的需求进行相关设计，包括功能设计和技术设计

• 第四步基于设计，进行编程和开发

• 第五步各种各样的，各层次的大面积测试

• 第六步部署上线和运维

  
  

瀑布式的软件开发实践过程中，开发人员一般先实现局部功能（模块），测试人员完成相关测试，然后再将资源开发其它的功能，这种过程类似敏捷开发，其本质还是一次性完成系统的集成和部署，跟敏捷理念不相同。

 

敏捷的开发方法，讲究的是部分的层层推进和快速适应，先交付一部分，让用户能够看到和体验到，并且获得用户的反馈，再通过逐步迭代，最终实现用户的需求和交付：

• 第一步有粗略的计划和思路方法

• 第二步收集用户的初步需求和关键需求

• 第三步选择部分需求，进行设计，开发，测试和部署

• 第四步重复第三步直到用户全部需求的完整实现

 

 

我们通过下面的表格，可以对比下两者之间的相对差异优劣和特点：

	瀑布	敏捷
项目执行的灵活性	较差	较好
部署上线的方式	大爆炸式，一次成型	积木式，多次成型
整体费用控制的难易性	容易	较难
变更影响特征	越是项目后期产生的变更，影响越大	变更影响相对较小
所需要的用户需求明确度	明确	模糊
需求的差距暴露时间	较晚	较早
文档可控制性	容易	较难
对开发人员的整体要求	一般	较高
对质量管理人员的要求	一般	较高
成功交付的可能性	一般	较高

 

了解了两者特点，我们想想为什么在GXP环境下，缺少真实Agile及验证案例？制药行业属于强监管的对象，大家包括监管方对于敏捷的第一反应是灵活，而这个灵活意味着不确认性和高风险性，最终对产品质量或者患者安全产生潜在的不利影响。其实，这只是我们对敏捷的意识不到位，形成的主观刻板印象造成的。其它行业已经使用敏捷进行了大量的软件开发，而且这些实践是有产出的，是有效的。从IT软件上看，用于服务普通消费者的互联网系统，和用于服务患者的医疗制药系统相比，前者的要求真的低很多吗？显然不是，普通消费者也需要真实可靠的数据的。造成这一现象的原因很多，我认为主要问题出在承担最终责任的制药企业身上，比如：

• 承受的监管压力--以前从未尝试过的新方法，监管挑战会多些，多一事不如少一事，安全起见，保持现状；

• 供应商能力--这个供应商的敏捷的能力或者资质，与其搞个Fake Agile，不如采用传统瀑布方法，或者软件开发和验证两条腿走路；

• 公司内部--破冰引入新的方法，万一搞砸了，那收不了场；用的都是COTS，没啥可敏捷的；现在的工作模式已经很稳定了，保持现状挺好；

我们也看到，日益激烈的市场竞争，迫使企业使用新的方法和系统，获得竞争优势，毕竟药企业要拼研发和生产效率，后台的这些IT软件系统在数字化的时代里，举足轻重。

当企业决定引入Agile时，BA/PM/用户/CSV/质量管理的小伙伴们，您们准备好了吗？

往

期

精

彩

关于CIO发展中心

「CIO发展中心」(http://www.ileader.com.cn) 于2005年由一群热衷于中国CIO职业发展的CIO 们倡导发起，并以「聚合中国CIO力量，助推CIO商业价值」为宗旨。旨在通过学术和经验交流、知识和理念宣传来促进职业规范的推进、成长环境的改善以及队伍素质的提升，进而促进信息应用水平提升，推动CIO机制的建立和完善。

Hello，伙伴们

长按二维码关注我们吧！

好文！必须点赞