今天部门大佬让我去设计并且开发一个为游戏中的AI精灵小助手的数据提供接口,强调了是敏捷开发原则。由于不太明确敏捷开发原则是什么,就去设计了一个AI精灵小助手中问题的后台管理页面,以及DB中表的设计。然后设计了一个很完善但是开发时间略长的实施方案。然后汇报工作的时候就被嫌弃太麻烦,可以简单实现,下个版本在完善。
敏捷开发原型
简单设计,快速实现,根据客户需求迭代,需要高效沟通
- 需求评审,用story的形式去描述需求
- 根据story描述的去划分需求
- 概要设计
- 详细设计
- 开发
- 自测
- 联调
- 灰度上线(灰度发布也称金丝雀发布,让一部分人去使用新版本,剩余部分的人去使用老版本,逐渐扩大范围直至全面上线)
- 全面上线
优点
注重沟通、客户写作、需求变化快、快速适应、建造模型
缺点
无法适用于大型项目,沟通需求大,造成成本大
瀑布开发原型
将功能实现和需求设计分开。将软件生命周期划分为:
- 制定计划
- 需求分析
- 软件设计
- 程序实现
- 测试
- 运维
优点
为项目提供了按阶段划分的检查点、只需要关心当前和下游功能实现、一般多嵌套于其他开发模式上
缺点
①各阶段间的联系较少,极少有互相反馈②只能在项目后期才能看到成品③根据设计文档的时间点跟踪项目的各个阶段④对需求的变更的适应力差
迭代开发原型
从某种角度上,迭代开发是一次完整经过所有流程,类似于小瀑布模式的开发流程,每次迭代都有一个成品,它也是最终成品的一部分(子集)
优点
①降低了一个功能增量的风险 ②需求变更可以在迭代的版本中实现③加快开发的进度④对新需求或者需求的变更的适应能力强
缺点
快速成型的软件可能会导致产品质量低
快速原型模式
快速建造原型,根据原型去细化需求,确认好需求的时候就可以抛弃原型,进行重新架构和开发。