由于周六就要开始项目经理考试了，这里复习一下敏捷知识，加深印象吧。

敏捷准则和理念

---

敏捷宣言

个体以及互动 胜过 流程和工具
可用的软件 胜过 完整的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划

敏捷十二原则

1. 我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求。
2. 欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变
   更，帮助客户获得竞争优势。
3. 要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
4. 项目实施过程中，业务人员与开发人员必须始终通力协作。
5. 要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。
6. 无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈。
7. 可用的软件是衡量进度的首要衡量标准。
8. 敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该都能够始终保持步
   调稳定。
9. 对技术的精益求精以及对设计的不断完善将提高敏捷性。
10. 简洁，即尽最大可能减少不必要的工作，这是一门艺术。
11. 最佳的架构、需求和设计将出自自组织团队。
12. 团队要定期反省怎样做才能更有效，并相应地调整团队的行为。

生命周期模型

价值驱动的交付

---

项目章程

敏捷项目章程应包含 3 个关键信息：

• 愿景：即项目发起的原因。
• 任务：即项目的内容，阐述团队为实现愿景需要做的内容。
• 成功标准：即管理的指标，定义项目如何是成功，用于验收项目。

由于敏捷方法本身就是为了应对需求和项目的不确定，因此对于敏捷项目的范围一般很少详细定义，它会随着整个项目的进行而变化。所以，敏捷项目章程通常比传统的项目章程粗略，章程包含的内容相对较少。敏捷章程更多聚焦在项目如何运行，而不是具体要做什么。

团队章程

团队章程是团队的社会契约，规定团队成员之间彼此互动的方式。团队章程由项目团队
共同制订。团队章程的目标是创建一个敏捷的环境，在这个环境中，团队成员可以发挥他们
作为团队的最大能力。
团队章程的内容包括：

• 团队价值观：例如可持续的开发速度和核心工作时间。
• 工作协议：例如“就绪”如何定义，这是团队可以接受工作的前提；“完成”如何定义，这样团队才能一致地判断完整性；考虑时间盒；或使用工作过程限制。
• 基本规则：例如有关一个人在会议上发言的规定。
• 团队规范：例如团队如何对待会议时间。

客户价值优先级

• 简单模式：最简单的优先级模式，通常会在工作项上标上 P1、P2、P3 等

• MoSCoW：MoSCoW 技术把用户故事以降序方式进行优先顺序排列
  M-must have，即必须有的；“必须有的”需求和特性是系统的必需组成部分（MVP
  的特性）。
  S-should have，即应该有的；“应该有的”是对开发不是很重要但有重要商业价
  值的产品特性。
  C-could have，即可能有的；“可能有的”特性是能增加一些商业价值的产品特性。
  W-won’t have this time，即希望有的，这次不会有。

• 虚拟价值：虚拟价值通过给发起人等同于项目预算的虚拟货币，要求他们将这些虚拟货币分配给系统中的特性集。这种方法对于识别系统组件的一般优先级非常有用，在限制业务价值特性的优先级排序中最有效率。

• Kano分析：卡诺分析技术将客户的喜好分为四个类别：惊喜、满意、不满意、无关紧要。这些分类可以帮助团队更好地理解与客户满意度相关的需求，推动客户满意度的提升。
  惊喜属性：也称为魅力属性，这些特性的交付是客户未预料到的、与众不同的或可以带来高价值的好处，可能给客户带来竞争力和高满意度。
  满意属性：也称为期望属性，作为满意的特性，越多越好。这些特性会给客户带来价值，创造竞争优势，大部分的竞争都聚焦在这个属性的领域。
  不满意属性：也称为必备属性、阈值属性，这些特性必须具备，如果不具备，客户就不会喜欢这个产品，但即使这些特性存在，也不会提升客户的满意度。
  无关紧要属性：也称为无差异属性，这些特性无论从哪个方面来说对客户都没有影响，因为客户对其根本就不关心，我们应该尝试消除、最小化或延迟支付这些特性。

