新考纲 PMP 备考精讲

新考纲：

Domain	占比	折合题目数（约）
People 人	42%	76
Process 流程	50%	90
Bussiness Environment 商业环境	8%	14
Total 总计	100%	180

项目管理方式	占比	折合题目数（约）
预测型项目管理方式	50%	90
敏捷和混合型项目管理方式	50%	90
共计	100%	180

单元一：适应型环境中的 5 大过程组

适应型项目：启动过程组：

        1、频繁回顾和重新确认项目章程。

        2、基于迭代敏捷方法中，在每个迭代都需要执行启动过程组。

        3、确保项目在最新的制约因素下朝最新的目标推进。

        4、根据经验丰富的客户代表，持续表达新的需求，不断针对新形成的交付结果提出反馈。

适应型项目：规划过程组：

        1、适应型和预测型的主要区别：做多少规划工作、什么时候做。

        2、基于初始需求制定高层级的计划，在每个特定规划周期再细化需求。

        3、让团队成员和相关方参与计划，依据更多的信息、判断和智慧来降低不确定性。

适应型项目：执行过程组：

        1、预测型：由项目经理确定工作内容、排定工作顺序、分配工作任务。

        2、适应型：项目经理阐明高层级的目标，授予团队成员以最有利于实现目标的方式自行安排具体工作。激发团队以其专有知识完成任务。

        3、对于刚刚进入敏捷环境的团队，在前期可能需要辅导和分配工作，直到他们具备自组织能力。

适应型项目：监控过程组：

        1、通过维护未完项清单，对进展和绩效进行管理。

        2、未完项清单按照优先级顺序，既包括需求，也包括变更。

        3、基于已经完成迭代的实际进展，来预测项目的进度、成本和范围。

        4、预测信息应该及时与相关方分享，以便一起应对问题、推动改善，以及管理相关方期望。

适应型项目：收尾过程组：

        1、在每个项目或阶段、迭代结束的时候需要执行收尾工作。

        2、适应型项目对需求进行优先级排序，首先实现最具商业价值的工作。

        3、即便提前终止项目，也已经创造和交付了一部分商业价值。

        4、预测型项目：提前终止意味着几乎所有的投入成为沉没成本。

单元二：敏捷概述

一、工作的不确定程度：

项目工作	特点	项目管理方法
可确定的工作	有比较明确的流程，执行的不确定性和风险通常较低	传统方法
高度不确定的工作	变化快，复杂性和风险高；需要在短时间内探讨可行性，根据评估和反馈结果快速调整	敏捷方法

二、敏捷思维模式：

《敏捷宣言》的四大价值观：

        我们正在通过亲自开发和帮助他人开发，发现开发软件的更好方法。通过这项工作，我们开始重视：

        1、个体及互动而不是过程和工具。

        2、可用的软件而不是完整详尽的文档

        3、客户合作而不是合同谈判

        4、应对变更而不是遵循计划

《敏捷宣言》的十二大原则：

        1、我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求。

        2、欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获取竞争优势。

        3、要经常交付可用的软件，周期从几周到几个月不等，且越短越好。

        4、项目实施过程中，业务人员与开发人员必须始通力合作。

        5、要善于激励开发人员，给予他们所需的环境和支持，并相信他们能够完成任务。

        6、无论是对开发团队还是团队内部，信息传递最有效的方法都是面对面的交谈。

        7、可用的软件是衡量进度的首要衡量目标。

        8、敏捷过程提倡可持续的开发，项目发起人、开发人员和用户应该能够始终保持步调稳定。

        9、对技术的精益求精以及对设计的不断完善将提高敏捷性。

        10、简洁，即尽最大可能减少不必要的工作，这是一门艺术。

        11、最佳的架构、需求和设计将出自于自组织团队。

        12、团队要定期反省怎样做才能更有效，并相应地调整团队的行为。

敏捷思维：可以扩展到非软件行业：

