敏捷发展——20年后

通过艾萨克LaBauve 2021年3月|白皮书| 19分钟阅读|本文的电子邮件|下载

从卑微的起步，敏捷方法论已经成为21世纪所有数字化、创新和快速发展事物的灵丹妙药。但有人担心，随着其使用范围的扩大，其效力正在逐渐丧失。二十年后，是时候重新评估当今世界的敏捷原则和实践了。

敏捷最初是一种精益软件开发方法，它可以在更短的时间内交付更高质量的代码。然而，在过去十年中，它的概念越来越多地被非技术业务团队所采用，从创意机构到创新实验室，从营销团队到人力资源部门。

敏捷的简单性和灵活性使它如此引人注目。然而，这也是一个潜在的弱点。在今天使用敏捷的人当中，对于敏捷是什么以及应该是什么还不清楚。虽然许多人现在把这个词用在自己的工作中，但很少有人能熟练掌握基本原理。

这导致了一个普遍的抱怨，许多项目只是名义上的敏捷——要么以瀑布方法运行这些实践，要么关注仪式而不是实际结果。

与此同时，Covid-19带领组织完全拥抱云架构和遥控工作。这种现象同时增加了对灵活性和快速发展的需求，同时挑战敏捷宣言的一些核心常见问题，了解团队如何合作。

因此，本文既是对那些不熟悉敏捷的人的入门读物，也是对敏捷的历史和发展的回顾和重新评估。

实践和原则

敏捷是建立在一套简单而直接的价值观和原则之上的，这些价值观和原则使敏捷既引人注目、范围广泛，又模棱两可。为了将这一理念变为现实，多年来涌现了许多敏捷实践和工具包。

然而，随着时间的推移，这些实践的使用和仪式化已经导致一些敏捷项目过度依赖方法而非目的——这是敏捷应该解决的关键问题之一。

今天，业务领导经常抱怨敏捷实践者对这些方法的应用过于热心。这往往疏远了大型企业中的其他团队，而不是作为一股变革的力量。

另一方面，采用敏捷思想精神的项目和团队——关注敏捷性、响应性和灵活性——往往难以跨组织扩展。这些类型的团队往往依赖于特定的成员或领导者，他们灌输了正确的文化，但往往没有采用足够的文档化的方法来实现敏捷的可复制性。

为了在整个企业中交付真正具有变革性的成果，将这两个挑战看作是相互独立但又相互关联的能力是很有帮助的。

我们的敏捷框架坑“遵守工具集”反对“坚持思想”（图1）。那些对支持敏捷项目的方法和实践的人正在做敏捷，而那些在心态和文化元素上强大的人就是敏捷。那些能够平衡的人通过缩放敏捷实践真正改变他们的企业。

图1所示。一个理解工具集和敏捷思维之间平衡的框架

来源:印孚瑟斯

我们使用“心态”来描述与敏捷宣言的原则和价值观最为一致的文化和组织特征和价值观。我们使用术语“工具集”来描述那些紧密遵循公认的与敏捷相关的工具和实践的团队——本文后面将列出其中最突出的工具和实践。

敏捷的根源

敏捷实践和原则来自三个不同的根源:制造、软件开发和项目团队管理。

制造业

大多数人将敏捷视为瀑布式软件开发模型的替代方案。然而，它的许多想法源于制造原理。第二次世界大战后，W. Edwards Denning利用贝尔实验室的研究原理，由他的导师指导改进了日本制造业的产品和工艺。丰田聘请Denning培训他们的经理在这些技术，这导致了丰田生产系统的发展。这是当今精益方法论的主要来源。

软件开发

Kent Beck在1996年开发了Extreme Programming，当时领导重写了克莱斯勒的工资应用程序。极限编程负责引入早期小型代码发布、自动化测试、结对编程、重构以及团队对代码的所有权等理念，将其作为所有项目的标准。尽管它早于敏捷，但它已经融入了敏捷的价值观和原则。

团队管理

