《Scrum 敏捷软件开发》豆瓣链接

第一部分 启航

第1章 为什么敏捷转型难（但值得）

为什么转型困难

成功的变革不是完全的自上而下或者自下而上

成功实施 Scrum 的关键是结合自上而下和自下而上的变革相关要素。

结束状态是不可预知的

这是一个没有终点的过程，需要持续的改进。

变化来的比以往更快

最佳实践是危险的

大野耐一：有一些事情称之为标准工作，但是标准是在不断变化的。如果我们把一些事情作为最好的可能方法，那么对于精益（持续增量的改善）的动力就消失了。

为什么值得投入

更高的生产力及更低的成本

Scrum 团队更有可能只开发用户真正需要的功能。

员工的参与度和工作满意度增强

敏捷过程提倡可持续的开发步调，日常工作具有更好的可控性，减少加班。

敏捷过程可以更快地看到工作成果，使团队更紧密地协作，更可能满足客户的期望。

更快的产品上市时间

更高的质量

没有遗留的缺陷拖累团队，所以他们可以持续不断地快速前进。

项目干系人的满意度提升

敏捷能更友好地应对优先级别的变化。

敏捷可以使技术团队和商业团队更容易达成共识。

现在的做法已不再有效

第2章 ADAPT 模型

成功、持续实施 Scrum 必备的5个活动：

• 意识（Awareness），当前的过程已不能实现可接受的结果
• 渴望（Desire），把实施 Scrum 作为一种方法来解决当前的问题
• 能力（Ability），有能力成功实施 Scrum
• 推广（Promotion），通过分享经验来推广 Scrum
• 传递（Transfer），把实施 Scrum 带来的影响扩大到整个公司

意识开发工具

• 通过沟通，说明问题的存在
• 使用度量数据
• 接触新的人与经验

重视新员工的多样性，刻意寻求不同背景的人。

• 运行一个试点项目
• 关注最重要的变革理由

渴望提升工具

• 告诉人们有更好的办法
• 创造一种紧迫感
• 造势（让愿意做的人去做）
• 让团队“试驾 Scrum”
• 统一激励机制（或至少消除不利因素）

以团队为导向的准则：

1. 更好地完成份内工作
2. 为知识的分享做出贡献
3. 愿意跨职位工作
4. 达到团队交付目标和质量目标

• 聚焦恐惧的消除
• 帮助人们学会放手
• 不要诋毁过去
• 努力让员工参与

能力开发工具

• 提供辅导和培训
• 赋予个体责任
• 共享信息
• 设置合理的目标
• 立即行动

Greene and Fry：做实验，保持耐心，并盼着犯错误。

Scrum 推广工具

• 讲述成功故事
• 开一个“敏捷野生动物园”
• 吸引注意力和兴趣

第3章 Scrum 实施模式（暂无摘录）

第4章 渐进敏捷（暂无摘录）

第5章 试点项目

Scrum 团队使用速率（Velocity）来衡量项目进展，它衡量某个 Sprint 中完成的工作。

第二部分 个体

第6章 克服抵触

员工和管理人员抵触变革的主要因素

第7章 新角色

ScrumMaster 对团队成员没有管辖权但对流程有控制权。

ScrumMaster 的职责是提供指导而非答案。

优秀 ScrumMaster 的品质

• 负责
• 谦逊
• 协作
• 投入
• 有影响力
• 知识渊博

产品负责人为团队指出正确的目标，ScrumMaster 帮助团队尽可能有效地达到目标。

产品负责人负责给团队提供愿景和边界。

优秀产品负责人的品质

• 始终都在
• 懂业务
• 善于沟通
• 果断
• 得到授权的

第8章 角色转换

分析员

在使用等级式产品负责人的大型项目中，一些分析员会转变成产品负责人的角色。
首席产品负责人考虑用户和市场，而分析员则可能担任各团队的产品负责人，协助首席产品负责人将愿景落实到团队的产品 Backlog 中。

是否需要将分析员计划未来的工作放到当前 Sprint 的 Backlog？

建议在 Sprint 的 Backlog 中包含 Sprint 计划会议中可以明确的所有具体分析任务。例如，如果产品负责人和团队都同意下个 Sprint 应包括A任务，那么与A任务相关的初步分析工作就应该被确认、估算并包括在当前 Sprint 的 Backlog。如果下个 Sprint 的工作尚不清楚，则当前 Sprint 的 Backlog 就不应包含与下个 Sprint 相关的具体工作任务。

