两万字谈谈如何使用 Scrum 框架进行敏捷开发

内容简介：两万字谈谈如何使用 Scrum 框架进行敏捷开发

〇、本文概述

本文介绍『 敏捷开发 』中的一个重要流派 —— 『 Scrum 』，主要从敏捷开发宣言、原则、 Scrum 的价值观、原则、角色、活动以及工件等几大方面阐述 如何使用 Scrum 框架进行敏捷开发 ，其中会有关于 敏捷型组织 、 Cynefiin 框架 、 技术债 等相关知识的介绍。

• 两万字谈谈如何使用 Scrum 框架进行敏捷开发
  • • 2.2 敏捷开发正式诞生的标志
    • 2.3 敏捷开发宣言和原则
      • 2.3.1 敏捷宣言的价值观
      • 2.3.3 其他具体的敏捷原则
  • 三、Scrum 含义、起源和发展
    • 3.1 Scrum 的原意和隐喻
      • 3.1.1 Scrum 英语单词的含义 —— 原意
      • 3.1.2 Scrum 在软件业的含义 —— 隐喻
    • 3.2 Scrum 的起源和发展
  • • 4.1 迭代 VS 增量 VS 冲刺
    • • 4.2.1 Scrum 概要框架图示
      • 4.2.2 Scrum 概要框架说明
    • • 4.2.1 Cynefin 框架与 Scrum 适用性
  • • • • 5.1.1.1 产品负责人概述
        • 5.1.1.2 产品负责人主要职责
        • 5.1.1.3 产品负责人特征或技能
        • 5.1.1.2 产品负责人日常工作
      • • 5.1.2.1 Scrum Master 概述
        • 5.1.2.1 Scrum Master 主要职责
        • 5.1.2.2 Scrum Master 特征或技能
        • 5.1.2.2 Scrum Master 日常工作
      • • 5.1.3.2 开发团队主要职责
        • 5.1.3.3 开发团队特征或技能
      • 5.1.4 职能经理（非 Scrum 角色）
    • • 5.2.1 需求和用户故事（非 Scrum 工件）
      • 5.2.4 潜在可交付产品增量

一、前言

前不久我在团队做过一段时间 Scrum Master， 当 Scrum Master 的实践过程中，曾经很浅略地做过一些关于迭代开发的思考和总结（《关于迭代的一些思考》 ，不过里面关于 Scrum 框架和敏捷开发大多是经验和直觉上的认知，缺少相应理论知识的理解和支持。

为了更深入地理解 Scrum 框架和敏捷开发，春节前后以及工作之余阅读了一些关于敏捷和 Scrum 框架的书籍和文章，从中收获颇多；恰逢 3 月 10、11 号公司作了敏捷培训，过程中我更是获益匪浅，并且自己对于敏捷和 Scrum 的认知和理解在培训中得到了进一步的验证和调整。

所以，在这里我将敏捷和 Scrum 框架的相关知识做适当的取舍、调整并整合起来（做知识的搬运工），同时也把从理论和实践所得的这些认知和理解写出来，希望能就 如何使用 scrum 框架做敏捷开发 这个主题做一个足够的阐述。

注：敏捷或者 Scrum 框架的知识浩如烟海，难以用一篇文章将其说透说全，这里主要讲解 Scrum 框架的重要组成部分 —— 角色、工件与活动；另外敏捷或者 Scrum 不像实打实的技术，里面很多观点都可能比较主观，希望自己认知和理解的内容能尽量客观地对其作出阐述；当然，由于知识和经验有限，如有偏颇，欢迎探讨和指正。

在下一章节，我们先来谈谈一下敏捷开发，往后再继续谈 Scrum 框架。

二、敏捷开发

2.1 敏捷开发的含义

敏捷开发是一种从上个世纪九十年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种 应对快速变化的需求 的一种软件开发能力。常言道：“ 天下武功，唯快不破 ”，此言用于形容“敏捷”的威力相当合适；但我更喜欢另一句西方谚语：“A chess novice can defeat a master if moving twice each round（ 如果允许一个新手一次走两步，那么他就可以击败象棋大师 ）”。敏捷意思为快，但敏捷思想不仅仅求快，它更多强调“ 多快好省 ”，产出得多，产出得快，产出得好，同时节省各种成本，既经济又实用。

它们更强调 程序员团队与业务专家之间的紧密协作 、 面对面的沟通 （认为比书面的文档更有效）、 频繁交付新的软件版本 、 紧凑而自我组织型的团队 、能够很好地 适应需求变化的代码编写和团队组织方法 ，也更 注重软件开发过程中人的作用 。

2.2 敏捷开发正式诞生的标志

2001 年，17 位软件开发人员（包括来自于 极限编程 、 Scrum 、 DSDM 、 自适应软件开发 、 水晶系列 、 特征驱动开发 、 实效编程 的代表们，还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者）齐聚犹他州的雪鸟镇，共同探讨一种轻量级的开发方法。雪鸟会议上，所有的与会代表就使用『 敏捷 』一词概括这种新型的轻量级方法达成了共识，并签署且发表了 《Manifesto for Agile Software Development》 （即 《敏捷软件开发宣言》 ），这成为敏捷开发正式诞生的标志，他们称自己为“敏捷联盟”。

那么，究竟《敏捷软件开发宣言》都宣言了些什么呢？接下来我们仔细看看。

2.3 敏捷开发宣言和原则

2.3.1 敏捷宣言的价值观

雪鸟会议上发表的《敏捷软件开发宣言》摘录如下：

2.3.2 敏捷宣言的原则

另外，宣言中还包括以下十二条原则：

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

敏捷宣言中这些价值观和原则，所谓 入门容易精通难 ，在旁人或者入门者看来也许略显空洞，所言无物；然而，敏捷精髓的实践者们一直坚信着这些理念，觉得它们字字珠玑，所言极是。不管我们是走敏捷的哪个流派，都不妨在实践敏捷的过程中，回过头来看看这些价值观和原则，想必会常看常新，大有裨益。

2.3.3 其他具体的敏捷原则

以下思维导图是其他具体的敏捷原则的说明。

作为敏捷众多流派中的被广泛实践的 Scrum 流派 ，同时也是我工作之后的两年多时间里团队中使用的敏捷开发方式，下一章我们来初步了解一下。

不过正式介绍 Scrum 框架之前，我想有必要先谈谈一个词 ——『 敏捷型组织 』。在实践敏捷的过程中， 个人要敏捷，团队要敏捷，更重要的是组织也要敏捷 ，而且我认为组织的敏捷是团队和个人真正实践敏捷的重要基石。

2.4 敏捷型组织

组织结构指的是一个 组织内部团队之间相互关系 的布局。

它包括把员工分配到不同的部门和团队，也包括为了发号施令而安排的层次结构。各公司有不同的组织结构， 职能型 和 矩阵型 两种基本结构已经使用多年，然而一种被称为 敏捷型结构 的组织结构更适用于软件开发行业。

我们先来看看这三种组织结构：

2.4.1 职能型组织

2.4.1.1 职能型组织的含义