Scrum是最流行的敏捷变体。它起源于1986年《哈佛商业评论》的一篇题为《The New New Product Development Game》的文章。作者Hirotaka Takeuchi和Ikujiro Nonaka描述了一种新的产品开发方法，它避免了完成项目阶段的标准概念，然后将其传递给新的团队(接力赛)。相反，它倾向于一个团队从头到尾生产产品的方法(橄榄球方法)。通过为整个产品生命周期而不是特定阶段组织团队，技术专长不会丢失。此外，产品团队做出的早期选择必须由同一个团队管理，而不是成为其他人的问题。

思维模式——敏捷的基础

2001年，17个程序员在犹他州狼群山的滑雪胜地见面，以分享软件开发的最佳实践。每个都来自一个不同的编程背景，但所有人都热衷于开发新的轻质方法。会议导致敏捷宣言，由12个原则支持的四个值（图2）的陈述。

对于软件开发社区来说，这是一个开创性的时刻。该宣言具有革命性，其隐含的信息标志着与20世纪公认的商业智慧的深刻转变。敏捷并不是在流水线上生产出一刀切、批量生产的产品。它解放了工程师，让他们成为创造者，可以探索自己的工艺，灵活而迅速地响应终端用户和客户的需求。

图2.敏捷宣言中的价值观

来源:敏捷宣言

敏捷的12条原则

虽然这是一个鼓舞人心的起点，但是敏捷的价值仍然是模糊的，并且没有规定任何特定的实践或方法。敏捷的12条原则有助于使敏捷获得成功所需的组织文化类型变得清晰和集中。

我们发现将它们分成四类是很有用的:优先级、文化、团队组织和工作过程。优先级原则关注于交付高质量和有价值的软件。文化原则确保了业务的一致性，对持续改进的关注，以及团队成员面对面会面的需求。团队组织原则和工作过程原则侧重于有效性、透明度和责任性。

优先级

• 我们的最高优先级是通过早期和持续交付有价值的软件来满足客户。
• 我们经常提供工作软件，每隔几周到几个月，偏好较短的时间尺寸。
• 可工作的软件是进度的主要度量标准。

文化

• 我们欢迎新的需求，即使是在开发的后期。敏捷过程利用变化来获得竞争优势。
• 业务人员和开发人员必须在整个项目中每天一起工作。
• 向开发团队传递信息以及在开发团队内部传递信息的最有效方法是面对面的交谈。

团队组织

• 项目是围绕有动力的个人建立的。组织应该给予他们所需的环境和支持，并相信他们能完成工作。
• 最好的架构、需求和设计来自自组织的团队。

工作流程

• 敏捷过程促进可持续开发。发起人、开发人员和用户应该能够无限期地保持一致的步调。
• 对技术卓越和良好设计的持续关注可以增强敏捷性。
• 简单——最大限度地减少不必要工作的艺术——是必不可少的。
• 团队定期反思如何变得更有效，然后相应地调整和调整其行为。

工具集-敏捷的实践和技术

随着团队已应用敏捷原则，具体实践已成为这种方法的同义词。最占主导地位的是Scrum和Kanban，可以应用于各种技术和非技术项目。但随着业务需求发生变化和对敏捷的理解深化，其他做法已经占据了中心阶段。值得注意的是，缩放的敏捷框架（安全）旨在使大型软件项目成为敏捷，并且Devops，这越来越受到自动化的一种方式。

然而，即使这些工具最初没有捕捉公众的想象，这些工具的普及也可以过性，这些工具可能会更适合今天的企业。以下清单简要介绍了许多这些实践，有关使用来自25名高级敏捷从业者的内部调查及其超过90名客户的经验的使用说明。

我们将这些分为三个主要的项目组:计划、执行和跟踪。

项目规划

项目规划是所有软件开发的主要特征。然而，敏捷试图以重要的方式重新设计这个过程。使用这种方法，需求不必在最早的阶段被详尽地定义。这一重要的好处降低了交付时间，实现了快速的发布周期。

