《Scrum指南》《Scrum要素》读书笔记

敏捷力

由Royce首次提出，表示不能使用瀑布模型做软件开发。

瀑布模型将开发和交互企业软件项目的流程分割为相互独立的阶段：

1. 需求收集
2. 设计
3. 编码
4. 测试

每一阶段必须等待上一阶段结束后才能开始，只有等待所有步骤都结束才有可能向用户交付价值。

敏捷运动并不是要反方法论。

敏捷流程的共同点：拥抱变化，视变化为成长的良机，而非障碍。

敏捷开发是一种整体(holistic)流程，即测试、设计、编码和需求收集是完全整合彼此依赖的流程。

怎么做敏捷开发？

• 边做边测试
• 及早且频繁地交付产品
• 文档边做边写，只写必需的文档
• 构建跨职能团队

敏捷方式的核心思想在于迅速交付商业价值，体现为可工作的软件，还要以定期增量的形式持续地交付价值。

敏捷价值观

• 个体和互动高于流程和工具
• 工作的软件高于详尽的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划

各种敏捷工具方法论和流程的选择非常多，应该尽力做到都尝试一遍。

整个项目生命期内敏捷计划一直在积累和演变。

传统软件开发方法是计划驱动，敏捷项目是规划驱动。

敏捷原则

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

Scrum

Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付可能最高价值的产品。

Scrum 是：

• 轻量的
• 易于理解的
• 难以精通的

Scrum 并不是一种过程、技术或决定性方法。Scrum 的精髓在于小团队。

在迭代与增量式的知识迁移中， Scrum 被证明特别有效。

Scrum 基于经验过程控制理论，或称之为经验主义。经验主义主张知识源自实际经验以及当前已知情况下做出的决定所获得。 Scrum 采纳一种迭代和增量式的方法来优化对未来的预测和控制风险。

透明、 检视和适应是经验过程控制的三大支柱，支撑起每一个经验过程的实施。

Scrum 框架由 Scrum 团队以及与之相关的角色、事件、工件和规则组成。

Scrum角色

产品负责人

角色概要：

• 持有产品愿景
• 代表业务
• 代表客户
• 拥有产品列表
• 划定故事优先级
• 设立故事的接收标准
• 有空回答团队成员们的问题

产品负责人责任在于帮公司得到最高投资回报；是唯一有权要求团队做事以及改变列表条目优先级的人；团队负责人和团队其他人之间有一层天生的紧张关系，团队负责人总想要更多，而团队必须维护可持续的速率。

Scrum Master

角色概要：

• scrum专家和谏言者
• 教练
• 障碍推土机（bulldozer）
• 引导者（facilitator）

团队成员

角色概要：

• 负责交付用户故事
• 做所有的开发工作
• 自组织地交付用户故事
• 支配估算流程
• 支配“如何干活”的决策
• 避免“与我无关”

一个scrum团队通常在五到九个人；需要最大化团队生产力；产品负责人和 Scrum Master 角色不包含在开发团队人数中。

产品负责人、scrum master和团队成员是猪（commited），所有其他利益相关方是鸡（involved）。

Sprint周期

Sprint 的长度限制在一个月内。

Sprint计划会议

标志着sprint的开始。频率：每周2小时。

1. 做什么？团队要选择一组交付物作为当前sprint的承诺；
2. 怎么做？团队要罗列出交付用户故事所需完成的所有任务。

**团队速率（velocity）**指每个sprint团队所完成故事点数的平均值。任务估算：任务小时、任务点、任务数。

Scrum日会（站立会议）

特点：

• 每天：每天开会
• 小：开发团队成员参加
• 简要：不应该超过15分钟
• 直截了当：分享：在上次Scrum日会之后，我已完成的内容；到下次Scrum日会之前，我期望完成的内容；导致我慢下来的障碍。

故事时间（“列表修整”会议）

频率：每周一次1小时。

估值未估计的故事；把过去加入sprint列表较大的故事拆分成更小的故事。

Sprint评审

频率：每周半个到一个小时。

所有干系人参加；团队报告未完成的故事，展示已完成的故事；收集干系人反馈

回顾

频率：每个迭代最后举行，每周1到2小时。

找出1到2件可改进的实事，制定行动计划，实现这些改变。

回顾议程