军队和工业界曾经使用过职能型结构的组织形式，这形式的结构 按照主要目的或职能来设置部门 ，基本上 根据员工的基本职能来组织 。在技术组织内，按照职能的不同分成不同的部门，如工程部，质量保证部，运维部，项目管理部等；同时，每个部门都有自己的管理层级结构，都有自己的负责人。在工程部，工程师向工程经理汇报，工程经理向工程副总汇报；在其他部门的汇报关系类似。

2.4.1.2 职能型组织的优缺点

这种职能型组织结构很多优点，比如

• 所有的经理几乎都是 按照层级提升 的；
• 员工在专业性方面也容易取得一致 ，技术相关的同事们（包括经理）很容易回答涉及技术方面的问题，整个机构都是 按照专业分工来组织 的，经理和工作伙伴具有同质性；
• 职责明确、容易分配任务、更好地遵循标准规范 ，这种简洁性使得工作分配极为容易。

当然，职能型组织结构有它的问题：

• 缺乏单一的项目负责人 ；
• 跨部门的沟通效果不佳 ；
• 部门间存在情感性冲突 。

考虑到这些利弊，当其 同质性的好处超过整体协调和所有权带来的问题 的时候，可以考虑采用职能型组织结构。比如，采用 瀑布式开发的组织 ，经常能从按职能划分的组织结构中获益。因为该结构下号与瀑布型方法中固有的阶段控制相匹配。

2.4.2 矩阵型组织

2.4.2.1 矩阵型组织的含义

尽管职能型组织结构有一些不可否认的优点，但仍存在弊端。为了克服这个问题，公司甚至军事机构演化出 矩阵型组织 。矩阵型组织机构的主要概念是 层级的两个维度 。在职能型组织的每个团队有一个经理，每个团队的成员向一个老板汇报；而矩阵型组织与职能型组织相反，包括至少两个管理维度，每个团队的成员或许有两个或多个老板，比如，传统的职能组织旁边 增加了项目管理团队 。

如上图， 深蓝色标注的员工，包括项目经理 1、工程师 1、工程师 2、质量保证工程师 1、质量保证工程师 2、产品 1、产品 2 组成了一个项目团队在一起工作 ；深蓝色标注的员工组成一个团队；橙色标注的员工又组成另一个团队；每个团队里的 项目经理对任务分配和项目进度负有责任 。在更大和更复杂的组织里，许多来自不同团队的人可以属于同一个项目团队。

2.4.2.2 矩阵型组织的优缺点

职能型组织的是三个问题：缺乏单一的项目负责人；跨部门的沟通效果不佳；部门间存在情感性冲突。而在矩阵型组织里，存在以下优点：

• 项目团队 负责解决所有的问题， 承担项目的所有责任 ；
• 项目组会频繁地开会和邮件沟通来解决沟通不佳的问题 。

同样的，矩阵型组织也有其弊端：

• 独立贡献者向多个有不同优先级的经理汇报 ，压力增加；
  
  • 比如工程师现在工程经理和项目经理之间，工程经理让他按照标准写代码，项目经理坚持必须按时完成任务，工程师面临压力和忧虑，担心自己的表现不能让经理们满意。
• 个人精力分散 ，项目团队本身也需要很多会议和邮件来维持项目的进展，占用更多的个人时间。

矩阵型组织结构解决了一些问题的同时，又引入了一些新的问题。假如保持职能型和矩阵型组织结构的优点，“是否有更好的办法？”答案是“有”，这就是“敏捷型组织”。

2.4.3 敏捷型组织

2.4.3.1 敏捷型组织的含义

随着从提供软件向提供服务方向的发展（SaaS —— 软件即服务，现在还有 PaaS —— 平台即服务 和 IaaS —— 基础架构即服务），技术人员开始思考如何做个好的服务提供者而不是软件开发者。伴随着这一演进，人们开始 思考服务的质量和可靠性 。另外，敏捷开发方式的出现，还有职能型和矩阵型组织弊端的存在，使被称为敏捷型的新组织结构应运而生。

我们把 跨职能同时符合服务架构 的组织，标示为敏捷性组织。在这种组织中，团队是 完全自主管理 和 自给自足 的。从形成概念，到研发，再到生产系统中的服务支持，团队负有全部的责任。跨职能部门的额总监、副总裁以及敏捷型团队替代了工程副总裁这样的常规管理角色。

2.4.3.1 敏捷型组织的优缺点

敏捷性组织具有如下优点：

• 组织边界适当变小，有效地降低情感性冲突（部门或者团队之间的互相推诿和相互抱怨）； 组织人员丰富多样，提高认知性冲突 （经验、技能和关系的多样性带来更优的解决方案）；

  冲突有好坏之分，好的冲突（ 认知型冲突 ）是 健康的争辩 ，是团队关于该 做什么或者为什么要做（以及该怎么做） 而发生的冲突，它涉及更大的视角和更多的经验；坏的冲突（ 情感型冲突 ） 基于角色，经常涉及该谁做 ，纠缠不清的基于角色的讨论往往被认为是政治性或者领地性的，如果处理不当会对团队产生不良影响。

  • 认知型冲突 有助于团队扩大行动的可能范围，不同的见解和经验凑在一起有机会从多角度出发解决难题；
  • 情感型冲突 会带来组织的创伤，结果会在战术和战略上限制选择，争斗关闭了我们思维的选择空间，意味着结果可能不是最佳的。

  通过营造开发、尊重的文化氛围，推动健康的争辩，吸纳各类人在技能和视野上互补，最大化策略的选择范围，把认知性冲突最大化，情感型冲突最小化，让团队快速成长。

• 团队 共享一个目标，荣辱与共 ，不再争论谁负责什么或谁应该执行哪些任务，个体对提供高质量、高可用性并能满足商业目标的服务负有更多的责任，并有能力处理产品或服务的全生命周期；

• 团队 被充分授权 ，有权力做出决定，高效地完成高质量的任务的动力更足，能进行产品的自主研发；

• 团队 沟通协作更为充分和顺畅 ，信息共享更为实时，提高团队的创造力与表现水平。

  

敏捷性组织的缺点：

• 敏捷性组织 去除了部门传统的管理角色 ，比如“工程副总裁”，有组织架构调整的缓冲期；
• 敏捷性组织需要原来团队按照组织设计中面向用户的服务 重新组织 。

没有一个组织结构是完美的，即便敏捷型组织存在着弊端，那些正在挣扎着试图解决不良的服务支持、大量的冲突、员工自我驱动力不强和整体缺乏创新的公司来说，敏捷型组织模式是个理想的选择。

我个人一个浅薄的观点：公司内部建设走“战区主战，军种主建”之路，其中的“战区”正是由相应的业务、产品，研发，测试、运维，设计等主力提供智能投顾和余额代偿服务的相关人员共同组成的敏捷型组织的阵地。

敏捷的相关知识介绍到此，接下来主要是介绍 Scrum 框架，首先从 Scrum 的含义、起源和发展开始。

三、Scrum 含义、起源和发展

3.1 Scrum 的原意和隐喻

3.1.1 Scrum 英语单词的含义 —— 原意

• Scrum 在英语中是『 英式橄榄球运动中争球 』的意思，在争球过程中，两个队的前锋在球前面围成一圈，彼此的胳膊架在一起，低头争夺球权，此时球队两军对垒，剑拔弩张，环境变化很快，如果团队没有 共同目标和方向 ，力量分散，很难抢到球。

