ACP考试-敏捷原则和理念及ACP敏捷项目管理考试中的专有名词及关键字

一、敏捷四大宣言:   

我们正在通过亲身实践以及帮助他们实践，揭示更好的软件开发方法，通过这项工作，我们认为：
个体和交互      胜过   过程和工具
可以工作的软件  胜过   面面俱到的文档
客户合作        胜过   合同谈判
响应变化        胜过   遵循计划

右项虽然也有价值，但是我们认为左项具有更大价值

4句宣言，采用" 甲 胜过 乙"的模式，不是简单的选择。不是建议使用甲不使用乙。而是甲和乙都被承认在同一个项目中，我们需要更多的聚焦在A方面
"虽然右项也有价值，但我们认为左项具有更大的价值。"，这句话是容易被忽略的，大部分人在理解敏捷的时候，会容易理解偏差，比如会认为敏捷不需要文档，或者敏捷不需要合同，也不需要流程。这个样就进沟里面了。我估计这也应该是一个考点，比如敏捷发起人认为，右项的流程、文档、合同、计划依然是需要的，只是提醒大家在项目实施中更多的关注左项的交互、可工作的软件、客户合作、响应变化。

二、下面我们来理解下敏捷的四点宣言?

1、个体和交互胜过过程和工具

流程和工具是我们项目中需要的，将团队的目的聚焦于个体参与和互动。项目是通过人来完成的，而不是通过工具。困难也是通过人来解决的，而不是通过流程。同样，项目是由人来完成的，范围由人来确定，项目成功也是由人来定义的。个体的参与和交互有利于项目的成功。但是，并不是说流程和工具对项目的成功没有帮助，这些反而是重要的组织过程资产。我们会自然地倾向于流程和工具带来的逻辑性和遇见性。然而，项目最终还是关系到人，所以要想成功，我们需要花费大量的时间去完善一些不可预知的领域。第一条价值观"个体和交互胜过流程和工具"有助于聚焦个体的时间、能量和激情。

2、可以工作的软件胜过面面俱到的文档

软件项目可以创造价值、高质量的软件为首要目标。然而很多人经常会过多的关注一些临时的可交付成果，比如泛泛的文档，却不太关注支持项目最终目标的可工作的软件。没有文档描述的软件在技术支持和维护上一定会出现问题及障碍，但是只有详尽的文档而没有完成软件对于任何一个组织而言都是没有价值的。所以，文档是需要的，但是需要把握其中的度。

在庞大的团队、复杂的软件系统中，会经常出现无文本遗留等问题。所以，在这样的环境下，文档是必需的。很多软件开发人员都会注重细节和流程，虽然这些可以带来高的收益，但是会使开发人员的关注点远离软件开发的项目的初衷——完成可工作的软件。所以敏捷宣言"可工作的软件胜过详尽的文档"提醒项目成员更多的聚焦与项目的目标——价值。如果过度的关注了文档而牺牲了可工作的软件，那么文档也是无用的、没有价值的。

3、客户合作胜过合同谈判

本条价值观提醒我们需要做到灵活与包容，而不能死板，类似于"正确的做事"和"做正确的事"。我们可以完全按照最初规定来完成产品，一旦客户改变想法或优先级，最好的做法就是通过灵活的方法完成新目标，而不是用最初的规定来对抗。

知识型项目是动态的，特别是软件系统；软件是无形的和难以参考的，每一个软件都是独特的。外界的需求变化很快，技术的革新非常迅速，我们应该识别出将要发生变更的事件，与客户共同的定义"完成"。这将取决于互信关系和更灵活的合同模式，同时也需要将我们工作的重点从没有附加值的活动(例如对范围的争论)转移至更富有价值的工作上。

4、响应变化胜过遵循变化

遵循计划是指按计划行事，中间可能需要采取纠正措施，目的是为了使预期的未来绩效与项目计划一致而做的一切事情。响应变化则是适应的过程，通过卓越构想和不断的反馈来采取适应性措施，适应性的目的是对实践而非预定计划的回应，是响应而非纠正。

