十二个原则
我们最重要的目标是，通过尽早持续的交付有价值的软件来满足客户的需求（持续尽早向客户交付软件）
欢迎对需求提出变更，即使再项目开发后期也不例外，敏捷过程要善于利用变更，帮助客户获得竞争优势（拥抱变化）
要不断交付可用的软件，周期从几周到几个月不等，且越短越好（频繁的发布可用软件）
项目实施过程中，业务人员与开发人员必须始终在一起通力协作（客户与开发在一起）
要善于激励项目人员，给予他们需要的环境和支持并相信他们能够完成任务（以人为本）
无论是对团队内还是团队间，最有效的沟通方法是面对面的交谈（7%语调+38%声音+55%肢体语言 交互式沟通）
可用的软件是衡量进度的重要指标（衡量开发过程的标准是交付可用的软件）
敏捷过程提倡可持续的开发，项目发起人、开发人员和用户应该都能够保持步调稳定（稳定的开发速度）
对技术的精益求精以及对设计的不断完善将提高敏捷性（敏捷高效的设计）
要做到简洁，即尽最大可能减少不必要的工作，这是一门艺术（简单有效，效能为上）
最佳的架构、需求和设计将出自有自组织的团队（重视teamwork）
团队要定期反省怎样做才更有效，并相应的调整团队的行为（积极调整）
项目开发生命周期
预测型生命周期
定义：传统方法，提前进行大量计划工作，然后一次性执行，执行是一个连续的过程
特点：瀑布、统一交付
需求：固定
活动：完整项目一次性执行
交付：一次性交付
目标：管理成本
适用场景：
充分了解拟交付产品
有厚实的行业基础
整批一次性交付产品有利于相关方
迭代型生命周期
定义：允许对未完成的工作进行反馈，从而改进和修改相应工作任务
特点：重复、循环
需求：动态
活动：重复执行直到取得正确结果
交付：一次性交付
目标：正确的结果
增量型生命周期
定义：向客户提供各个已完成的交付成果，从而可以立即使用
特点：渐进、持续交付
需求：动态
活动：每个增量执行一次
交付：多次交付
目标：速度
适用场景
管理日常风险
应对小的需求变更，难以处理影响到架构的变更
敏捷型生命周期
定义：敏捷方法，既有迭代、也有增量，便于完善工作，频繁交付
特点：小步迭代、快速试错
需求：动态
活动：重复执行直到取得正确结果
交付：多次交付
目标：得到客户反馈持续交付价值
适用场景
根据stacey矩阵分析，需求不确定但技术确定或需求确定但技术不确定的情况下使用
出现繁杂问题，需求小步迭代，快速验证试错
混合型生命周期
定义：预测型+敏捷型
使用场景
传统到敏捷转型过渡期
使用每种生命周期的优点