项目经理

在 Scrum 中不需要该角色。传统的项目经理可成为 ScrumMaster，产品负责人或其他团队角色。

Scrum 团队成员自己承担选择任务的责任。

架构师

架构师的主要职责是考虑变化和复杂性。

程序员

他们将不能再呆在自己的隔间里等待有人来告诉他们具体该写什么程序。他们需要积极主动地理解产品需求。

在 Scrum 团队中的程序员被期望能共享产品整体成功的责任。

不能说：给我完美需求，然后在我实现它时请走开。

测试员

测试员需要适应更频繁且有意义地与其合作者交流，包括内部与外部。

不能说：给我完美需求文档，我将确保系统做了它描述的所有内容。

每个人都需要思考产品，对每个特性提出问题并思考如何将它加入（或减少）到整个产品中。

第9章 技术实践

追求技术进步

测试驱动开发

TDD, Test-Driven Development, 测试驱动开发

确保系统中的所有代码都可以被测试。

重构

通过不断地重构，并且在一些小问题变成大问题前不断地修复它们，有助于防止代码腐烂。

集体所有权

确保开发人员不会变得太专以至于只能在某一方面做出贡献。

确保没有一个地方变得太错综复杂以至于只有一个开发人员可以明白和完成其工作。

持续集成

采用持续集成的 Scrum 团队中的任何一个程序员，要求他每天递交几次代码，并且运行一个覆盖整个应用程序的回归测试套件。

Scrum 团队需要一个合适的自动化测试环境。

对于复杂的系统，可以分割测试套件，但不能放弃持续集成。一个正式的每日构建对任何一个 Scrum 团队都是必须的。

结对编程

设计：有意的而又是涌现式的

第三部分 团队

第10章 团队结构（暂无摘录）

第11章 团队协作（暂无摘录）

第12章 领导自组织团队（暂无摘录）

第13章 产品 Backlog

使用顺序式开发过程的时候，我们尝试用一个很长的前期需求收集阶段作为开始，在该阶段中，产品的需求会被完全确定和细化。这个想法是，在项目前期，通过更长期的、更努力和更好的思考，项目的主体开发阶段将不会遇到任何黑暗角落。

Scrum 团队放弃漫长的前期需求阶段。对需求的概要描述会在项目早期收集，但在那个时候它们只是最粗略的描述，然后在项目进行过程中逐步完善。它们被记录在一个产品 Backlog 中。产品 Backlog 包括所有待添加功能的列表，它由产品负责人维护，并根据优先级按顺序保存。与传统的需求文档不同，产品 Backlog 具有很高的动态性，其中的事项会被增加或减少，同时在每个 Sprint 中，这些事项会因为对产品、用户和团队等有更多的了解而重新排列优先级。

从文档到讨论的转变

• 书面文档会让你暂停做出判断。
• 有了书面文档，我们就不能像谈话时那样反复声明要表达的意思。
• 书面文档不利于团队责任制。

敏捷开发的目标是找到文档和讨论之间的合理的平衡。

你并不需要除去所有的文档。只要尽量消除不需要的文档并让其他保留的文档尽可能简短，甚至考虑自动生成这些文档。

《精益软件开发》作者 Tom Poppendieck：当文档主要用于用户任务交接时，它们是罪恶的；而当它们用于捕捉交谈记录使其不被忘记时，则是有价值的。

在产品 Backlog 中使用用户故事

用户故事是将团队焦点从编写功能需求转移到谈论它们的最佳方式。

用户故事是从需要该功能的用户角度来讲述的短小简单的描述。

简单的模板：作为一个<用户类型>，我想<某个目标>，以便于<一些原因>。

与其将用户故事写在某个软件中，作者更喜欢将用户故事写在 3# x 5# 的索引卡片上。

用户故事并不意味着像是需求文档那样完整的功能描述，它只是一个开始。用户卡片可作为开发团队和产品负责人之间的承诺：开发团队答应产品负责人，在他们开发该用户故事前将与产品负责人讨论，而产品负责人答应团队，当团队准备讨论时他保证将有时间参与。

卡片不需要记录所有的细节，细节在产品负责人和团队讨论后产生。

作者收集到的数据表明：6人团队在为期2周的 Sprint 中平均能完成6到9个用户故事。

持续地提炼需求

涌现的需求

不能提前确认的功能被称作涌现的需求（特指没有预期到的需求）。

