pmp2022 敏捷知识点整理

一、敏捷宣言
个体和交互 胜于 流程和工具
工作的软件 胜于 详尽的文档
客户合作 胜于 合同谈判
响应变化 胜于 遵循计划
二、敏捷十二原则
准则1：我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
准则2：欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势。
准则3：要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
准则4：项目实施过程中，业务人员与开发人员必须始终通力合作。
准则5：要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。
准则6：无论是对开发团队还是团队内部，信息传达最有效的沟通方法是面对面的交谈。
准则7：可用的软件是衡量进度的首要衡量指标。
准则8：敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该保持步调。
准则9：对技术的精益求精以及对设计的不断完善将提高敏捷性。
准则10：简洁，即尽最大可能减少不必要的工作。这是一门艺术。
准则11：最佳的架构、需求和设计出自于自组织团队。
准则12：团队要定期反省怎么做才能更有效，并相应地调整团队的行为。
三、敏捷阶段框架
相较于结构化项目管理的启动、规划、执行、监控、收尾五大过程组，部分流派将敏捷也做了一个五阶段框架：构想、推演、探索、适应、结束。他们不能直接跟结构化项目管理中五大过程组完全匹配对应，但是可以粗略这样对应。
构想阶段，得到产品愿景；
推演阶段，得到用户故事清单、产品待办事项列表、产品发布计划等；
探索阶段，执行得到完成的用户故事；
适应阶段，对完成的进行把关；
结束阶段，完结整个项目。
四、四种生命周期及对比
预测型生命周期：一种更为传统的方法，提前进行大量的计划工作，然后一次性执行;执行是一个连续的过程。也称为瀑布式。
迭代型生命周期：这种方法允许对未完成的工作进行反馈，从而改进和修改该工作。
增量型生命周期：这种方法向客户提供各个已完成的，可能立即使用的可交付成果。
敏捷生命周期：这种方法既有迭代，也有增量，便于完善工作，频繁交付。
五、仆人式领导
特征：建立社区、倾听、同理心、成长承诺、治愈能力、管理能力、意识、洞察力、说服力、化繁为简能力。
1、帮助、促进团队发展。
2、为团队消除障碍。
3、为他人贡献铺路。
4、教育相关方，使其了解为什么要敏捷以及如何敏捷。
5、通过指导、鼓励和帮助为团队提供支持。
6、通过技术项目管理活动，如量化风险分析来帮助团队。
7、庆祝团队的成功，为团队与外部团队合作提供支持，并起到桥梁作用。
六、敏捷团队特征
1、团队规模：3-9名。
2、理想情况下，集中办公。
3、100%专职成员、跨职能团队、通才型专家、自我激励自律的成员。
4、鼓励自我管理团队，由团队成员决定谁执行下一阶段工作。
5、敏捷团队与仆人式领导一起茁壮成长，领导支持团队的工作方法。
6、团队频繁创造产品增量，团队集体对工作负责并共同拥有完成工作所需的所有必要技能。
7、限制在制品(WIP)、彼此依赖实现交付。
8、以各种方式开展合作(结对、群集、群体开发)。
七、敏捷团队的角色
1、跨职能团队成员：拥有各种必要技能;以常规节奏交付潜在可发布产品;核心职责是在短时间内交付任务。
2、产品负责人：指导产品的开发方向;创建、维护产品待办事项;根据商业价值排序任务;提供反馈。
3、团队促进者：确保遵循敏捷流程;引导、指导、消除障碍。
八、卡诺分析与MoSCoW卡诺分析
Kano用于给需求进行优先级排序，它将需求分为以下四种类型：
作为阀值的功能：必须的功能。是产品要成功就必须具备的那些功能。改善增加阀值功能数量到一定程度，对客户满意度提升就没有多少影响了。
线性功能：“越多越好”的功能。它的改善与数量增加能直接提升用户满意度，它的降低和数量减少也直接降低用户满意度。
兴奋点和惊喜点：指提供了很高满意度，并常常为产品增加额外价格的那些功能。但是缺少它不会让客户满意度降到中性以下。
无关紧要属性：这些特性无论从哪方面来说对客户都没有影响。因为客户对其根本就不关心，我们应该努力消除、最小化或者延迟交付这些特性。
MoSCoW
莫斯科法则，就是must or should，could or would not，用于给需求进行优先级排序。
按照“Must：必须做的；Shoud：应该做的；Could：可以做的；Would not：不要做的”来做，保证PO所需要的Must、Should完成，并力争Could能完成;在响应变更时，优先考虑牺牲Could乃至Should需求特性。
九、DoD工作完成准则
Definition of Done，工作完成准则。是帮助干系人对项目工作达成一致的必要准则，由团队所有成员一起决定，一般在敏捷各个层次的计划上制定，包括如下三个层级：
发布DoD，如：完成发布规划范围内的那些需求;至少通过一次发布的回归测试;修复所有等级为1、2的缺陷……
迭代DoD，如：所有完成的用户故事已验收;所有代码得到静态分析，纠正最高级别的不符合项;所有新增代码得到评审;所有完成的用户故事都有对应的测试用例……
用户故事DoD，如：用户故事最终的描述符合INVEST;用户故事都有对应的测试用例……
传统项目铁三角：范围相对固定，成本进度是变量；
敏捷铁三角：成本进度相对固定，范围是变量；
敏捷三角强调价值和质量，约束(范围、进度、成本)。
十、用户故事
用户故事描述了对用户、系统或软件购买者有价值的功能，用来收集客户需求。在卡片正面描述用户的需求，在背面描述该功能对应的期望：如估值、交付实践、验收标准等。正面描述实例如下：