CRC卡

类责任协作者(CRC)卡是软件开发计划的最早形式之一。1988年引入的CRC卡物理地显示了面向对象编程中使用的不同类之间的关系。一个团队通常以小组练习的形式创建这些卡片，以设计软件如何相互作用和组合在一起。

规划扑克

规划扑克是项目规划中最早的元素之一。它在2002年首次被描述为一种评估任务长度和难度的方法，而不需要成员相互影响。在规划扑克时，团队成员会收到不同点数的卡片(通常是斐波那契数列)。在产品所有者描述用户故事之后，每个团队成员默默地选择一张卡片，卡片上有他或她认为应该分配用户故事的点数，并将卡片正面朝下放置。一旦所有的团队成员都投票了，卡片就会被揭示出来，团队成员给出最高和最低的估计来解释他们的理由。然后，团队尝试通过玩额外的回合来达成共识。

神奇的估计

因为有些计划扑克会话会占用一整天的时间，所以在2010年开发了魔术估计，作为一种缩短为用户故事分配点数的时间的方法。这种方法对于估计整个待办事项和大致了解项目的规模和复杂性是最有用的。

使用魔法估计，点数值被放置在地板或墙上，每个用户故事或待定项都写在一张卡片上。然后，产品所有者简要地描述待定项，团队确定一个用户描述或待定项，作为基线任务。这个任务分配的总数接近墙上点范围的中间。

然后，每个团队成员都会收到一组独特的待定项卡片。团队将这些卡片放在与基线任务的相对复杂性相比较的点值下。如果团队成员不确定，则将卡片放在一边，以便产品负责人进一步解释。在接下来的回合中，团队成员可以将卡片从一个积分值移到另一个积分值。但是没有移动或移动得不太远的卡片会在卡片上写下它们的积分值，并交给产品负责人。整个待办事项列表可以在一个小时或更少的时间内估计出来。

用户故事

用户描述将软件项目中的特性划分为功能增量。它们的使用起源于1998年的极限编程实践，但在几年后得到了更正式的描述。用户故事已经成为敏捷团队中创建可行工作单元的标准，我们的调查受访者表示，它们的使用在今天几乎是普遍的。

投资清单

INVEST清单在2003年被提升为一种编码有用用户故事的方法。根据该文档，一个好的用户故事应该是可协商的、有价值的、可评估的、小的、可测试的，并且独立于所有其他故事。如果它不能满足这些标准，团队应该考虑重新措辞或重写故事。

故事映射

2008年，引入了故事映射的概念来帮助团队考虑一组功能对每种类型的用户都有用。这通常采用绘制用户故事的形式，该模板抵抗复杂性和优先级的独立维度。目的是避免延迟有价值的商业功能的情况，因为它们依赖于其他，优先级功能。

领域驱动设计

创建于2003年的领域驱动设计的核心是通过使用特定业务的命名法来命名代码中的函数和类，从而使代码更加“易于阅读”。

“完成”的定义

Scrum中使用的术语“完成的定义”是在2005年提出的。这个想法帮助团队创建一致且易于理解的接受标准。一旦特性被接受，它有助于限制返工的成本，并限制开发团队和产品所有者之间产生误解的风险。“完成”的定义是一种共同的理解;纠结于一系列的标准可能会适得其反。

准备好了的定义

在2008年，“完成”的定义扩展为“准备好”的定义，它包含了用户故事的开始。这有助于确定某个特性是否已准备好开发。这样做的目的是避免在没有良好定义的完成标准的特性上开始工作。这有助于避免返工。

租船项目

2006年制定了项目章程，以确定项目的范围和目标。这样做是为了使项目不会陷入无限的发布周期。随着软件开发人员开始选择更多基于产品的方法，而不是基于项目的方法，这种特许方法不再受欢迎。

项目执行

