6.1 开发方法和生命周期
预测型、增量型、迭代型、敏捷型或混合型。
预测型生命周期：
这是一种更为传统的方法，提前进行大量的计划工作 ，然后一次性执行;执行是一个连续的过程
采用迭代型方法的生命周期。
这种方法允许对未完成的工作进行反馈，从而改进和修改该工作。
** 采用增量型方法的生命周期：**
这种方法向客户提供各个已完成的，可能立即使用的可交付物。
采用敏捷型方法的生命周期：
这种方法既有迭代，也有增量，便于完善工作，频繁交付价值
6.2 敏捷相关的概念
1.灵魂
敏捷宣言和十二大原则
2.角色
团队、PO、团队促进者、PMO
3.方法
Scrum、看板、xp
4.过渡
6.2.1 角色-跨职能团队成员(team)
- 一般情况人数在3-9个左右
- 团队成员跨职能(包括开发人员、测试人员、用户界面设计师等 )鼓励成为T型人才，最好是全栈式工程师
- 敏捷团队成员需要全职，不能随意发生变化(至少迭代内)，否则影响团队速度
- 在团队章程/迭代代办列表约束内有权力做任何工作形式的决策来确保达到迭代/冲刺的目标
- 承诺和责任而不是肆无忌惮的高度的自组织能力(重点强调尊重.自由散漫)需要向Product
Owner演示产品功能 - 团队需要定义DoD(针对所有任务的)
6.2.2 DoD/AC/DoR的区别和联系
在敏捷项目管理中，常用Definition of Done“完成的定义”来表示工作是否已完成，不同的活动有不同的完成定义(迭代DoD发布DoD、每日DoD、用户故事DoD等)。
DoD是针对于所有需求，任务，迭代，交付定义的(整体性）而验收标准AC(Accept criteria )是针对每个需求定义的(局部性 )
DoR(Definition Of Ready)是某一个阶段正常开启的先决条件。而DoD则是某阶段产物完成的标准和原则
6.2.3 角色-产品负责人(Product Owner)
- 决定发布的日期和发布的内容
- 作为客户的代言人
- 确定需求优先级
6.2.4 角色-团队促进者( Team Facilitator )
- 此角色在不同的敏捷模型中可能被称为项目经理、Scrum Master、Team Facilitator等
- 促动者倡导仆人式领导(servant leadership)
- 促动者更像是守望者，不是做决策，而是提供支持。对流程负责，对内容不负责
- 和Product owner及团队紧密地工作在一起，他可以及时地为团队成员提供帮助
- 解决团队开发中的障碍(海通障碍、流程障碍等）
- 做为团队和外部的接口，处理外界对团队成员的干扰(信息发射源、看板解决信息不对称的问题;新的需求转移给PO解决新需求影响团队的问题)
- 保证开发过程按计划进行，组织各种会议(如Scrum中的:站立会(Daily Scrum),冲刺回顾会、迭代规划会等
6.2.3.1 仆人式(服务型)领导为团队赋权
- 提升自我意识(不强行决策与干预)
- 倾听(了解根因与现状，了解团队的情绪)
- 为团队服务(解决团以现有的障碍，而不是制造麻烦）
- 帮助他人成长(培训与辅导）
- 引导与控制（让团队说话，在流程上控制好，而不是内容)
- 促进安全、尊重与信任(先私下沟通，鼓励团队自组织)
- 促进他人精力和才智提升(减少其他人对团队的影响)
6.3 敏捷相关的方法
- Scrum
Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务产品负责人代表利益所有者，开发团队包括了所有开发人员
Sprints(冲刺)，Scrum的项目过程由一系列的Sprint组成，长度一般控制在2-4周，通过固定的周期保持良好的节奏，产品的设计、开发、测试都在Sprint期间完成，Sprint结束时交付可以工作的软件，在Sprint过程中不允许发生变更。
Scrum of scrums，Scrum of Scrums(SoS)也称为“meta Scrum”，是由两个或多个Scrum 团队而不是一个大型 Scrum 团队所使用的一种技术。 - DSDM( Dynamic Systems Development Method )
6.4 混合型生命周期存在的意义和价值
6.4 敏捷转型成功的策略与方法
6.5 难点题
过去曾合作过几个项目的敏捷团队成员正在进行一个新的软件开发项目。他们正在使用故事点来估计完成新项目的用户故事所需的努力程度。以下哪种方法是该团队最可能使用的用来估计第一个用户故事的方法？
A. 梳理产品待办列表
B. 玩规划扑克游戏
C. 选择一个中等大小的用户故事
D. 使用亲和估算技术
解析：
故事点是用作一种计量单位,用来表达或定义一个用户故事的整体大小。其中更重要的是赋予用户故事的相对值,而不是原始值。例如,一个被赋予价值6的用户故事应该是一个被赋予价值12的故事的一半,是一个被赋予价值2的故事的三倍。给一个用户故事分配好故事点后,只要用其他用户故事与估算好的故事点进行比较,就可以为它们分配价值。在开始的时候,团队不知道哪个是最大的故事,哪个是最小的故事,解决方案也不需要是唯一的。由于团队成员在过去也合作过一些项目,他们应该有能力在新的用户故事中选择一个有可能属于中等大小的故事。亲和估算和规划扑克是真正有助于估算用户故事的技术,但它们对估算第一个用户故事没有帮助。因此,在给定的场景下,选择一个中等大小的用户故事是最好的选择。
一个制作新产品的大型敏捷项目已经启动。几个团队正在同时开展新功能和增强功能方面的工作。项目经理面临严重的扩展挑战,以确保不同功能的创建并协作。
若要解决这种情况,项目经理应该做什么？
A. 将工作划分为多个版本。
B. 执行充分的前期规划以管理依赖关系。
C. 通过大量协作工作进行交付。
D. 使用相同的团队进行开发、集成和测试。
解析：
“在许多情况下,不断涌现的需求往往导致真实的业务需求存在与最初所述的业务需求之间存在差异。因此,敏捷方法有目的地构建和审查原型,并通过多次发布版本来明确需求。这样一来,范围会在整个项目期间被定义和再定义。”题目关键词为“大型敏捷项目”,项目经理可通过划分版本的方式,管理功能和范围,A符合题意。B不适用于敏捷项目；C没有解决功能变化的问题；D与题干多个团队的表述矛盾。
你的一个关键相关方对上一次迭代的演示（demo）质量感到不满。在回顾会上,其中一个开发人员在整个会议中公开指责其他团队成员,以至于伤害了人们的感情。你出面提醒团队,回顾会是让他们从之前的工作中学习,并做出小的改进的时候。两周后,在下一次回顾会上,同一个团队成员又重复了同样的 指责 行为。以下哪项是你可以改进的团队发展行为？
A. 建立高的团队绩效
B. 设置作战室war room
C.提供延伸目标stretch objectives
D.鼓励合作解决问题
本系列文章记录了PMP第7版核心知识点，持续更新，有兴趣的关注博主以待后续。
上一章 ：第五章 团队绩效域