另外用户故事需满足INVEST属性，并遵循3C原则。

用户故事的故事点估算，是通过规模的相对大小来排列故事，最终基于这些排列来进行估计。常见估算有宽带德尔菲和计划扑克、亲和估算等。
宽带德尔菲：一种基于团队共同参与的估算方法，一群专家匿名提交估算结果，彼此不知道真实的结果，这样可以提升团队成员对结果的认同感，也可以避免产生一些“光环效应”。一般会进行多轮，直到达成共识。相较于一般的德尔菲，宽带德尔菲是专家匿名投票后，会开放空间让大家交流和讨论。
计划扑克：每人10张数字牌，每个人选一张卡片，代表这个故事所花费的成本，这个时间点选择的卡片不能给他人看。所有参与者同时展示自己的卡片。团队一起来讨论这些估计值，尤其对异常值(最高的和最低的)要着重讨论。
亲和估算：快速估计大规模需求未完项的一种技术，利用衬衫尺寸(尺码S/M/L/XL/XXL等)、咖啡杯尺寸(小杯、中杯、大杯等)或斐波那契序列(序列中的数字等于前两个数字值之和)中的数字将用户故事快速置于规模类似的群组中。

十一、速度
一个Sprint中完成的故事点数。这个数按时间取平均值，来预测多个Sprint中可以完成的工作量。随着团队成员彼此熟悉，以及成员对项目工作的不断熟悉，速度值会趋于稳定。它反应了团队历史工作能力。但是注意速度是独特的，在不同团队、不同项目间进行比较没有意义。
十二、信息发射源
信息发射源是一系列高可视化展示信息的方式。包括燃尽图、燃起图、累计流量图、故事地图、任务板、看板等等。它有高度可见、透明、实时、简单等特点。
十三、看板与任务板
看板来自于精益，它显示所有的特性的状态，帮助团队了解工作在流程中是如何流动的。保持在特性层次而不是任务板的任务层次。它不能直观准确地帮助了解团队成员在完成哪个任务，但能帮助直观查看工作流程中各阶段正在进行的工作数量。
任务板用来透明展示任务的状态，可以跟踪进度，让团队对项目的工作任务状态清楚明白，帮助团队成员自我组织。
两者相同之处体现在：任务板、看板都是信息发射源，都能将项目信息直观的展示给团队成员。
不同之处：
1、看板是为了帮助团队跟踪工作在流程中如何流动，能发现流程中的瓶颈，同时也能帮助了解特性的进展状态。工作流程与团队工作方式一致。
2、看板中的卡片显示的是特性，有可能没有细化到任务层次，不是跟踪团队成员的具体工作任务状态的最佳信息发射源。
3、任务板显示所有任务的状态，能让团队成员清楚透明的跟踪进度，并进行自适应调整计划。