一、敏捷思想概念总结
1、：
我们一直在实践中探索更好的软件开发方法，在实践中帮助他人，从而建立起来 了解以下价值观：
-
个体与互动重于 流程和工具 -
工作的软件重于 详尽的文档 -
客户协作重于 合同谈判? 响应变化 重于 遵循计划
也就是说，虽然右项有其价值，但我们更注重左项的价值。
2、：
-
我们最重要的目标是通过不断提前交付有价值的软件来满足客户
-
面对需求的变化，即使在开发的后期，敏捷过程也能为客户的竞争优势控制变化
-
经常交付可以工作的软件，往往每隔几周或一两个月就会采取较短的周期
-
业务人员和开发人员必须相互合作，项目中的每一天都不例外
-
激发个人斗志，以他们为核心建设项目，提供所需的环境和支持，辅以信任，实现目标
-
无论团队内外，传递信息的最佳效率和最高方式都是面对面的对话
-
可以工作的软件进度的主要测量标准
-
敏捷过程提倡可持续发展，责任人、开发人员和用户应能够共同保持稳定的步伐
-
不懈追求卓越的技术和良好的设计，提高敏捷性
-
以简洁为基础，是一门艺术，尽量减少不必要的工作量
-
来自组织团队的最佳架构、需求和设计
-
团队定期反思如何提高效果，并调整自己的行为
3.敏捷核心实践和原则
? 尽快演示迭代中交付的价值
? 用户故事反映了商业价值和优先级
? 客户不断改进
? 所有要求的验收试验
? 回顾
? 节奏或速度可持续
? 沟通
? 高度可视化
? 预设计和需求收集
? 项目完工预测
? 死亡行军项目：项目团队免费加班以弥补估计差距
? 任务管理工具等强制使用工具
? 管理和控制自上而下
? 大量文件、特殊状态报告、软件架构图、软件需求规格说明书、测试计划
? 强调合作、团队授权、频繁的过程演示
? 轻量级，依靠白板，概要卡和方便工具
? 开发重点吸引开发者
? 上市时间更快，生命周期由高优先级特征驱动，
? 注意，拉而不是推
? 容易理解
? 满足客户的需求
二、敏捷3355- Scrum 角色 工件 活动
（3 种角色、 5 个仪式、 3 个工件、 5 个价值观） 
Scrum 是管理产品开发的单一团队过程框架。该框架包括 Scrum 人物、事件、工件和规则采用迭代方法交付工作产品。
? Scrum 提供简单和可证明的结果
? 它包括其他敏捷工程技术
? 它强调小团队和团队的授权
? 欢迎变更需求
? 允许单源优先项目开展
? Scrum 会议包括日常状态会议
? 在冲刺阶段提供潜在的可交付增量承诺
透明性：
? 过程或项目的各个方面都必须对结果负责，透明；
? 利用信息发射源，使这些关键信息，如产品待办事项列表、冲刺待办事项、障碍、风险和项目进展对所有利益相关者都是透明的。
检视：
? 根据项目目标，团队定期检查其绩效和进
? 他们不断寻找问题和计划之间的偏差。
调整：
? 根据观察期间的检查，采取必要的变更过程，避免问题再次发生，提高项目交付成功率。
Scrum 团队由 5 到 9 个（7±2)由团队成员组成。有三种角色:
? 产品负责人（PO）：产品负责人定义项目愿景、需求和优先级，对产品成功负责。
? Scrum Master：负责团队，消除障碍，帮助他们实现产品负责人设定的目标。
? 开发团队：自组织、跨职能。他们合作确定如何最好地满足产品负责人的目标。
团队中有鸡和猪的角色，猪的角色包括 scrum master，PO, team；“鸡” 角色是指团队成员以外的管理角色
? 清晰表达产品待办列表
? 排序产品待办列表项，最好实现目标和使命
? 优化开发团队执行的价值
? 确保所有人都能看到、透明、清晰地显示产品待办列表 Scrum 团队的下一步
? 确保开发团队对待办产品列表有足够的了解
Scrum Master 负责确保每个人都能正确理解和实施 Scrum。因此，Scrum Master 要确保
Scrum 团队遵循 Scrum 理论、实践和规则。
Scrum Master 是 Scrum 服务型领导团队。Scrum Master 帮助 Scrum 团队外的人知道他们是如何与他们交谈的 Scrum 通过改变他们与团队的互动是有益的 Scrum 最大化团队互动模式 Scrum 团队创造的价值。Scrum Master 在期望设置和管理中发挥重要作用，中发挥重要作用。
A）Scrum Master的职责是： ??在项目生命周期早期定义基本规则；
??确保团队理解关系人的期望；
??与团队沟通项目愿景，有利于确保团队；
??认识到他们的目标与项目的总体目标密切一致；
??以连贯的单元模式工作；
??承诺愿景。
B）Scrum Master制定的基本规则包括：
??设定Scrum仪式开始-结束时间；
??减少主题的分散；
??会议期间停止中断；
??允许团队成员，特别是初级成员自由发言；
??在做出决定之前，应广泛收集所有成员的意见。
3）团队：
有自主权选择如何最好地满足目标负责。
Scrum 工件以不同的方式表达工作任务和价值，可以提供透明度、检查和调整的机会。Scrum 工件是为了最大化关键信息的透明度，所以每个人都需要相同的
的理解。
1 产品待办列表（Product Backlog）
??产品需求列表；
??产品负责人优先排序列表；
??待办事项列表中的条目以用户故事的形式呈现；
2 Sprint 待办列表（Sprint Backlog）
??是产品待办列表的子表，只记录当前迭代工作；
??将用户故事分成任务，团队成员主动接收任务；
??迭代中的任务可以由团队成员添加、删除或更改。
3 产品增量（PSPI：Potentially Shippable Product Increment）
??团队在迭代中完成交付结果，集成到以前的迭代结果中，形成增量交付。
??每次交付的用户故事必须符合验收条件。
4、Scrum 会议(5 个仪式)
**① 冲刺计划会议：**Scrum 团队的所有成员出席，在此次会议中,开发团队识别当前冲刺开发交付的产品待办事项中的故事。
这个会议时间箱为：一个月的冲刺，会议时间 8 小时，4 个小时用于选择故事和 4 个小时估算分配。
由 Scrum Master 和开发团队参加,产品负责人可以自行选择是否参加。每日站立会议是快速专注的会议，用来分享迭代或迭代进展。
每个团队成员就他们将要完成的任务对其他人做口头承诺。
每个团队成员回答以下问题:
“昨天做什么?”
“今天将做什么?”
“遇到了什么问题?“
每日立会只有猪的角色可以发言，鸡的角色不可以发言
这次会议时间箱 15 分钟,每天发生在同一时间和地点。
这次会议是由 Scrum 团队的所有成员参加。
开发团队将可能移交的可交付物开发特性演示给干系人和项目发起人。
Sprint 评审会议的结果是一份修订的产品待办列表，确定很可能进入下个 Sprint 的产品待办列表项。
这个会议时间箱为一个月的迭代，4 个小时，比冲刺计划会议的持续时间更短。
1、冲刺评审是在迭代末期进行的时间盒（有指定时间限制）会议，此时不断变化的解决方案展示给利益相关者，他们的反馈得到收集。
该会议是：
针对冲刺末期召开；
被时间盒定义到四个小时，按月冲刺和较短的时间段；
冲刺评审会议由包括开发团队，产品负责人，Scrum Master，和企业的利益相关者的整
个团队出席；
这些冲刺评审会议被团队通过录音、快照来展示产品。
2、 冲刺评审的益处进行常规冲刺评审会议有助于：
产品根据利益相关者的需要在变化；
任何反馈或升级在即将到来的冲刺或发布中被记录和强调；
优先级排序的待办事项将被展示给利益相关者去评估是够满足他们的期望；
逐步完善未来的项目计划。
3、 冲刺评审的重要性在一个 2 周冲刺的项目中，没有组织冲刺会议将导致项目进度落后于整整一个月。
这是因为：
开发的需求没有满足利益相关者的期望；
为即将到来的冲刺所选择的需求，没有同利益相关者的需求保持一致。
是由 Scrum 团队的所有成员参加。这次会议的焦点是对整个迭代进行回顾。细节包括：什么进行顺利，缺少什么，需要改变什么等等。团队就未来的迭代改进计划达成一致。这个会议时间框为一个月的迭代，3 个小时，比迭代评审时间短。
如上图所示，,所有的会议都会在每次迭代中重复。
冲刺回顾是针对迭代末期进行的时间盒（有指定时间限制）会议，目的是认识团队可以如何提高他们的工作方式，就未来的迭代改进计划达成一致，该会议：
针对冲刺末期召开；
被时间盒定义到三~四个小时按月冲刺和较短的时间段；
由包括开发团队，产品负责人，ScrumMaster，和企业的利益相关者的整个团队出席；
在冲刺回顾中，团队将认识到他们做的好的领域以及有待改进的领域。
来自于回顾会议的反馈对实施持续改进策略和最大化团队交付价值非常关键。
细节包括：什么进行顺利，缺少什么，需要改变什么等等……
Scrum 团队在冲刺中经常会面进行待办事项的梳理。
梳理或细分是一种逐步完善待办事项的方法，所以它会保留现有信息同时反映利益相关者的需要。
该会议有助于：
增加新用户故事；
丢弃不相关的用户故事；
估算新增加的用户故事；
重新估算用户故事；
对用户故事进行优先级重排序；
史诗分解成更小的用户故事。
需要记住的点：
梳理会议提供了调整估算范围的最佳时机；
利益相关者的期望通过对产品待办事项进行与时俱进的更新来管理； 已经完成优先级排序和更新的产品待办事项应该作为冲刺评审会议的一部分由利益相
关者来评审；
来自于运营和维护问题的反馈需要被考虑，新需求必须添加到产品待办事项中；
识别出的现有缺陷经过分析后，需要确保他们在梳理会议上被讨论。
三、其他常考知识点
它是指掌握了敏捷知识和经验的人员其在组织和团队转型中能够发挥培训、辅导和指导的作用。
敏捷教练可以是内部教练或外部教练，教练需要：
1）跟不同团队共事时具备平衡视角；每个团队具备不同的进展节奏，可能会面临制约，需要帮助去克服；
2）忠于团队成员价值；
3）认识社会心理及团队复杂性；
4）运用有效方法解决团队面临的问题；
5）开发方法进行非侵入型干预从而改变团队动力；
6）学习真正需要什么才能让人们作为一个团队去工作。
仆人式领导是一种为团队赋权的方法。仆人式领导是通过对团队服务来领导团队的实践，它注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。仆人式领导的作用是促进团队发现和定义敏捷。仆人式领导实践并传播敏捷。仆人式领导按照以下顺序从事项目工作：
目标确立后，鼓励团队创造一个人人都能成功的环境。要求每个团队成员在项目工作中做出贡献。
值并反思产品和过程，团队就是敏捷的。团队将其过程称作什么并不重要。
A. 提升自我意识；
B. 倾听；
C. 为团队服务；
D. 帮助他人成长；
E. 引导与控制；
F. 促进安全、尊重与信任；
G. 促进他人精力和才智提升
MoSCoW 技术是进行需求优先级排序的敏捷方法。在这种技术下，需求基于以下方面排序：
1）Must 必须有-这些需求是强制性的
2）Should 应该有-这些需求不是强制性的，但是高度渴望的
3）Could 可以有-这些需求如果满足会很好
4）Won’t 不会有-当下可以不去满足，但是将来可以加入在开始新一轮时间箱前，会有一个新的 MUSTs 加入。这些可能是新的需求，或者现有需求被调整优先级进而转移成为 MUSTs。
看板在项目实施期间作为信息发射源运用，它有助于相关干系人去了解冲刺或迭代的当下状态。
1）看板是一个跟精益和及时制生产相关的概念。
任务板被细分成段来反映关键活动。
故事是由索引卡或代表的便利贴来表示。
卡的状态由它在任务板上的位置来表示，并随着项目进展从开始到结束变化。
看板帮助团队意识到他们是如何工作以及下一步要做什么。让团队形成自我指挥。
2）kanban 卡片
Kanban 任务板上的每一张卡片就是 kanban 卡片。
Kanban 卡片用来显示迭代过程。
Kanban 任务板上的卡片呈现在开发周期的不同环节中移动的工作部件。
Kanban 卡片反映所有需要被跟踪的事物。例如：用户故事，缺陷，任务。
在用户故事定义完整前，相关干系人需要对用户故事必须经历的部分进行评估。
3）简化的看板面板简化的看板面板有 3 列:
待完成
进展中
已完成
任务用卡片表示，卡片状态展示在其中一列的下方。
五问法是一种通过不断重复询问为什么来识别问题根本原因的技术。每个为什么的答案成为了识别下一个为什么的驱动力。
确切地说，不是强制的使用五个“为什么”来深入到问题的根源，“五”只是一个指示性的数字。这种技术同鱼骨图结合起来使用提供了一个问题解决可视化过程。
它是团队需要满足的所有标准的核对单，只有可交付成果满足该核对单才能视为准备就绪可供客户使用。
信息发射源概念由 Alistair Cockburn 发明。根据他的理解，信息发射源的定义是：一个信息发射源在任何人都可见的地方显示信息。有了信息发射源，大家不需要问任何问题。
信息发射源的特征有：让团队成员可以看见项目和项目进展的当前状态；大部分敏捷团队在过程中不同程度使用它。
最受欢迎的信息发射源有：任务板；大型可视化表格，包括燃尽图；持续集成构建健康指标，包括街灯等。
信息发射源有助于对于成功验收、交付物的共识。
信息发射源用来促进干系人期望管理，对当下进行的工作可见、透明。 他们提供团队日常进展、工作质量、障碍和风险的视图。
敏捷项目中运用的一些信息发射源有：燃起图；燃尽图；看板或任务板；障碍日志
燃起图根据工作范围展示已完成工作量。在特征驱动开发中又被称为“特征完工图“
上图显示了在第五次迭代前后范围增加。
燃尽图显示在一次迭代或发布中的剩余工作量。这些图可以用来追踪实际速度和预期速度的对比，评估项目绩效。
燃起图和燃尽图用来预测团队最可能的速度，团队按照这个速度去开发即将到来的冲刺或迭代交付物，从而促进有效计划。
最小可交付价值
最小可售单元
最小可行性产品
在敏捷开发中，WIP 限制决定了每种情况下的工作流中可以存续的最大工作量。限制进行中的工作数量可以更容易辨识团队工作流中的无效工作。在情况变得更糟前，一个团队在持续交付通道中的瓶颈是非常容易辨别的。
WIP 限制通过强制让团队聚焦在更小的一套任务中来改善吞吐量和减少“将要完成”的工作量。从根本上来讲，WIP 限制鼓励的是“完成”的文化。更重要的是，WIP 限制可以让阻碍和瓶颈显而易见。当有明确指示现有工作遇到瓶颈时，团队可以聚焦在阻塞问题上尽快的理解、实施和解决。一旦消除阻塞，团队中的工作将再次开始流动。这些优势可以确保在最短的时间内向用户交付有价值的增量，从而使得 WIP 限制成为敏捷开发中一个非常有价值的工具。