虽然涉及项目规划和跟踪的敏捷元素有用，但主要目标是改变项目执行的态度。在写入第一行代码之前，敏捷可以选择改变是不可避免的，应该受到欢迎的，而不是坚持确定所有功能。代替将客户视为被殴打的敌人，团队应每天使用业务，以确保计划功能携带价值。要执行这些想法，团队需要更好地定义了这看起来的样子的例子。

精益、Scrum和极限编程都早于敏捷，但它们的一些元素现在被认为是敏捷的组成部分。

持续集成

敏捷软件开发最著名的特性之一是持续集成。在美国软件开发人员和公共演说家马丁·福勒(Martin Fowler)给出更完整的描述之前，这个词已经使用了很多年¹在2000年。早些时候，最佳实践是“预定的”集成，因为在持续集成中缺乏彻底的测试。当为自动测试开发工具时，持续集成变得更加流行。自动集成代码是敏捷在短时间内生成工作代码的关键驱动因素之一。

持续交付

代码集成的自动化促进了软件自动化的进一步发展，导致了持续交付的创新². 这种方法通过自动将代码推送到质量保证或登台环境来自动化软件开发的下一步。连续交付需要在回归测试完成后手动批准。这些测试确认新功能不会破坏现有系统，并已准备好投入生产。

持续部署

2006年，软件作者Jez Humble、Chris Read和Dan North发表了第一篇描述持续部署的文章^3.．通过自动化(无需人工干预)将代码部署到生产环境，这进一步实现了软件开发的自动化。作者指出，这只有在完全自动化的单元、集成和回归测试中才能实现，以最大限度地减少在生产环境中引入错误的机会。

DevOps

DevOps⁴是微服务、持续集成和交付、监视和日志记录以及作为代码的基础设施的组合。这是2009年开发的⁵以解决开发团队和运营团队试图实现敏捷实践之间的摩擦。从那时起，DevOps就成为了敏捷最流行的风格之一。

结对编程

结对编程始于1996年，是极限编程的一个元素。编码是成对完成的，一个开发人员输入代码，另一个帮助指导如何编写代码。这种做法一直受到褒贬不一的评价。有些开发者喜欢反复的头脑风暴。然而，与人一起工作与许多程序员的人格是对立的，经常被拒绝作为一种实践。

乒乓球的编程

第一次出现是在2003年，乒乓编程⁶是结对编程的进化。它结合了结对编程和测试驱动开发。使用这种方法，开发人员A编写一个失败的测试，而开发人员B编写代码使测试通过。然后开发人员B编写一个失败的测试，开发人员a编写代码使测试通过。这种方法是用来让两个程序员都参与到这个问题中来的，这样一个开发人员分区的风险就会降到最低。

验收测试

验收测试⁷于2002年开发，并使用自动化测试来确定某个特性是否已准备好发布。这些测试是与客户一起创建的，并显示由用户描述生成的代码是否产生正确的输出。

反映车间

反映车间⁸是在2001年开发的，很快就流行起来了⁹．这些设计是为了帮助团队确定何时结束当前的版本迭代或开始新的版本迭代。目的是作为一个团队来反映迭代或sprint的哪些部分进行得很好，哪些部分没有成功。利用来自研讨会或回顾的信息，团队可以对他们的过程进行调整。

精益软件开发

精益首先在《精益软件开发：敏捷工具包》一书中被描述¹⁰在2002年。原则是消除浪费、扩大学习、尽可能晚地决定构建什么代码、尽可能早地交付、授权团队、将完整性构建到产品中，并优化整体。

FitNesse

FitNesse¹¹是一个在2003年开发的工具，用于促进自动化集成测试和支持验收测试，而不仅仅是单元测试。FitNesse允许软件最终用户创建测试，然后将其转换为代码，并可以自动运行以测试新功能。

验收测试驱动开发

验收测试驱动开发¹²(ATDD)是让所有团队成员，包括客户和测试人员，在任何代码创建之前协作地编写测试的实践。最初，Extreme Programming的创始人Kent Beck认为这种方法不切实际。然而，它作为一种允许非技术人员参与测试设计的方法而变得流行起来。

积压整理