最初的计划有时候是不完全完善的。如果我们努力将项目按照最初的计划执行，那么会使我们投入更多的精力去响应必然的更变，从而导致投入的精力会浪费掉。但是敏捷宣言并没有建议我们为了应对变化而完全放弃计划。我们需要对项目做计划，同时我们也要明白，最初的项目计划是我们开始的时候制定的，随着工作的进程，我们需要持续更新计划。

"响应变化胜过遵循计划"对于存在很高变更比率的软件项目尤为重要。同样，我们通过相应变化来代替抑制变化以及大量的时间和精力来遵循一个大型计划。敏捷项目具有很高的工作队列的可视性，通过代办事项和任务看板来形成计划。敏捷价值观的主旨就是提倡适应性计划，要求全员积极参与。

ACP敏捷项目管理考试中的专有名词及关键字

1、积极倾听：重复对方的话，反馈，开放性问题
2、适应性领导：帮助团队，排障
3、亲和估算：快速把用户故事放置到一个可比较的组里（比如T-Shirt比大小的组）
4、自组织团队：是项目和流程的专家，可以独立决定每次迭代做多少故事点（理想日）的工作，有能力独立完成每次迭代的任务，自行决定任务完成的方式和方法
5、敏捷计划：战略（愿景和产品路线图）、发布、迭代、站会。需提前规划，在执行过程中不断适应
6、敏捷味道(Smell)：影响项目的不好征兆（Symptom）
7、敏捷空间(Space)：团队可以协作、沟通、清澈和可视化的区域
8、探针：小步试错
9、CARVER:用来度量项目的目标的几个维度：Criticality,Accessibility,Return,Vulnerability,Effect, and Recognizeability
10、协作：一种使团队达成共同目标的方法
11、寂静锥(cone of silence):团队不被打扰的环境
12、跨职能的团队(Cross-Function Team）：一个人在团队中会做三件以上不同的事（比如设计、开发和测试），一个事情在团队中会有3个以上的人回做
13、周期时间(Cycle Time):一个用户故事从确定要做到真正交付的周期
14、解聚（disaggregation）：把史诗故事拆解成小的用户故事。每个用户故事大概是2-5天内完成?
15、点投票（dot voting):参与式决策的一种方法，可以通过扑克牌或报点数等方法来实现
16、极端人物（Extreme Persona):特殊的人物角色，比如强盗、抢劫犯等角色如何使用此应用
17、波菲纳切列数列（Fibonacci Sequence):一组数列通常用在敏捷估算
18、梳理（Grooming）:把产品订单进行解聚或对订单进行工作量的估算
19、宽频沟通：面对面沟通
20、信息冰箱(Information refrigerator)和信息雷达图（Informaiton Radiator）:信息不透明与透明，一个硬币的两面
21、迭代0：在真正开始第一轮迭代开发之前，可以把架构探针和需求收集等工作作为一个迭代
22、迭代H：专门为发布到生产环境所准备的一个迭代
23、MVP：Minimal Viable(切实可行的） Product
24、MMF：Minimal Marketing Feature,对客户交付的最小有价值的特性
25、Monopoly money：通过虚拟的货币买特性，从而比较特性彼此的优先级
26、停车场（Parking Lot）:一个暂时放置对优先级有争议或搁置的特性
27、参与式决策模型（Participatory Decision Models）：敏捷强调利益相关方参与，比如针对故事点的集体投票、买特性等实践
28、计划游戏（Planning Game）：极限编程(XP)的实践，评估工作优先级和工作投入量，以创建发布计划
29、计划扑克（Planning Poker）:用来评估团队针对指定用户故事的工作量的工具
30、100点方法（100-Point Method):给一个产品的不同特性的重要性标分值，客户的总共的点数是100点。
31、Tabaka's Model:一个日本设计的模型，表征具有敏捷的自组织和高绩效的团队的良好特质，属于敏捷文化的典范。