敏捷方法：符合《敏捷宣言》价值观和原则的方法：

 三、Sceum 框架

         1、产品的所有需求，都在左面的 Product Backlog （产品代办列表、产品未完项列表）里面，它是一个动态的，且有优先顺序的表格，简称 PB 。

        2、团队成员从 PB 里面领完任务之后，放到我们此次迭代的 Sprint Backlog（冲刺列表）里面。

        3、在我们此次的迭代过程中，要执行每日站会（昨天完成了什么，今天计划干什么，遇到了什么问题），等到此次迭代快要完成的时候再抽出一点时间帮助产品经理梳理一下 PB ，看看哪些需求是不是太大了，排下顺序等。

        4、等到我们这次迭代完成之后，我们就完成了此次的产品增量，需要请我们的产品经理和相关方 review 一下，提建议和反馈，若有需求和变更，则直接更新到待办列表里面。

        5、最后还要开一个 retrospective （回顾会议），则这次迭代就结束了。

3355：

践行敏捷的两种策略：

        策略一：在正规的敏捷方法中选择适合自己项目的方法，深刻领会其精髓，并根据情况进行裁剪。

        策略二：在敏捷章程和原则的指导下，采用最佳敏捷实践，形成自己独特的敏捷方法。

三、敏捷、精益与看板方法：

        精益生产（Lean Production，简称 LP）是美国麻省理工学院数位国际汽车计划组织的专家对日本 “ 丰田（Just In Time）生产方式 ” 的赞誉之称。

看板方法：

        1、原地出发：不改变组织结构。

        2、渐进变革，破坏性小，实施阻力小且切实有效。

        3、里面 5 的意思是在我这个条里面最多只能有 5 个工作，要是少了我自己会去取。

四、斯泰西复杂度模型

什么情况下用自适应方法

        1、适应型方法是什么？迭代、增量、敏捷、变更驱动、非线性。

        2、最终的目标难以描述。

        3、变更速度极快。

        4、需要研究和开发。

        5、具有风险和不确定性。

单元三：生命周期选择：

四种生命周期：

特征
方法	需求	活动	交付	目标
预测型	固定	整个项目只执行一次	一次交付	管理成本
迭代型	动态	反复执行直至修正	一次交付	解决方案的正确性
增量型	动态	对给定的增量执行一次	分次较小规模交付	速度
敏捷型	动态	反复执行直至修正	频繁小规模交付	通过频繁小规模交付和反馈实现客户的价值

每个项目在连续区间寻找最合适的方法：

预测型生命周期的特征：

        1、其他的名字：计划驱动型、瀑布型、系列式、预测型。

        2、确定的需求、稳定的团队、低风险。

        3、限制潜在变更，走严格的变更控制流程。

        4、项目结束时交付价值。

迭代型生命周期的特征：

        1、通过连续的原型或概念验证来改进产品。

        2、根据反馈，团队在下一个迭代中可能要重复某些工作（返工）。

        3、适用场景：相关方对产品需求达不成共识、复杂度高、需求变更频繁时使用。

        4、缺点：需要更长的时间。不断学习，不断优化。

增量型生命周期的特征：

        1、好处：让客户尽快（几天/几周）获取价值。有些企业无法等待所有的项目完成，愿意接受整个方案中的一部分，随后逐步增量交付。

        2、好处：可以根据前面增量交付学习到的经验教训，优化后续流程。

        3、根据客户反馈，调整后续工作的内容，实现最大价值。

        4、建造 MVP 、展示度量、一个不断学习的过程、基于学习之后的水平继续建造。

敏捷生命周期的特征：

        1、结合了迭代和增量的特征。

        2、获得早期反馈，为客户提供可见性，及时调整，加大了客户对产品的控制。

        3、尽早交付价值，客户早受益。

混合生命周期的特征：

        1、根据项目需要，综合采用预测、迭代、增量、敏捷等组合方法。

        2、采用什么方法并不重要，要回答的问题是：“我们怎么做，项目才能最成功？”。

        3、为了向真正的敏捷过渡，我们可能需要经过 “ 混合模式 ” 时期。

        4、真正的敏捷并未某个专有的敏捷方法，而是适合企业的定制方式。

单元四：创建敏捷环境

仆人式领导 Servant Leader

        1、为团队赋权。

        2、通过对团队服务来领导团队。

        3、理解和关注团队成员的需求和发展。

        4、使团队达到高绩效。