• 当抢到球后，必须把球往后场传递以便得分，这又需要球队 作为一个整体具有高度的默契与高超的技巧 才办得到。

• 最后赛场上所有球员处于同一时间和空间， 赛场的秋毫变化 （球的位置、队友的位置、敌对人员的位置、观众的加油声、团队士气与人员状况、天气与球场的状况、裁判的表现和教练的战术等等的变化）都被 实时共享 ，大家 瞬间聚力讨论快速决策 适应这些变化，这样的状态对于取得争球的胜利是至关重要的。

3.1.2 Scrum 在软件业的含义 —— 隐喻

在软件开发历史过程中，Scrum 先驱们将 Scrum 这个词的隐喻应用于软件开发。它是一套 轻量级的核心价值观、原则和实践 ，统称为 Scrum 框架 ，在这个框架中人们可以解决复杂的自适应问题，同时也能高效并有创造性地交付尽可能高价值的产品。

在这个框架下，我们可以检验 Scrum 团队是否符合 Scrum 原意的要求：

• 团队成员是否有共同目标？
• 团队成员是否开诚布公地紧密合作？
• 团队成员是否经常检视和调整？
• 团队成员是否各自发一颗球（各做各的用户故事等），各自努力往后场冲刺以争取个人绩效？
• ......

如果我们的 Scrum 团队遭遇困难，可以思考一下如何向优秀的球队学习，也许是一个突破困境的机会。在进一步探讨 Scrum 框架之前，我们先来了解一下 Scrum 的起源和发展。

3.2 Scrum 的起源和发展

1986 年，『 竹内弘高 』和『 野中郁次郎 』在《哈佛商业评论》中刊登一篇题为“新型新产品开发策略（ The New New Product Development Game ）”的文章，将橄榄球和争球—— Scrum 的隐约应用于软件开发：

产品开发的“接力赛”方式......可能和要求最快，最灵活的目标有冲突。一种整体方式或“橄榄球”方式（即团队作为一个整体打完比赛，来回传球），也许能够更好地迎合当下的竞争需求。

（英文原文：The traditional sequential or “relay race” approach to product development—exemplified by the National Aeronautics and Space Administration’s phased program planning (PPP) system—may conflict with the goals of maximum speed and flexibility. Instead, a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.）

这篇文章描述了本田、佳能、富士施乐这样的公司是如何通过可伸缩、基于团队的“蜂拥式”的方式开发世界一流的产品。

1993 年，被誉为 Scrum 之父的其中一位 —— Jeff Sutherland （曾参与敏捷软件开发宣言的起草，是Scrum的共同发明人，现为Scrum基金会总裁） 和他的团队把 1986 年 竹内弘高 和 野中郁次郎 那篇文章的概念与面向对象开发，基于经验的过程控制、迭代和增量开发、软件过程和生产率研究、复杂适应系统中的概念结合起来，创立了用于指导软件开发工作的 Scrum 过程。

1995 年，被誉为 Scrum 之父的另外一位 —— Ken Schwaber （敏捷软件开发宣言的17位发起人之一，与 Jeff Sutherland 合作，共同建立了 Scrum 软件开发方法）在 OOPSLA 上发表第一篇关于 Scrum 的论文 —— 《SCRUM 开发过程 （SCRUM Development Process） 》。

此后，Sutherland 和 Schwaber 一起完成了一份关于 Scrum 的重要文档 ——《 Scrum 指南 （ The Scrum Guide ）》。两位 Scrum 先驱把这本指南描述为 “ Scrum 金科玉律，Scrum 专有文档 ”，并把它比作是象棋游戏的游戏规则说明：“ 描述棋子（各个部件）的行走规则，顺序，输赢如何定义，等等。 ”尽管指南有像说明书一样的价值，但是这本身也是指南的局限 —— 我们并不能仅依靠一份说明书就能把象棋下好，关于 Scrum 更多的原则，价值和实践需要进一步的去探讨。

四、Scrum 框架概述

4.1 迭代 VS 增量 VS 冲刺

在日常开发中，我们经常定义迭代名为 Sprint 1、Sprint 2 ... Sprint N，这里 Sprint 的英文原意是 冲刺 的意思，所以对应着 Sprint 1、Sprint 2 更合适的称呼是冲刺 1、冲刺 2。但这里更想强调的一点是， 迭代式开发 ， 增量式开发 和 冲刺开发 不仅仅是术语的不同，其在开发方式上也是有区别的。

4.1.1 迭代式开发

• 基于的观念：
  • 承认在把事情做对之前有可能做错，在把事情做好之前有可能做坏；
• 迭代式开发本身是一种有计划修改的开发策略：
  • 通过多次开发来改善正在构建的特性，逐步得到一个完善的解决方案；
  • 例如，对一个知之甚少的产品：
    
    • 开始时可以先创建原型以获得重要知识；
    • 接着可以创建一个更好一点的修改版；
    • 在接下来是一个相对好的版本；
    • 最后得到想要的完整的产品；
• 优点：
  • 改进产品的一种非常好的方式
• 缺点：
  • 在遇到不确定因素时，很难实现确定需要改进多少次。

4.1.2 增量式开发

• 基于的原则：
  • 先构建部分，再构建整体；
• 增量式开发是一种逐步增加特性的开发策略：
  • 把产品分解成更小的特性，先构建一部分，在从中了解它们在目标使用环境中的具体情形，然后根据更多的理解来做出调整，构建更多的特性。
• 优点：
  • 过程中获得重要的信息，使我们能够适应开发工作并改变工作方式
• 缺点：
  • 逐步构建的过程中，有迷失全局的风险（见木不见林）

4.1.3 冲刺开发

• 基于的观念：

  • 同时利用迭代式开发和增量式开发优点，消除两者的缺点，即既迭代又增量。

• 冲刺开发是一种使用固定时间盒来适应性迭代产品增量的开发策略：

  • 在冲刺内做完所有的相关阶段工作（分析、设计、开发、测试、集成等），而不是一个阶段工作，创建可工作的产品增量（产品的部分特性而不是全部）。
    
    • 这个增量需要包含前期已开发的特性，或者需要与前期已开发的特性集成与测试，而不是分离的特性并且没有与前期的特性集成，否则就不能被认为完成。
  • 冲刺每次做一个或多个特性，这样能快速地修改特性，体会到迭代式开发的好处，同时又不必特意为后面的迭代制定计划。

• 优点：

  • 冲刺完成获取相关反馈后，我们可以进行调整，在接下来的冲刺中可以选择开发其他特性（评审检视产品）或者修改用于构建下一组特性的过程（回顾检视过程），这有助于解决实现不知道需要改进多少次的问题。冲刺开发不需要提前确定迭代次数，在增量开发产品时，持续不断的反馈能做到迭代次数合理，经济合理。

• 冲刺思想的一种误用：

  • 每个冲刺只做一种类型的工作 —— 例如，冲刺 1（分析）、冲刺 2（设计）、冲刺 3（编码）、冲刺 4（测试）。这种做法是把 Scrum 披上瀑布式开发的皮 —— 被戏称为 WaterScrum 或者 Scrummerfall。

4.2 Scrum 概要框架

这一节主要是简单描述一下 Scrum 的概要框架，让大家有个初步的认识，后面会有关于 Scrum 框架更为详细的说明。