涌现的需求让你不可能很完美地预测进度。前期的设计阶段总是不完美，在涌现的需求还没有出现前，设计人员不可能考虑到这些需求。

处理涌现需求的第一步是认识到我们不可能想到每一件事情。

产品 Backlog 冰山

在产品 Backlog 中，团队很快要实现的那些条目必须拥有足够的细节，以便每条都能在一个 Sprint 中编程实现、测试和集成。所以位置靠前的用户故事会更小并更容易理解，而位置靠后的用户故事则更大，理解上也更粗略一些。

梳理产品 Backlog

黄金法则是我们应花每个 Sprint 中10%的精力梳理 Backlog 列表，以便为将来的 Sprint 做准备。

对于产品 Backlog 的讨论不局限于某个时间或会议，任何时候，任何团队成员之间，都可能进行讨论。

优秀的 Scrum 团队不需要在它开始实现某功能前已经充分理解它。相反，在每个 Sprint 开始时，对该功能的理解只需要达到该团队认为相当有可能在该 Sprint 中实现它即可。我们只需要一种准时和恰到好处的方法来理解产品 Backlog 中的功能需求，而不是在前期就竭尽所能地理解所有需求。

为什么要持续地提炼需求

• 事情会发生变化
  在项目的过程中，优先级会发生变化。
• 不需要
  开发条目要给予足够的可见性，以便让团队能看到足够远，从而避免大部分问题。
• 时间有限
  同等对待所有的需求是一种浪费。

对用户故事的持续提炼

团队成员必须能够创建大型的需求，这些需求位于产品 Backlog 冰山的底部；之后将它们分解为中等规模的条目；最后将它们拆分为足够小的块，从而让每个小块都能在单个 Sprint 中交付。

用户故事示例：

作为一个用户，我需要登录系统，以便只有我才能访问自己的信息。

该用户故事可能被拆分为更小的用户故事集合：

• 作为一名已注册过的用户，我能用我的用户名和密码登录，让我能信任该系统。
• 作为一名新用户，我能通过创建用户名和密码注册，让该系统能记住我的个人信息。
• 作为一名已注册过的用户，我能改变我的密码，让我能保证它是安全的或容易记住的。

（略）

在一个大需求被拆分为小的故事后，建议在 Backlog 中去掉该需求。如果需要可以备份该需求以便可查。

加入满意条件

当用户故事被拆分到足够小的粒度，进一步拆分已不再有帮助。此时通过向用户故事中增加满意条件，我们还可以持续地提炼需求。一个满意条件是某个简单的概要验收测试。满意条件可以防止团队迷失方向。

示例：

作为负责市场的副总裁，我想在评估以往广告促销活动的效果时可以选择节假日季节，以便我能确认那些有利润的促销活动。

满意条件：

• 确保它可工作在大部分零售节假日：圣诞节、复活节、总统节、母亲节、父亲节、劳动节以及新年
• 支持跨2个日历年的节日（不存在跨3个的）
• 节假日季节可以从某个节假日到另一个设定（比如感恩节到圣诞节）

学会在没有详细说明书的情况下开始

这并不是说要抛弃使用详细说明书，实际上是要合理地使用它。

详细说明书的一个不足是它们很少保持更新。

通过事例说明

改变写详细说明书的方式，考虑通过事例来说明一个产品。

用户故事示例：

作为一个雇员，我希望对于我享有的假期请求可以自动批准，那样我就无需等到某人手工批准。

该用户故事的事例——申请比可用天数更多时间的请假不会被自动批准的例子

测试工具推荐：FitNesse, Cucumber

跨职能的团队能降低对文档的需求

Scrum 团队是一个跨职能、多学科的团队。

没有采用敏捷时，测试人员常常抱怨程序员没有持续更新文档，而程序员抱怨他们不能从这些文档中受益。

创建 DEEP 的产品 Backlog

• 详略得当（Detailed Appropriately）
• 做过估算的（Estimated）
• 涌现的（Emergent）
• 排列优先级的（Prioritized）

不要忘记讨论

与产品 Backlog 中所写内容同等重要的是针对它的讨论。这些讨论发生在团队和产品负责人头脑风暴讨论确定产品 Backlog 最初的事项的时候，也发生在 Sprint 中团队和产品负责人持续提炼他们对某个功能的理解的时候。

第14章 Sprint

