最近在着手准备ACP考试，仔细看了下相关的书籍，对每章知识点进行相应的整理，想着记录下来，后续如有更好的理解，再回头更新。
之后会按照以下目录进行梳理：
- 敏捷的理念
- 价值驱动交付
- 干系人管理
- 打造高绩效团队
- 适应性计划
- 发现与解决问题
- 持续改进
- 敏捷的实践
适应性计划
-
敏捷计划的概述
为什么需要适应性计划
良好的计划是成功的一半，良好的计划能够在实施过程中，不断理解和挖掘用户需求，确保产品是用户需要的，降低风险，减少不确定性；
类似于PMP中的滚动式规划，敏捷中计划更关注计划的过程，鼓励变更，所以敏捷的计划更具敏捷性。
敏捷计划和瀑布计划的区别- 追踪真实需求，重复初始计划；
敏捷计划：在前期对项目的愿景有一个初步讨论，之后敏捷用原型进行迭代，干系人可以基于原型进行调整，体现渐进明细的概念。
瀑布计划：在前期就需要对项目进行详细说明和反馈。 - 敏捷计划贯穿整个项目，不仅仅是前期工作；
敏捷计划：采用敏捷的初衷就是因为存在较多的变更，如果在前期规划过多，反而造成了资源的浪费，提倡在整个生命周期中都进行计划，以便针对细化的信息进行调整；
瀑布计划：强调前期计划的重要性，主要集中在范围规划，时间规划，成本规划，质量规划，人力资源规划，沟通规划，风险规划，采购、干系人、变更等计划上； - 敏捷是移动打靶，需要即使调整中期计划；
敏捷计划：目标是移动时，更加需要做大量的中期调整以保证目标达成，采用复杂的探测和适应系统来获取反馈并做出调整；
瀑布计划：目标是静止的，可以做更多的计划，从而向那个精致的目标努力前进。
- 追踪真实需求，重复初始计划；
-
敏捷计划的层次
分成5个层次，计划的层次体现来渐进明细的特点，最终目的是为了交付与原始设计对象一致的产品。
敏捷愿景：在敏捷的章程中记录，章程作为项目启动的第一个文档中，可以回答以下一些问题（5W1H）；- what： 到底是什么（愿景、目标、任务）
- why：为什么要做？是否有价值？商业论证；
- when： 什么时间开始，什么时间完成；
- who：哪些人会参与项目？干系人是哪些？
- how：我们如何达到项目目标的？
产品路线图：为PO所拥有，是产品需求的高层次概述，常用作特性优先级排序、特性归类和粗略时间框架确认的工具；勾画了多个版本的演变过程，是项目层面的粗粒度计划，关注目标而不是细节。
创建产品路线图步骤：- 确认需求：
- 需求分类或设定主题：
- 评估工作量：
- 评估粗略时间框架，粗略估算发布时间：
发布计划：有助于客户和敏捷团队决定项目一定的时间范围或阶段内应该开发的内容和产品理想的发布时间；
发布计划的制订步骤：- 确定满足的条件：有PO来筛选和确认
- 用户故事的估算：PO维护2-3个需要发布的清单，对这些清单的需求估算即可；
- 选择迭代周期：依靠资源和进度进行；
- 估算速率：依赖以往发布的速率来估算；
- 确认用户故事的优先级：
- 选择用户故事和发布日期：
故事地图：故事地图是一种组织需求的可视化方式，能够提供比传统需求列表更丰富的上下文，是一个用于展示发布计划的很有用的工具。
包含几个方面：骨干、行走的骨架和额外的特性（排序进入版本）；
迭代计划：一个迭代是较短的研发周期，主要是把优先级较高的需求纳入当前迭代的任务中；
制订迭代计划主要有两个方法：- 基于迭代速度的迭代计划：
- 调整用户故事优先级；
- 预测迭代速度；
- 识别迭代目标&选择用户故事；
- 细分实现用户故事的任务；
- 估算任务的理想天数，任务最好每天状态有更新；
- 基于团队承诺的迭代计划：
- 相对任务来说，对用户故事进行承诺更好，因为任务本身容易发生变化；
- 根据选择的用户故事的工作量，可以判断团队的工作负荷；
- 要注意迭代中所需技能的匹配情况；
每日站会计划：今天打算做什么可以被视为每日计划，反馈环为1天。
在敏捷方法中，不提倡一开始就将不那么明确的需求非常详细的提出。相反，一开始保持需求的“粗粒度”，可以在后续进展中逐渐完善和明确。有三点好处：- 保持平衡，避免过度开发；
- 延迟决策，避免开发后续会改变的功能，降低变更的成本。
- 拥抱变化，当采用增量开发尽早获得反馈时，反馈可能带来变化。
-
敏捷计划的工具
时间盒
固定时间段，相对比较段，计划的工作要在这段时间内完成。相当于一个检查点，采用时间盒的敏捷项目实施提供了频繁的检查点。
时间盒的设置也为了客服帕金森定律：有多少时间就会花完多少时间，而工作也不一定可以完成。渐进明细
是一种滚动式规划的技术，一个滚动预测未来的计划聚焦于近期准备完成的工作，因为未来太遥远。
随着项目进行中细节的涌现，要持续地明确计划和估算，这就是渐进明细的关键所在。最小可售功能
增量交付在帮助团队获得早期投资回报的时候，也获得了早期的反馈，给后续的功能开发提供了参考基于价值的分析
在项目中的每个阶段，我们都要分析每个工作的商业价值，然后排列工作顺序，并优先交付最高价值的功能，分析价值也需要综合以下两个因素：- 开发成本；
- 回报频率；
基于价值的分解和排序
在项目开始，往往会定义一个产品愿景，基于这个额愿景去收集干系人的需求，对需求进行分类、排序，形成产品代办事项列表，选择高优先级的需求纳入首轮迭代。- 定义愿景：
有两个比较好的方法来进行产品的构想；- 设计产品盒子：4-6人一组，任务是设计产品盒子；正面：产品名词、标志、3-4个产品卖点；反面：详细功能描述及操作要求。
- 电梯测试说明书：
- 对于（目标客户）；
- 谁（对需要或机会的陈述）
- 这个（产品）是（产品类别）
- 它（优点、引人购买的原因）
- 不同于（主要的竞争产品）
- 我们的产品（差异化在哪）
- 特性分解：分解项目愿景为潜在的特性，特性最终会成为特性列表的一部分；
- 特性排序：根据商业价值和风险进行排序，形成排序后的特性列表；
- 迭代循环：选择高优先级的特性进行首轮迭代，也会在过程中识别额外的需求等，这个过程将逐渐明细；
敏捷游戏
* 记住未来：设定愿景、引导需求；
召集干系人，假设时间为版本发布的1周后，整理出未来保证发布成功后所需要做的工作，然后进行归类和梳理；
目的是为了更好的理解干系人对成功对定义，同时可以更好地思考如何能达到成功这个目标。
* 修剪产品树：收集和打磨需求
把树叶想象成某个产品特性，基础对特性靠近主干，依赖于基础特性对处于胶原或较高的位置。
目的是思考各个特性之间如何关联的过程，干系人可以更好的理解优先级排序和定义开发顺序。
* 快船：识别威胁和机会
目的是为了识别风险，并且以此制订风险计划，包括减轻威胁和利用机会。这个步骤应该处在我们对用户故事排序之前，因为很多风险应对步骤需要在用户故事排序对时候被纳入考虑。
* 买功能：优先级排序
* 效益成本比：收益与成本对比 -
敏捷对估算
估算的概念
估算是一项滚动进行对工作，项目初期，信息不明确，估算相对粗略，所以需要在项目进行中持续不断地进行估算。
估算的方法-
宽带德尔菲**：进行多伦匿名投票，避免相互影响；
步骤：- 定义问题的规划
- 评估整体项目
- 分解问题
- 创建问题的规格、识别假设与限制条件
计划扑克：计划扑克在我其他的文章中有专门提到过，可以参考：计划扑克
亲和估算：
估算的单位
-
故事点数：
如果觉得理想时长不太现实时采用；
在使用故事点进行估算时，需要注意：- 故事点数的定义：不同团队的故事点标准都可以不一致，只需要在单个项目一致即可。
- 解聚前后不需要相等：对史诗故事解聚并估算是，有时候估算综合会超出对史诗级故事对总估算量，原因是因为史诗故事太大，很难被估算准确；第二，在解聚时，会了解到更多对工作信息，会估算的更加准确。
同理，对于用户故事拆分为任务也是一样的； - 规模是相对的：4个故事点的用户故事，需要付出的努力是1个故事点的4倍。
使用故事点估算的主要优点：
- 有助于形成跨职能团队协助的氛围：故事点可以用来衡量整个团队；
- 相对稳定：不会随着时间、人、方法的变化而改变；
- 单纯度量单位：无需考虑时间的长短，单纯从工作量上考虑，避免把理想人天数和实际人天数进行对比；
- 操作简单；
- 达成工时：不同的人估算得到的故事点应该是一致的，和技能水平无关。
-
理想人天：在没有任何干扰下（包括喝水、接听电话下），完成工作所需要花费的时间；
有如下主要优点：- 简化估算；
- 易于向团队以外的人解释；
- 开始估算时容易起步
- 容易估算开发速率；
估算的步骤
步骤有如下几步：- 使用故事点数和理想时长来确认项目规模；
- 通过确认团队的有效性&生产力，使用小时或者人天（人周、人月）为单位来计算工作量；
- 在考虑团队规模、所需资源以及依赖度的情况下，将工作量转化为时间计划；
- 通过计算劳动力价格并添加其他项目费用的方法来计算项目费用；
-