仆人式领导的关注点：

        1、目的：促进全体人员一起为项目目的协同工作。

        2、人员：鼓励每个人在项目中做出贡献。

        3、过程：没有完美的过程或流程，关注结果。通过不断思考，优化过程。

仆人式领导风格： 

敏捷环境中的项目经理：

        1、需要项目经理，项目经理能够创造重要的价值。

        2、需要采用仆人式领导风格。

敏捷团队：

        1、包含三个角色：跨职能团队成员、产品负责人、团队促进者。

        2、在刚开始实施敏捷的时，可能需要从外部聘请团队促进者。

敏捷团队特点：

        1、3-9 人组成。

        2、集中办公。

        3、100% 专职人员；限制 WIP 在制品，一个人不要同时接多个工作。

        4、自我管理，团队决定下一个阶段做什么工作。

        5、和仆人式领导一起成长。

        6、团队有通才和专才。

        7、团队集体拥有完成项目所需的全部技能 - 跨职能团队。

团队结构：

        1、主张：集中办公。

        2、其他方式包括分布式团队和分散式团队。

                a、分布式团队：不同地点，每个地方都有一个跨职能团队。

                b、分散式团队：一个跨职能团队，成员分散在不同的地方。

虚拟团队：

        1、有一个开例会和张贴图标的集中场所。

        2、建立虚拟的共享空间，比如鱼缸窗口（一直开着屏幕）和远程远程结对（共享屏幕）。

专职的小组成员：

        1、主张：100% 投入的专职成员。

        2、其他方式：只投入 25% 或 50% ，多任务切换会损失 20 - 40% 的效率。随着任务的增加，损耗呈指数级增长。

通才型专家：

        1、“ I ” 型人才是指在一个专业上很专，在其他专业上不怎么行的人。

        2、“ T ” 型人才是指在一个专业上很深，对其他专业也有一定掌握的，在需要的时候能帮得上忙的人。

        3、一个团队拥有 T 型人才多一些，可以使团队的协作更加灵活。

        4、采用敏捷方法的团队，希望团队人员大部分是 T 型人才。

克服组织孤岛：

        组织孤岛的意思是部门各自为政、成员向职能经理报告、职能经理评估成员绩效、职能经理关注团队指标。

        要如何克服这种情况呢？需要仆人式领导去教育、说服、建立关系、寻求协作。此时的项目经理更像是政治家、外交家、游说家。

单元五：在敏捷环境中交付

项目章程：

        1、项目愿景：我们为什么要做这个项目？

        2、谁会从中受益？如何受益？

        3、达到哪些条件表示项目成功？

        4、人们如何合作？预期的工作流是什么？

        5、仆人式领导引导章程的制定过程，团队一起参与制定。

团队章程：

        1、团队价值观（比如：可持续的开发速度）。

        2、工作协议（比如：关于 DoR、DoD的定义、时间盒、WIP 等）。

        3、基本规则（比如：会议规则）。

        4、团队规范（比如：时间观念、沟通方式等）。

        5、团队章程是一种社会契约，规定人们之间互动的模式。这种模式一定要符合敏捷环境，让每人尽情发挥能力。

常见敏捷实践：

        1、回顾

        2、代办事项列表编制

        3、代办事项列表细化

        4、每日站会

        5、展示 / 评审

        6、规划基于迭代的敏捷

        7、其他

一、回顾：

        1、敏捷原则：团队要定期反省如何能够做到更加有效，并相应的调整团队的行为。

        2、回顾的时间点：一个增量完成、一个迭代 / 冲刺、出现问题时、其他里程碑。

        3、回顾的关注：人、关系、流程、工具等；主观数据、客观数据等。

        4、回顾的输出：找出改进项目，并加以排序，确实要落实的事项，确定如何衡量改进效果。

二、代办事项列表编制：

        1、所有工作的有序列表。

        2、以故事形式呈现。

        3、渐进明细。

        4、产品负责人负责。

        5、产品负责人编制产品路线图，显示预期的交付成果时间顺序。路线图可以修改。