• 准备阶段（set the stage）：建立起大家对目标的共同理解，摸清与会者的轻松度和参与度。
• 收集数据（gather data）：关注在sprint中发生了什么，使用团队工件。
• 洞察问题（generate insights）：团队要借助一些活动以便：发现数据的模式；发现最重要的条目；深化理解；寻找因果关系；确定解决方案或改进方案。
• 确定方案（decide what to do）：只选定一个地方做改进，选择团队控制范围和能力范围内的那些事情去实现。
• 结束（close）：认可团队成果并予以称赞。

Scrum工件

• 产品列表：产品预期交付物的累积清单，又叫“用户故事”或“故事”，在整个开发流程中一直都在变；列表顶部多是个头小且定义完善的条目，列表往下故事个头更大定义也粗略。
• Sprint列表：团队当前sprint的任务清单。
• 信息辐射器：放在所有人都能看见的地方。
• 燃尽图：描述了剩余工作随时间变化的轨迹；纵坐标绘制剩余工作量，横坐标是时间；发布燃尽图、Sprint燃尽图、燃耗图。
• 任务板：待办（to do）、办理（doing）、已办（done）、已报告等。
• 完成之定义（Definition of Done）：代码评审、设计评审、重构、性能测试、单元测试通过、更多内容。

增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。

用户故事

模板：

作为<某类用户>

我想<做某事>

从而<创造出某些价值>

聚焦目标：

为了<达成某目标>

作为<某类用户>

我想<做某事>

聚焦价值：

为了<创造某价值>

作为<某类用户>

我想<做某事>

用户故事是交谈的敲门砖，它们不是完整的需求或说明书，而是占位符；接收标准将之付诸实践；用户故事、交谈和接收标准结合起来组成了完整的需求规格说明书。

估计

我们往往对于绝对大小判断不擅长，但对于相对大小判断准确，包括相对倍数。

估计的两步流程：

1. 给所有工作都分配相对大小值，单位为故事点；
2. 完成几个工作项，度量它们实际花费的时长，速率就是平均每个sprint所完成的故事点数量。

分配故事点的方式：

• 使用斐波那契数列来估计故事所需要的点数；
• 团队估算游戏：集体排队+你的数字
• 计划扑克

辅助性实践

铁三角

速度、成本、范围是管理周期中著名的“铁三角”。可以使用“单指针表盘”来呈现这个三角。

用户角色人物：

• 首要角色人物：必须先满足这个人的需求，然后才轮到其他人的需求。
• 负面角色人物：不会使用系统的人。

故事地图：

指示了故事的优先级，指出了它们彼此的关系和用户更高层的目标。

1. 明确系统的用户以及他们将要做的各种活动；
2. 把相关联的故事都排列在这些活动的下面，更重要的故事放在不太重要的故事上方；
3. 在上面从左到右画出一条水平线，线上方的故事在发布里面，下方的不在发布里。

使用纸上原型可以降低设计过程人员参与的门槛，具有较高的参与度，让学习成效最大化。

项目微章程：

明确记载了项目关键信息的概要文档。

包含元素：

• 代号：给项目取个名字。
• 使命宣言：表达出项目的目的。
• 愿景宣言：描述想要创建的未来。
• 电梯演讲：言简意赅、记住不忘。
• 商业价值：项目对业务而言在金钱或其他方面的价值是什么。
• 客户和用户：客户是可以做购买决策的人，用户是实际上和产品产生互动的人。
• 质量指标（metrics）：价值的度量指标。
• 里程碑：重要的时间点或项目中重要的时刻。
• 资源：
• 风险：可能危害或颠覆项目的事情。
• 权衡：现实地评估团队运作环境中的各种约束。

重构

重构就像文胸，必须要合身才有支撑和提升的功效。就像女人在生活中也需要不同的文胸一样，系统在成长过程中也需要有不同的架构。敏捷选择浮现式（emergent）架构和设计替代BDUF。

测试驱动开发

测试驱动开发（TDD）目标在于快速地开发出设计精良、正确性已获证实的代码。简单讲，先写自动化测试，然后再编写产品代码，并让它通过测试。

结对编程

结对编程：用一台电脑写代码，更快速地产出设计更精良、整洁的代码，还能消灭知识筒仓。

结对编程的方式：

• 驾驶员—导航员结对
• 乒乓结对
• 测试驱动开发结对编程游戏

总结

通过阅读《Scrum指南》和《Scrum要素》，我明白了更多Scrum框架的细节以及敏捷开发和瀑布模型的由来、区别和对比。相比较瀑布模型的“笨重”、必须所有步骤结束后交付价值，Scrum采用迭代式开发，不仅开发更为迅速，也有对于开发人员的激励作用，项目收益也更多。当将要敏捷开发时，Scrum应为首选。