一、 敏捷原则和理念

1、敏捷的4条宣言就是敏捷之道，12条原则可以被视为敏捷之法。

2、常见正向的关键词：价值、消除浪费、持续改进、自组织、透明化、面对面；常见的负面的关键词：详尽的文档、详细的报告。

3、在对相关人员进行教育和培训之后，逐步开展敏捷实践的活动，以促进敏捷的转型。

4、不管实际的做法如何，在考试中要把敏捷运行的环境想象成为：品德高尚的员工、以人为本的公司、尊重欢乐的文化；要遵循责任、尊重、公正、诚实的职业道德规范。

5、要遵循敏捷社区价值观，包括：愿景、仆人式领导力、信任、协作、诚实、好学、勇气、开放、适应力、领导变革、透明化。

二、价值驱动交付

1、范围、时间、预算、质量产生冲突，在敏捷中的基本原则是不允许牺牲质量，管理层可以决定时间和预算，通过调整范围来解决冲突。

2、PO决定了产品的方向，基于商业价值对工作进行排序。

3、价值流的映射，源自精益管理的技术，可以用来识别和消除浪费，以改进流程。

4、燃起图和燃尽图是进度跟踪的管理工具。

5、我们的最高优先级是通过持续地交付有价值的软件来满足客户。

6、根据风险的高低和价值的大小进行优先排序，高风险和高价值的任务得到最优先的执行。

7、用户故事的详细水平（level of detail）要符合“刚好够用”原则，由PO和团队共同协商确定。

三、干系人管理

1、在敏捷项目中保持与干系人频繁的沟通是保证项目成功的重要手段。

2、敏捷项目管理师要与干系人合作移除障碍。

3、速率是用来测量团队在每个迭代中的生产能力的，当前速率是团队上一个迭代完成的故事点数。

4、“人物(persona)”能够快速辨识关键干系人及他们的利益所在，被创建的人物可用真人为参考，也可以是多个用户的混合，并且被创建的人物可以体现用户的典型性。

5、随着项目的进行，迭代能够提供项目进展的强有力证据，这时可以利用实际迭代的速度来判断项目的绩效和估计项目未完成的部分，当跟踪了多个迭代的速率之后，就可以估计一个项目完成需要多长时间。

6、信息发射源向干系人展示了进展的相关信息，另外一些风险的相关信息也会展示在信息发射源中。

7、冲突五个级别的基本特征是：阶段1：开放、讨论、共识；阶段2：争论，但没有指责，认为自己有理；阶段3：指责，认为是别人的错；阶段4：凡是对方说的都是错的，已经没有具体的问题了；阶段5：不沟通，有我无他，势不两立。

 四、高绩效团队

1、管理敏捷团队保持灵活领导力的有效方式是持续提升我们自身的情商、自我认知、自我控制、社会认知和社会技能。

2、经验丰富的成员对新成员进行指导是新成员快速成长的方式。

3、出现团队成员之间冲突时，首先应该鼓励当事人自己解决冲突，其次才会考虑介入这个冲突，给与指导并解决这个冲突。

4、敏捷团队领导需要确认PO的可用性，PO应该与团队一起工作，当其可用性出现问题时，敏捷项目经理需要确认PO的可用性，并要求PO投入更多的精力。

5、共享工作区是一种实体环境或者虚拟环境，比如实体环境可以共用一块办公区域，使用大型的白板；虚拟形式可以是共享网站、在线协作工具等；其主要目的就是帮助团队成员快速分享信息，彼此协作。

6、敏捷鼓励团队参与、理解和共担责任，敏捷团队领导要引导团队自己做出解决方案，建立相互信赖，自组织的团队。

7、分布式团队面对的最大挑战是复制集中办公团队的面对面沟通、渗透式沟通及隐性知识分享所带来的好处；对于分布式团队建设要先想办法改善团队成员之间的关系，借助一些工具改善分布式团队的沟通，例如：视频会议、基于WEB的会议引导、在线调查应用、即时通讯工具、VOIP、基于展现的应用和交互式的白板等。

8、自组织的团队意味着团队成员应用自己的知识，判断最好的工作方式，而不是由领导来告知怎么做，领导最好以仆人式领导的方式出现，明确迭代的目标，保护团队不被干扰，移除障碍，并规定可接受的行为，对团队进行授权。

9、一名仆人式领导理想上是名促成者，倾听敏捷团队的需求，清除团队障碍并为提高生产率提供工具和其他支持。

10、围绕斗志昂扬的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。

11、鼓励规模较小的团队中的成员成为通才，而不是专才，充分贡献自己的知识和技能。

12、敏捷推荐面对面的沟通，因此集中办公提供这样的环境，便于团队协作和信息的分享。

13、个别团队成员出现问题，建议单独私下进行沟通，并确定最好的措施。

14、敏捷管理的专业人士应该与团队合作，分享任务、故事、承诺相关的信息，他是通过每日站会来实现的。

15、敏捷团队主管保护开发团队免受外部的干扰，扫清妨碍团队生产力的一切障碍，使得团队成员保持专注。

五、适应性计划

1、敏捷项目主管筹划项目组合、促进项目优化和选择的决策，应该使用代办事项列表梳理（grooming）技术来达成上述目的。

2、明确定义用户故事是PO、团队和教练合作完成的，其中对用户故事的澄清是PO的职责。

3、复杂的功能应该进行分解，这里应该应用用户故事的INVEST原则，并关注最有价值的部分。

