敏捷ACP 常用关键词整理 敏捷ACP 常用知识点整理
一、MoSCoW
1、MoSCoW :
读作"莫斯科",适用于故事优先级的排序,首次出现在 3-13敏捷产品实践:产品待办事项列表的排序 ; 基于价值的分析的一种技术 ( ACP --- 作业一 --- 19题 ) ; 适用于 需求变化幅度 <= 40% ; 当需求变化幅度 >= 60% , 需要使用 看板 进行排序。
2、各个词的解释是:
M-must have必须有;
S-should have应该有;
C-could have可以有;
W-won't have this time这次不会有
二、INVEST
1、INVEST :
用户故事的特征,出现在: 3-6用户故事的属性 ,invest : 投资的意思 --- 写好用户故事就是一场投资。
2、各个词的解释是:
I-Independent : 独立的
N-Negotiable : 可协商的
V-Valuable : 有价值的
E-Estimatable :可估算的
S-Small : 小的 (2-5天执行)
T-Testable : 可测试的
三、SMART
1、SMART :
目标是明确的、可实现的,并且与组织的总体目标保持一致。 这有助于提高注意力、积极性和责任感,增加成功的可能性。 首次出现在 ( 综合练习第50题 )
2、SMART 名词解释如下:
S-specific 详细的,
M-measurable 可测量的,
A-achievable 可完成的,
R-relevant 相关的
T-timeboxed 时间限制
3、有助于敏捷工作者记忆一项明确任务的特征。
- S-Specific :任务是指明显有助于用户故事开发的任务,应该是清晰明确的。
- M-Measurable :任务是指团队和客户能够验证的任务。
- A-Achievable :任务是指开发者可切合实际地执行和理解的任务。
- R-Relevant :任务是指明确地为用户故事增加价值的任务。
- T-Timeboxed :任务是指能够对开发所需的工作量和时间进行估算的任务。
四、WIDETOM
1、WIDETOM :
价值流程图中,辨别出过程中存在浪费。
2、名词解释如下:
W-waiting等待
I-inventory库存
D-defects缺陷
E-extra processing额外流程
T-transportation运输
O-over-production过度生产
M-motion动态。
五、WIP
1、WIP:
work in process ,在制品 : 指材料或部分已开始生产但是还未完成的产品 。
2、限制在制品 考题: 综合-31题
如果你的团队不设置任何在制品限制(WIP),很有可能出现什么情况?
A:不会出现任何瓶颈,并且有些人会没事干。
B:有些人会没事干,并且我们无法知道瓶颈在哪。
C:不会出现任何瓶颈,但是每个人都会很忙。
D:每个人都会很忙,但是我们无法知道瓶颈在哪。
3、课程知识点: 单团队-XP和Kanban-[5-10看板:概述 ]
同时进行的工作,不要太多。 限制同时进行的工作数量。
六、3C
1、3C:
出现在: 3-5用户故事的格式 , 分别是: 卡片 、对话 、确认。
2、用户故事3要素:
一个角色,一个目标和一个可达到的商业价值,通常的形式是:“ 作为xx角色,我需要yy目标,由此我可以zz价值。”
七、敏捷宣言4个价值观和12个原则
1、4个价值观分别是:
个体和互动 高于 流程和工具
可工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
尽管右项有其价值,但我们更重视左项的价值
2、12个原则分别是:
- 客户价值 : 我们的最重要的目标是,通过尽早持续交付有价值的软件来使客户满意。
- 持续改进 : 团队定期反思如何能提高成效,并相应地调整团队的行为。
- 团队自组织 : 最好的架构、需求和设计出自于自组织团队。
- 简洁为本 : 以简洁为本,最大限度地减少工作量。
- 技术卓越 : 坚持不懈地追求技术卓越和良好设计,从而提升敏捷能力。
- 可持续开发 : 敏捷流程倡导可持续开发。项目发起人、开发人员和用户应该都能够始终保持步调稳定。
- 可工作的软件 : 可用的软件是衡量进度的首要指标。
- 面对面沟通 : 无论团队内外,传递信息效果最好且效率最高的方式是面对面交谈。
- 激发和信任 : 要善于激励项目人员,为他们提供所需的环境和支持,信任他们所开展的工作。
- 跨职能合作 : 业务人员与开发人员必须相互协作,项目中的每一天都不例外。
- 短周期交付 : 采用较短的项目周期(从几周到几个月不等),不断地交付可工作的软件。
- 拥抱变化 :即使在项目开发后期也欢迎需求变更。敏捷流程要善于利用需求变更,为客户创造竞争优势。
八、5Y
1、5Y:
敏捷常用的解决问题技巧,首次出现在:(ACP --- 作业三 --- 42-以下哪一个是敏捷常用的解决问题的技巧 )
2、5Y 内容如下:
沉没成本谬误;
持不同意见的人;
保持善良,开放;
提问探究性问题;
积极聆听
九、常见错误答案关键词
1、加班、施压、全部、所有、忽略、紧迫、超出期望(项目百分百原则)、竞争、警告
十、知识分享
1、敏捷知识分享,标准实践如下:
跨职能团队,
自主管理和自我约束团队,
协作,
每日站立会议,
迭代/冲刺计划,
发布计划,
结对编程
项目回顾/反思
现场客户支持
十一、ATDD 验收测试驱动开发
1、ATDD 英文全称:
Acceptance Test Driven Development,也就是常常听到的 验收测试驱动开发。
(首次出现在:作业六--第八题)
2、4 个步骤可简记为4个Ds:
1)Discuss 讨论
2)Distill 提取
3)Develop 开发
4)Demo 示范
3、要实施ATDD,您可以按照以下步骤进行操作(by : GPT)
1. 与产品所有者和利益相关者合作,定义功能或用户故事的验收标准。【讨论】
2. 使用测试框架(如Cucumber或Behave)编写基于验收标准的自动化验收测试。 【提取】
3. 运行验收测试以确保它们失败,表示尚未实现该功能或用户故事。
4. 编写代码以实现该功能或用户故事。 【开发】
5. 再次运行验收测试以确保它们通过,表示代码符合验收标准。 【示范】
十二、Scrum 的几个会议
1、产品待办事项梳理会
-
-
- 时长:没找到具体时长 .
- 参会人员: PO + SM + dev + ( 相关方参加?)
- 主要内容: 分解用户故事, 粗略估算时长
-
2、冲刺(迭代)计划会
-
-
- 时长:4至8小时 (迭代时长2周
- 参会人员: PO + SM + dev + 相关方
- 主要内容: 选取用户故事 ; 确定迭代目标 ;最终 DOD ; 创建任务版 ; 风险分析(定性、定量)
-
3、每日站会
-
-
- 时长:15 分钟
- 参会人员: PO + SM + dev
- 主要内容:昨天干嘛 ; 今天干嘛 ; 遇到的问题 (跟踪风险)
- 作用: 同步进度,反馈问题 。 ( 站会不讨论问题)
-
4、冲刺(迭代)评审会
-
-
- 时长: 4至8小时 (迭代时长2周
- 参会人员: PO + SM + dev + 相关方
- 主要内容: 邀请客户 演示迭代成果
- 作用: 评审 可用的产品而非文档,收集客户反馈意见,为后续迭代调整
-
5、冲刺(迭代)回顾会
-
-
- 时长:1-2小时 , 一般下午开 比较好
- 参会人员: SM + dev (参考:敏捷实施路线图-单团队单迭代 - 光环ACP MAX)
- 主要内容: 哪些工作做的好 ; 哪些做的不好 ; 哪些需要改进
- 作用: 经验教训总结
-
参考资料: 敏捷SCRUM核心要点“3355”
十三、敏捷反馈技术包括
1、反馈技术如下9个:
样板
模拟
演示
评价
结对编程
单元测试
持续整合
每日站立会议
冲刺计划
十四、风险燃尽图、风险燃起图
1、风险燃尽图 定义:
记录随着时间风险严重度情况的图表
2、相关介绍(by GPT):
风险燃尽图(Risk Burn-Down Chart)是敏捷开发中常用的一种风险管理工具。它是一个可视化的图表,
用于跟踪项目中的风险和问题,并显示它们的状态和进展情况。
与风险燃尽图类似,风险燃起图(Risk Burn-Up Chart)也是一种风险管理工具,用于跟踪项目中的风险
和问题。与风险燃尽图不同的是,风险燃起图显示的是风险或问题的数量或严重程度随时间的变化情况。
风险燃起图通常由两个轴组成:时间轴和风险轴。时间轴表示项目的时间线,而风险轴表示项目中的风险
和问题。每个风险或问题都在风险轴上表示为一个点或条形,其高度或数量表示该风险或问题的严重程度
或数量。随着时间的推移,点或条形的高度或数量会增加或减少,表示该风险或问题的状态和进展情况。
风险燃起图可以帮助团队识别和跟踪项目中的风险和问题,并确保它们得到及时解决。通过使用风险燃起图,
团队可以更好地了解项目的状态和进展情况,并采取必要的措施来确保项目的成功。
总之,风险燃起图是敏捷开发中一种非常有用的风险管理工具,可以帮助团队识别和跟踪项目中的风险和问
题,并确保它们得到及时解决。如果您有任何进一步的问题或疑虑,请告诉我,我会尽力帮助您。
3、相关的考试题目
风险燃尽图的定义是
A.记录随着时间风险影响力情况的图表
B.记录随着时间风险管理情况的图表
C.记录随着时间风险发生概率情况的图表
D.记录随着时间风险严重度情况的图表
干系人能够通过基于风险的燃起图( burn up chart ) 查阅到的信息是?
A.在发布中到目前为止已查明的缺陷
B.在一个迭代中待完成故事点数量
C. 在发布中剩余用户故事待分解数量
D.最可能在一个项目中被完成的故事点的数量
干系人可以在基于风险的燃尽图中,查阅到什么信息?
A.在一次迭代中仍要完成的故事点数量
B. 在一次发布中仍要分解的故事点数量
C.在发布中识别的剩余缺陷数量
D.最坏情况下项目中将完成的故事点数