4.2.1 Scrum 概要框架图示

4.2.2 Scrum 概要框架说明

上图描述了一个 Scrum 冲刺的概要框架，就像大家所熟知的那样：

1. 『 产品列表 』首先要建立产品列表 —— 一个按优先级 排序 的、有粗略估算的、成功开发产品所需特性及其他功能的列表。
   
   • 在产品列表的指导下，我们总是先做优先级最高的条目（比如上图中的特性 A、B、C）；
   • 换句话说就是，当一个冲刺完成时，已完成的条目都是优先级最高的。
2. 『 冲刺计划会 』一般情况下，产品列表中的工作量远远不是一个短期冲刺内能够完成的。所以冲刺开始时，团队需要制定计划，说明在下一个冲刺中要创建产品列表中的哪几个高优先级的特性。
3. 『 冲刺 』工作本身是在一些短周期、时长固定的冲刺中完成的，每个冲刺从一周到一个月。
   
   • 在每个冲刺中，自组织，跨职能的团队完成所有必需的工作 —— 例如设计、开发、构建和测试 —— 产生完整的、可工作的、可以放入产品的特性。
4. 『 冲刺评审会回顾会 』在冲刺结束时，团队与利益干系人一起评审已经完成的特性，获得它们的反馈，产品负责人和团队既可以对下一步工作内容进行修改（在评审会上），也可以修改以前的工作方式（在回顾会上）。
   
   • 评审会 上，如果利益干系人在看到一个完成的特性时，意识到自己没有考虑到另一个必须包含在产品中的特性，此时，产品负责人只需要建立一个代表该特性的新条目，并把它以适当的有线顺序插入产品列表，留到后面的冲刺中完成。
   • 回顾会 上，如果开发团队在回顾冲刺过程中，意识到自己没有考虑到依赖风险导致开发过程不必要的等待时，开发团队可以提出下一冲刺计划会上考虑依赖风险并做好相应的控制。
5. 『 潜在可发布产品增量 』在冲刺结束时，团队应当得到一个潜在可发布产品（或者产品增量）。如果业务上适合，就可以发布；如果不适合在每次冲刺后发布，可以把多个冲刺的一组特性合并在一起发布。

到这里为止，我们对 Scrum 框架有了个初步的了解，这时候我们可能会有疑问，为什么我们要使用这样的框架来做软件开发呢？它适用于所有的软件开发活动吗？下面一节我们来做个简单的探讨。

4.3 为什么选择 Scrum

4.2.1 Cynefin 框架与 Scrum 适用性

我们先来看一下著名的 Cynefin 框架 ，它可以帮助我们更好地理解工作环境并确定适合的工作方式。

Cynefin 框架最早是在 1999 年威尔士学者 Dave Snowden 在 知识管理 和 组织战略 中提出的。Cynefin 是威尔士语，意为 “栖息地” 或 “住所”，指人们对生活环境的共同文化、宗教、地理和部落的总体经验和感受。这个框架用于 描述问题、环境与系统 ， 说明什么环境适合使用什么解决方案 。

Cynefin 框架定义了五种域：复杂、繁杂、混乱

、简单和无序，并且比较了各个域的差别，以及描述了 Scrum 适合哪些域。

4.2.1.1 复杂域

• 特征与处理方式：
  • 在处理复杂问题时，不可预测性 > 可预测性
  • 如果有正确答案，也只有事后才知道
  • 问题是涌现的。
  • 需要研究探索才能认识问题、进而根据认知进行检视、调整
  • 处理复杂问题需要创造性的创新的方法
  • 需要为试验活动营造一个容忍失败的环境，以便获取重要信息
  • 大量的互动和交流必不可少
• Scrum 框架适用性： 特别适用
• 适用的软件开发活动举例： 创新的新产品的开发

4.2.1.2 繁杂域

• 特征与处理方式：
  • 在处理繁杂问题时，可预测性 > 不可预测性
  • 因果可以发现，但不是很明显
  • 可能有很多正确答案，需要专家诊断并找出这些答案
  • 繁杂问题是专家控制的良好实践域
  • 通过测量数据获得控制权
• Scrum 框架适用性： 适用，但非最佳方案
• 适用的软件开发活动举例： 1. 性能优化 （性能优化工作需要调整参数来找出系统的最佳整体性能，这个问题最好能找到专家，让他们评估情况，调研几种备选方案，根据实践做出响应）2. 软件日常运维

4.2.1.3 混乱域

• 特征与处理方式：
  • 在处理混乱问题时，需要快速度响应，立即采取行动，然后检视，看情况是否稳定，然后调整并把环境迁到复杂域中
  • 需要作出很多决定，没有时间思考
  • 立即采取行动，重新建立秩序
  • 寻找可行（而非正确的）答案
  • 新领域，没有人知道
  • 没有清晰的因果关系
• Scrum 框架适用性： 适用，但非最佳方案
• 适用的软件开发活动举例： 1. 突发情况 （已经没时间再排列优先级并确定下个迭代做什么工作，需要立即采取行动，果断止损）；2. 处理外部依赖缺陷 （比如通过立即升级来处理 fastjson 缺陷）

4.2.1.4 简单域

• 特征与处理方式：
  • 在处理简单问题时，因果关系显而易见
  • 问题和解决方案相对稳定，不太可能变更
  • 有已知的解决方案，评估后选一种合适的解决方案。
  • 评估实际情况，将情况分类，根据已经确定的时间提出响应措施
  • 适合使用一组明确的、可重复的、已知能够解决问题的步骤
• Scrum 框架适用性： 适用，但非最佳方案
• 适用的软件开发活动举例： 1. 生产同样的产品 ；2. 部署环境

4.2.1.5 无序域

如果不知道自己处于哪个域，说明就是在无序域中。因为无法理解自己的处境，所以这个域很危险；如果处于无序域，要考虑的不是在无序域中如何使用 Scrum，而是要 尽早摆脱这个域 ；摆脱无序域需要 把问题分解为小的组成部分，并安排到另外 4 种域之一中 。

4.2.1.6 事务性工作

• 特征与处理方式：
  • 不知今后很长一段时间有多少工作，无法为一周或者更长时间的迭代指定可行的计划，即便知道有多少工作，也很可能收到高优先级的支持请求并把预定的长远计划替换掉（比如客服）
• Scrum 框架适用性： 不适用，适合看板
• 适用的软件开发活动举例： 1. 常常被打断的支持与维护工作（非日常运维）

4.2.2 Scrum 的好处

从上一节的 Cynefin 框架可知， Scrum 框架最适用于复杂域、适用于繁杂域但非最佳 。如果我们的软件开发活动所处的领域很复杂，未知的东西比已经的多，那么我们需要一种开发方式，能够让我们快速探索新想法和新方法，快速了解哪些解决方案可行、哪些不可行（即快速探索和反馈）。

如果把没有采用敏捷（或者 Scrum ）而是采用传统开发方式或者没有任何开发方式的业务人员和开发人员找到一起，问他们“你们对软件开发工作的结果感到满意吗？”或者“你们认为我们是否及时、经济、高质量地交付了良好的客户价值？”，通常他们的回答都是“否”，并如出一辙地补充说：