4、采用最小可售功能（MMF）进行发布，80%的产品价值是由20%的产品功能来实现的，要用最小的代价，最快的速度，实现最少的功能集合。

5、用户故事优先级决定于两个因素，一个是商业价值，另一个是成本，以最低的成本实现最高的商业价值。

6、敏捷项目规划采用适应性的方式，承认规划是持续进行的，采用多种方式进行积极主动地更新，适应性规划认可早期的规划是必要的，但是不完美的，需要在项目实施的过程中安排重新规划和调整适应的活动，比如冲刺计划会议时，始终确保每次只计划和处理一个冲刺，并致力于当前的冲刺。

7、集体决策是否一个功能包含进下一个发布或迭代是最好的选择，因为优先顺序和团队速率都会影响下一个迭代可以完成哪些用户故事；优先顺序决定优先选哪些故事，速度决定能够选择多少高优先级的故事。

8、在迭代计划会议结束后，进入迭代开发环节，在每日站会上将发现的问题提出来。

9、迭代遵守时间盒的概念，在既定的时间段内进行相应的工作和活动，如果时间结束，但计划工作没有完成，停止正在做的工作，并将未完成的工作移到下一个时间盒，将不完整的故事放进产品代办列表中，以便PO重新排列优先顺序。

10、迭代遵守时间盒，并且一个项目所有的迭代具有相同的时长，保持时长一致可以帮助衡量开发团队的表现，并能更好的计划每次新的迭代。

11、敏捷管理专业人士应该和干系人一起来制定发布计划，并通知客户计划结果。

12、没有价值的待办事项的优先级在产品待办事项列表中的位置是比较低的，但是保持了需求的完整性。

 六、 发现于解决问题

1、敏捷通过迭代评审会议获得客户最快速度的反馈，及时获得客户的反馈可以避免我们在错误的方向上走的太远。

2、要防止问题的再次发生，需要找到问题的根本原因，并积极采取措施。

3、出现问题出现时，需要首先定义问题、然后分析根本原因、接下来制定计划和方案、最后实施解决方案彻底解决问题。

4、遇到问题简单的等待或者求助管理层都不是正确的选择，督促（引导）负责人及时解决才是最优答案。

5、迭代评审也是重新梳理代办事项列表的一个时间点，通过正确的待办事项列表和优先顺序确保为客户持续地提供价值。

6、刺探是小型的试验，以证明你已经了解在正式开发前所需要的信息，也可以作为一个单独的迭代存在。

7、团队决定如何完成用户故事，可以应用刺探技术获得对不确定性的反馈。

8、团队成员在每日站会上提出问题，并将之可视化，以促进问题的解决。

9、团队通过产品待办事项和每日站会来监督供应商的工作。

10、要让技术债务可见，并按照正确的优先顺序进行处理，并将其插入到待办事项列表中。

11、技术债务也是产品代办列表的内容来源之一，要根据正确的优先顺序来处理技术债务问题。

12、在迭代审查会上审计（audit）风险。

 七、持续改进

1、迭代回顾会议的目的是为了发现哪些方面需要改进，在每个迭代之后都会开展回顾会议，团队成员聚在一起审视和提升工作方法和团队合作。

2、敏捷团队开始时可能犯错，但每隔一段时间总结应该如何做才能更加有效，然后相应地调整自己的行为。

3、迭代回顾一般不识别和讨论风险，发布回顾会议会讨论接下来的发布面临的风险。

4、考试中不声明一般是指迭代回顾。

八、敏捷实践方法

1、跨职能的团队是SCRUM中的关键词，而XP中突出的是完整的团队，并且Scrum是模仿XP的。

2、每日站会上不进行具体问题的讨论，问题的讨论及解决方案在会后专门找相关干系人处理。

3、SM要与干系人合作移除实施Scrum活动过程中产生的障碍，负责人是SM。

4、在第一次Sprint计划会议进行全面的风险识别和分析，将风险加入到信息发射源，在后续迭代的规划会议上识别新风险或对已识别的风险进行更新，包括概率和影响的变化。

5、完成的概念也就是DoD，应该由PO和团队共同来定义，而PO最终确认工作是否达到了验收标准。

6、冲刺待办事项列表在冲刺期间，一般是不进行增加和减少的，如有必要需PO批准。

7、在迭代期间，团队需要持续获得PO的反馈，以确保产品开发沿着正确的方向进行，迭代演示不是针对PO的，也不是只在演示时才获得PO的验收。

8、缩减范围以保持原进度还是保持原来的范围以延长进度时间，需要和PO协商处理。

9、结对编程看起来不那么有效率，但是它可以尽早地发现问题，并实现知识共享。

10、CFD中显示了Leadtime、Backlog Size，Remaining to be done、Cycletime和WIP。

11、Scrum中SM负责引导会议按照Scrum的规则完成，PO负责保证评审工作顺利完成。

12、在Scrum中，识别的风险不是被加入风险登记册，而是由PO加入待办事项列表中，并根据风险调整待办事项列表的优先顺序。

13、小的变更有PO批准，大的变更由关键干系人批准，批准的变更会反映在待办事项列表中，小变更通常没有流程，大变更要有专门的流程。

14、任务板一般由三栏To Do，In Progress和Done；看板相当于升级的任务板，看板的栏位要和具体的开发流程相对应，一般包括：输入、开发、测试、部署等过程。