燃尽图

燃尽图是一个用来展示迭代进度的信息发射源，以图形化的方式展现了团队本迭代内剩余的工作量（y 轴）与工作日（x 轴）的关系。其目的是监控迭代进度或者项目的进度，追踪剩余总和并预测达成迭代目标的可能性。一般，在团队每日站会开会后，由团队更新燃尽
图。

风险燃尽图

风险燃尽图是用于跟踪项目伴随时间风险的风险管理技能，是项目风险严重程度的累积。
通过风险燃尽图，干系人可快速查看随着时间项目风险管理的绩效（比如提高、降低以及相应的数值）。严重度（影响和收益的产品）是沿着竖轴绘制，横轴是时间。在理想情况下，风险严重度会随着时间降低。

燃起图

燃起图以图形化的方式展现了项目或团队多个迭代的需求累计完成情况（y 轴）与各迭代（x 轴）的关系。通过延长实际线（按最近迭代或平均斜率），可以大致判断要完成当前的所有需求还需要几个迭代。燃起图可以看出项目范围的变化。
除了显示已完成的工作量，燃起图还能显示项目中的实际总工作量。

任务/看板面板

任务看板是一种很好的追踪和报告价值的方法。团队在过程中可以及时地发现问题、快速反馈，同时，工作项的完成也会增加信心。

故事地图

故事地图是客户价值优先级排序的工具，提供了一个关于功能何时交付的产品路线图。
故事地图还可以用作跟干系人沟通的工具，把故事放在墙上作为一个项目计划的信息发射源。
故事地图鼓励大家用不同的方式参与，通过可视化的展示引发干系人的关注。

用户故事

用户故事是大小适中的，可以被理解的商业功能模块。敏捷团队通常依赖用户故事和用
户故事待办事项（通常可以等价为产品待办事项）进行商业需求优先级的排序。

• 用户故事三要素：角色、活动、商业价值。
• 用户故事的 3C：卡片、交谈、确认。
• 用户故事的 INVEST 属性：独立的、可协商的、有价值的、可估算的、小的、可测试的。

产品路线图（Roadmap）

产品路线图为产品负责人所拥有，是产品需求的高层级概述，常用作特性优先级排序、特性归类和粗略时间框架确定的工具。产品路线图又勾画出产品多个版本的演变过程，是项目层面的粗粒度计划，关注的是目标而不是细节。

Scrum 事件

---

冲刺（Sprint）

冲刺的输出是潜在可交付的产品增量（Product Shippable Increment，PSI），冲刺过程中迭代目标不变、质量目标不降低。冲刺开发是有节奏地小步快跑，但建立在坚实的质量基础上。

一个冲刺就是一个时间盒（有时间限制），在这个时间盒中至少应该有产品发布，时间盒的长度一般是 2~4 周。迭代周期长短的设定取决于团队应对外界需求变化的能力。冲刺可以在时间盒结束前取消，但只有产品负责人才有权力取消 Sprint。如果某个Sprint 对其所在环境失去了价值和意义，那么它就应该被取消。当取消某个 Sprint 时，任何做完和完成的产品待办事项都需要进行评审，所有未完成的内容都会被放回到产品待办列表中，并重新估算。

在第一个 Sprint 之前有一段特殊时期，被称为 Sprint 0（零迭代），也称为 Inception阶段，用来完成一些必要的准备工作。Sprint 0 的周期不应该太长，一般在 4 周以内。

冲刺规划会（Sprint Plan Meeting）

冲刺规划会用于确定在这个冲刺中需要交付哪些产品，以及如何达成目标。产品负责人展示产品待开发项，整个团队成员对其进行讨论，分享彼此的观点。开发团队基于他们的估算预测在这个冲刺中将要交付的产品，并决定这些功能将如何进行交付以实现冲刺的目的。长度为 1 个月的冲刺，其计划会议最长不超过 8 小时，其中 4 小时用于选择用户故事，4小时用于估算分配。