• “项目失败率高得让人无法接受”；
• “交付日期延迟了”；
• “投资带来的汇报常常打不到预期”；
• “软件质量很差”；
• “生产率低得让人羞愧”；
• “没有人对结果负责”；
• “员工士气低落”；
• ......

而认真踏实地使用 Scrum 的团队和组织，却是另一番不一样的情况。

• 这些组织或者团队总是让客户感到满意，他们不仅仅交付了客户第一天在对真正需求知之甚少的情况下提出的功能，而且交付了客户真正想要的功能；
• 他们还频繁地发布了较小的版本并由此提升了投资回报；
• 而且，毫不留情地暴露组织功能失调和浪费的地方，还为他们节约了成本。

Scrum 关注在 每个冲刺交付可以工作的、集成好的、经过测试的、具有业务价值的特性 ，力争 更快交付成果 。处于复杂域的组织必须根据竞争对手、客户、用户、监管部门和其他利益干系人的 互动快速做出调整 ，Scrum 能很好地帮助他们取得成功。

五、Scrum 框架详述

本章节会详细讲解 Scrum 框架的各大角色、工件以及活动。

参考下图，图中 绿色标记的是三大角色 （产品负责人、Scrum Master、开发团队）、蓝色部分标记的是三大工件（产品列表、冲刺列表、潜在可交付产品增量）、橙色标记的是七大活动（冲刺、产品列表梳理、冲刺计划会、冲刺执行、每日站会、冲刺评审会、冲刺回顾会）。

5.1 三大角色

5.1.1 产品负责人

5.1.1.1 产品负责人概述

• 是 有授权 的产品领导力中心，是唯一有权决定要 构建哪些特性 并 以何种顺序构建 这些特性的人；
• 需要保持一个清晰的构想并把它 传递给每一个参与者(包括利益干系人、开发团队等) ；
• 产品负责人的身份决定他要对正在开发和维护的解决方案 全面负责 ；
• 还有责任确保总能 完成价值最高的工作 （可能包括偏技术的工作）；
• 与 Scrum Master 和开发团队积极合作，及时 解答 Scrum Master 和开发团队提出的问题 。
  

5.1.1.2 产品负责人主要职责

产品负责人勾勒产品愿景、为产品指明方向、计划开发节奏、考虑开发成本等，他责任重大，一方面要理解组织中利益干系人、客户、用户（有时候还包括开发团队）的需求，是他们的 代言人 ，担任的是 产品经理 的角色；另一方面，对正在开发的特性和开发顺序，要和开发团队紧密合作，验收开发出来的产品，担任的是 业务分析员 和 测试人员 的角色。

以下思维导图是产品负责人主要职责的说明。

5.1.1.3 产品负责人特征或技能

虽然优秀的产品负责人体现出很多特征或技能，但可以归为四类： 领域知识 ， 人际交往能力 ， 决策力 和 责任心 。

以下思维导图是产品负责人主要特征或技能的说明。

5.1.1.2 产品负责人日常工作

为了更好地理解产品负责人的职责，这里也通过一张图大致列一下产品负责人的日常工作内容。

以下图片是产品负责人主要日常工作内容的说明。

5.1.2 Scrum Master

5.1.2.1 Scrum Master 概述

• 负责 指导 团队在通用的 Scrum 框架上 建立并遵循自己的过程 ，帮助每个参与者理解并乐于接受 Scrum 的价值观、原则和实践；
• 充当教练、 在过程方面发挥教导作用 ，帮助团队以及组织中的其他人指定合适的高绩效、有组织特色的 Scrum 方法；如果采用 Scrum 可能是一个充满挑战的变革管理过程，需要帮助组织顺利适应这个过程；
• 负责 保护团队不收外部干扰和障碍 ，（在个人无法有效解决遇到的障碍时）发挥领导作用，清楚阻碍团队生产率的障碍；
• 是领导者，不是管理者， 无权控制团队 。

5.1.2.1 Scrum Master 主要职责

Scrum Master 既是 Scrum 团队的教练、是 Scrum 过程权威，也是团队服务型领导、“保护伞”和“清道夫”，一个真正优秀的 Master 同样不易养成。

以下思维导图是 Scrum Master 主要职责的说明。

5.1.2.2 Scrum Master 特征或技能

Scrum Master 必须见多识广，具备领域知识和技术知识，要善于提问，要有耐心和协作精神，要懂得保护团队，并且让沟通公开透明。

以下思维导图是 Scrum Master 主要特征或技能的说明。

5.1.2.2 Scrum Master 日常工作

为了更好地理解 Scrum Master 的职责，这里也通过一张图大致列一下 Scrum Master 的日常工作内容。

以下思维导图是 Scrum Master 主要日常工作内容的说明。

5.1.3 开发团队

5.1.3.1 开发团队概述

• 负责确定如何交付产品负责人要求的产品；
• 由多种职位的人组成的多样化 跨职能团队 ，负责产品的设计、研发、测试等，包括架构师、开发人员、测试人员、数据库管理员、运维人员等；
• 开发团队成员整体具备的技能足以实现产品负责人要求交付的业务价值。

5.1.3.2 开发团队主要职责

以下图片是开发团队主要职责的说明。

5.1.3.3 开发团队特征或技能

以下思维导图是开发团队主要特征或技能的说明。

5.1.4 职能经理（非 Scrum 角色）

虽然 Scrum 框架中并没有明确定义经理的角色，但经理在敏捷组织中依然发挥着重要的作用。

以下思维导图是职能经理主要职责的说明。

5.2 三大工件

5.2.1 需求和用户故事（非 Scrum 工件）

5.2.1.1 需求

瀑布开发以及 Scrum 开发对待需求的不同:

• 瀑布开发 ：需求是 必需的 、是 不可协商的 、早早地就 已细化 并且是独立的。
• Scrum 开发 ：需求细节是在开发期间 持续不断的对话中商讨出来的 ，而且是等到团队开始构建功能的时候， 及时、刚好地细化 这些需求为团队提供支持，分为大便级需求、板砖级需求、钻石级需求。

5.2.1.2 用户故事

• 定义：
  • 用户故事是可用于 陈述业务价值 的一种简便格式，适合各种 PBI，特别是特性。
• 意义：
  • 用户故事的制作方式旨在帮助业务人员与技术人员 双方都能了解需求 （ 关注做什么，为什么做 ）。
• 格式：
  • 作为<用户角色>，我想<目标>，这样可以<利益> ；
  • 样例：作为一名典型用户，我想看到某地址周围餐馆的公正评价，这样可以决定去哪里吃饭。
• 抽象级别：
  • 史诗、主题、用户故事（特性）
• 注意项：
  • 任务不是故事，要详细地说明如何做，它不是故事，因此在写故事的时候必须要避免任务级细节。
