5种常见开发模式

  • 瀑布式开发
    • 典型的预见性方法
    • 自上而下
    • 上一阶段结束，下一阶段执行，不可回溯
    • 优点
      • 预先计划
      • 便于确定预期的开发成本和时间
    • 缺点
      • 无法预知未来
      • 环环相扣，一环出问题，满盘皆输
      • 测试发现问题，开发没法及时解决（开发此时可能已经处于下一个项目的研发中）
    • 适合场景
      • 具有明确定义和不变需求的中小型项目，比如小型公司网站开发
      • 需要严格控制流程，预算和时间表可预测的项目，比如政府类项目
      • 必须遵守多个规章制度的项目，比如医疗软件
      • 使用了业内熟悉的成熟的技术方案的项目
  • 增量和迭代开发
    • 增量开发
      • 项目切割成子模块（相对独立）
      • 横向开发
      • 可以顺序进行，也可以并行进行
      • 如果研发资源有限，需要进行子模块的排序
      • 如果研发资源充足，那么在设计阶段PM任务量较大
    • 迭代开发
      • 项目切割成子任务（以上一次迭代为基础进行）
      • 纵向开发
      • 项目初期不需要完整的规范，在开发过程中可以对需求进行少量更改，但需求根本和主体不能改变
      • 每次迭代需要留下清晰的文档
    • 优点
      • 如果失败，只是一小部分的失败，降低损失，软件容易成功
      • 也可以根据上线版本的用户反馈，结合完成下一次迭代方案
    • 缺点
      • 沟通或文档的不清晰，会导致后期融合出现问题
    • 适合场景
      • 大型关键企业应用程序，最好由松散耦合的部分组成，比如微服务或web服务类
  • 看板开发
    • 属于敏捷开发的一种（scrum也是其中一种）
    • 自下而上（与瀑布式开发对比）
    • 后道工序需要时，给前道工序发信号，前道工序才启动任务
    • 用户需求为原动力
    • 优点
      • 没有明显的迭代过程，可以随时加入新需求
      • 即来即增加，即变即更新
      • 团队中的人可以清楚看到所有任务的负责人以及进度等
      • 透明度高有助于准确估计最要紧的任务，项目组越来越自动化
      • 站立会 —— 每人交代已完成的任务和遇到的问题（对于复杂问题会有专项讨论）
      • 遇到问题，立刻停下来解决
    • 缺点
      • 不利于思维的发散
    • 适合场景
      • 要求处理目标用户前期反馈的新项目
      • 业务要求不能被清晰地转换成产品需求的中型定制化项目
  • 极限编程（XP）
    • 属于敏捷开发的一种
    • 与看板开发相比，更注重快速解决问题
    • 团队人数少，人人平等，畅所欲言
    • 优点
      • 没有总体设计，设计过程贯穿始终
      • 只要满足需求，通过测试即可（因为满足需求后，后期会有迭代版本）
    • 缺点
      • 对团队要求高
      • 由于过程不拘泥于形式，后期文档在完整性上会有所欠缺
      • 项目组成员流动会带来巨大问题
    • 适合场景
      • 要求处理目标用户前期反馈的新项目
      • 业务要求不能被清晰地转换成产品需求的中型定制化项目
      • 经常发生变化的项目、紧急上线任务和封闭开发等

从操作灵活性和用户参与度进行对比