GXP环境下，对敏捷开发及验证的思考
关注并标星【CIO发展中心】
与更多CIO 一路同行
第一步详尽的计划，能够把项目的生命周期中的各项工作安排地明明白白，清清楚楚
第二步则是进行充分地分析以形成完整和详尽的需求
第三步基于完整的需求进行相关设计，包括功能设计和技术设计
第四步基于设计，进行编程和开发
第五步各种各样的，各层次的大面积测试
第六步部署上线和运维
第一步有粗略的计划和思路方法
第二步收集用户的初步需求和关键需求
第三步选择部分需求，进行设计，开发，测试和部署
第四步重复第三步直到用户全部需求的完整实现
瀑布 |
敏捷 |
|
项目执行的灵活性 |
较差 |
较好 |
部署上线的方式 |
大爆炸式，一次成型 |
积木式，多次成型 |
整体费用控制的难易性 |
容易 |
较难 |
变更影响特征 |
越是项目后期产生的变更，影响越大 |
变更影响相对较小 |
所需要的用户需求明确度 |
明确 |
模糊 |
需求的差距暴露时间 |
较晚 |
较早 |
文档可控制性 |
容易 |
较难 |
对开发人员的整体要求 |
一般 |
较高 |
对质量管理人员的要求 |
一般 |
较高 |
成功交付的可能性 |
一般 |
较高 |
承受的监管压力--以前从未尝试过的新方法，监管挑战会多些，多一事不如少一事，安全起见，保持现状；
供应商能力--这个供应商的敏捷的能力或者资质，与其搞个Fake Agile，不如采用传统瀑布方法，或者软件开发和验证两条腿走路；
公司内部--破冰引入新的方法，万一搞砸了，那收不了场；用的都是COTS，没啥可敏捷的；现在的工作模式已经很稳定了，保持现状挺好；