本文为博主原创，转载请注明出处
敏捷随堂一
1.最能描述敏捷的核心理念：可工作的解决方案是看到工作进展最准确的方式
敏捷宣言原则和精益求精方法中的简洁是指： 将不做的工作数量最大化
2.探针Spike，又称为探测故事，主要用于对一项技术风险比较大得工作单独安排一个用户故事或任务，进行预言工作，了解其可行性。探针故事的目的不是要实现该特性；
3.产品演示会议
是在开发团队完成产品功能阶段性开发后，邀请干系人或客户参与的产品功能展示会议，在此会议上并不需要估算开发所需的时长；
其好处有：1.了解功能是否合适；2.了解功能的可用性；3.了解新的需求；；；；（不能了解功能估算）
4.是否完成是由产品负责人（客户代表）来决定某一事项是否已完成
5.信息看板可展示 sprint 状态
6.产品负责人询问每次迭代的进展情况以及后续迭代的工作期望；敏捷项目管理师应向产品负责人提供 燃尽图和 燃起图
燃尽图体现了已完成工作与迭代计划的比较，可以反映工作的进展情况，体现已经完成工作的累积情况、完成工作的走势以及后续工作的预期
7.一名团队成员意识到一项任务所花的时间比原始故事的时间长，可以预防的方式为：
一项任务所花费的时间比原始估算的时间长，很可能是将用户故事拆分成任务时，该任务规模太大，所以可以将该任务分成多个部分，拆分后，也可以被其他成员进行领取；
8.在初始计划阶段，项目团队应如何定制一份可靠和实际的计划：
在进度计划中创建一个缓冲，允许产品待办列表有所更改
9.产品负责人需要负责对用户故事进行讲解说明
10.敏捷项目经理的特征：
1.对于团队的不同阶段假设不同的领导类型；2.允许团队管理；3.引导合作
敏捷随堂2
敏捷中的速率不是用来评价过去是否完成承诺的，而是用来更好地为未来做预测。敏捷不强调评价个人绩效，鼓励团队协作，从团队的角度完成工作；
故事点数是一个故事的相对大小，不是持续时间的估算；
敏捷中采用滚动式规划、逐步完善的方式进行，所以要跟踪迭代，并根据需要重新规划；
在产品发布之前，项目团队应开展阶段结束演示，通过评审会对产品进行演示，得到产品负责人对产品的确认；
计划扑克技术用来评估故事规模的常用技术‘
看板需要限制在制品数量，以快速交付产品；
每日站会的主要目的是通过团队成员的“昨天做了什么”，“今天打算做什么”，了解项目进度，通过“需要什么样的帮助”来暴露项目风险；其重要特征是：密切的配合，专注，每日承诺
敏捷里可以设置迭代0完成正式开放的准备工作，比如：构建办公环境，进行技术准备，语言一些关键用户故事等；
对于Scrum，每一个迭代应该产出潜在可发布的产品功能增量；
每个迭代产出应该是可用的产品功能，这些功能可以交付，但是不一定交付，因此是潜在的可交付产品增量；
结对编程的过程中，可以由资深的工程师带领经验不足的工程师一同工作，快速提高团队整体水平；
敏捷中团队的基本规则由团队自己制定，属于团队
敏捷项目管理师应该鼓励团队达成共识，由团队共同探讨做事方法，站会无法解决问题，回顾会议上讨论计划的事情太迟了；
敏捷故事是基于一个有纪律的迭代进度计划，这些迭代进度逐渐提高可预测性，同时适应变更；
价值映射图将项目工作可视化，找出整个流程中哪些节点是增值活动、哪些节点是非增值活动，以最大限度地消除浪费
随堂练习三
产品待办事项是一列所有需要在迭代中开发的产品特性综合性清单，他是不断变化的，以适应客户需求。随着项目发展，因为客户逐渐理解产品需要更完备，所以待办事项中的项目特性更明确
持续集成的极限编程（XP）原则是代码建立后即集成到完整代码库。由此集成后，代码库和整个系统即建成和测试完成。持续集成只是提高快速交付和集成缺陷早期探测的一个极限编程的原则，持续集成理论上是指随时有可以发布的工作产品。
除了使用故事点来估算用户故事的相对尺码外，敏捷团队还可以使用理想时间。理想时间代表时间量，即不受会议，个人生活，非工作日或其他拖延，障碍和分心的干扰的情况下，相对于待办事项中其他用户故事，单独个人简历，测试和发布用户故事所花的时间；
当估计敏捷项目，常用类比估算，它属于自上而下的估算方式，敏捷并不推荐在事先做非常详细的估算，鼓励适当的估算精确度，尽早开始探索实际工作；
站立会议的由来是鼓励所有团队成员站立进行会议以确保会议的效率，理由是站立带来的不舒适感，会使成员减少浪费时间；
敏捷尝试减少 WIP (work in progress:在制品) ：WIP 是指材料或部分已开始生产但是还未完成的产品，是正在进行中的工作
用于定义用户故事的罗恩.杰弗里斯的3C是指卡片，对话和确认
最佳体验不能成为一个好的验收标准，无法进行有效测试
只有燃起图才能查看所有已完成故事的总点数
敏捷团队必须时常处理产品待办事项里的产品特性优先级问题，从发布计划到迭代计划，敏捷团队必须优先处理产品的用户故事/特性来确保高质量和高价值的特性优先得到开发；以此帮助带来乐观和较早的投资收益；
两个处理产品优先级的常用方法是：MoSCow 和 Kano：
MoSCow 方法将产品特性分为：必须含有，应该含有，可以含有 和 会含有四类；
Kano 方法将特性分为：必须含有，不满足因素，满足因素，和愉悦因素
敏捷1：
1.Sprint的速度低于预期，敏捷团队成员应该 管理沟通，以重置相应团队成员和干系人的期望
敏捷倡导适应型规划，随着团队对于工作的深入认识，计划可以进行调整。应该通过沟通，合理引导干系人的期望
团队一对一沟通并不是最佳沟通方式，同时冲突和低效在题目中没有体现出来
2.预测未来发展----通过路线图
3.团队对用户故事细节不理解，需要PO及相关干系人进行澄清，而不是经理或领导决定
4.燃尽图和燃起图虽然类似，但一般使用的情形是 迭代燃尽图 和 功能燃起图 ，主要原因在与其数值是否有较大的变化。
本题要求范围变更，只能由燃起图而不是燃尽图体现，另一方面，题目支出需要知道不久的将来发布什么功能，故事地图相对产品路线图更加详细具体；
5.需要提前交付特性（功能）时，审查DOD（完成的定义）确保交付的特性符合各方的要求，比如质量要求，再进行交付
8.敏捷团队履行承诺，但感觉能提高速度，团队成员可以通过 减少非生产性时间 来实现这一点
非生产性时间即非增值活动占用的时间，降低非增值活动，尤其工作中的浪费，从而提高增值活动的比例，提升工作效率
9.在线协作网站也是一种信息发射源，干系人通过在线网站随时了解项目状态，敏捷推荐减少会议
10.以团队为核心，团队做出合理建议应该给予支持
12.需求定义不清时，通过增加干系人的参与度，共同研讨达成一致意见。重点在于干系人共同参与而不是由个别人决定（如SME）。研讨会在PMP及敏捷里一般都是正确选项
13.对于特性的变更需要与PO商量影响和应对措施，然后判断是否需要在当前迭代中增加新的功能或产品价值
17.信息辐射源具有高度可视的，通过计划会议和每日站会创建风险和问题清单并且持续不断的进行监控
19.Sprint计划会议详细定义下一个sprint应包含的功能
22.周期时间过长，应该减少在制品数量，增加系统的单位时间产出成果。Little 法则说明在制品数量越少，平均每个产品完工的周期就越短
24.回顾会议用于总结本迭代的优良做法和待改进的工作方法，回顾会议讨论的是做事的方法
25.敏捷方法并不是适合所有项目，也不是解决任何问题的灵丹妙药。同时敏捷实践的方法也是多种多样。最佳做法是向人们提供敏捷原则，其中最关键的原则就是聚焦客户需求
和业务目标，也就是价值导向的原则
30.技术债务不能指望一次性清理王城，推荐的做法是与产品新特性的开发同步开展。其良好的做法是：将技术债务先收集起来，放入待办事项，供未来迭代处理
38.敏捷团队的开发人员尽量不要被调走，因为团队是很长时间才磨合好的，敏捷教练有维护团队的责任
40.在当前sprint中， Scrum主管应该移除和记录出现的障碍
42.在创建最小可行产品（MVP）时，演示的方法至关重要；MVP 推荐经过干系人共同参与产品演示，评审会议的方法来定义
46.敏捷项目团队 接受成功标准，产品负责人定义故事的验收标准
47.敏捷团队应该在 执行阶段 创建sprint可交付成果
51.当要求额外特性时，将其加入待办事项列表，需要po重新排列现有的产品功能，以确定优先顺序
52.在站会上，团队决定了一种处理故事的新方式，再开始制定解决方案，敏捷管理专业人士应该 结束对话，保持sprint承诺。。
因为站会上识别的问题不宜在展会上讨论问题及解决方案
54.管理产品质量可能很困难，可能是产品设计或架构方面制约了新特性的开发，需要考虑重构以拓展产品的可持续可开发性。。
D的问题在于题意为管理质量有风险，而不是当前质量有问题
55.团队之间的冲突首先由当事人自行解决，如果不能有效解决，scrum主管应该及时截图解决问题
57.非功能性需求，如响应速度，差错率等等，这些需求需要查看之前的规范文档，有必要时称为一个探测故事进行研究
67.若要在项目早期以最低的成本是别别并应对风险，敏捷团队可以采取的最有效行动是 ： 查看信息信息发射源记录
敏捷提倡风险记录在信息发射源中，将风险透明化，不鼓励采用风险登记册的方式用文档管理风险
69.客户需求不断变化，需要缩短迭代长度，帮助在一个较短时期内聚焦开发工作
72.团队整体的底士气不能只依靠团队自身来解决，应及时介入，与团队一起解决这个问题
73.共享工作区是一种实体环境或者虚拟环境，比如实体形式上团队公用一块办公区域，使用大型白班，虚拟形式的信息共享网站，在线协作工具等，其主要母的就是帮助
团队成员快速的分享信息，彼此协作
78.新版本特性开发与支持旧版本不能横向比较哪一项工作更重要。不过在估算新特性开发速度时必须要考虑对过去版本的维护成本。
确定速度时，从生产能力中减去支持成本
80.WIP用于避免在规划阶段计划过多的工作项，提升工作效率；当计划工作项超过WIP时，说明规划不佳
82.当团队有多余精力时，可以拉入其他高优先级的工作。减少人员或调整事件对于敏捷来说并不鼓励，敏捷建议保持事件和成本不变
当迭代速度高于预期时，最适应的应对措施是：团队应该增加sprint中包含的待办事项数量
87.干系人参与对项目成功至关重要，定义好产品愿景后，与干系人分享，获得知识。接下来可以开始手机产品待办事项。
89.看板的使用者是团队，团队成员利用看板更新自己的工作状态，进而作为一个团队对于整个项目状态进行更新和监督
91.首先鼓励团队成员自行讨论并达成解决方案。如果冲突继续，团队领导再介入其中
92.最小可售特性包含两个要素：一是对于市场有价值，而是功能最小集合
定义：通过为市场增加价值的最小功能数量
96.项目发起人要求提供敏捷的简要概述：项目将关注技术卓越和良好设计
97.职能经理权限比较大，层级管理的特点比较明显
强矩阵里项目经理拥有比职能经理更大的权力
105为确保产品符合业务需求，敏捷项目经理应该采取的首要步骤是：让干系人的利益和期望相符合
满足业务需求一方面需要明确干系人的利益，另一方面也要引导干系人的预期。只有当预期合理，并且符合干系人的利益，产品才能实现最终的业务需求
106.在敏捷项目迭代期间，产品负责人想知道解决软件质量问题的周转事件。除了使用看板意外，还可以使用累积流量图
122.一个敏捷团队正在为未来一年后发布的产品工作，已经详细规划了所有迭代。应该首先进行发布规划
为期一年的项目应该采取渐进明细的规划方法，先规划总体发布计划，再规划近期的迭代计划
132.一家公司希望从传统实践转向敏捷实践。敏捷教练首先应向公司提供建议：评估组织可能的转型成功因素
136.敏捷倡导专注的价值观，认为人在一段时间内最有利于提高项目绩效，产出成果
143.一家公司聘请敏捷教练帮助解决孤岛和人员损耗问题。敏捷教练 应提供建议：培养由通才专家组成的团队，并鼓励个人学习新的技能
144.一个工程机构将其项目管理方法改为敏捷Scrum。那么实现这种转变的最佳方式是：让一个高级主管负责领导这次转变
高层重视是转变敏捷的必要
148.评估新任务时，跨职能团队 能够弥补缺失的信息
跨职能团队的知识和技能互相补充，提供更全面的全队能力
149.对于新技术、新框架的使用，可以专门安排一个需求条目进行研究，将该条目加入产品待办事项有助于区分优先级
153.看板需要展示的栏目包括：待办，执行中，已完成等条目
155.在没有完全理解敏捷过程之前对齐进行自定义或裁剪是危险的。建议先遵照敏捷方法在几个项目上进行实践，不是方法有问题，很可能是你还不太会运用它
178.产品功能特性的选取主要是产品负责人的职责，应由产品负责人出席，没有必要让整个团队参与竞争对手的软件演示活动
180.迭代周期不应随意更改。目前正要开始第三次迭代，处于迭代规划会，可以调整用户故事的大小以适应迭代，而不是要等到迭代末的回顾会再进行讨论。
价值流图：把工作步骤展现出来，详细研究每个环节的具体工作，找出整体上的改进点
时间盒：敏捷鼓励各项活动遵守时间限制，比如每日站会，计划和评审会议，总迭代时长等
燃起图：可以了解整个项目的总故事点数，可以识别变更信息
燃尽图：可以了解剩余工作的总量，从过去的曲线也可以看出团队到目前为止的表现情况；当前迭代情况可以参考燃尽图，查看完成多少工作，剩余多少工作
每日站会：团队成员分享故事、任务的完成情况，通过所遇到的障碍了解承诺达成的情况，
鱼骨图：又称石川图，用于分析问题的根本原因
帕累托分析：用于分析造成大部分问题的少数重要原因
计划扑克：是一种典型的使用故事点来估算用户故事相对规模的方法
卡诺模型/卡诺分析：根据客户对于产品功能特性的偏好程度排列优先顺序
累积流量图：可以看出当前缺陷的数量，目前处于哪个解决状态以及循环时间盒前置时间等多个指标
看板需要展示的栏目包括：待办，执行中，已完成等条目
人物角色：Personas 能够快速辨别关键干系人及他们的利益所在
最小可售功能发布：80%的产品价值是由20%的功能来实现的。要用最小的代价，最快的速度实现最小功能集合
结对编程：尽管看起来不那么有效率，但是结对编程能够尽早发现问题并实现知识共享
看板：看板的核心理念是通过限制WIP，减少周期时间，让工作快速流动起来，以便尽早交付产品增量
敏捷中没有风险登记册的概念，且不推荐概率和影响评估
产品待开发功能必须由产品负责人确认，并且给予相应的优先级。
在sprint结束时，会进行迭代评审会议，可同时进行 sprint演示，展示产品特性，了解功能时，可通过对产品特性的演示深入了解该功能特性
完成50%的特性不能做为速度计算在内。计算速度时只能统计 100% 完成的
持续构建与增量式交付主要关注点是持续交付最高价值的工作项。增量式交付首先交付优先级最高的工作
任务创建详细描述该用户的特点、期望以及使用场景等信息。创建该用户画像有利于站在用户的角度思考解决方案
敏捷团队规模小，这样需要团队成员具有多种技能的“通才”，提高了团队的合作效率、更创新、更健壮
敏捷推荐团队由跨职能团队成员组成，团队成员是一专多能的通才。。
当迭代产出质量不高，需要更频繁的检查
开发团队对成员的任务领取和分配负责
出现新需求时，不要立刻开始实施，先加入产品待办事项列表，然后与当前条目比较优先顺序，根据优先级决定先后顺序
做题时，一定要考虑一些做法的可行性
敏捷练习二
11.基于风险的刺探是团队研究某个问题而进行的快速的概念验证活动，基于风险的刺探也常用来探测陌生的全新的技术，在深入采用这种技术之前，探测的结果能够避免陷入太深
28.在团队个体背景差异很大，在规划一次团队建设活动时，团队领导应使用 情商 类型的人际关系技巧
情商-识别、评估和影响我们自己、其他人和团体的情绪的能力。管理敏捷团队，保持灵活领导力和有效方式就是持续提升我们自身的情商（自我认知，自我控制，社会认知和社会技能）
38.一个开发团队正在为一个跨州的分布式项目工作，与此相关的常见问题是：在不同地点的开发人员之间形成对抗性的“我们与他们”的关系
44.出现问题需要探究根本原因，以彻底解决问题
46.敏捷组织应该是目标导向的，团队的技能培养应该以实现项目目标，为客户创造价值为前提。需要说服团队成员需要积累更多的经验。技术培训本身在题干中没有提及
51.具有整体产品愿景的产品负责人要求提供详细项目计划，敏捷团队应该花时间规划 具有较高确定性的立即任务，以及具有较低确定性的即将到来任务
54.一名敏捷团队成员由于遇到个人问题而频繁请假，阻碍了项目进展，敏捷团队领导应该：在下一次会议上提出这个，收集其他团队成员的意见
55.要让技术债务可见，并按照正确的优先顺序进行处理。将技术债务插入到待办列表来解决问题
70.一名敏捷团队成员很安静，很少在会议上发言，且很少在回顾会议上提出反馈，敏捷管理专业人士应该：与该团队成员单独开会，以确定其提供反馈的舒适程度
个别团队成员出现问题，建议单独进行沟通，并确定最好的措施
76.一名拥有封闭只是的高级团队成员辞职，提供极少信息。结果团队经历瓶颈。若要确保在该情景中继续保持开发，团队领导应该实现做：交叉培训团队的补充技能
交叉培训能够很好的避免题目中所出现的问题；；事先可以通过交叉培训，让个人技能称为全团队的共有技能
78.鼓励团队尝试新技术，同时利用时间盒管控风险，因为项目时间紧
79.产品负责人如何快速确定当前sprint的团队承诺状态：查看燃尽图和燃烧图
92.敏捷迭代遵守时间盒的概念。在既定的时间内进行相应的工作和活动，如果事件结束但计划工作没有完成，停止正在做的工作并将未完成的工作移到下一时间盒
93.迭代遵守时间盒的概念，并且一个项目内的所有迭代具有相同的时长，保持时长一致可以帮助衡量开发团队的表现，并能更好的计划每次新的迭代；
97.如果由于缺乏参与，团队的速度下降，敏捷管理专业人士应该：调查原因，并在下一次回顾会议上陈述该问题
101.待办列表梳理基于 商业价值和成本进行正确的排序
107.降低产量并增加浮动时间将导致速率的降低
109.迭代周期应该稳定，不是根据工作大小而调整的。
110.随着项目的进行，迭代能够提供关于真实进展的强有力的证据，这时可以利用完成迭代的速率来判断实际绩效并估计未完成的部分。当跟踪了多次迭代的速率以后，就能估计完成一个项目需要多长时间
113.更新报告并不是敏捷推荐
116.在当前sprint 中，SCRUM 主管 应该删除和记录出现的障碍
134.回顾会议未能按敏捷团队领导的预期改进效率，若要确保回顾会议为团队和项目带来价值，团队领导应该：辅助并提醒团队聚焦回顾会议行动项
147.启动新项目首先要进行可行性分析，采用刺探（探针）的手段进行试验而不是写详细文档计划，这是敏捷推荐的做法
150.团队收集并提供个人估算，说明估算是自下而上，由团队工作做出的，这符合宽带德尔菲方式，在团队每个人估算的基础上达成一致同意
155.发布计划相对迭代计划是比较粗糙的，发布计划描述对可能开发什么以及在什么时间范围开发的粗略视图和期望
迭代计划描述需要在特定版本中开发的故事详细视图、估算和验收标准
162.一年的计划无法实施详细的计划，应遵循近期详细，远期粗略的规划；可要求团队详细分解下一次迭代和剩余持续实践的粗略估算
168.敏捷强调价值优先，在项目中实实在在地体现价值是让干系人接受敏捷最有效的方式
169.结对编程在预估时时长翻倍，为开发人员和审查人员分配相同的时间完成工作
175.迭代规划会议内容为 估算故事大小，确定故事优先级
建议采用合作的方式处理各方面目标的冲突问题
当问题的根本原因并没有在四个选项中正面出现，依照最优法进行选择，对于缺陷的澄清不是PO的职责；；
在迭代规划会议上，需要确定每个故事的验收标准和测试方法
出现团队成员间的冲突时，鼓励当事人解决该冲突
Scrum 主管要与干系人合作移除实施Scrum过程中产生的障碍
决定用户故事优先级的两个因素：商业价值和成本，以最低的成本实现最高的商业价值
简单的等待或者停止都不是正确的选择，督促负责人及时解决才是最优的；
冲刺待办列表在冲刺期间一般是不进行增加新的故事的
在组织中实施敏捷，关键在于营造一个适合敏捷的氛围，减少团队成员的障碍，从而发挥团队的自组织性，提高没一个个体的潜能是实施敏捷的关键之一。确保所有团队成员都有适当的资源。
根据风险的高低与价值的大小进行优先排序，高风险且高价值的任务得到最优先执行
尊重团队的自组织原则，同时关注每个团队应具备较为均衡的技能
增量式规划不需要特别详细的计划，制作够用的计划，识别高层及风险，了解目前的优先事项
对于信息分享，敏捷推荐信息辐射源的做法，引导干系人主动查看信息辐射源了解项目状况
高绩效团队的两个主要特点：一是工作方式自组织，二是设定挑战目标，以实现绩效为根本目的
敏捷推荐解决方案来源于 团队共同研究的成果，慎重选择由管理层确定方案的思路
在敏捷初期激励团队的有效方式是来自干系人尤其是客户或高层及的反馈，如果可以看到功能/问题被更快更好的实现/解决，有助于推动群体实施敏捷
发生进度落后时，在截至日期（迭代结束日）完成可能完成的工作，然后安排一次回顾会议，找到未来改进的方向
仆人式领导支持团队的工作，识别障碍，采取适当的行动帮助团队消除障碍，同时减少不必要的状态汇报工作
标签: 项目管理
