目录
1、Scrum：
敏捷里的3355：
什么是Scrum：
Scrum的优点：
Scrum的理论：
Scrum的三大支柱：
透明性：
检视：
调整：
2、Scrum的角色简介：
Scrum各角色的关键：
PO：
Scrum Master：
团队：
（其他）敏捷教练：
3、Scrum事件：
Sprint：
Sprint Planning：
Daily Scrum：
Sprint Review：
Sprint Retrospective：
4、Scrum的三个工件：
产品待办列表（Product Backlog）
Sprint 待办列表（Sprint Backlog）
产品增量（PSPI：Potentially Shippable Product Increment）
5、Scrum的5个仪式（会议）：
所有的会议都会在每次迭代中重复。
① 冲刺计划会议：
② 每日站立会议：
③ 冲刺评审会议（review）：
④ 冲刺回顾会议（retrospective）：
⑤ 待办事项梳理会(Grooming)：
6、其他概念：
1、Scrum：
敏捷里的3355：
3种角色：产品负责人（PO，Product Owner）、Scrum Master、开发团队（Dev Team）
3个工件：产品、迭代Backlog、产品增量
5个仪式：冲刺计划会议、每日站立会议、 冲刺评审会议、冲刺回顾会议、待办事项梳理
5个价值观：勇气、开放、专注、承诺、尊重
什么是Scrum：
Scrum 是一个轻量的框架，它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织创造价值，Scrum 是用于管理产品开发的单个团队过程框架。该框架包含 Scrum 角色、事件、工件和规则，采用迭代方法来交付工作产品。
Scrum的优点：
Scrum 提供简单和可证明的结果它包含其他敏捷工程技术它强调小型团队和团队授权欢迎需求的变更它允许单一来源的优先项目工作开展Scrum 会议包括日常状态会议提供团队在冲刺阶段一个潜在的可交付增量承诺
Scrum的理论：
Scrum 基于经验主义和精益思维。 经验主义主张知识源自实际经验以及根据当前观察到的事物作出的判断所获得。精益思维减少浪费，专注于根本。
Scrum 采纳一种迭代和增量的方法来优化对未来的预测性并控制风险。 Scrum 让一群共同拥有所 有技能和专长的人员参与进来完成工作，并根据需要分享或获得所需技能。
Scrum 将 4 个正式事件组合在一起以在一个容器型事件 Sprint 中进行检视和适应。这些事件之所 以起作用，是因为它们实现了基于经验主义的 Scrum 的三个支柱：透明、检视和适应。
Scrum的三大支柱：
透明性：
过程或项目的各个方面必须是对结果负责任的，透明的；
运用信息发射源，让这些关键信息，如产品待办事项列表、冲刺待办事项、障碍、风险和项目进展对所有的利益相关者是透明的。
透明度较低的工件可能导致做出降低价值并增加风险的决策。透明使检视成为可能，没有透明的检视会产生误导和浪费。
检视：
团队根据项目目标定期检查他们的绩效和进展；
他们不断寻找问题和计划的偏离。
检视使适应成为可能，没有适应的检视是毫无意义的。Scrum 事件旨在激发改变。
调整：
基于观察期间的检查，采取必要的变更流程，以避免问题再次发生，提高项目交付成功率。
当所涉人员没有得到授权或不能自管理（self-managing）时，则适应将变得更加困难。在通过检 视学到任何新东西时，Scrum Team 会做出相应调整。
2、Scrum的角色简介：
Scrum 团队一般由 5 到 9 个（7±2）团队成员组成。有三种类型角色：
产品负责人（PO，Product Owner）：
产品负责人定义项目愿景、需求和优先级，对产品成功负责。
Scrum Master：
负责团队，并移除障碍，帮助他们实现产品负责人所设定的目标。
开发团队（Dev Team）：
自组织、跨职能。他们协同工作，以确定如何最好地满足产品负责人的目标。
Scrum各角色的关键：
PO：
客户代表，定义所有产品功能，决定产品发布的内容以及日期，对产品的投入产出负责，根据市场变化对需要开发的功能排列优先顺序，合理地去调整产品功能和迭代顺序，认同或拒绝迭代的交付，确保开发团队知道产品待办事项列表。
清晰地表达产品待办列表项对产品待办列表项进行排序，最好地实现目标和使命优化开发团队所执行工作的价值确保产品待办列表对所有人可见、透明、清晰，并且显示 Scrum 团队的下一步工作确保开发团队对产品待办列表项有足够的理解
Product Owner 可以自己做上述工作，或者也可以将职责委托他人。 然而无论如何， Product Owner 是负最终责任的人。
Product Owner 是一个人，而不是一个委员会。在 Product Backlog 中，Product Owner 可以代表许 多利益攸关者的期望要求。那些想要改变 Product Backlog 的人可以尝试去说服 Product Owner 来 做到这一点。
Scrum Master：
项目早期SM和PM相对统一（制定规则、管理期望、管理相关方、指定沟通策略、管理承诺等），项目执行起来之后SM和PM进行切割（不做决策），鼓励言论自由，保证仪式，团队有问题优先内部讨论解决，保护团队一个整体。
Scrum Master 负责确保所有人都能正确地理解并实施 Scrum。因此，Scrum Master 要确保 Scrum 团 队遵循 Scrum 的理论、实践和规则。 Scrum Master 是真正的领导者，是 Scrum 团队中的服务型领导。
Scrum Master 帮助 Scrum 团队外的人员了解他们如何 与 Scrum 团队交互是有益的，通过改变他们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。Scrum Master 在期望设定和管理中扮演重要角色，以此去创建高绩效团队。
1）Scrum Master的职责是：
在项目生命周期早期定义基本规则；确保团队理解干系人期望；同团队沟通项目愿景，有利于确保团队；认识到他们的目标同项目总目标紧密一致；以连贯的单元模式工作；对愿景给予承诺。
2）Scrum Master制定的基本规则包括：
设定Scrum仪式的开始-结束时间；保持对主题的专注减少分散；会议期间杜绝中断；允许团队成员特别是初级成员言论自由；在制定决策前应广泛搜集所有成员意见。
3）Scrum Master 以多种方式服务于 Scrum Team ，包括：
作为教练在自管理和跨职能方面辅导 Scrum Team 成员；帮助 Scrum Team 专注于创建符合 Definition of Done 的高价值 Increment；促使移除 Scrum Team 工作进展中的障碍；确保所有 Scrum 事件都发生并且是积极的、富有成效的，并且在时间盒（timebox）内完成。
4）Scrum Master 以多种方式服务于 Product Owner，包括：
帮助找到有效定义 Product Goal 和管理 Product Backlog 的技巧；帮助 Scrum Team 理解为何需要清晰且简明的 Product Backlog 条目；帮助建立针对复杂环境的基于经验主义的产品规划（empirical product planning）；当需要或被要求时，引导利益攸关者协作。
5）Scrum Master 以多种方式服务于组织，包括：
带领、培训和作为教练辅导组织采纳 Scrum；在组织范围内规划并建议 Scrum 的实施；帮助员工和利益攸关者理解并实施针对复杂工作的经验主义方法（empirical approach）；消除利益攸关者和 Scrum Teams 之间的隔阂。
团队：
自主选择，全职能（这意味着团队成员具有在每个 Sprint 中创造价值而 所需的全部技能），跨团队本身不进行解决，决策在团队内，平级的，没有子团队或层次结构。
有自主权选择如何最好地满足目标，并且为之负责。即是自管理的，这意味着他们在团队内部决定谁做什么、何时做以及如何做。
（其他）敏捷教练：
指掌握了敏捷知识和经验的人员其在组织和团队转型中能够发挥培训、辅导和指导的作用。 敏捷教练可以是内部教练或外部教练，教练需要：
跟不同团队共事时具备平衡视角；每个团队具备不同的进展节奏，可能会面临制约，需要帮助去克服；忠于团队成员价值；认识社会心理及团队复杂性；运用有效方法解决团队面临的问题；开发方法进行非侵入型干预从而改变团队动力；学习真正需要什么才能让人们作为一个团队去工作。
3、Scrum事件：
Sprint 是所有其他事件的容器。Scrum 中的每个事件都是检视和适应 Scrum 工件的正式机会。这些事件都是为实现所需的透明度而特别设计的。未能按规定运作任何事件将导致失去检视和适应的 机会。Scrum 使用事件来创造规律性，并以此最小化对 Scrum 中未定义的会议的需要。最理想的是，所有事件都在同一时间同一地点举行，以便减少复杂性。
Sprint：
Sprint 是 Scrum 的核心，在这里创意（idea）转化为价值。
它们是固定时长的事件，为期一个月或更短，以保持一致性。前一个 Sprint 结束后，下一个新的Sprint 紧接着立即开始。 实现 Product Goal 所需的所有工作，包括 Sprint Planning、Daily Scrum、Sprint Review 和 Sprint Retrospective，都发生在 Sprint 内。
在 Sprint 期间：
不能做出危及 Sprint Goal 的改变；不能降低质量；Product Backlog 按需进行精化（refined）；随着学到更多，可以与 Product Owner 就范围加以澄清和重新协商。
Sprint 通过确保至少每个日历月一次对达成 Product Goal 的进展进行检视和适应，来实现可预测性。当 Sprint 的长度拉得太长时，Sprint Goal 可能会失效，复杂性可能会上升，同时风险可能会增加。可以使用较短的 Sprint 来产生更多的学习周期，并将成本与工作投入（effort）的风险限制在更短的一段时间内。每个 Sprint 都可以视为一个短期的项目。
如果 Sprint Goal 已过时，那么就可以取消 Sprint。只有 Product Owner 有取消 Sprint 的权力。
Sprint Planning：
Sprint Planning 通过安排在 Sprint 中要做的工作来启动 Sprint。最终的计划是由整个 Scrum Team 协作创建的。
Product Owner 要确保与会者准备好讨论最重要的 Product Backlog 条目 ，以及它们如何映射到Product Goal 。Scrum Team 还可以邀请其他人参加 Sprint Planning 以提供建议。 Sprint Planning处理以下话题：
话题一：为什么这次 Sprint 有价值？话题二：这次 Sprint 能完成（Done）什么？话题三：如何完成所选的工作？
Daily Scrum：
Daily Scrum 的目的是检视达成 Sprint Goal 的进展，并根据需要调整适应 Sprint Backlog，以调整即将进行的计划工作。Daily Scrum 是一个属于 Scrum Team 的 Developers 的 15 分钟的事件。为了降低复杂性，它在 Sprint 的每个工作日都在同一时间同一地点举行。如果 Product Owner 或Scrum Master 正在积极处 理 Sprint Backlog 条目，那么他们将作为 Developers 参与其中。
Sprint Review：
Sprint Review 的目的是检视 Sprint 的成果并确定未来的适应性。Scrum Team 向关键利益攸关者展 示他们的工作结果，并讨论 Product Goal 的进展情况。
在 Sprint Review 期间，Scrum Team 和利益攸关者将评审在这次 Sprint 中完成了什么，以及环境发 生了什么变化。基于这些信息，与会者可以就下一步的工作进行协作。 Product Backlog 也可能会 进行调整以适应新的机会。Sprint Review 是一个工作会议，Scrum Team 应避免将其仅限于展示。
Sprint Retrospective：
Sprint Retrospective 的目的是规划提高质量和效能的方法。
4、Scrum的三个工件：
Scrum 的工件以不同的方式表现工作任务和价值，可以用来提供透明性以及检视和调整的机会。Scrum 中的工件就是为了最大化关键信息的透明性，因此每个人都需要有相同的理解。
Scrum 的工件代表工作或价值。 它们旨在最大限度地提高关键信息的透明度。 因此，为适应而检 视它们的每个人对工件都有相同的基础。 每个工件都包含一个承诺，以确保它提供可增强透明度并聚焦于可度量进展的信息：
对于 Product Backlog 而言，它是 Product Goal。对于 Sprint Backlog 而言，它是 Sprint Goal 。对于 Increment 而言，它是 Definition of Done。
这些承诺的存在是为了强化经验主义和 Scrum Team 及其利益攸关者的 Scrum 价值观。
产品待办列表（Product Backlog）
包含业务需求、技术需求、NFR（非功能性需求）等，理想情况下，每个一待完成的工作都将对客户产生价值，PO对该列表进行优先级排序，每个迭代开始前，优先级排序还需要再度修正。
产品需求列表；产品负责人对该列表进行优先级排序；待办事项列表中的条目以用户故事的形式呈现；是 Scrum Team 所 承担工作的唯一来源。
Sprint 待办列表（Sprint Backlog）
Sprint Backlog 由 Sprint Goal （为什么做）、为 Sprint 选择的 Product Backlog 条目（做什么）以及交付 Increment 的可执行计划（如何做）组成。
是产品待办列表的子表，只记录当前迭代的工作；将用户故事拆分成任务，团队成员主动领取任务；团队成员可以添加、删减或者更改迭代中的任务。
团队成员有共同的迭代目标，为交付可工作的成功努力，迭代列表种的任务进行了估算，剩余的工作了估计每天需要更新。
产品增量（PSPI：Potentially Shippable Product Increment）
团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付；每次交付的用户故事必须符合验收条件。每次交付的增量必须处于可用状态，而不管是PO是否决定发布这个用户故事（交付和上线）。
5、Scrum的5个仪式（会议）：
所有的会议都会在每次迭代中重复。
① 冲刺计划会议：
Scrum 团队的所有成员出席，在此次会议中，开发团队识别当前冲刺开发交付的产品待办事项中的故事。
这个会议时间箱为：一个月的冲刺，会议时间 8 小时，4 个小时用于选择故事和 4 个小时估算分配。
② 每日站立会议：
由 Scrum Master 和开发团队参加，产品负责人可以自行选择是否参加。每日站立会议是快速专注 的会议，用来分享迭代或迭代进展。 每个团队成员就他们将要完成的任务对其他人做口头承诺。
每个团队成员回答以下问题：“昨天做什么?”，“今天将做什么?” ，“遇到了什么问题?”。
每日立会只有Scrum Master，PO， Team的角色可以发言，团队成员以外的管理角色不可以发言 这次会议时间箱 15 分钟，每天发生在同一时间和地点。
③ 冲刺评审会议（review）：
这次会议是由 Scrum 团队的所有成员参加。 开发团队将可能移交的可交付物开发特性演示给干系人和项目发起人。
Sprint评审会议的结果是一份修订的产品待办列表，确定很可能进入下个Sprint的产品待办列表项。 这个会议时间箱为一个月的迭代，4 个小时，比冲刺计划会议的持续时间更短。
（1）冲刺评审是在迭代末期进行的时间盒（有指定时间限制）会议，此时不断变化的解决方案展示给利益相关者，他们的反馈得到收集。 该会议是：
针对冲刺末期召开；被时间盒定义到四个小时，按月冲刺和较短的时间段；冲刺评审会议由包括开发团队，产品负责人，Scrum Master，和企业的利益相关者的整个团队出席；这些冲刺评审会议被团队通过录音、快照来展示产品。
（2）冲刺评审的益处是进行常规冲刺评审会议有助于：
产品根据利益相关者的需要在变化；任何反馈或升级在即将到来的冲刺或发布中被记录和强调；优先级排序的待办事项将被展示给利益相关者去评估是够满足他们的期望；逐步完善未来的项目计划。
（3）冲刺评审的重要性在一个 2 周冲刺的项目中，没有组织冲刺会议将导致项目进度落后于整整一个月。 这是因为：
开发的需求没有满足利益相关者的期望；为即将到来的冲刺所选择的需求，没有同利益相关者的需求保持一致。
④ 冲刺回顾会议（retrospective）：
是由 Scrum 团队的所有成员参加。这次会议的焦点是对整个迭代进行回顾。细节包括：什么进行顺利，缺少什么，需要改变什么等等。团队就未来的迭代改进计划达成一致。这个会议时间框为一 个月的迭代，3 个小时，比迭代评审时间短。
冲刺回顾是针对迭代末期进行的时间盒（有指定时间限制）会议，目的是认识团队可以如何提高他们的工作方式，就未来的迭代改进计划达成一致，该会议：
针对冲刺末期召开；被时间盒定义到三~四个小时按月冲刺和较短的时间段；由包括开发团队，产品负责人，ScrumMaster，和企业的利益相关者的整个团队出席；在冲刺回顾中，团队将认识到他们做的好的领域以及有待改进的领域。来自于回顾会议的反馈对实施持续改进策略和最大化团队交付价值非常关键。细节包括：什么进行顺利，缺少什么，需要改变什么等等…
⑤ 待办事项梳理会(Grooming)：
Scrum 团队在冲刺中经常会面进行待办事项的梳理。 梳理或细分是一种逐步完善待办事项的方法，所以它会保留现有信息同时反映利益相关者的需要。 该会议有助于：
增加新用户故事；丢弃不相关的用户故事；估算新增加的用户故事；重新估算用户故事；对用户故事进行优先级重排序；史诗分解成更小的用户故事。
需要记住的点：
梳理会议提供了调整估算范围的最佳时机；利益相关者的期望通过对产品待办事项进行与时俱进的更新来管理；已经完成优先级排序和更新的产品待办事项应该作为冲刺评审会议的一部分由利益相关者来评审；来自于运营和维护问题的反馈需要被考虑，新需求必须添加到产品待办事项中；识别出的现有缺陷经过分析后，需要确保他们在梳理会议上被讨论。
6、其他概念：
MVP三个最小：最小可交付价值、最小可售单元、最小可行性产品。
敏捷发布计划：在一个敏捷项目中，了解实际项目进度所需要看的。
DOD完成的定义：它是团队需要满足的所有标准的核对单，只有可交付成果满足该核对单才能视为准备就绪可供客户使用。
探测：敏捷中使用的一种技术，一般情况下只用来判断可行性的所有不确定地方，有风险、技术、商业模式等。
优先级技术-MoSCoW：MoSCoW 技术是进行需求优先级排序的敏捷方法。在这种技术下，需求基于以下方面排序：
①Must 必须有-这些需求是强制性的
②Should 应该有-这些需求不是强制性的，但是高度渴望的
③Could 可以有-这些需求如果满足会很好
④Won’t 不会有-当下可以不去满足，但是将来可以加入 在开始新一轮时间箱前，会有一个新的 MUSTs 加入。这些可能是新的需求，或者现有需求被调整 优先级进而转移成为 MUSTs。
Kanban看板：
看板在项目实施期间作为信息发射源运用，它有助于相关干系人去了解冲刺或迭代的当下状态。
①看板是一个跟精益和及时制生产相关的概念。
任务板被细分成段来反映关键活动故事是由索引卡或代表的便利贴来表示。卡的状态由它在任务板上的位置来表示，并随着项目进展从开始到结束变化。看板帮助团队意识到他们是如何工作以及下一步要做什么。让团队形成自我指挥。
②kanban 卡片
Kanban 任务板上的每一张卡片就是 kanban 卡片。Kanban 卡片用来显示迭代过程。Kanban 任务板上的卡片呈现在开发周期的不同环节中移动的工作部件。Kanban 卡片反映所有需要被跟踪的事物。例如：用户故事，缺陷，任务。在用户故事定义完整前，相关干系人需要对用户故事必须经历的部分进行评估。
③简化的看板面板简化的看板面板有待完成、进展中、已完成3列，任务用卡片表示，卡片状态展示在其中一列的下方。
精彩内容
您阅读本篇文章共花了：
发表评论