待定事项梳理，也被称为待定事项细化，在2005年首次被提到，但直到2008年才被正式描述。这涉及到产品所有者和团队的其他成员审查待办事项列表中的项目的重要性和优先级。目标是删除不相关的用户描述，根据网络信息添加新的用户描述，评估或重新评估用户描述，并细化任何太大而不能适应迭代的当前用户描述。

行为驱动开发

行为驱动开发¹³(BDD)，也称为示例规范，由Dan North在2006年首次描述，是测试驱动开发(TDD)的一种改编。North最初的见解是，把编写测试功能看作是用一句话来测试一个行为。这限制了测试的范围，因为只能描述这么多。该方法还通过问“系统当前不做的下一个最重要的行为是什么?”来编码流程从哪里开始?尽管在他最初的文章中没有提到敏捷联盟¹⁴解释说BDD要求团队成员应用“五个为什么”¹⁵每个用户故事，并确保它与业务结果相关。

安全

安全¹⁶起源于2007年，当时是为了解决大型软件项目的问题。它是一套指导企业扩大精益规模的实践和组织结构¹⁷和敏捷¹⁸. SAFe是一个规范性的框架，用于创建敏捷团队中的敏捷团队。SAFe通常非常适合已建立的层次结构。从业者有时会批评¹⁹由于框架的说明性，它被认为“不是敏捷的”。但它越来越受欢迎，或许正是因为这些原因，而不是因为这些原因。根据敏捷状态报告^20.SAFe于2020年发布，它的受欢迎程度大约是第二流行的伸缩框架Scrum的两倍。

敏捷测试

创建于2017年，敏捷测试²¹采用从开始到交付的协作实践，支持质量的频繁交付。敏捷测试侧重于缺陷预防，而不是缺陷检测。它还包括提问以测试想法；自动化测试；探索性测试；以及可靠性、安全性和性能测试。

项目跟踪

跟踪Sprint或项目的进度至关重要，以确保按时交付工作软件。这与敏捷的第一个原则 - 最高优先级是以早期和连续交付有价值的软件来满足客户。

速度

第一个定义的敏捷项目跟踪方法是速度、燃尽和燃尽率。所有这些方法在2002年开始流行。速度是Scrum中使用的一种度量方法，它显示了一个团队在给定的sprint中完成的故事点的数量。在sprint中，速度是对同一团队的有用度量。但是它不能用于比较团队，因为分配给给定任务的描述点的数量可能有很大的不同。此外，即使在同一个团队中，也可以通过允许团队在未来的sprint中夸大任务所需的故事点来操纵速度度量。

烧毁

燃尽的²²速率，在2000年首次描述，是一种查看团队是否达到当前sprint或项目目标的方法。它显示了剩余的工作量与剩余的时间，以及任何未来点的预期位置。燃尽图的缺点是sprint或项目范围的变化没有被捕获，并且按照预期工作的团队看起来可能会落后。

燃耗

Boodup Charts通过显示相对于团队性能以及总范围的理想燃尽率以及总范围来解决未经突出的范围变更问题。

五列任务委员会

2003年，五列²³Scrum联盟的创始人之一，程序员Mike Cohn正式描述了任务板。这些列包括story、to do、in process、to verify和done。

跟踪进度可以确保软件准时、高质量地交付，这与敏捷的第一条原则是一致的

三列工作委员会

以前的任务板由三列任务板在2007年被占用，其中删除了“故事”和“验证”列。任务板在大多数敏捷的实施中具有非常严重的功能，因为他们将团队重点放在每日会议期间的进展和障碍。重要的是在物理空间中拥有一个身体工作委员会作为团队进度的不断提醒。虚拟板可以太容易被遗忘。Kanban董事会于2007年介绍，并与三柱板相似。Kanban董事会的关键差异是，该团队限制了所允许正在进行的项目数量。这使Teachs在轨道上持续到释放Sprint末尾的工作代码，通过强迫他们在开始一个新的之前完成用户故事。我们调查的受访者表示他们普遍使用Kanban董事会。

