（1） 跨职能的团队，是Scrum中的关键词；
完整的团队，是XP中的关键词
（2） 管理敏捷团队，保持灵活领导力的方式就是持续提高我们自身的情商、自我认知、自我控制、社会认知和社会技能
（3） 经验丰富的团队成员对新成员进行指导是新成员快速成长的过程
（4） 鼓励作为当事人的团队成员自行解决冲突，其次才会考虑介入这个冲突，并在必要时给予指导
（5） 敏捷团队领导，需要确认PO的可用性，PO应该与团队一起工作，当其可用性出现问题时，SM需要确认其可用性，并要求其投入更多的精力
（6） PO决定了产品的方向，他们基于商业价值，对工作进行排序
（7） 明确定义用户故事，是PO、SM、Devs合作完成的，其中用户故事的澄清是PO的职责
（9） 及时得到客户的反馈能够避免我们在错误的方向上走得太远
（10） 共享工作区，是一种实体环境、或者虚拟环境。
比如，实体形式上，团队公用一块办公区域，使用大型的白板；虚拟形式的信息共享网站、在线协作工具等，其主要目的就是帮助成员快速地分享信息、彼此协作
（11） 复杂的功能应该进行分解（INVEST原则），并关注最有价值的部分
（12） 敏捷鼓励团队参与、理解和共担责任，SM要帮助团队自己提出解决方案，建立相互信赖、自组织、自管理的团队
（13） 采用最小可售功能(MMF)进行发布，80%的产品价值是由20%的功能来实现的，要用最小的代价、最快的速度实现最小的功能集合
（14） 每日站会上不进行具体的讨论，问题的讨论和解决方案在会后组织补充会议或问题解决会议处理
（15） SM要与干系人合作移除实施Scrum过程中产生的障碍
（16） 分散办公的最大挑战是复制集中办公团队的面对面沟通、渗透式沟通及隐性知识分享所带来的好处，并要想办法先改善团队成员间的关系。
（17） 下列一些工具常用于分散办公的团队。比如：视频会议、基于Web的会议引导、在线调查应用、及时通讯、VoIP、基于展现的应用和交互式白板等
（18） 在第一次Sprint计划会议进行全面的风险识别和分析将风险加入到信息发射源，然后在后续的规划会议期间识别新风险，或对已识别的风险进行更新，包括概率、影响会发生变化
（19） 价值流的映射，原自精益制造的技术，可以用来识别并消除浪费，以改进流程/过程
（20） 自组织的团队意味着团队成员运用自己的知识判断最好的完成工作的方式，而不是由领导来告知怎么做，领导最好以仆人式的领导的方式出现：明确迭代的目标，保护团队不被干扰，移除障碍并规定可接受的行为，对团队进行授权
（21） 围绕斗志昂扬的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务
（22） 鼓励规模较小的团队中的成员不是专才而是通才，充分贡献自己的技能
（23） 决定用户故事优先级有两个因素：一个是商业价值，一个是成本。以最低的成本实现最高的商业价值
（24） 敏捷项目规划采用适应型的方式，承认规划是持续进行的，通过多种方式，积极主动地更新。
（25） 早期规划是必要的，即使可能有瑕疵，需要在项目过程中安排重新规划及调整适应的活动。比如，在冲刺计划时，始终保持每次只计划和处理一个冲刺，并致力于当前的冲刺
（26） 集体决策将该功能包含进下一个发布版本的可行性是最好的选择，因为优先顺序、团队速率都要考虑的
（27） 要让技术债务可见，并按正确的优先顺序进行处理，将其插入到待办列表中
（28） 速率是用来测量团队在每个迭代中的生产能力的
（29） 简单的等待或者停止，都不是正确的选择，督促负责人及时解决才是最优的
（30） 迭代评审也是重新梳理代办列表的一个时间点，通过正确的待办列表和优先顺序确保为客户持续提供价值
（31） 已完成的定义是DoD的概念，DoD应该由团队共同定义；
而工作是否达到了验收标准最终由PO确认。
（32） 冲刺代办列表，在冲刺期间，一般是不进行增加的
（33） 在迭代期间，团队需要持续获得PO的反馈，以确保工作在正确的方向上，迭代演示不是针对PO的，也不是只有在演示时才获得PO的反馈
（34） 敏捷推荐面对面的沟通，因此集中办公用来提供这样的办公环境，变于团队的合作和信息的分享
（35） 个别团队成员出现问题，建议单独进行沟通，并确定最好的措施，要注意保护其隐私；
如果是个别团队成员的工作出现问题，就需要与团队一起讨论解决方法
（36） 在迭代计划工作已经完毕，进入迭代的每日工作环节，在每日站会上，将问题提出来
（37） 刺探是小型的独立实验，以证明你已经了解正式开发前所需要的信息，可以作为一个单独的迭代存在
（38） 团队负责如何完成用户故事，并应用刺探技术获得快速的反馈
（40） 团队成员在每日站会上提出问题或障碍，并将其可视化，以促进其解决
（41） 项目团队应如何计划和监督分包商的工作呢？
通常是通过产品的代办事项和每日站会
（42） 敏捷管理的专业人士应与团队合作，分享任务、故事、承诺相关的信息，这是通过每日站会来实现的
（43） 迭代回顾会议的目的是为了发现哪些方面需要改进，在每个迭代之后都会开展回顾会议，团队成员聚集在一起，审视和提升工作方法和团队合作
（44） 我们的最高优先级是通过持续地、尽早地交付有价值的软件来满足客户
（45） 迭代遵守时间盒的概念，在既定的时间段内进行相应的工作和活动。如果时间结束，但计划工作没有完成，停止正在做的工作并将未完成的工作移到下一个工作盒，将不完整的故事放回到产品代办列表中，以便PO重新排列优先顺序
（46） 迭代遵守时间盒的概念，并且一个项目内的所有迭代拥有相同的时长，保持时长一致可以帮助衡量开发团队的表现，并能更好计划每次新的迭代
（47） 人物角色能够快速辨识关键干系人及他们的利益所在，创建的人物可以以真人为参考，也可是是多个用户的混合，并且被创建的人物能够体现用户的典型性
（48） 敏捷团队开始时可能犯错，但每隔一段时间总结如何更加有效，然后相应地调整自己的行为
（49） 技术债务也是产品代办列表的来源之一，要根据正确的优先顺序来处理技术债务问题
（50） 缩减范围已保持原进度，还是保持原范围而延长进度时间，需要和PO进行协商处理
（51） 敏捷团队主管筹划项目组合以促进项目优化和选择的决策，团队主管应使用什么呢？
--使用代办列表梳理
（52） 在对相关人员进行教育和培训后，逐步开展敏捷的实践活动，以促进敏捷的转型
（53） 应该和干系人一起制定发布计划，并通知客户结果
（54） 没有价值的工作的优先顺序在产品代办列表中是比较低的，但是保持了需求的完整性
（55） SM保护开发团队免受外部干扰、扫清妨碍团队生产效率的一切障碍，使得团队成员保持专注
（56） 随着项目的进行，迭代能够提供关于项目进展的强有力的证据，这时可以利用完成迭代的速度来判断实际绩效，并估计未完成的部分，当跟踪了多次迭代的速率之后，就能够估计完成一个项目需要多长时间
（57） 根据分析的高低和价值的大小进行优先排序，高风险且高价值的任务得到最优先的执行
（58） 结对编程尽管看起来不那么有效率，但是能尽早发现问题，并实现知识共享
（59） 累计流量图中显示了Lead time（前置时间）、backlog size、remaining to be done、cycle time和WIP
（60） 信息发射源向干系人展示了进展的相关信息、风险的相关信息
（61） 产品不一定是指商业产品，也可能是解决方案
（62） 创建产品愿景的责任人是产品负责人，他是产品愿景声明的owner，但是其他干系人也可以提出反馈。产品负责人根据反馈修改并最终确定产品愿景声明
（63） PO对产品代办列表的优先顺序有最终拍板权
SM对障碍代办列表由生杀大权
开发团队对故事的大小有最终决定权
（64） 发布不需要包括路线图中的所有功能，但至少要包含最小可上市的特性集（MMF）。
（65） 产品带办列表中的事项是以用户故事的形式存在的，包括功能性用户故事，非功能性用户故事，探针用户故事、技术债务、风险应对的用户故事等。
（66） 解决技术债务、问题、风险等异常，首要要将其可视化。如：加入待办列表，加入信息辐射源等
（67） 站会不提供解决方案，只提出/暴露问题/障碍，使其对团队可见。
（68） 需要构建缓冲来降低不确定性对时间的影响。
（69） 当缺乏完成故事的技能或者风险较高时，可以考虑用试探的方法。
（70） 对大故事、复杂故事，要先分解再定验收标准，然后再排序，然后再确订是否会出现在后续的迭代中
（71） 敏捷为相关方创造价值，而不一定是发起人。
（74） 敏捷时间和成本不变，范围可变。通过优先级排序，聚焦最优先功能，形成最小可售特性。
（75） 出现无法达成原计划时，我们依然要尽可能多的交付高价值故事，形成MMF，未完成部分US放入PB，由PO管理。
（76） 迭代结束时，相关方提出几个要求，SM下次迭代怎么做？
--将要求作为DoD的一部分，为下次迭代工作提供指导
（77） 使用燃尽图来沟通项目进展情况，有助于保持团队士气。
（78） 回顾会聚焦过程改进/优化，评审会聚焦产品改进/优化
--敏捷的两个优化
（79） 召开项目协作引导会来制定目标，有助于成员了解并努力实现共同目标
（82） 针对项目过程中的挑战，与团队共同探讨解决方案
（83） “快速失败”不等于要降低质量，所以出现质量降低时不能宣传它。
（84） 当个人目标/利益和团队目标/利益冲突时，优先团队目标/利益，但是也要兼顾个人目标
（85） 分析流程中存在的问题，使用价值流程图，找出过程中的浪费
（87） 项目变更比较密集或者频繁，可以考虑缩短迭代长度，有利于保持相对稳定的工作；
（88） 项目中成员工作上出的问题，就是团队集体的问题，建议由团队集体商讨来解决。
（89） 敏捷对于估算并不要求准确，通常采用适应性的估算方式，渐进明细，后续不断优化的原则。
（90） 构架设计应该在早期就与团队商议讨论，获取全面的知识，并且确保理解一致性
（91） 敏捷的基本规则，包括价值观、原则和实践。
（93） 管理敏捷团队保持灵活领导力的有效方式是持续提高自身情商。
（94） 客户或者PO持续检查或者持续评审，才能保证持续提供价值。
（95） 迭代已经完成团队就进入每日工作环节，问题，挑战障碍等就可以在每日站会上提出。
（98） 团队识别到的行政任务，SM可以承担，让团队成员专注于交付。
（99） 题干中如果出现了首先然后等顺序词语答案中的时间顺序如同时与题干不对应，一般不选。
（100） SM负责删除和记录在当前sprint中出现的障碍。
PO负责拍板故事是否已完成
（101） 完成一次里程碑后，应组织一次团建，以良好的收尾上一阶段和开启下一阶段。
（102） 当团队对工作失去兴趣时，是团建的良好时机，此时团竞有利于恢复和激活团队活力。
（103） 会议的促进者主要职责是搭建平台，邀请众人共创，自己如果需要表达观点可以在其他人发言之后补充。
（104） 团队是估算的主体，应让他们参与对客户承诺的过程。
（105） 解决孤岛和竖井问题的有效措施，有组建通才团队，鼓励个人学习新技能。
（106） 对于新框架、新技术的使用，可以将其作为一个故事处理。：选加pb，再排序
（107） 识别到重大问题，应该立即采取行动，与团队合作解决问题
（108） 出现新需求时，不要立刻开始实施，先加入产品待办事项，
然后与当前条目比较优先顺序，根据优先级决定先后顺序。
（109） 敏捷对待项目外部变化的基本原则是适应和调整。出现外
部依赖干扰正常执行的情况时，可以首先思考如何动态调整任务，比如调整先后顺序，核心是团队保持学习和敏锐的适应能力。
（110） 增量式规划不需要特别详细的计划，制作够用的计划、识
别高层级风险，了解目前的优先事项
（111） 为避免项目中的短视问题，敏捷团队可以扩大实践，包括规划和展望，快速识别未知事项等
（112） 在敏捷初期激励团队的有效方式是来自干系人尤其是客户或高层的反馈，如果可以看到功能/问题被更快更好地实现/解决，有助于群体推动实施敏捷。
（113） 敏捷强调价值优先，在项目中实实在在地体现价值是让干系人接受敏捷最好的方式
（114） 缺失的功能需求首先要先加入产品待办事项列表中，功
能驱动开发模式 FDD 没有PO这个角色，由团队创建用户故事并加入待办事项列表。
（115） 敏捷包括两类愿景，一是产品愿景，二是团队愿景（团
队章程）。团队愿景主要是共同的价值观，协作规则和其他必要的协议
（116） 燃起图可以体现项目范围变更，可以体现团队目前完成的所有工作
（117） 理解产品目标，要从产品愿景入手。产品愿景又称产品章程
（相关知识点：团队愿景又称团队章程）
（118） 每日站会能增强团队成员间的沟通，有助于团队在迭代期间的持续改进
（119） 重复的工作可能存在优化空间，执行价值流分析，找出非增值活动，以便进一步改进
（120） 采用新方法时，团队应确定其对整体时间的影响
（121） 管理产品质量困难，可能是产品设计或者架构制约了新特性的开发。需要考虑重构来使产品可以被持续开发
（122） 非功能需求，需要查看之前的规范文档，若不确定如何继续，可做为一个探测故事进行研究
（123） 新开发和旧维护不能横向比较哪个更重要。但是在估算新开发速度时，必须要考虑对过去版本的维护成本
（124） WIP用于避免在规划阶段计划过多工作，当计划超过WIP时说明规划不佳
（125） 满足业务需求既要明确干系人的利益，也要引导干系人的预期
（126） 为什么定期沟通目标很重要，因为会有适应和调整
（127） 在回顾会议之前重申会议的基本规则，如坦诚开发，对事不对人等，这是构建舞台阶段需要完成的事项
