ACP笔记01｜敏捷考试框架

一、考试大纲

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 混合型生命周期

定义：将预测型生命周期和适应型生命周期混合在一起使用，会很好地运用到两者的优点

适用：①当组织从传统项目管理过渡到敏捷项目管理的过渡期；②当需要使用每种生命周期的优点时