日常会议

1994年，计算机科学研究员James“Cope”Coplien在他对Borland Quattro Pro团队的观察中描述了每天开会的想法，他在其中描述了频繁开会对团队过程、质量和生产力的影响。1997年，软件开发人员和行业顾问Ken Schwaber描述了“每日scrum”²⁴到1998年，每天的“站立”会议成为极限编程的核心实践。在2004年，日常会议被推广为敏捷的核心实践。这种做法没有改变，因为每天的会议是敏捷团队的很大一部分。有时候，执行敏捷缺乏有效性的原因在于每天开会的人是谁。不到一半的受访者表示，他们每天都与相关商业人士合作。

看板

看板²⁵作为一种通过平衡容量和消除工作流瓶颈来管理项目的方法，2007年出现。看板的四个原则——工作流可视化、限制正在进行的工作、改进工作流以及通过减少摩擦来持续改进——表明看板的实践是一个迭代的变更过程，不仅在生产中，而且在文化中。这一点很重要，因为文化变化往往是敏捷采用的最大挑战之一。

敏捷提供了大量的工具和实践。然而，要想取得成功，就不能把它们硬塞进现有的过程中。相反，敏捷必须在整个组织范围内大规模工作，员工可以自由使用适合特定环境的技术和技巧。为了整体地工作，所有人、流程和技术都必须遵循敏捷宣言，这需要重大的文化变革。事实上，做好敏捷与其说是对其技术的严格调整，不如说是思维方式。持续发展和学习文化的需要至关重要。

敏捷不仅仅是关于软件。在后2019冠状病毒病(covid -19)时代，各种动荡冲击着业务和运营模式，敏捷必须超越技术，让所有业务功能和所有行业部门都能感受到它的存在。正如我们在本作品集的其他敏捷论文中所强调的那样，任何敏捷组织的顶峰都是业务和操作模型在名称和实质上都是敏捷的。这样的组织能够迅速对环境冲击做出反应，其领导层能够团结整个团队，以新的方式大规模地交付底线。

参考文献

1. 持续集成，马丁·福勒，2000年9月10日，martinFowler.com
2. 持续集成、持续部署和持续交付之间的区别是什么?， Marko Anastasov, 2017年7月27日，Semaphore
3. 部署生产线，杰斯·汉博、克里斯·里德和丹·诺斯，2006年7月，ACM数字图书馆
4. DevOps是什么，AWS.
5. DevOps的起源:名字里有什么?Steve Mezak, 2018年1月25日，DevOps.com
6. 成对编程乒乓模式，WikiC2.com
7. 验收测试，敏捷联盟
8. 敏捷软件开发亚马逊(Amazon)的阿利斯泰尔·考克伯恩(Alistair Cockburn)
9. 极限编程与敏捷软件开发， Mary Poppendieck, Wayback Machine
10. 精益软件开发：敏捷工具包，亚马逊(Amazon)的Mary Poppendieck
11. FitNesse用户指南，罗伯特C。马丁和迈卡D。马丁和帕特里克·威尔逊·韦尔什，菲特内斯
12. 验收测试驱动开发，敏捷联盟
13. 引入BDD， 2006年3月，Dan North & Associates
14. 行为驱动开发(BDD)，敏捷联盟
15. 5个为什么，维基百科
16. 规模化敏捷框架，维基百科
17. 扩展的创新，维基百科
18. 敏捷软件开发，维基百科
19. 当心安全(企业伸缩敏捷框架)，黑暗的邪恶化身肖恩·德克斯特，2020年1月1日，中
20. 第14届敏捷年度状态报告, stateofagile.com
21. 我们对“敏捷测试”的定义， Janet Gregory和Lisa Crispin, 2017年6月30日，敏捷测试员
22. 燃尽图，敏捷联盟
23. Scrum任务板，山羊软件
24. 每日例会，Wayback机器
25. 看板为初学者解释，完整的指南, Kanbanize