前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >PMI Agile Certified Practitioner (PMI-ACP)7A备考心得

PMI Agile Certified Practitioner (PMI-ACP)7A备考心得

作者头像
freesan44
发布2022-10-08 09:19:47
6720
发布2022-10-08 09:19:47
举报
文章被收录于专栏:freesan44freesan44

ACP证书

前提

考完PMP之后,想对项目管理有更好的了解,就用备考PMI-ACP,一次通过,以下是备考心得:

心得

学习技巧

  1. 时间盒子汇总:

时间盒子

  1. Product Backlog 产品待办事项。由 PO 负责维护,包括增、删及优先级排序。 Sprint Backlog 冲刺待办事项。本次冲刺内规划要完成的内容,源于 Product Backlog, 由 团队一起选择,并定义 “完成” 的标准。 Incremental 可交付产品增量。冲刺结束后可对外发布的可工作的产品功能/软件,需在 Sprint Review Meeting 上进行演示。
  2. Scrum 团队 3 个核心角色:Product Owner、Dev Team、Scrum Master. Dev Team: 自组织的、跨功能、无头衔、通才而非专才、责任归属团队。 PO: 只有一个人扮演 PO 角色。负责产品待开发项优先级排序、澄清需求。确保开发团队的 价值,对最终产品负责、对风险负责,与干系人沟通。 Scrum Master: 确保 Scrum 理论、规则和实务,推动 Scrum 相关知识、负责移除团队障碍、 仆人式领导、教导/引导团队提高产品价值、与其它 Scrum team 合作 (Scrum of Scrums).
  3. Scrum 5 种事件: Sprint 冲刺: 时间盒固定,长度 2~4 周 。 Sprint Planning Meeting 冲刺计划。确定 Sprint 目标,在每次迭代冲刺前举行。最长 8 小时。 Daily Scrum Meeting 每日站会。昨天做了什么,今天计划做什么,遇到什么阻碍。15 分钟。 Sprint Review Meeting 冲刺评审。团队全体参与、邀请相关干系人参与。展示迭代产品,以获得客户反馈, 2~4 小时。PO 可以拒绝接收成果。 Sprint Retrospective Meeting 冲刺回顾。每个冲刺结束时举行,团队一起复盘本冲刺过程,总结经验与教训,形成切实可行的改进清单。只有开发团队内部参加,PO/SM/干系人无需参加,若参加,则不能参与讨论,可最后发言。2~4 小时。
  4. XP 核心实践:1) 完整的团队 2) 规划游戏(三个阶段:探测→计划→调整) 3) 小型发布 4) 客户测试 5) 共享代码 6) 编码标准 7) 可持续的进度 8) 隐喻 9) 持续集成 10) 测试先行/测试 驱动开发 11) 重构 12) 简单设计 13) 结对编程
  5. FDD 特性驱动开发:为产品开发一个整体的模型,先构建产品特性列表和工作计划,开发团队再构建和开发。
  6. DSDM 动态系统开发:也称业务中心框架开发方法。倡导以业务为核心,快速而有效地进行系统开发。 基本观点:80%/20%法则。MoSCoW 基于客户价值的优先级分析。
  7. Lean 精益开发:7 大价值观:1) 消除浪费 2) 构建质量 (常用技术:重构、持续集成和单元测试) 3) 创建知识 4) 推迟决策 5) 快速交付 6) 尊重 7) 整体优化。
  8. Kanban 看板开发:是一个拉式系统,专门用于知识型工作。1) 可视化价值流 2) 限制 WIP 3) 度量和管理流动 4) 协同改进 5) 显示化流程规则。 看板没有时间盒的限定,没有迭代的概念,强调持续交付。当一个工作完成时,就会启动拉 式机制。
  9. 敏捷宣言: 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划
  10. 十二条敏捷原则: 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。 欢迎需求变化,即使在开发后期也一样。善于掌控变化,帮助客户获得竞争优势。 经常地交付可工作的软件,相隔几星期或几个月,倾向于采取较短的周期。 业务人员和开发人员必须每天在一起协作工作。 激发个体的斗志,以他们为核心搭建项目。提供他们所需的环境和支持,相信他们能够达成目标。 在团队内部,传递信息效果最高效的方式是面对面的交谈。 可工作的软件是进度的首要度量标准。 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。 对技术精益求精,对设计不断完善,将提高敏捷能力。 以简洁为本,极力减少不必要工作量。 最好的架构、需求和设计出自于自组织的团队。 团队定期地反省如何能提高成效,并由此调整团队的行为。
  11. TDD 测试驱动开发: 测试驱动开发(Test-Driven Development, TDD), TDD 的四个步聚过程 1.在开发某个功能代码之前先编写测试 2.核对和确认测试,运行所有测试,并且全部通过 3.编写产品代码,接着测试 4.重构产品代码,以消除重复设计,优化设计结构
  12. ATDD 验收驱动开发 ATDD 验收测试驱动开发使测试的焦点从代码本身转向业务需求,包含 4 个步聚: 1.讨论 Discussion, 讨论需求。 2.提取 Distill, 提取(提练)测试 3.开发 Development,开发代码并连接测试 4.示范 Demo,示范(演示)软件
  13. 敏捷沟通:当然敏捷的第六项原则是“开发团队内部和之间最有效和最有力的传达信息的方式是面对面对话。”从这层意思上说,敏捷倾向于和鼓励所有干系人和团队成员的协作,因为沟通的最好方式是面对面对话,并且反过来,促进知识分享。基本上成千的决策都是在项目的过程中决定的,其中的许多决策是为了应对团队无可避免面临的问题的。因此适当地熟悉问题解决的策略,工具和技能对敏捷团队来说是至关重要的。
  14. 史诗故事:是一个大型故事,可能横跨几个迭代周期。它也被称为一种能力。
  15. 用户故事:意思是来描述用户渴望得到的功能。一个好的用户故事包括三个要素: 1.角色:谁要使用这个功能。 2.活动:需要完成什么样的功能或目标。 3.商业价值:为什么需要这个功能,这个功能带来什么样的价值。
  16. 产品待办事项:是一列所有需要在迭代中开发的产品特性综合性清单,它是不断变化的,以适应客户需求。随着项目发展,因为客户逐渐理解产品需要更完备,所以待办事项中的项目特性更明确。
  17. 理想时间(Ideal Time) :代表时间量,即不受会议、个人生活,非工作日或其他拖延,障碍和分心的干扰的情况下,对待办事项中用户故事的估算。
  18. 时间盒:是管理某个时间被限定的项目的一种方法。只有在规定时间内通过验收的功能包含在时间盒内。时间盒法约束了 团队,尽管不是以一种特别消极的方式。它只是规定时间上不能灵活变化,但是范围可以变化。这种情况下迭代和版本 在进度上都不会灵活。
  19. 速率/速度(Velocity):是指对每一迭代团队完成的用户故事点或故事数量的衡量。衡量团队速度的指标(一轮迭代完成 的故事点数),用于在迭代计划中创建项目进度表。一个敏捷团队可根据稍前的速度记录来估算下一个迭代可完成的用 户故事点数量。
  20. 故事点:表示开发一个用户故事的相对工作量。每一个故事点表示一个固定的开发工作量值。当估算敏捷团队时,必须考 虑复杂度,工作量,风险和依存关系。** 故事点是开发工作的固定单元,用在相对测量用户故事中,以达到估算参与开 发的工作量的目的。故事点并不以时间为基础,而以意义为基础。故事点代表成本,价值点代表利益。
  21. 信息发射器/信息发射源(Information Radiator ) :显示项目进度和状态的高度可见的图表和数字项。敏捷项目中,典型的信息发射器包括:看板,项目燃尽图,任务板,燃起图、缺陷图表。信息发射源的对立面是信息冷冻机。信息冷冻机是一种图表或组件,你必须开发或探索才能理解里边的内容。它意味着不透明。** 敏捷团队和外部干系人沟通的主要方式是信息发射源。
  22. 燃尽图(Burn down chart):也译成燃烧图,是一个常用的来展示迭代进度的信息发射源。它记录两项序列:剩余的实际工作和剩余的理想/预估的工作。竖轴是工作单元(常是故事点或时间),横轴是迭代持续时长(常是日期数 字)。理想/预估的工作序列是条向下倾斜的直线,由需完成工作价值(例如 20 故事点)的竖轴出发,延长至横轴上 迭代的最后一天(即 0 故事点)。实际工作序列每日更新,取决于敏捷团队的生产率和任务的复杂性。实际工作序列 常常是易变的,并非直线,它随着项目团队干涉开发流程而消长(往往是非线性的,反映开发的起伏)。燃尽图的作用 是:管理范围和进程。