增量开发主要是一块接着一块地构建一个系统。一部分功能先被开发出来，然后另一部分功能被加入前一部分功能，以此类推。

Alistair Cockburn：增量开发是一种分段和调度策略。

迭代开发是先开发一个初步的版本，得到用户对它的反馈，然后开发包含反馈的后续版本，并根据需要不断重复该过程。

Cockburn：迭代开发是一种重做调度策略。

迭代和增量开发指的是产生反馈，从中学习，之后调整我们正在构建的东西和我们的构建方式。

每个 Sprint 应递交可工作的软件

学会如何在每个 Sprint 中递交可工作的软件是一个新的 Scrum 团队必须克服的最大挑战之一，但是做到这点对于实现敏捷是非常关键的。

敏捷方法强调可工作的软件，因为：

• 可工作软件鼓励反馈
• 可工作软件帮助团队衡量它们的进度
  项目中最大的风险之一就是不知道还剩余多少工作量需要完成。
• 可工作软件允许产品在需要时尽早发布

“潜在可交付”的含义

任何一个新团队需要做的一件事情是讨论并同意“完成（done）”的定义，该定义的内容与应用于所有产品 “Backlog” 的用户故事的满足条件是一样的。

在我们想为每个 Sprint 提交潜在可交付的产品的某个部分时，我们不需要在每个 Sprint 结束时就具备一个完整的产品。产品是可用的，对于这个正在开发的特性，其功能可能不全但是真的可以工作。

识别“潜在可交付”的指导方针

• 潜在可交付意味着测试过
• 潜在可交付并不意味着系统功能的完整
• 潜在可交付意味着集成已做好

每个 Sprint 提交一些有价值的东西

Scrum 团队要在每个 Sprint 提交一些对用户或客户有价值的东西，完成那些可以让用户看到功能特性的任务。

在当前 Sprint 为下个 Sprint 做准备

只在一个 Sprint 中塞入能完成的东西

放入 Sprint 中的每个用户故事必须理解透彻，并在这个 Sprint 中通过各种讨论后确认能在这个 Sprint 中完成。

在 Sprint 中团队有两个目标：

1. 完成当前 Sprint 计划的工作
2. 准备下一个 Sprint

每个 Sprint 始终保持协作

Scrum 项目的特点就是跨职能团队一起工作，而不是将工作从一个组交接给另一个组。

Grossman：在苹果公司，产品不会从一个团队传递给另一个。不存在分离的、顺序式的开发阶段，相反，它是同时进行并且是一体的。产品通过所有部门并行的方式一起完成，包括设计、硬件和软件，经过无穷轮的多学科的设计评审。

避免特定活动的 Sprint

缺点：

• 进度风险增加
• 花太长时间完成从想法到可运行、测试过的功能特性
• 并没有真正解决交迭工作的问题

保持时间箱定期性和严格性

固定 Sprint 长度的好处：

• 团队受益于定期的节奏。当 Sprint 长度可变，团队成员会经常对进度有点不确定。
• Sprint 计划变得更容易
• 发布计划变得更容易

绝不要延长 Sprint

不要改变目标

在 Sprint 里不许改变任何任务，团队在第一天承诺一系列工作，然后期望它们的优先级在整个 Sprint 保持不变。

Scrum 不允许变化进入 Sprint 而乐于异常终止并启动一个新 Sprint。

第15章 做计划

做计划是 Scrum 的基础。Scrum 团队始终承诺开发最有价值的功能。要做到这一点，团队和产品负责人必须要有交付某个功能会花费多少开发成本的估算，否则他们只能按照意愿来排列优先级。

逐步完善计划

早期计划要抓住将要交付内容的要素，但是把细节放到以后考虑。我们只在自己有足够多的知识来支撑这些细节的时候才添加它们。

在早期的计划中不考虑细节，并不是说我们不能承诺项目结束时将交付什么内容，只是我们需要为变更及其对应项目的不确定性预留一些空间。

逐步完善计划的优势：

• 它可以最大限度地减少时间上的投资
  项目开始前详细的计划基于非常多的假设，但随着项目的进行，这些假设会与现实不符。
• 它允许在最佳时机做决策
  项目参与者在项目进行过程中会越来越了解他们的项目。
• 它允许我们改变路径
• 它可以帮助我们避免落入相信计划的陷阱
  一个彻底的、证据充分的计划可以欺骗我们，让我们相信一切都已经考虑周全。

区别对待估算和承诺

