计划驱动的过程：所有过程活动均事先计划，按照计划衡量进度 需求可以事先清楚、完整定义，且不会有太大变化 最终得到的软件系统有较高的可靠性、安全性要求 涉及多个部门或团队，涉及复杂的协调和沟通
敏捷开发：只做增量的短期计划并根据变化和反馈不断进行调整 需求不确定且经常变化（变化蕴涵着竞争优势） 对于最终软件系统的可靠性和安全性要求没那么高 开发团队规模较小且能够充分沟通
特点：拥抱变化
客户需求（场景、故事）驱动 认识到有效的计划都是短期的 迭代地开发软件同时强调构造活动（设计与实现交织） 频繁交付可运行的“软件增量” 根据变化进行适应性调整
Q：什么样的项目适合于采用计划驱动的开发方法？什么样的项目适合于采用敏捷开发方法？
精益思想：消除浪费，做有价值的工作
精益思想指引敏捷开发
主要特征 基于时间盒（Time Box）的迭代 增量以及演进式开发（Adaptive Development）
精益思想的具体实践：将表示软件开发任务的卡片或贴纸放在“看板墙”上用于表示开发进度，让开发流程变得可见
软件开发环节的快速迭代使得运维环节的效率和响应性成为主要瓶颈 DevOps将敏捷的精神延伸到运维阶段，包含贯穿软件开发和运维的一系列实践集合
CI：持续集成实践 •开发人员频繁地（一天多次）将代码变更提交合并到中央存储库，并自动运行构建和执行单元测试，从而确保新代码可以和原有代码正确地集成在一起
CD（Delivery）：持续交付 任何代码变更提交后都能够 自动运行构建和执行单元测试 自动将所有代码变更部署到测试环境和类生产环境 确保当代码变更部署到生产环境后可以正常工作，从而以可持续的方式快速向客户交付新的代码变更
CD（Deployment）：持续部署 任何代码变更提交后都能够 自动运行构建和执行单元测试 自动将所有代码变更部署到测试环境、类生产环境以及生产环境
【？？持续交付和持续部署的区别是什么】 持续部署（Continuous Deployment）是持续交付的一种更进一步的实践
将用户流量从旧版本应用逐渐转移到新版本，通过快速回滚应对发布错误
需维护两个环境 蓝环境：旧版本的生产环境，用于对外提供软件服务 绿环境：新版本的预发布环境，用于对新版本进行测试
部署过程 将新版本发布到绿环境中并进行测试，确认是否正常工作 如果没问题，修改路由将用户流量从蓝环境引流到绿环境 如果引流之后出现问题，修改路由再切回蓝环境，并在绿环境中进行调试，从而找到问题的原因
aka灰度发布
先引流一部分用户流量到新版本部署中 如果服务这些用户流量的新版本部署没有问题，再逐渐将更多用户流量引流到新版本部署中 随着时间推移，对新版本进行增量部署，直到所有的用户流量都引流到新版本部署中
一旦出现问题，支持快速回滚 通过路由配置，禁止将用户流量引流到部署新版本的服务器上
软件功能或特性在正式发布前，先将其第一个版本部署到生产环境 如果发现问题，通过设置功能开关及时关闭，支持快速回滚