考试技巧

  1. 站在出题者角度判断其想考什么?换位思考,独特的知识点
  2. US/需求变化 听 PO 的、进入产品待办事宜列表排优先级
  3. 题干:一年、长期、高管要看 答案:release、产品路线图、粗略。
  4. 反敏捷的观点(敏捷无用、加快迭代速率),这是思想认识问题。 选项:思想教育、 培训
  5. 频繁的与客户交流 大概率正确答案
  6. 题干:机密、敏感、隐私 选项:安全、合规
  7. 题干:人忙不开、技术孤岛、人员离职等 选项:跨技术、通才
  8. 题干:无活力,原因很可能没有目标感。 选项:给目标、远景、使命,不能给钱、 团队建设。高级人员很消极:挑战性任务
  9. 题干:遇到困难、问题、投诉、BUG、沮丧 选项:先调查、开会、研究原因,然后再 给solution。 错误选项:直接给solution,“要求”
  10. 站立会:暴露问题,不讨论和解决问题;SM 少说话
  11. 新产品、新技术、陌生 选项:刺探、探索性测试
  12. 要求加资源加人、多给钱、缩小范围、延长工期、加班、请病人帮忙,都是错的
  13. 分布式团队 选项:VOIP、共享白板、电子看板、VC
  14. 浪费 选项:精益/价值流
  15. 变化 选项:分析影响
  16. 人员交流不便 选项:主张人员集中,团队驻扎,主张面对面直接交流
  17. 频繁交流、交付—频繁客户反馈—早发现缺陷—高质量交付
  18. 不作跨团队速率比较
  19. 仅 错误选项
  20. 满意度 选项:卡诺分析
  21. 斐波拉切数列 选项:敏捷扑克
  22. SM 与团队合作 好于 要求、建议;“与团队合作”大概率正确
  23. 说服业务支持敏捷 选项:做一个样板工程,用成功案例来说话
  24. 找(让)行政领导、管理层出面解决问题,得到管理层批准,领导替团队做了许多决策, 错误概率大;但提到与经理合作,正确概率大。自组织商量、脑风暴解决正确概率大
  25. WBS/甘特图: 错误概率大
  26. 题干出现:钱、贵、价值、ROI,选项:选 PO;出现排需求优先级,选 PO;出现“排优 先级”,该选项正确概率较大
  27. 题干提到了供应商的问题,答案要出现与供应商相关的解决方案,正确概率大
  28. 一对一 错误概率大

结语

祝大家7A通过考试!

成绩单

成绩单

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2022-09-30,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前提
  • 心得
    • 学习技巧
      • 考试技巧
      • 结语
      相关产品与服务
      腾讯云 BI
      腾讯云 BI(Business Intelligence,BI)提供从数据源接入、数据建模到数据可视化分析全流程的BI能力,帮助经营者快速获取决策数据依据。系统采用敏捷自助式设计,使用者仅需通过简单拖拽即可完成原本复杂的报表开发过程,并支持报表的分享、推送等企业协作场景。
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档