# 前言
# 预测型（瀑布型）的特点
- 用计划驱动，需求必须明确，一开始就要收集详细的需求
- 如果需求经常发生变化，需要通过变更流程修改计划
- 一开始就要编写大量的文档
- 客户参与度不高，他们认为在收集需求的时候已经讲得很清楚了
- 需要花大量的时间来汇报当前的项目状态
- 价值只有到项目结束的时候才能显现，造成了较高风险
- 无法灵活应对市场变化
# MVP (Minimum Viable Product) 最小可行产品
开发团队通过提供最小可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。MVP 对于创业团队来说很重要，可以快速验证团队的目标，快速试错。
# STACEY 矩阵
在项目开始时，发起人就声明，表现产品的优势将极其重要。因为项目具有高度的不确定性，预计会发生许多变化。所以项目发起人与项目经理和项目领导团队召开会议，讨论最佳方法。项目经理应该提出什么建议？
项目具有高度的不确定性
一位项目经理正在领导一个处于启动阶段的新项目，该项目将构建一种新型的软件技术服务，这种服务以前在组织中从未存在过，并将为几个运营团队重组业务流程。该项目经理需要决定将要使用的项目管理方法，许多团队成员和相关方的意见相互矛盾。项目经理应该做什么？
A - 先分析，再决定，选这个
# 混合型生命周期
这是一个过渡
从传统的瀑布型 / 预测型到敏捷的过渡
- 许多团队无法在一夜之间切换到敏捷工作方式
- 组织越大，活动越多，转换需要的时间就越长
- 可以在风险不大，具有中低程度不确定性的项目中尝试
- 在成功使用混合方法后，再尝试更复杂的项目实现渐进过渡
一个组织正在努力启动一个重要项目。项目经理已确定范围定义是阻止项目启动的主要工作项。虽然大多数范围的工作项都是在相关方之间定义和商定的，但有一些工作项在这个阶段很难掌握，而且很复杂。项目经理应该做什么？
A - 完全用敏捷不合适，因为大多数已经掌握了
B - 也就是混合方法
C - 必须要用预测，这是不行的
D - 还是在说要明确范围，所以错误一名项目经理已被指派到正在启动的一个大型项目中，以交付复杂的设备。项目的一部分将是某个长期研究过程的结果，但一旦完成，项目的另一部分必须以增量方式交付给客户。项目经理应该为该项目选择哪种方法？
一部分。。。另一个部分。。。 = 混合
# 敏捷宣言和原则
# 敏捷的定义及敏捷宣言
并不强调快，而是强调适应
敏捷是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。
个体互动胜过流程和工具
可用的软件胜过详尽的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
尽管右项有其价值，我们更重视左项的价值。
# 敏捷开发十二原则
- 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
价值驱动(vs 传统的计划驱动) - 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。(以获得更快更多的反馈)
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
提倡集中办公，或虚拟的鱼缸窗口 - 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。(通过敏捷，将团队培养成自组织团队，而不是先有自组织团队才能做敏捷项目)
- 团队定期地反思如何能提高成效，并依此调整自身的行为表现。
# 敏捷实践
# Scrum
一个简单的例子
项目：某家庭需要采购一批商品，包括主食、日用品、饮料、零食、调料、肉类、蔬菜等等。
项目特点：
- 需求不明确，目前能想到的就是要采购这些，而且比较概括需要细化；
- 时间紧张，需要立即开始采购；
- 极有可能出现需求变更。
每次采购的特点：
- 时间固定：来回 20 分钟
- 人力固定：一个人
- 价值驱动：
- 按照优先级采购
- 较小的增量，快速迭代，每次交付最有价值的东西
敏捷方法拥抱变更
- 单有新的需求出现，应该添加到 “待采购的商品” 列表中，排列优先级 当前的采购一般不允许变更
# Scrum 框架
# Scrum 的核心
3-3-5-5
- 三个角色
- 产品负责人 Product Owner（业务负责人、客户代表）
- 敏捷教练 Scrum Master （教别人敏捷应该怎么去做）
- 开发团队 Dev Team （具体执行的人）
- 三个工件
- 产品待办事项列表 Product Backlog
- 冲刺待办事项列表 Sprint Backlog （Sprint = 冲刺 / 迭代）
- 产品增量
- 五个事件
- Sprint
- Sprint 计划会议
- 每日站会
- Sprint 评审会议
- Sprint 回顾会议
- 五个价值观
- 承诺、专注、开放、尊重、勇气
# Scrum 中的 3 个角色
# 产品负责人 Product Owner PO
产品负责人是管理产品待办事项列表的唯一责任人。
是人，而不是组织
产品代办事项列表的管理包括:
- 清晰地表达产品待办事项列表条目 (业务负责人)
- 对产品待办事项列表中的条目进行排序，最好地实现目标和使命
- 确保产品待办事项列表对所有人可见、透明、清晰，并且显示 Scrum 团队的下一步工作
- 确保开发团队对产品待办事项列表中的条目达到一定程度的理解
产品负责人可以亲自完成上述工作，也可以让开发团队来完成。然而，产品负责人是最终的责任人。
产品负责人是一个人，而不是一个委员会。产品负责人可能会在产品待办事项列表中体现一个委员会的需求，但要想改变某条目的优先级必须先说服产品负责人。
为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他的决定。产品负责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发团队按照另一套需求开展工作，开发团队也不允许听从任何其他人的指令。
产品负责人决定接受或者拒绝每次 Sprint 完成的产品增量，产品负责人决定产品的发布。
# 敏捷教练 Scrum Master
Scrum Master 负责确保 Scrum 被理解并实施。
为了达到这个目的，Scrum Master 要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。
Scrum Master 是 Scrum 团队中的服务式领导。（该角色也被称为项目经理、Scrum 主管、团队促进者等）
Scrum Master 服务于产品负责人，包括：
- 找到有效管理产品待办事项列表的技巧
- 确保产品负责人了解如何安排产品待办事项列表
- 清晰地和开发团队沟通愿景、目标和产品待办事项列表条目
- 帮助理解并实践敏捷
Scrum Master 服务于开发团队，包括:
- 指导开发团队自组织和跨职能
- 移除开发团队进展过程中的障碍
- 教导并领导开发团队创造高价值的产品
- 在 Scrum 还未完全被采纳和理解的组织环境下指导开发团队
Scrum Master 服务于组织，包括:
- 领导并指导组织采用 Scrum
- 帮助相关方理解并实施 Scrum
- 发起能提升 Scrum 团队生产力的变革
- 帮助组织更有效的应用 Scrum
# 开发团队
开发团队负责在每个 Sprint 的结尾交付潜在可发布的 “完成” 产品增量。只有开发团队的成员才能创造增量。
开发团队由组织构建并授权来组织和管理他们的工作。
开发团队有以下几个特点:
- 他们是自组织的，没有人 (即使是 Scrum Master 都不可以) 告诉开发团队如何把产品待办事项列表变成潜在可发布的功能。
- 开发团队是跨职能的，团队作为一个整体拥有创造产品增量所需要的全部技能。
- Scrum 不认可开发团队成员的头衔，无论承担哪种工作他们都是开发者。此规则无一例外。
- 开发团队中的每个成员可以有特长和专注领域，但是责任归属于整个开发团队。（团队成员是 T 型人才）
- 开发团队不包含如测试或业务分析等负责特定领域的子团队。
自组织：自主选择任务、自己决定如何实现、团队自己估算并决定每个 Sprint 完成哪些工作、主动学习、管理层级相同。
开发团队人员相对稳定、全职，团队规模一般 3~9 人
# Scrum 中的 3 个工件
# Product Backlog – 产品待办事项列表 PB
- 用户故事：作为一个 <角色>，我想要 < 功能 >，以便于实现 < 价值 >
- 角色：谁要使用这个功能。
- 功能：功能的相关描述。
- 价值：为什么需要这个功能，这个功能带来什么价值。
产品待办事项列表是一个排序的列表，包含所有产品需要的东西，也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。
产品待办事项列表列出了所有的特性、功能、需求、改进方法和缺陷修复等对未来发布产品进行的改变。
它是一个按照优先级由高到低排列的一个序列，排在顶部的产品待办事项列表条目需要立即进行开发。排序越高的产品待办事项列表条目比排序低的更清晰、更具体（符合 “就绪的定义
DOR”Definition of Ready） 。根据更清晰的内容和更详尽的信息就能做出更准确的估算。优先级越低，细节信息越少。通过产品 Backlog 的梳理来增添细节、估算和排序。这是一个持续不断的过程，产品负责人和开发团队协作讨论产品代表事项列表条目的细节。
在产品待办事项列表梳理的时候，条目会被评审和修改。梳理在 Sprint 中是一项兼职活动，在产品负责人和开发团队之间展开。
开发团队负责所有的估算工作。产品负责人可以通过协助团队权衡取舍来影响他们的决定。但是，最后的估算是由 执行工作的人来决定的。
# Sprint Backlog – 冲刺（迭代）待办事项列表
Sprint 待办事项列表是一组为当前 Sprint 选出的产品待办事项列表条目，外加交付产品增量和实现 Sprint 目标的计划。
Sprint 待办事项列表使开发团队确定的、达到 Sprint 目标所需的工作清晰可见。
开发团队将用 Sprint 待办事项中的用户故事拆分成任务，团队成员主动领取任务（而不是由其他人分配任务）。
Sprint 待办事项列表是一份足够具体的计划，使得进度上的改变能在每日站会中得到理解。
开发团队专注于达成 Sprint 的目标。
# Product Increment – 产品增量
增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。
在 Sprint 的最后，新的增量必须是 “完成” 的，这意味着它必须可用并且达到了 Scrum 团队的 “完成” 的定义的 DOD(Definition of Done)。
增量是在 Sprint 结束时可检视的和已完成的产品组成部分。
增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用。
- 技术负债（Technical debt）
- 又译技术债务，也称为设计负债（design debt）、代码负债（code debt），是编程及软件工程中的一个比喻。
- 指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。
- 这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。
- 软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。
- 1992 年，沃德・坎宁安首次将技术的复杂比作为负债。
# Scrum 中的 5 个事件
P - Sprint 规划会议
D - 每日站会
C - Sprint 评审会议
A - Sprint 回顾会议
# Sprint
- Sprint 常翻译为 “冲刺” 或 “迭代”
- Sprint 是 Scrum 的核心，其持续时间为一个月或更短时间的限时（比如两周），以构建一个 “完成的”、可用的和潜在可发布的产品增量。
- 在整个开发过程期间，Sprint 的长度通常保持一致
规定的“时间盒”。 - Sprint 由 Sprint 计划会议、每日 Scrum 站会、开发工作、Sprint 评审会议和 Sprint 回顾会议构成。
- 在 Sprint 期间不能做出有害于 Sprint 目标的改变。
- 所有未完成的产品待办事项都会被放回到产品待办事项列表中，并重新估算。花在它们身上的工作会很快地贬值，所以必须经常性地重估。
- 如果提前完成了，建议处理技术负债；说明对团队工作量的评估不准确
- Sprint 可以在 Sprint 结束之前取消。只有产品负责人才有取消 Sprint 的权力。
- 如果某个 Sprint 对其所在环境来说失去了价值和意义，那么它就应该被取消。然而，由于 Sprint 的时间都很短，所以取消 Sprint 的意义不大。
# Sprint 计划会议
每个 Sprint 的开始是 Sprint 计划会议。Sprint 计划会议是限时的，以两周的 Sprint 来说最多 4 小时为上限（一个月的 Sprint 则为 8 小时）。
Sprint 计划会议的前半段，产品负责人把待完成的高优先级功能介绍给 Scrum 团队。
Sprint 计划会议的后半段，开发团队可以针对这些功能提出问题，如果团队有信心完成某一个功能，就把这个功 能从 Product Backlog 移动到 Sprint Backlog 中。
如果团队发现增加的工作量已经超过了整个团队一个 Sprint 能够完成的总量，团队会立即建议产品负责人停止。
理论上团队按照优先级次序选择用户故事直到团队认为足够为止，实际情况中，团队也可能选择最高优先级的五 个故事，然后又选择两个低优先级但是与前五个故事有关的故事。团队会和产品负责人沟通，但是通常由团队决定一个 sprint 完成多少。
团队和产品负责人一起确定 Sprint 的目标，在 Sprint 结束时的 Sprint 评审会议中审视是否达成目标。
Sprint 期间不变更，变更不应该纳入到 Sprint 待办事项中，而应该纳入到产品待办事项中，并与剩余的工作按优先级进行排序。
# “故事点” 和 “团队的速率”
- 故事点（ Story Point ）和相对估算
- 是一个度量单位，用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果。
我们可以选择一个最简单的用户故事作为基准，来衡量其他的用户故事的工作量是多少个故事点。 - 刺探 / 探测 / 探针 （Spike）
- 一种快速而简陋的实现，是作为将被丢弃的试验品而设计的，主要是为了获取背景知识以知道某需求在技术上可行还是不可行，通常在不能有效估计用户故事时采用该方法。
- 速率（ Velocity ）
- 衡量团队在单个 Sprint 中可以解决的工作量的指标，也是 Scrum 的关键指标。
- 由于每个团队选取的基准用户故事不同，不同的敏捷团队每个 Sprint 完成的故事点不具有可比性。
- 完成的故事点并不是越多越好，而是越稳定越好。
- 团队的速率一般需要经过多个 Sprint 才能稳定。
# 每日 Scrum 站会
每日 Scrum 站会是一个以 15 分钟为限的事件。
Scrum Master 确保开发团队每日站会如期举行，但开发团队自己负责召开会议。
每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。
在会议上，每一个开发团队成员都需要说明：
- 昨天，我为帮助开发团队达成 Sprint 目标做了什么
- 今天，我为帮助开发团队达成 Sprint 目标准备做什么
- 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标。
注意：会上只记录问题而不讨论问题，另外，了解 SoS 会议 — Scrum of Scrums
开发团队或者开发团队成员通常会在每日 Scrum 站会后立即聚到一起进行更详细的讨论，或者为 Sprint 中剩余的工作进行调整或重新计划。
Scrum Master 强制执行每日 Scrum 站会规则 —— 只有开发团队成员才能参加（其他相关方也可以参加，但不能发言干扰会议）。
每日 Scrum 站会增进交流沟通、减少其他会议、发现开发过程中需要要移除的障碍并促进快速地做决策、提高开发团队的认知程度。这是一个进行检视与适应的关键会议。
# 信息发射源（信息扩散器）
- 在集中办公的区域设立一块大白墙或白板，上面用高可视化、图形化的方式展示出项目的实施状态和信息，如产品待办列表、问题列表、迭代燃尽图等等。
- 可以最大程度促进团队成员间、团队和相关方间透明式的信息流通。
- 敏捷提倡引导相关方观看信息发射源以获得项目状态，而不是单独发送项目状态报告。如：燃尽图，燃起图，累积流量图，停车场图等。
# Sprint 评审会议
- Sprint 评审会议在 Sprint 快结束时举行，两周的 Sprint 一般两小时，用以检视所交付的产品增量并按需调整产品待办列表。
- Scrum 团队和相关方协同讨论在这次 Sprint 中所完成的工作。
- 开发团队演示 “完成” 的工作并解答关于所交付增量的问题，演示增量的目的是为了获取反馈并促进合作。
- 参会的所有人就下一步的工作进行探讨，为下次的 Sprint 计划会议提供有价值的输入信息。
- Sprint 评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个 Sprint 的产品待办列表项。
# Sprint 回顾会议
- Sprint 回顾会议发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前。
- 两周的 Sprint 中回顾会议不超过 2 小时。
- Scrum Master 鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得他们能在下个 Sprint 中更高效更愉快。
- 在 Sprint 回顾会议结束时，Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。
# Scrum 中的 5 大价值观
- 承诺 – 愿意对目标做出承诺
- 专注 – 把你的心思和能力都用到你承诺的工作上去
- 开放 – Scrum 把项目中的一切开放给每个人看
- 尊重 – 每个人都有他独特的背景和经验
- 勇气 – 有勇气做出承诺，履行承诺，接受别人的尊重
# Kanban 系统
# 看板：可视化管控，消除瓶颈
# 极限编程
# 极限编程中的十二个最佳实践
计划游戏 (Planning Game)：快速制定计划、随着细节的不断变化而完善；
小型发布 (Small Release)：系统的设计要能够尽可能早地交付，在非常短的周期内以递增的方式发布新版本，可以很容易地估计每个迭代周期的进度，便于控制工 作量和风险；同时，也可以及时处理用户的反馈。
系统隐喻 (System Metaphor)：找到合适的比喻传达信息；
简单设计 (Simple Design)：只处理当前的需求使设计保持简单；
测试驱动 (Test-driven)：先写测试代码再编写程序 TDD。（类似的还有 ATDD 验收测试驱动开发，BDD 行为驱动开发）
重构 (Refactoring)：重新审视需求和设计，重新明确地描述它们，以符合新的和现有的需求；在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。
结对编程 (Pair Programming)：由两个程序员在同一台电脑上共同编写解决同一问题的代码。通常一个人负责写编码，而另一个负责保证代码的正确性与可读性。
集体所有权（Collective Ownership）：任何人在任何时候都可以在系统中的任何位置更改任何代码。每个成员都有更改代码的权利，所有的人对于全部代码负责。
持续集成 (Continuous Integration)：可以按日甚至按小时为客户提供可运行的版本；提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试， 避免了一次系统集成的恶梦。
每周工作 40 小时 (40-hour Week)：要求项目团队人员每周工作时间不能超过 40 小时，加班不得连续超过两周，否则反而会影响生产率。
现场客户 (On-site Customer)：在团队中加入一位真正的、起作用的用户，他将全职负责回答问题。
编码标准 (Code Standards)：强调通过指定严格的代码规范来进行沟通，尽可能减少不必要的文档。