• 好故事的 INVEST 原则：
  • 独立（Independent ）:
    • 用户故事应该是 独立 的，至少也应该是 相互间松耦合 的； 依赖程度高的故事会使估算、排优先级顺序和规划复杂化 ；这里的独立也不是说完全消除依赖，而是在写故事的时候，尽量避免依赖关系。
  • 可协商（Negotiable）：
    • 故事的细节是可协商的，不是以前需求文档写就的书面合同； 可协商有助于避免彼此推诿，相互指责的心态 。如果故事可协商，开发人员就不会说：“如果你想要，就该把它写到文档里”，业务人员也不会说：“你明显没有理解需求文档，因为你开发的东西是有误的”。
    • 产品负责人告诉团队如何实现故事，这是违背可协商性的常见例子。如果 如何做变得不可协商，就会减少团队创新的机会 ，由此导致创新浪费。
  • 有价值（Valuable）：
    • 对客户、用户或者两者来说，故事都要有价值，否则就会造成浪费。
    • 这里主要想强调一下技术故事，比如“作为开发人员、我想迁移系统到最新版 Oracle 数据库管理系统上，这样就可以避免在即将退役的 Oracle 版本上运营”， 技术故事要说服产品负责人以适当的顺序加到产品列表。
      
      • 但有时候，很多技术故事实际都不应该纳入产品列表，为什么？
      • 比如“作为开发人员，我想对（上个冲刺的）特性 A 做集成并部署在线上环境，这样可以让特性 A 交付给客户”，这类故事应该 属于完成业务价值所涉及的任务 。 如果开发团队的完成定义比较严，就没有必要再写这些故事，因为完成已经隐含这些工作 。
  • 可估算（Estimatable）
    • 团队无法估算故事的大小，原因不外乎两个：这个 故事太大或太模糊 以至于估不出来； 团队积累的知识还不够多 ，所以估不出来。对于前者，团队就得和负责人一起，把它 拆成更容易估算的故事（钻石级） ；如果是后者，就需要通过某种形式的 探索活动来获取信 息。
  • 小（Small —— 大小合适）
  • 可测试（Testable）
    • 故事的相关测试要么通过，要么失败。“可测试”意味着故事要有相应的 优质接受标准 。如果没有可测试的标准，冲刺结束时我们怎么知道故事有没有做完？另外，因为这些 测试往往提供重要的故事细节 ，所以团队很可能需要这些测试来估算故事的大小。

5.2.2 产品列表

• 排好优先级的具有 粗略估算 的产品特性列表

  • 对于开发新产品，产品列表是为了满足产品负责人的愿景而开发的 新特性 ；

  • 对于正在开发的产品，产品列表还可能包含 新特性 、 对现有特性的变更 、 需要修复的缺陷 以及 技术改进点（重构或偿还技术宅） 等；

    

    

• 高优先级条目出现在产品列表的 顶部 ， 低优先级 条目出现在 底部 ；

• 是一个 不断演进 的工件，在业务环境发生变化或 Scrum 团队（通过每个冲刺获得的对软件的反馈）深入了解产品后， 可以添加、删除或修改其中的条目 ；

• 产品列表中 保留合理的存量 （经过梳理的，准备就绪并可以实现的条目），一个似乎对很多团队都有效的、有启发意义的方法是 准备好两三个冲刺的 故事。

  • 比如，如果团队在每个冲刺一般能做大约 5 个 PBI，那么团队在梳理列表时，任何时刻都总有大约 10 到 15 个 PBI 是准备就绪的（没记错的话，我在白板上看到拿铁团队下个迭代准备改进的一个点就是准备好 2 个冲刺量的故事点）。

    

5.2.3 冲刺列表

• 已选定 的 高优先级 的并将在 下一个冲刺完成 的的产品特性条目
• 大多数情况下 需要细分成任务进入冲刺 ，少数情况下冲刺列表如果足够细，可以 直接称为任务进入冲刺 ；

5.2.4 潜在可交付产品增量

• 是冲刺 结束后的产出 ，包含 软件的新特性、修复的缺陷、改进后的技术点 等
• 最低限度的定义为 ：产出一个完整的产品功能，经过设计、构建、集成、测试并且编写了文档；
• 最激进的定义为 ：当业务部门想要交付（或部署、发布）时，能够确保每个冲刺都为内外部客户交付所需价值；
• “潜在可发布”并不是说开发什么必须实际交付，交付是一个业务上的决策，只有适合时才做交付；最好理解为 对冲刺中实际开发的产品的一种信心 ： 意味着如果业务部门想要交付的话，那么我们在交付这个冲刺的结果之前，不需要再做其他重要工作（比如重要的测试和集成等）。

5.3 七大活动

5.3.1 产品列表梳理

• 产品负责人建立产品愿景，因为愿景可能很大，所以需要建立一组特性并收集到按优先级排序并有粗略估算的产品列表中。这个建立和优化产品列表条目、估算并确定他们的优先级的顺序的过程成为“产品列表梳理”。
• 梳理包括创建、增加、修改、删除条目或者调整条目的优先级等

5.3.2 冲刺

5.3.2.1 时间盒固定（前一冲刺结束后马上开始新冲刺）

• 设定 WIP 数量限定
• 强制排列优先顺序
  • 时间盒强制我们按照优先级排序并执行最重要的最小批量的工作，因此可以集中注意力快速完成有价值的事情。
• 展示进度
  • 在冲刺结束前，通过完成和验证重要的工作，时间盒帮我们展示相关进度，特别是冲刺产出在大特性上的进度。
• 避免不必要的完美主义
  • 避免花太多时间尝试把事情做“完美”，或者说避免当“足够好”已经满足要求的时候还要“镀金”，时间盒强制结束可能无休止的工作(无休止的知识探索、无休止的原型试验、无休止的优化等)。
• 促进结束
  • 当团队有一个确定的结束日期时，事情更有可能做完。冲刺结束的最后期限不容更改，可能激发团队成员全力以赴按时完成工作。
• 增强可预测性
  • 虽然我们不能准确预测从现在开始一年内、半年内要完成哪些工作，但预测下一个短冲刺能够完成的工作是完全可以做到的。

5.3.2.2 长度一致（如无例外，每个冲刺时间长度固定）

团队在当前冲刺中无法完成所有的工作，这并不是延长冲刺长度的正当理由。到了冲刺最后一天才意识到无法完成工作，所以想通融通融，增加一天两天来完成，这种做法是不合适的。 需要延长冲刺是不能正常工作或者有改进空间的征兆 。

• 节奏感
  • 冲刺中稳定的节奏感让人们能够“专攻这个领域”、“屡战屡胜”、或者“进入最佳状态”；这是因为稳定的节奏感使单调而必要的活动成为习惯，从而留出心力，集中做有趣、增值的工作
• 消除工作强度的差别
  • 传统瀑布项目中，工作强度到项目最后陡然增长，而在 Scrum 中，每个冲刺的强度量变曲线都和其他冲刺相近。
  • 每个人都知道需求梳理、冲刺计划会、冲刺评审会回顾会等活动的时间安排，减少不必要的召集会议人员的沟通时间、也能更好地让所有参与人安排时间，减少等待；
• 简化计划过程
  • 团队使用长度可变的冲刺时，“团队的平均速率是每个冲刺 20 个点”这类的说法就没有意义了；由于长度可变，团队的平均速率估算变得复杂，当开发大版本需要多个冲刺完成时，将难以估算究竟需要多少个冲刺才能完成。

5.3.2.3 短迭代（一周到一个月不等，一般为两周）

• 短迭代容易规划，并且规划相对科学
  • 短时间范围做规划所需要的工作量比给长时间范围的计划工作量小得多，结果也准确得多。
