个人总结，仅供参考，欢迎加好友一起讨论
PMP - 敏捷管理核心考点梳理
敏捷开发方法与预测型的开发方法是完全两种不一样的理念，而且敏捷的知识点在PMP考试种占比非常高，预测型项目知识点有50%的考题，敏捷或者说敏捷混合预测的题目占比50%。
01 敏捷4大宣言和12大原则
4大宣言可以从哪2个角度来分类？
解析：
4大宣言如下（参考）：
- 个体以及互动而不是过程和工具
- 可用的软件而不是完整的文档
- 客户合作而不是合同谈判
- 应对变更而不是遵循计划
1和3强调人，团队内部要合作互动，团队外部和客户之间也要合作互动。
2和4强调价值交付，可用的软件和应对变更，都是为了更好地交付价值。
所以，4大宣言从“人/客户”和“价值交付”两个角度分类。
12大原则可以从哪3个维度来分类？
解析：
12大原则如下（参考）：
- 我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求。
- 欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势。
- 要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
- 项目实施过程中，业务人员与开发人员必须始终通力协作。
- 要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。
- 无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈。
- 可用的软件是衡量进度的首要衡量标准。
- 敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该都能够始终保持步调稳定。
- 对技术的精益求精以及对设计的不断完善将提高敏捷性。
- 简洁，即尽最大可能减少不必要的工作，这是一门艺术。
- 最佳的架构、需求和设计将出自于自组织团队。
- 团队要定期反省怎样做才能更有效，并相应地调整团队的行为。
其中，
1、2、3、7描述的是价值交付（及早，持续不断，短周期交付可工作有价值的软件）。
4、5、6、8、11、12描述的是人员（提供信任的环境，团队内外需要不断互动合作，团队是自动自发进行工作，并且有问题也会定期反思）。
9、10描述的是过程（不断追求更好技术，不多做无用功）。
所以，12大原则的三个维度是价值交付、团队人员和项目 过程
一说到敏捷，你就会想起以下哪个词——价值交付、按照计划严格执行，欢迎和拥抱变更，强制命令，自组织团队，为了赶进度加班加点完成，仆人式管理，合作双赢？
解析：
敏捷，价值交付、按照计划严格执行，欢迎和拥抱变更，强制命令，自组织团队，为了赶进度加班加点完成，仆人式管理，合作双赢。
02 SCRUM敏捷实践
3355分别代表什么，比如3个角色是哪3个角色，5个事件是哪5个事件？
解析：
SCRUM架构的3355指的是：3个角色，3个工件，5个事件，5个价值观。
3个角色：产品负责人、Scrum项目经理/主管/教练、开发团队。
3个工件：产品待办事项列表、Sprint待办事项列表、产品增量。
5个事件：Sprint、Sprint规划会议、每日站会、Sprint评审会议、Sprint回顾会议。
5个价值观：承诺、勇气、专注、开放、尊重。
PO产品负责人，他最主要的职责是什么，他需要维护的一个表格叫什么表？
解析：
产品负责人的主要职责：
-
负责将Scrum团队的工作所产生的产品价值最大化
-
对产品待办列表进行有效管理开发并明确地沟通产品目标
1 创建并清晰地沟通产品待办列表项（Product Backlog items）
2 对产品待办列表项进行排序
3 确保产品待办列表是透明的、可见的和可理解的
-
产品负责人是负最终责任的人
SCRUM敏捷教练，他的管理风格应该是怎样的？团队遇到问题，他应该是亲自撸起袖子去干还是协助指导？有外部的干系人来干扰团队，影响进度，他应该是让团队自己去协调还是主动去协调干系人？
解析：
Scrum Master，帮助团队每个人理解Scrum理论、实践、规则和价值，是服务型领导、仆人式领导。
1 服务于产品负责人
- 帮助找到有效定义产品目标和管理产品待办列表的技巧
- 帮助Scrum团队理解为何需要清晰且简明的产品待办列表项
- 帮助建立针对复杂环境的基于经验主义的产品规划
- 当需要或被要求时，引导相关方协作
2 服务于开发团队
- 作为教练在自管理和跨职能方面辅导Scrum团队成员
- 帮助Scrum团队专注于创建符合完成的定义的高价值增量
- 促使移除Scrum团队工作进展中的障碍
- 确保所有Scrum事件都发生并且是积极的、富有成效的，并且在时间盒（timebox）内完成
3 服务于组织
- 带领、培训和作为教练辅导组织采纳Scrum
- 在组织范围内规划并建议Scrum的实施
- 帮助员工和利益攸关者理解并实施针对复杂工作的经验主义方法（empirical approach）
- 消除相关方和Scrum团队之间的隔阂
开发团队最大的特点是什么？他需要SM敏捷教练或者PO产品负责人给他下命令去做事情吗？工作的安排和分配是团队自己去处理还是需要SM敏捷教练去安排？开发团队中是否存在高级工程师，初级工程师，中级工程师的说法？
解析：
开发团队Develop Team，包含各种专业人员，负责在每个Sprint结束时交付潜在可发布并且“完成”的产品增量。
团队规模：7±2人。
开发团队具有下列特点：
- 自组织的团队：自动自发，积极主动，团队根据各自的特长自行分配工作任务
- 跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能
- 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人员）
- 不认可开发团队中所谓的“子团队”，不存在质量检查、测试等等子团队
- 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队
另外：
专职小组成员（100%全职）
一个人在团队中只投入25%或50%的能力，会进行多任务处理和任务切换，降低团队工作的产出，并影响团队预测交付能力的一致性。
团队工作场所：集中办公和分布式团队（虚拟团队）
虚拟团队沟通技术包括鱼缸窗口和远程结对
- 鱼缸窗口，通过在团队分布的各个地点之间建立长期视频会议链接
- 远程结对，通过使用虚拟会议工具来共享屏幕，包括语音和视频链接
克服组织孤岛
组织孤岛指企业不同部门之间缺乏有效沟通和合作，造成信息孤立和资源利用不充分的问题。
为克服组织孤岛问题，就要与团队成员的不同管理者合作，让他们为跨职能团队安排必要的专职人员。
产品待办事项列表PB表是谁在维护，详细的用户故事和史诗级的用户故事有什么区别？PB表是渐进明细还是一步到位的？
解析：
什么是用户故事？用户故事就是作为一个<角色>，我想要什么<功能>，以便于实现<价值>。
其中：
角色：谁要使用这个功能
功能：实际的功能描述
价值：需要这个功能的原因，这个功能带来什么（带来的价值）
用户故事要符合DOR定义，DOR定义（Definition of Ready），“准备就绪”的定义，定义了用户故事可以被开发团队接受并进入开发阶段的最小要求，是需求准入的标准。
用户故事编写时要符合Invest原则，其中用户故事必须有价值，这是Invest原则中最重要的一条。
Invest原则：
- lndependent（独立的）∶指用户故事应该尽量独立于其他用户故事，依赖太强会导致制定计划、确定优先级等工作变得困难。
- Negotiable（可商议的）：指用户故事应该是一个简短的描述，可以通过与客户的沟通协商进行修改。
- Valuable（有价值的）：指用户故事必须具有价值。
- Estimable（可评估的）：可估算的，故事是可以估算大小的。
- Small（小的）：用户故事应该足够小，可以在一个迭代中完成。
- Testable（可测试的）：指用户故事应该是可测试的，以便验证其是否满足客户的需求和期望。
用户故事优先级排序符合MoSCoW法则，MoSCoW法则是一种需求分级和优先级制定的方法，通过将需求分为四个优先级来帮助团队更好地规划和管理项目。且可以利用风险价值矩阵，帮助识别最优先开发的用户故事或者特性。
MoSCow法则：
- M（Must have，必须有）：这些是项目中不可缺少的必要需求，必须得到满足才能使项目成功。
- S（Should have，应该有）：这些需求不是必须的，但是它们非常重要，可以使项目得到更好的结果。
- C（Could have，可以有）：这些需求是可选的，有益但不必须，如果有时间和资源可以考虑满足。
- W（Won’t have，不做）：这些需求暂时不考虑或者不满足，但是可以在以后的版本中进行考虑。
风险价值矩阵：
- 高价值高风险 —— 首先做
- 高价值低风险 —— 其次做
- 低价值低风险 —— 最后做
- 低价值高风险 —— 一般不做
详细的用户故事可以用于Sprint中，史诗级的用户故事是一个功能集合或者一个比较大的用户故事，由于颗粒较大不能用户Sptint中，还需要进一步进行细化颗粒分割成较小的有价值的用户故事。
产品待办事项列表PB表，是一个按照优先级由高到低排列的一个序列，排在顶部的产品待办事项列表条目需要立即进行开发。排序越高的产品待办事项列表条目比排序低的更清晰、更具体。
Scrum团队所承担工作的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。
产品待办列表的梳理和细化为产品待办列表项增添细节、估算和排序的动作，这是一个持续的过程。在产品负责人和开发团队之间展开。
冲刺待办事项列表SB表是什么时候更新制定的，里面的用户故事是来源于哪里？谁把SB表的用户故事进一步细化成具体的任务并进行分配的？
解析：
冲刺待办事项列表，由冲刺目标（为什么做）、为本次冲刺选择的产品待办列表项（做什么）以及交付增量的可执行计划（如何做）组成。
通过Sprint冲刺规划会议，完成冲刺待办事项列表Sprint Backlog。
- Sprint计划会议的前半段，产品负责人把待完成的高优先级功能介绍给Scrum团队
- Sprint计划会议的后半段，开发团队可以针对这些功能提出问题，如果团队有信心完成某一个功能，就把这个功能从Product Backlog移动到Sprint Backlog中
通常由开发团队决定一个Sprint完成多少用户故事。
产品增量是什么时候确定的，要符合哪个标准？谁最终拍板确认产品增量完成？
解析：
在Sprint的最后，新的增量必须是“完成”的，它必须可用并且达到了Scrum团队“完成”的定义的标准。（DOD的标准）
- 增量是在Sprint结束时可检视的和已完成的产品组成部分
- 增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用
当一个产品待办列表项符合完成的定义时，就会产生一个增量。
什么是DOD（Definition of Done）原则：
在冲刺规划会议就要确定“完成”的定义，准出的标准。可以理解为“验收标准”，包括质量标准，合规标准等。
冲刺Sprint过程中，如果有新增的重要的功能性的需求，处理的流程是怎样的，是直接在本冲刺的半途完成、下一个冲刺完成还是先放在产品待办事项列表PB表上排序后再确定？谁有权利取消冲刺Sprint？
解析：
Sprint代表冲刺或者迭代。
Sprint是Scrum的核心，构建一个“完成的”、可用的和潜在可发布的产品增量。Sprint由Sprint计划会议、每日Scrum站会、开发工作、Sprint评审会议和Sprint回顾会议构成。
固定的时间盒：2-4周。在整个开发过程期间，Sprint的长度通常保持一致。
在Sprint期间：
- 在Sprint期间不能做出有害于Sprint目标的改变（比如有新变更，一般不会添加到当前冲刺）
- 不能降低质量
- 产品待办列表按需进行精细化（比如用户故事细化后还是太复杂，需要进一步分解）
Sprint取消（非常罕见）：
- 如果Sprint目标过时（公司发展方向或者市场上或技术上的状况发生改变），那么Sprint就会被取消
- 只有产品负责人才有取消Sprint的权力
- 由于Sprint的时间都很短，所以取消Sprint的意义不大
Sprint规划会议是什么时候举行的，这个会议的目的是什么？PO需不需要参加这个会议，如果不参加会怎么样？
解析：
Sprint中要做的工作是在Sprint规划会议中来做计划的，由整个Scrum团队共同协助完成。
Sprint规划会议参与人员：PO产品负责人、Scrum Master、开发团队。
Sprint规划会议具体：
-
这次Sprint能做什么？
1 产品负责人讲解Sprint的目标以及达成该目标所需完成的产品待办列表项
2 开发团队自己决定选择产品待办列表项的数量
-
如果完成所选的工作？
1 开发团队通过将产品待办列表项分解为一天或更短的较小项来完成的，并自行分配任务
2 产品负责人能够帮助解释清楚所选定的产品待办列表项，并作出权衡。
Sprint规划会议结束，生成Sprint待办事项表。
每日站会一般是谁举行的？要回答哪3个问题？如果会议上有团队成员提出来有一个很大的障碍，是否在会上进行讨论和制定相应的方案呢？
解析：
每日Scrum站会在同一时间同一地点举行，以便降低复杂性。
会议时长及频率：每天15分钟。
参与人员：开发团队（敏捷教练和产品负责人可参加可不参加）。
会议要回答3个问题：
- 昨天，我为帮助开发团队达成Sprint目标做了什么
- 今天，我为帮助开发团队达成Sprint目标准备做什么
- 是否有任何障碍在阻碍我或开发团队达成Sprint目标。
每日站会需要注意事项：
- 会议上只提出问题，而不分析和解决问题
- 任何人都可以参加每日站会，但是只有敏捷团队才可以发言，其他人只能旁观
- 会议是为了促进团队之间的交流，不是向某个领导汇报
每日站会开得好，可以解决下面哪个问题呢？团队成员不会重复做别人的工作，问题或者风险能够及时发现，工作能够透明化，冲刺待办事项列表SB表能够更加有条理，及时将新需求放在PB表上面？
解析：
共济压力
健康的敏捷团队都会共济压力。所有的团队成员都要承诺要一起完成冲刺的工作。这就使得团队成员之前相互依赖并且对彼此负责。如果一个团队成员连续几天都做相同的事情，并且没有进展，显然缺乏前进的动力，而其它团队成员不能视而不见。因为他未完成的工作会变成其他成员的障碍。
细粒度的协作
在站立会中，团队成员的交流应该快速而且有重点。举例，当一个成员说完今天计划做什么后，另外一个成员可以会说：“哦，原来你今天计划做这个啊，这就意味着我要调整我的工作优先级，没关系，你按照你的计划做吧，我可以调整。很高兴你说了这些。”这种细粒度的协作使得团队成员知道他们之间如何及何时仰仗对方。一个敏捷团队应该追求高效、零等待，避免等待浪费。
聚集少数任务
在站会期间，团队中的每位成员都可以知道哪些工作正在进行，哪些工作已经完成。健康的团队应该关注事情的完成，也就是说任务不能一直处在进行中。在站会中，团队需要确认哪几个少数任务是当前的焦点，这样团队就可以尽快把焦点任务做完。换句话说，做完10件事，远比正在做100件事儿更有意义。
每日承诺
在站会上，团队成员需要对团队做出承诺。这样团队成员就知道敏捷交付什么成果并如何保持彼此负责。
提出障碍
其实在敏捷中任何时间都可以提出障碍，但是站会是一个黄金时刻，团队成员可以停下来认真思考“有什么事情阻碍了我或让我的工作放缓了”
Sprint评审会议review meeting和Sprint回顾会议Retrospective Meeting，这两个会议有什么区别？哪一个会议可以产生产品增量，必须客户来参与？哪一个会议是能够让冲刺不断持续改进？
解析：
Sprint评审会议是在Sprint快结束举行，用以检视所交付的产品增量并按需调整产品代办列表。
其参与人员包括：Scrum Master、PO产品负责人、开发团队、客户等重要相关方。
会议内容：
- 开发团队演示“完成”的工作并解答关于所交付增量的问题
- 获取相关方的反馈并促进合作
- 就下一步的工作进行探讨，为下次的Sprint计划会议提供有价值的输入信息
会议输出：
- 产品增量和相关方反馈的信息
- 修订后的产品待办列表，阐明很可能进入下个Sprint的产品待办列表项
Sprint回顾会议是Scrum团队检视自身并创建下一个Sprint改进计划的机会。
其参与人员包括：Scrum Master、PO产品负责人、开发团队。
会议内容：
- 团队共同讨论本次冲刺有哪些做的比较好的
- 团队共同讨论本次冲刺有哪些还需要改善的，分析根本原因
- 制定改进方案
会议输出：
- 经验教训登记册（做的好和需要改善的）
- 下一个冲刺马上可以执行的改进计划
03 其他敏捷相关概念
MVP最小可行产品具体是什么定义，一般可以在哪些情景中应用？
解析：
最小可行性产品（Minimum Viable Product），是快速的构建符合产品功能的最小功能集合，满足客户需要的初步产品原型，验证产品的市场需求和商业可行性。强调“最小+可行”。
- 客户无法明确确定需求，可以构建初步产品原型，通过后续反馈和修正，最终满足客户需求
- 在市场不确定的情况下或者风险比较大的时候，通过MVP设计实验来快速检验你的产品或方向是否可行
看板管理最主要解决哪2个问题？
解析：
看板，一个由列和卡片组成的面板，其中每列表示工作流程中的一个阶段，每张卡片则表示这个阶段内需要完成的具体任务。通过将工作流程和任务状态在看板上明确可见，团队成员可以更好地了解项目进展、发现问题并加以解决。
任务板，通过细分项目中的任务，把它们分配给团队成员，并跟踪和记录任务完成情况的一种工具。
敏捷的发布规划有3个层级，每个层级代表什么意思？
解析：
敏捷发布规划是基于项目路线图和产品发展愿景，提供了高度概括的发布进度时间轴（通常是3~6个月）同时，敏捷发布规划还确定了发布的迭代或冲刺次数，使产品负责人和团队能够决定需要开发的内容，并基于业务目标、依赖关系和障碍因素确定达到产品放行所需要的时间。
产品愿景和产品线路图
其中产品愿景，包括项目的目标，产品是什么，产品如何支持公司或者战略等。产品愿景驱动出了产品线路图，产品线路图是一个高层级的计划，产品需要的总体描述，定义宽松的时间框架，并规划记录产品需要多少次发布，驱动了产品的发布计划，确定需要多少个版本可以实现最终的产品。
发布计划
发布计划，是制定一个高层级的发布计划，该计划将说明每个发布中要包含的基本特性和功能，并记录1次发布需要进行多少次迭代。
迭代计划
迭代计划，说明了当前迭代要做多少个高优先级的用户故事，并通过用户故事交付的功能优先级排序，为交付用户故事创建相应的任务。
敏捷团队的团队章程有哪些内容？
解析：
敏捷项目章程包含以下内容：
- 我们为什么要做这个项目？这是项目愿景
- 谁会从中受益？如何受益？这可能是项目愿景和/或项目目标的一部分
- 对此项目而言，达到哪些条件才意味着项目完成？这些是项目的发布标准
- 我们将怎样合作？这说明预期的工作流
敏捷团队章程，其目标是创建一个敏捷的环境，团队成员可以发挥他们作为团队的最大能力。
包含：
- 团队价值观，例如可持续的开发速度和核心工作时间
- 工作协议，例如“就绪”如何定义，这是团队可以接受工作的前提；“完成”如何定义，这样团队才能一致地半
断完整性；考虑时间盒；或使用工作过程限制 - 基本规则，例如有关一个人在会议上发言的规定
- 团队规范，例如团队如何对待会议时间
691
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
