# 传统与敏捷
# 预测型（瀑布型）存在的问题
- 用计划驱动，需求要明确，一开始就要收集详细的需求
- 如果需求经常发生变化，需要通过变更流程修改计划
- 一开始就要编写大量的文档
- 客户参与度不高，他们认为在收集需求的时候已经讲得很清楚了
- 需要花大量的时间来汇报当前的项目状态
- 价值只有到项目结束的时候才能显现，造成了较高风险
- 无法灵活应对市场变化
# MVP (Minimum Viable Product) 最小可行产品
- 开发团队通过提供最小可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。
- MVP 对于创业团队来说很重要，可以快速验证团队的目标，快速试错。
# 敏捷发布规划
# Scrum 框架
# 一个简单的例子
项目：
某家庭需要采购一批商品，包括主食、日用品、饮料、零食、调料、肉类、蔬菜等等。项目特点：
- 需求不明确，目前能想到的就是要采购这些，而且比较概括需要细化；
- 时间紧张，需要立即开始采购；
- 极有可能出现需求变更。
产品待办事项列表（PB)
优先级从高到低排序，越往上越详细，越往下越大概（做到的时候再细化）
每次采购的特点：
- 时间固定：来回 20 分钟
- 人力固定：一个人一个篮子
- 价值驱动：按照优先级采购
较小的增量，快速迭代，每次交付最有价值的东西
- 敏捷方法拥抱变更
- 当有新的需求出现，应该添加到 “待采购的商品” 列表中，排列优先级。
- 当前的采购一般不允许变更。
# Scrum 中的 3 个角色
# 产品负责人 PO
产品负责人是管理产品待办事项列表的唯一责任人。
包括:
- 清晰地表达产品待办事项列表条目
- 对产品待办事项列表中的条目进行排序，最好地实现目标和使命
- 确保产品待办事项列表对所有人可见、透明、清晰，并且显示 Scrum 团队的下一步工作
- 确保开发团队对产品待办事项列表中的条目达到一定程度的理解
产品负责人可以亲自完成上述工作，也可以让开发团队完成。然而产品负责人是最终责任人。
必须懂业务，最懂需求的人，与客户接触最多，才能写出待办事项 PB
# 开发团队
开发团队负责在每个 Sprint 的结尾交付潜在可发布的 “完成” 产品增量。
只有开发团队的成员才能创造增量。开发团队由组织构建并授权，来组织和管理他们的工作。
开发团队有以下几个特点:
- 他们是自组织的，没有人 (即使是 Scrum Master 都不可以) 告诉开发团队如何把产品待办事项列表变成潜在可发布的功能。
应该逐渐把团队成员培养成自主的自觉的，可以授权他们自己做一些决定。
- 开发团队是跨职能的，团队作为一个整体拥有创造产品增量所需要的全部技能。
- Scrum 不认可开发团队成员的头衔，无论承担哪种工作他们都是开发者。此规则无一例外。
- 开发团队中的每个成员可以有特长和专注领域，但是责任归属于整个开发团队。团队成员是 T 型人才。
I 型人才是指专精于一个领域，是传统项目常见的人才。
T 型人才是一专多能，就是有一个方向是自己比较擅长的，但是其他方面也懂一些。有利于任务的分配和团队的协作，是敏捷需要的人才- 开发团队不包含如测试或业务分析等负责特定领域的子团队。
# Scrum Master 敏捷教练 / 项目经理 / 促进者
- 负责确保 Scrum 被理解并实施。
- 为了达到这个目的，Scrum Master 要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。
- Scrum Master 是 Scrum 团队中的服务式领导。
偏管理，不一定懂业务
只关注，大家要遵守敏捷的思想，要理解敏捷的原则，；另一方面，及时帮助团队成员，帮助产品负责人要消除一些障碍。
简单的说，就是成员遇到什么困难，Scrum Master 帮忙解决；有谁在打扰成员工作，比如有客户、有相关方在干扰，Scrum Master 来帮助避免别人的干扰。
# Product Backlog – 产品待办事项列表
- 用户故事
- 作为一个 <角色>，我想要 < 功能 >，以便于实现 < 价值 >
- 角色：谁要使用这个功能。
- 功能：功能的相关描述。
- 价值：为什么需要这个功能，这个功能带来什么价值。
产品待办事项列表是一个排序的列表，包含所有产品需要的东西，也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。
产品待办事项列表列出了所有的特性、功能、需求、改进方法和缺陷修复等对未来发布产品进行的改变。
它是一个按照优先级由高到低排列的一个序列，排在顶部的产品待办事项列表条目需要立即进行开发。排序越高的产品待办事项列表条目比排序低的更清晰、更具体。根据更清晰的内容和更详尽的信息就能 做出更准确的估算。优先级越低，细节信息越少。
通过产品 Backlog 地梳理来增添细节、估算和排序。这是一个持续不断的过程，产品负责人和开发团队协作讨论产品代表事项列表条目的细节。
在产品待办事项列表梳理的时候，条目会被评审和修改。梳理在 Sprint 中是一项兼职活动，在产品负责人和开发团队之间展开。
# Sprint 冲刺
常翻译为 “冲刺” 或 “迭代”
Sprint 是 Scrum 的核心，其持续时间为一个月或更短时间的限时，以构建一个 “完成的”、可用的和潜在可发布的产品增量。
时间短且固定在整个开发过程期间，Sprint 的长度通常保持一致（规定的 “时间盒”）。
Sprint 由 Sprint 计划会议、每日 Scrum 站会、开发工作、Sprint 评审会议和 Sprint 回顾会议构成。
在 Sprint 期间不能做出有害于 Sprint 目标的改变。
Sprint 可以在 Sprint 结束之前取消。只有产品负责人才有取消 Sprint 的权力。
如果某个 Sprint 对其所在环境来说失去了价值和意义，那么它就应该被取消。
- 然而，由于 Sprint 的时间都很短，所以取消 Sprint 的意义不大。
# Sprint 计划会议
Sprint 中要做的工作在 Sprint 计划会议中来做计划。
开发团队自己决定选择产品待办列表项的数量。
- 只有开发团队可以评估接下来的 Sprint 可以完成什么工作。
产品负责人能够帮助解释清楚所选定的产品待办列表项，并作出权衡。
如果开发团队认为工作过多或过少，他们可以与产品负责人重新协商所选的产品待办列表项。
这个 Sprint 中所选出的产品待办列表项加上交付它们的计划称之为 Sprint 待办事项列表（Sprint Backlog）。
# Sprint Backlog – 冲刺（迭代）待办事项列表
每个 Sprint 的开始是 Sprint 计划会议。
Sprint 计划会议的前半段，产品负责人把待完成的高优先级功能介绍给 Scrum 团队。
Sprint 计划会议的后半段，开发团队可以针对这些功能提出问题，如果团队有信心完成某一个功能，就把这个功能从 Product Backlog 移动到 Sprint Backlog 中。
如果团队发现增加的工作量已经超过了整个团队一个 Sprint 能够完成的总量，团队会立即建议产品负责人停止。
理论上团队按照优先级次序选择用户故事直到团队认为足够为止。
- 实际情况中，团队也可能选择最高优先级的五个故事，然后又选择两个低优先级但是与前五个故事有关的故事。
- 团队会和产品负责人沟通，但是通常由团队决定一个 Sprint 完成多少。体现了团队的自组织
团队和产品负责人一起确定 Sprint 的目标，在 Sprint 结束时的 Sprint 评审会议中审视是否达成目标。
- 故事点
Story Point - 是一个度量单位，用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果。
- 我们可以选择一个最小的用户故事作为基准，来衡量其他的用户故事的工作量是多少个故事点；或用一个理想工作日作为一个故事点。
- 团队的速率
Velocity - 衡量团队在单个 Sprint 中可以解决的工作量的指标，也是 Scrum 的关键指标。
# 每日 Scrum 站会
每日 Scrum 站会是一个以 15 分钟为限的事件。Scrum Master 确保开发团队每日站会如期举行，但开发团队自己负责召开会议。
每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。
在会议上，每一个开发团队成员都需要说明：
- 昨天，我为帮助开发团队达成 Sprint 目标做了什么
- 今天，我为帮助开发团队达成 Sprint 目标准备做什么
- 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标。
注意：会上只记录问题而不讨论问题，为了不浪费别人的时间
另外，了解 SoS 会议 — Scrum of Scrums开发团队或者开发团队成员通常会在每日 Scrum 站会后立即聚到一起进行更详细的讨论，或者为 Sprint 中剩余的工作进行调整或重新计划。
Scrum Master 强制执行每日 Scrum 站会规则 —— 只有开发团队成员才能参加。
每日 Scrum 站会增进交流沟通、减少其他会议、发现开发过程中需要要移除的障碍并促进快速地做决策、提高开发团队的认知程度。这是一个进行检视与适应的关键会议。
# 信息发射源（信息扩散器）
- 在集中办公的区域设立一块大白墙或白板，上面用高可视化、图形化的方式展示出项目的实施状态和信息，如产品待办列表、问题列表、迭代燃尽图等等。
- 可以最大程度促进团队成员间、团队和相关方间透明式的信息流通。
- 敏捷提倡引导相关方观看信息发射源以获得项目状态，而不是单独发送项目状态报告。如：燃尽图，燃起图，累积流量图等。
燃尽图，哪些做了还剩多少，进度是快了慢了，所有的信息一目了然。这样做的好处就是可以减少很多不必要的会议。
# Product Increment – 产品增量
在 Sprint 的最后，新的增量必须是 “完成” 的，这意味着它必须可用并且达到了 Scrum 团队 “完成” 的定义的标准 DOD。
增量是在 Sprint 结束时可检视的和已完成的产品组成部分。
增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用。
# Sprint 评审会议
- Sprint 评审会议在 Sprint 快结束时举行 ，用以检视所交付的产品增量并按需调整产品待办列表。
- Scrum 团队和相关方协同讨论在这次 Sprint 中所完成的工作。
- 开发团队演示 “完成” 的工作并解答关于所交付增量的问题，演示增量的目的是为了获取反馈并促进合作。
- 参会的所有人就下一步的工作进行探讨，为下次的 Sprint 计划会议提供有价值的输入信息。
- Sprint 评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个 Sprint 的产品待办列表项。
敏捷要求客户频繁参与，不断的给予反馈，就是如果有问题，我们当场就能够发现问题。
# Sprint 回顾会议
- Sprint 回顾会议发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前。
- Scrum Master 鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得他们能在 下个 Sprint 中更高效更愉快。
- 在 Sprint 回顾会议结束时，Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。
每个 Sprint 都会完成一轮 pdca，每个 Sprint 都在做持续的改进。
对于敏捷项目来说，一般情况下，不太会签闭口合同，也就是固定的费用的合同
我们最多只能这么说，有一个粗略的、轻量级的估算
一般来说我们用的是包人头的方式。