• 反馈快
  • 短周期的冲刺可以产生快速的反馈
  • 每个短冲刺开发一些可以工作的软件，然后有机会检视和调整所构建的软件以及构建软件所需的方法。
  • 这种快速反馈能够使我们迅速剪掉不适合的产品路径或开发方法，避免在错误决定的基础上做出更多错误的决定而导致错上加错；
  • 还能使我们更快地发现和利用稍纵即逝的商机。
• 投入产出比高
  • 更早、更频繁的交付，可以更快地产生收入，从而提高整体的投入产出比
• 错误有限
  • 持续期短的冲刺所犯的错误也有限，一个两周的冲刺，所犯的错误相对小且可控；
  • 由于有快速反馈，错误被及时制止。

• 有助于“满血复活”

  

  • 人类的本性如此， 等待满足的时间太长，兴趣和兴奋度会越来越弱 ；如果做的 项目持续期非常长，不仅失败的可能性增加，还可能最终失去工作热情 ；
  • 没有可见的进度，也看不到结果，人们开始失去兴趣 ，到了最后，他们自己宁愿自己出钱也要做其他产品。
  • 频繁交付可以工作的产品，让参与者保持较高的参与热情 ； 早期频繁交付所带来的满足感，会使我们回复兴趣并渴望继续完成目标。

• 有意义的检查点多

  • 每个冲刺的评审会都是一个有意义的检查点，多个冲刺保证有足够多的检查点做检查和修正，为决策提供支持。

5.3.2.3 冲刺目标锁定（不允许改变冲刺目标或者更换人员）

• 冲刺目标是团队和产品负责人作出共同承诺的基础
  • 团队承诺 在当前冲刺结束之前 完成目标 ；
  • 产品负责人承诺 在冲刺执行过程中 不变更需求 ；
  • 另外， 项目或者职能经理承诺 在冲刺执行过程中 不变更人员
  • 这种共同承诺说明了冲刺的重要性，它 既能做到顺应变化而调整业务需求 ， 又能让团队集中精力在一个短的固定周期内高效发挥其才能以创造价值 。通过定义和遵循目标， Scrum 团队能够一直高度关注一个明确定义的、有价值的目标。
• 不许变更、允许澄清
  • 变更是工作或资源的变动 ，在经济上会造成潜在的严重浪费、中断工作流或在一个冲刺内大量增加工作范围。
    
    • 比如产品负责人：“哦，我所说的是要能够在警察数据库中搜索少年犯，并不只是按姓名搜索，还要能够按照嫌犯的纹身照片来搜索数据库” —— 增加根据照片的搜索很有可能以为着开发量大增，势必会影响团队承诺交付的按照姓名搜索的能力。（这种情况下，创建新的 PBI 放到 Backlog 里）
  • 澄清是在冲刺执行期间提供更多的细节 ，帮助团队实现冲刺目标。
    
    • 开发团队：“你说搜索出来的少年犯应该显示在列表中，你对列表排序有什么偏好吗？” 产品负责人：“有，按姓名字母排序。” 开发团队：“没问题。”
  • 如果在冲刺计划完成之后再变 ，不仅影响投入，还会 付出额外的成本 对冲刺中的变更重新制定计划（耗费时间重新梳理 PBI 优先级，依赖，耗费时间移除已开发的特性等）。
  • 变更还可能损害团队的士气和信任关系 。
    
    • 产品负责人作出承诺，说不改变目标，但最后出尔反尔，这样做自然影响团队士气，进而影响到他们努力做完其他 PBI 的目标。
• 注重实效胜于“锁定目标”
  • 当环境发生变化急需更改目标时，固守原有目标毫无意义，我们需要“锁定目标”，但更应从经济技术等角度考虑，更应注重实效。

5.3.2.4 一致认同的完成定义（产出潜在可发布产品增量）

• 完成的定义至少要产生一个产品功能的完整切片，即 经过设计、构建、集成、测试并编写了文档 ， 能够交付已验证的客户价值 。
  
  • 如果性能测试重要，则要包含性能测试，否则不能算是真正的潜在可发布产品增量。槽糕的是，当冲刺结束很久之后做性能测试，发现不能正常运行，将要花更多的时间和精力去修复，甚至重新设计开发。
• Scrum 团队需要又一个健全的完成的定义，自信构建的产品增量质量高、可交付。 任何妥协都会剥夺组织根据自身情况交付商业价值的机会并欠下技术债 。

5.3.3 冲刺计划会

以下图片是冲刺计划会的参与者、输入和输出。

除了图片所示，我们还应该关注的是：

• 产品负责人、开发团队和 Scrum Master 一起确定下一个冲刺要开发的产品列表条目最高优先级的子集，并且 细分出每个条目的任务 的过程。
• 冲刺计划要注意输入（特别是约束-- 假设，依赖，业务或技术风险 等）
• 过程中， 开发团队给出完成每项任务所需工作量的估算值 。
  
  • 在使用估算扑克时，我们不用平均数，也不使用数值范围之外的数字，在要求人们为任务作出一个估算大小时，实际是在 激发人们思考任务的细节，让所有假设和风险显露出来，让开发团队从团队的角度对任务的工作量达成共识 。

5.3.4 每日例会

• 团队成员轮流回答三个问题：
  
  • 昨天我完成了什么工作？
  • 今天我计划完成什么工作？
  • 有什么障碍让我无法取得进展？
• 通过回答这些问题，每个人都能了解全局，知道发生了什么，实现冲刺目标的进展如何，是否需要修改当天的工作计划，有什么需要处理的问题等。
• 每日例会必不可少，它能帮助团队管理一个冲刺内快速、灵活的工作流。
• 不是用来解决问题的 ，而是检视、同步和适应性制定每日计划的活动；团队可以选择 把问题的讨论放在每日例会之后和相关人讨论 ；
• 不是传统意义上的状态会议 ，尤其不是以前那种由项目经理召集、为了了解项目最新状态而举行的会议。

5.3.5 冲刺执行

以下图片是冲刺执行的参与者、输入和输出。

除了图片所示，我们还应该关注的是：

• 蜂拥式开发
  • 有余力的团队成员聚在一 起合力做完一个已经开始的条目 之后 再继续转做其他的条目 ；
  • 拥有火枪手态度和 T 型技能的团队会采用蜂蛹式开发。
• 任务执行：强调技术实践 —— 极限编程
  • 我们希望开发团队成员在工作中发挥自己的技术特长，在短期，固定市场的冲刺中完成工作并控制技术债。这里的技术实践并不是指深奥难懂的技能，而是已经用了数十年当仍然决定 Scrum 或其他软件开发方法成败的技能。
  • 敏捷社区把这些技术实践成为“极限编程”
    
    • 测试驱动开发
    • 重构
    • 简约设计
    • 结对编程
    • 持续集成
    • 集体代码所有制
    • 编码规范
    • 隐喻
    • 自动化测试
    • ...

5.3.6 冲刺评审会

以下图片是冲刺评审会的参与者、输入和输出。

除了图片所示，我们还应该关注的是：

• 评审会检视与调整“产品” ；
• 所有参与人（包括 Scrum 团队、利益干系人、客户或其他团队感兴趣成员）清楚 了解产品现状提出反馈，并指导下一步开发工作 ，以确保产出最合适的解决方案。

