一、考试大纲
1.思想吸收阶段
— 敏捷的价值和原则（L1）
— 敏捷的框架和术语（L1）
2.付诸行动阶
— 段混合模式
— 敏捷的方法和方式（L2）
— 看板
— 速度/生产力/生产量
— 周期时间/交货时间知识分享（L2）
3.演进升华阶段
— 建立敏捷团队（L1）
— PMI职业道德（L2）
二、敏捷与瀑布区别
1.瀑布模型将识别变化延迟到最后的测试或用户使用阶段才发现，极大地增加了返工或变更的成本
· 官僚、慢、庞大
2.敏捷思想里通过短期迭代，尽可能早的交付可用的得带版本来拥抱和适应变化，从而减少风险和不确定性
· 经验型的开发模式
· 快速响应、适应变化
· 增量开发、迭代开发
三、敏捷思想
3.1 三大支柱
透明、检查、适应
3.2 五个核心
承诺、专注、开发、尊重、勇气
3.3 敏捷宣言
1.个体和交互高于流程和工具
· 项目是由人来执行的而不是工具
· 优秀的成员没有良好的交流，那也会失败
· 我们致力于个体和交互，但不是不需要流程与工具
· 需要哪些工具和流程是由组织团队决定的
· 合适的工具对于成功也非常重要
2.可交互的软件高于完备的文档
· 传递信息的必要性
· 团队需要编制易于编写和阅读的文档
· 最终完成工作的软件是开发人员想要的
· 轻量的文档也节省了时间和成本
3.客户合作高于合同谈判
· 合同谈判没办法帮助开发理解客户需求，只有通过与客户进行更多的交流才能让开发人员理解客户需求
· 保持沟通是一项重要的措施，可以帮助软件符合需求
· Scrum要求每个冲刺交付可用的软件，用这个软件与客户交流
4.拥抱变化高于遵循计划
· 应对软件环境的变化是敏捷开发的一个重要的特性
· 敏捷开发将需求控制到短期内，并保证需求的稳定
· 敏捷团队致力于响应变化，但并不是不需要计划，反而需要更多的规划
· 敏捷开发方法是“规划-执行-调整”，不断的学习和调整是敏捷开发的核心
3.4 敏捷原则
1.我们最高优先级的工作是通过尽早和持续不断的交付有价值的软件，来满足客户的需求
· 首先要让客户满意，而不是内部领导满意
· 尽早、频繁的持续交付，与客户形成早期的良好合作，及时反馈提高产品质量
· 交付有价值的软件
2.我们欢迎需求变更，即使是到开发后期也欢迎。敏捷过程将会通过变更，而使客户获得竞争优势
· XP的方法中提到了“拥抱变更”
· 敏捷的方法就是用一种轻量级、高透明性的方法，将变更进行优先级的排序，并放入待开发项中以待开发，使得项目处于高适应和灵活的环境
· 接受变更并通过建立有效的方法处理它们，那么团队更有精力关注在开发的最终产品上，而不是针对变更争论不休
3.经常交付可用的软件，交付周期从几个星期到几个月不等，时间间隔越短越好
· 频繁的测试和反馈很重要，特别是持续集成工具给开发人员也提供了这样的反馈
· 开发人员交付可用的软件，并且尽早地、经常性地交付它
· 敏捷关注的目标是交付满足客户需要的软件
4.在项目进行过程中，业务人员和开发人员应该开展日常协作工作
· 业务人员可以从实际的客户立场出发指引开发人员
· 面对面交流效率更高
· 通过和业务人员每天在一起，开发团队了解业务的方式，远远超过了开需求收集会议的效果
· 业务人员也能了解到那种解决方案昂贵、开发难度大、哪些功能更节约成本
· 如果不能面对面，建议定期在一起工作，可以2天一次，具体根据工作的类型来定频略
5.使用积极主动的成员来参与项目，并提供他们所需要的支持和环境，信任他们能完成工作
· 首先需要激发每一位团队成员的斗志，让大家更好地服务与项目
· 其次组织也需要为他们提供环境和支持
· 最后组织要给予他们信任，想信团队成员能够完成工作
6.面对面交流是开发团队最迅速，也是最有效率的信息交流方式
· 人与人交流的三大要素：文字（7%）、声音（38%）、肢体动作（55%）
· 不同的人理解能力不一样，面对面的交谈避免工作上由于理解造成的隐患
· 在一些技术交流中，文档也可以辅助作用帮助开发人员沟通
7.可使用的软件是项目进展状况的主要度量
· 敏捷项目通过度量当前软件满足客户需求的数量来度量开发速度
· 一个功能不能被测量或者进行测试 ，他就不能被视为完成
8.敏捷过程倡导可持续的开发速度。发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度
· 在进行任务拆分到每天的过程中，每天的任务应保证在一天可以完成的范围之内
· 敏捷不要求用明天的精力来完成今天更多的事情，稳定且快速的开发将帮助项目最终顺利完成
· 平稳的状态下工作，可以保持团队中充满快乐和生产力，降低环境的紧张气氛，增进同事之间的关系
9.对卓越技术和良好设计的持续关注有助于提高项目的敏捷性
· 需要给团队足够的时间进行重构，重构有利于改善软件的质量和性能，是程序的设计模式和加固更趋合理，提高软件的扩展性和维护性
· 在努力实现提高价值的功能，还需要保持中立，关注解决方案的设计，通过平衡使得系统更具有使用价值，还是的维护、变更、扩展更加容易
10.简化（尽最大可能减少不必要的工作）是一门艺术
· 使用简单的方式来实现需求，是敏捷开发的一项艺术所在
· 开发人员可以高质量的完成最简单的工作，如果出了问题也容易处理
· 代码的质量需要另外的原则来保证：随时重构。随时重构是防止系统混乱的重要途径之一
11.最佳的架构、需求和设计都源于自我管理的团队
· 敏捷的团队都是自组织团队，任务不是以人为单位而是以团队为单位分配的
· 整个团队共同承担责任，每一个团队成员都能够影响他们
· 敏捷对于成员的要求较高，非常倡导全栈式工程师
12.在有规律的时间间隔中，团队成员需要讨论如何提高以后的工作效率，然后相应调整自己的行为
· 敏捷知道所处的环境是变多的，如果要保持团队的敏捷性，需要跟随环境一起变化
· 对于敏捷来说要解决一个问题便是快速应对变化
· 随时随地对自身进行更新是应对环境变化的一种途径
· 敏捷常用检查、回头看、回顾等方法频繁进行回顾，让细节不容易被遗忘，也能很快的应用到以后。随时随地的总结自身，进行自我更新
四、开发周期
4.1 预测型生命周期（瀑布流模式）
定义：也成为完全计划驱动性生命周期，要求在项目的前期确定项目范围以及交付此范围的时间和成本
适用：①充分了解拟交付的产品；②有厚实的兴业实践基础；③整批一次性交付产品有利相关方
图例：需求 → 可行性 → 规划 → 设计 → 建造 → 测试 → 移交
4.2 迭代型生命周期
定义：将项目分为很多个冲刺（Sprint），在每一个冲刺中都会运行一次开发过程，并且为客户交付可以使用的产品
适用： ①管理技术风险 ；②不断演化需求
图例：先画出头像、身子和背景的轮廓 → 逐步将三者层层完善（现有整体再有细节）
4.3 增量型生命周期
定义：将产品分为很多个模块，这就如同搭积木，一块一块地往上累加
适用： ①管理日常风险；②可以应对小的需求变更，但是难以处理影响到架构的变更
图例：先画出头部 → 再画出身子 → 最后画出背景逐形成一幅画（局部层层交付）
4.4 混合型生命周期
定义：将预测型生命周期和适应型生命周期混合在一起使用，会很好地运用到两者的优点
适用：①当组织从传统项目管理过渡到敏捷项目管理的过渡期；②当需要使用每种生命周期的优点时
网友评论