每日站会（Daily Scrum Meeting）

每日站会是一个拥有时间盒的每日会议（通常不超过 15 分钟）。这个会议每天在同样的时间和地点召开，每个开发团队成员只回答三个问题：

1. 从上一个每日站会到现在，我完成了什么？
2. 从现在到下一个每日站会，我计划完成什么？
3. 有什么阻碍了我的进展？

每日站会提出的问题和风险要及时曝光，张贴在显眼的地方。每日站会可以确定由谁解决问题，但不制订解决方案。只有 Scrum 团队的成员，可以在会议中发言。产品负责人可以不参加每日站会，即使参加也不能发言，以免破坏站会的时间盒。
每日站会可以带来透明性、信任和更好的绩效，能帮助快速发现问题，并促进团队的自组织和自立。

冲刺评审会（Sprint Review/Demo/Show-case Meeting）

冲刺评审是一个在冲刺结束时举办的会议，用来检查增量或者开发出来的产品，必要时也可对产品待开发项进行调整。评审会通常的形式为演示+验收，仅演示当前冲刺完成的条目。开发团队证明工作已经“完成”，并且对此增量回答任何问题。产品负责人决定此增量是否“完成”，具有一票否决权。产品负责人和团队讨论剩余的产品待开发项，以及下一步需要完成的工作。对于周期为 1 个月的冲刺，评审会议的限时为 4 小时。

产品待开发项（Product Backlog）

产品待办事项列表也称为产品需求池、产品功能列表，是一份涵盖产品中已知所需每项内容的有序列表，包括业务需求、技术需求、NFR（非功能需求）、Bug、Spike 等，它是产品需求变动的唯一来源。产品负责人负责管理产品待办事项列表的内容、可用性和排序。
一个好的产品待办列表需要符合“DEEP”原则：

• Detailed appropriately：详略得当
• Emergent：浮现式的
• Estimated：做过估算的
• Prioritized：排过优先级的

产品待办列表一直处于动态变化，它会随着产品及其应用环境的改变而演进，需要持续更新以反映出需求。任何人（产品负责人、SM、开发团队）随时都可以向 PB 表中增加事项，但仅产品负责人负责排序，有最终决定权。

产品待办列表中排序越高的事项比排序低的事项拥有更多细节，任何一个产品待办事项都能够在 Sprint 的时间盒期限内适当地完成。这些能够在 Sprint 中完成的产品待办事项列表称为“准备就绪”（DoR），它们将作为 Sprint 计划会议中的待选产品列表项。

待办产品列表项的足够透明程度要通过产品待办列表精化活动来实现。

冲刺待开发项（Sprint Backlog）

Sprint 待办列表是一组为当前 Sprint 选出来的产品待开发项，同时附上交付产品增量和实现 Sprint 目标的计划。Sprint 待办列表是开发团队对于下一个产品增量所需功能及其工作的预测，关注的是团队怎么做才能在一个迭代内交付。

Scrum 开发团队可以在 Sprint 期间修改 Sprint 待办列表。当新工作出现时，Scrum开发团队需要将其加入 Sprint 待办列表中；当计划中的某个部分失去意义时，就可以将其从 Sprint 待办列表中移除。Sprint 待办列表由 Scrum 开发团队全权负责，团队中的任何人都可以添加、删除或更改迭代中的工作项。Sprint 待办列表中的任务实现顺序也由 Scrum开发团队决定，因为开发团队最清楚任务之间的依赖关系。对于剩余工作量的估算（绝对估算，人天等）每天需要更新。Sprint 待办列表中的每项任务由一个人负责（通过认领而不是指派的方式）。

产品增量（PSI）

增量是一个 Sprint 完成的所有产品待办列表项，以及之前所有 Sprint 所产生的增量价值的总和。在 Sprint 的结尾，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。在每个 Sprint 结束时，团队必须有新的增量交付。