5.3.7 冲刺回顾会

以下图片是冲刺回顾会的参与者、输入和输出。

除了图片所示，我们还应该关注的是：

• 回顾会检视与调整“过程”；
• 回顾会要充分利用主观和客观数据（禅道上 bug 统计，bug 修复时长，燃尽图等）
• 重点关注必要的 持续过程改进 ，讨论 Scrum 流程、开发过程、相关技术实践哪些是可行的，哪些是不可行的，帮助优秀的团队成为卓越的团队；

• 找数量适中的过程改进项并承诺在下一个冲刺采用。

  

到这里，关于 Scrum 框架的角色、工件与活动已经大体讲完，下面讲一个重要的概 念 —— 技术债 作为本文的结束。

六、技术债

本章节主要讲什么是技术债，有哪些类型技术债，技术债有什么影响，以及如何处理技术债。

6.1 什么是技术债

1992年，Ward Cunningham 率先提出技术债的概念，他的定义如下:

代码写好就交，意味着欠债的开始。稍微欠点技术债的确可以加快开发速度，但前提是 事后及时重写代码 ，...... 如果只结不还，后果很危险。在不确定的代码上花的每一分钟，都算是技术债的 应付利息 。不稳定，脆弱的代码所引发的债务负担，会 使整个工程陷入裹足不前的艰难境地 ......

• 技术债具体包括：

  • 不合适（或糟糕）的设计 —— 因为当前所用技术或业务发生重大变化，我们 之前曾经有效的设计变得不再使用 ；
  • 缺陷 —— 我们已知但还没有时间解决的软件的问题；
  • 测试覆盖不充分 —— 有些地方我们明明知道 该做更多测试却没有做 ；
  • 手工测试过多 —— 实际 该做自动化测试 的时候我们还在做手工测试；
  • 集成和版本管理不善 —— 在集成和版本管理的时候，采用的 方式既费事又容易出错 ；
  • 缺乏平台经验 ；
  • ...

• 技术债的分类：

  • 低级技术债
    • 团队成员或业务人员 业务或技术不成熟 或 流程缺陷 而导致 设计粗糙，工程实践糟糕和测试不足 ；
  • 不可避免的技术债
    • 良好的设计要演进而来， 一开始的设计难免因不完善 而带有技术债，表现为随着时间推进而受影响，必须做出改动；
    • 依赖的 第三方接口不断演进 ，我们没有及时跟进。
  • 策略性技术债
    • 组织有意做出策略性决定，让产品开发 抄近道 ，希望实现一个重要的短期目标；
    • 组织为削减成本，把 带有技术宅的产品推到市场 ，等有收益后再有资金做后续开发。

6.2 技术债有什么影响

• 技术债不可预测
  • 技术债的一个重要特质：以不可 预测的非线性方式 增长；
  • 当技术债积累到某个临界点，增加任何一丁点的技术债，都会让产品达到爆发点，变得不可管理或混乱，从而诱发不确定的大灾难；
  • 不偿还的技术债逐步积累，我们不知道 最后一根稻草何时会压死骆驼 ，然而一旦发生，后果不堪设想。
• 交付时间变长
  • 承担技术债意味着现在 向未来申请借用工作时间
  • 今天的债务越多，明天的速率就越慢，速率越慢，交付新特性和产品补丁需要的时间越长 ；
• 缺陷数量过多而无力生产
  • 技术债使的产品变得复杂，不同的缺陷盘根错节，以高的惊人的频率造成重大的产品故障，再有缺陷过多难以管理，从而影响正常的增值开发工作。
• 开发和支持成本上升
• 可预测性降低
  • 如果债台高筑，基本上不太可能进行任何形式的预测
  • 导致的结果是我们 做出承诺并未兑现承诺而建立合理预期的能力被大大削弱
• 挫折感四处弥漫
  • 开发链路中所有人都因此备受挫折，久而久之，开发的乐趣消失殆尽，取而代之的是日复一日、周而复始地与不受人待见却得硬着头皮面对的问题“战斗”。

6.3 如何处理技术债

• 使用良好的实践
  • 停止向产品增加低级债务 —— 再不粗心大意和添乱了
  • 测试驱动开发、持续集成、自动化测试和代码重构等
• 使用强完成定义
  • 完成定义检查表中包含的技术细节越多，积累技术债的可能性就越少
• 让技术债可见
  • 把技术债当做缺陷 录入缺陷跟踪系统 （比如禅道）
  • 为技术债创建 PBI ，使重要的技术债与产品列表的新特性一样醒目
  • 创建一个 特殊的技术债列表 （比如在任务白板旁边安置一个技术债白板，用便利贴来记录具体的各项技术债，让每日例会和冲刺过程中可见）
• 偿还技术债
  • 并非所有技术债都应偿还
    • 行将就木的产品
    • 一次性原型 —— 原型的价值不在于代码，而在于经验认知
    • 短命产品
  • 应用“童子军原则”，有债就还
    • “童子军原则”:"离开营地时，要让它比你进去时更干净"，如果发现营地脏乱，就应该清理，不管罪魁祸首是谁，要有意识地为亦喜下一个露营队改善环境；
    • 同样的，我们在每次改动产品时，都要尝试让产品设计和实现更好，而不是更差；
    • 针对每个 PBI，我们承诺保质保量完成工作，而且在自己所开发特性的相关区域内如果发现技术债，只要力所能及，就要清理干净；
    • 当然，对于某些技术债，偿还到一个合理的阈值就好，因为还有其他更重要的工作要完成。
  • 分期偿还技术债
    • 面对债台高筑的产品，团队往往会选用一次性付清的方式解除技术债；更好的做法是分期、分步骤偿还已知技术债，而不是后期一次性付清；
    • 单独创建“技术债冲刺”或“重构冲刺”，这样的冲刺只有一个目的：“工作核心就是减少技术债”；这样的话，团队选择的不是交付客户价值，而是舍本逐末，专门解决本该在每个冲刺中逐步解决的技术债；后期一次性解除成本高，导致浪费。
  • 先偿还高利息技术债
  • 一边做有客户价值的工作，一边偿还技术债
    • 在做 PBI 的同时，维护已知技术债；既能够专注于高息技术债，又能够把维护技术债与以价值为中心的方式结合。

参考书籍： 1.《Scrum 精髓 - 敏捷转型指南》 2.《Scrum敏捷软件开发》 3.《架构即未来》 —— 好书，推荐！

其他参考资料： 1. wiki 敏捷软件开发 2. wiki Scrum 3. Scrum 指南 4.【第一领导力专栏】从美式橄榄球的Scrum 看敏捷组织的“形”“意”“神” 5. Scrum這個字是什麼意思 6. Scrum懶人包 – 10分鐘讀懂Scrum與敏捷軟體開發入門 7. 历史：敏捷宣言诞生记 8. 敏捷进化趣 9. 敏捷拥护者眼中敏捷开发的常见问题

与其临渊羡鱼 不如退而结网 | 与其诅咒黑暗 不如燃亮灯火 | 与其哀叹路遥 不如上下求索

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• ????谈谈单元测试
• 谈谈日志的最佳实践
• 谈谈 Redux
• 谈谈线程池
• 谈谈看板上列的设置
• 谈谈动态规划的本质

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。