如果没有一个好的估算作为开始，一个团队的承诺将变得毫无意义。

要有一个好的估算，团队和产品负责人需要知道两个关键问题：

• 需要完成的工作的规模
• 对团队完成这个工作的进度的预期

计算初始速率只是第一步，一旦有了历史数据并创建置信区间后，需要把它变成一个范围。

团队最好有历史数据或者运行一个或两个 Sprint 后再做出承诺。

第16章 质量

质量保证是整个团队的责任。

把测试集成到流程中

测试完全不是事后的纠正活动，而是为了验证在之前的开发过程中没有引入错误。

爱德华·戴明：我们应该停止依靠大量检验来保证质量，而是要改进工艺流程，从一开始就生产出优质的产品。

为什么最后才测试没有效果：

• 很难改进现有产品的质量
• 错误一直未被发现
• 项目状态难以测量
• 错失反馈时机
• 测试很可能被削减

不同层次的自动化

很难写出自动化测试的一个原因是在错误的层次上进行自动化。

自动化测试金字塔，从下到上分别为：单元，服务，UI

用户界面的负面属性：

• 脆弱。一个小变动可以破坏很多测试。
• 成本高
• 耗时

保留用户界面测试的角色

在服务层执行主要的测试。在用户界面层的测试只需要确认服务被正确的按钮调用，并且数值正确显示在结果字段中。

很多自动化测试投入上的错误是因为一直忽视了整个中间服务层的测试。

第四部分 组织

第17章 扩展 Scrum

Scrum of Scrums 会议

每个参与者要回答三个问题：

1. 从上次会议后，我的团队做了哪些会影响其他团队的东西？
2. 在下次会议前，我的团队计划做哪些会影响其他团队的东西？
3. 我的团队遇到哪些问题可以寻求其他团队的帮助？

第18章 分布式团队

没有共同愿景，几乎不可能形成一个强有力的团队文化。

团队文化部分起源于团队成员彼此间达成的共识。

Scrum 只是一种项目管理框架，它的大量实现细节留给每个团队来完成。

创建一个有凝聚力的团队，关键在于团队成员间建立信任感。

不幸的是，许多项目过早地安排太多时间用于团队建设的练习和讨论，这是一个普遍和危险的错误。在团队早期的运行过程中，越多的人和另外的人进行交互，越有可能做出匆忙的判断并强调他们的差异。作者建议推迟关系建设，直到团队成员彼此了解更重要的东西，如特定技能、优势、工作方式等。可以通过在早期关注进展而非关系建设来做到这一点。

各个团队是由技能、态度和工作方式等方面志趣相投的成员组成的团队，比各团队是围绕着表面属性（国籍，工种等）组成的团队更稳固。

作者强调：

1. 项目启动时焦点要放在早期进展的演示上
2. 社交的整个预算不应该花在前面两个 Sprint
3. 早期的社交活动应该依赖于项目的工作，诸如为制定版本发布计划而把团队召集到一起。

第19章 与其他方法论共存

敏捷不是目标，敏捷意味着持续的改进。

第20章 人力资源、后勤和PMO

在工作空间里应该可见的东西

• 大的、可见的图表。如燃尽图。
• 额外的反馈设备。如熔岩灯。
• 团队里的每个人
• Sprint Backlog
• 产品 Backlog
• 至少一个大白板
• 一些安静和私有的空间
• 食物和饮料
• 一个窗户

第五部分 下一站

第21章 看看进展如何

测量的目的

测量的真正目的是为了减少不确定性。

在软件度量的讨论中，我们常常陷入追求完美的沼泽。我们其实不需要完美的测量，我们只需要测量来帮助我们回答问题。

一般性的敏捷评估

一个生意并不需要完美，它只是需要比竞争者做得好（并且一直保持领先）就行了。

Scrum 团队平衡记分卡

Kaplan 和 Norton 建议企业应该从四个角度：财务、客户、业务流程及学习与成长来衡量业务的状态。

作者觉得更适合的另外的四个角度：

• 卓越运作
  团队努力提供以高生产率生产高品质的产品，同时满足成本和进度目标。
• 面向用户
  团队专注提供客户所需要的功能。
• 商业价值
  节约了成本，增加收入等。
• 未来的方向
  在递交今天的产品和功能的同时，团队建设未来所需的技能和能力。

第22章 没有终点

Scrum 团队围绕着可递交的功能点来组织，而不是围绕着技术或架构分层。