三、待办事项列表的细化：

        1、在迭代中期，产品经理和团队开会进行细化，为下一次迭代做准备。

        2、基于流程的敏捷：及时细化。

        3、基于迭代的敏捷：一个小时。

        4、需要鼓励多方协作一起讨论，故事足够细，等于小于 8 小时。

四、每日站会：

        1、做出承诺，发现问题，保证顺畅。

        2、15 分钟。

        3、看板或任务板

        4、任何人都可以当主持人。

        5、主要讨论：我完成了什么？我计划完成什么？我遇到了什么障碍？

        6、基于流程的敏捷：团队从右到左对看板进行评估。回答问题：

                a、我们需要做什么来推动某个工作？

                b、有人在做看板上没有的工作吗？

                c、作为一个团队，我们需要做什么？

                d、当前工作流程中的瓶颈是什么？

 站会的反模式：

        1、站会变成了状态报告会议。

        2、问题变得明显时，才说出来。

        3、在站会上解决问题（应该放在停车场）

        4、重在承诺，而不是状态报告。

五、展示 / 评估：

        1、展示后，产品负责人接受或拒绝故事。

        2、基于迭代的敏捷：发生在迭代结束时。

        3、基于流程的敏捷：完成一个连贯的功能组合时。

        4、频率：每两周至少展示一次。

六、规划基于迭代的敏捷：

        1、工作：待办事项列表中的故事。

        2、资源：团队。

        3、应在团队能力和工作量之中找到平衡。

        4、敏捷团队：持续规划。

敏捷团队的衡量指标：

        1、替代原则（不好的）：是指此次任务完成了多少，比如：百分之九十。

        2、实证指标 / 经验指标：只需要说完成具体的数据就好了，不需要说完成了百分之多少。

        3、西瓜项目（不好的）：表面都是绿色的，里面是红色的，实际上一点都没完成。

        4、0 /100 原则：为了避免西瓜项目，使用 0 / 100 原则。没有完成任务，绩效就是 0 。

指标一：燃尽图

指标二：燃起图

指标三：功能图（燃起+燃尽）

指标四：看板面板

指标五：产品待办事项列表燃起图

指标六：敏捷中的挣值分析4条线

指标七：已完成功能的累计流量图

 

单元六：有关敏捷项目的组织因素

敏捷项目，如何签署合同？

        1、敏捷是否只适用于内部研发？客户项目也适合，但要修改合同签署的方式。

        2、如果给客户做项目，拥抱变更，随时调整需求，怎么控制成本和工期？内部项目也需要控制成本和工期。

敏捷合同怎么签？

 

单价法：

        1、按照功能（用户故事）。完成一组功能，支付一组功能的费用。

        2、按照人天。完成客户布置的工作，用了多少人天，就结算多少人天。

        3、激励措施：设定一个交付期限，提前交付，人天费率上浮。反之，下浮。

总价法：

        1、合同中确定总的工时数，或者预算。

        2、需求可以增加，可以修改，但是所花费的工时数或预算不能超过合同金额。

付款方式的改变：

        1、原来：按节点。首付、概要设计、详细设计、初步验收、终验。

        2、现在：按交付的功能。我用上功能，产生效益（价值），我给你付钱。

实施方式的改变：

        1、原来：合同中签订的范围要全部完成。

        2、现在：客户可以中途叫停。因为他认为已经完成的功能足够了，剩下的用不着了。（记得要一笔终止赔偿）

分包方式的改变：

        1、原来：设计一个包，采购一个包，开发一个包，安装一个包。

        2、现在：纵向切。一个包都有 MVP ，负责某个功能组的设计、采购、开发和安装，端到端。

敏捷合同总结：

        1、多层结构，把合同分成两部分。

        2、动态范围方案。

        3、固定时间和材料（不超过人工时）。

        4、总价增量（规定每个小交付包 / 功能组合的价格）。

        5、团队扩充。

        6、累进的时间和材料。

        7、注重价值交付。原来按里程碑付款，现在按交付方式增量付款。

        8、提前取消方案。

        9、支持全方位供应商。

        10、1 和 2 和 3 属于动态总价，4 和 5 和 6 属于动态单价，7 和 8 和 9 属于合同方式。