敏捷发展——20年后

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

从一开始，敏捷方法已经成为21世纪所有数字化、创新和快速发展的事物的灵丹妙药。但也有人担心，随着它的普及，它的效力正在逐渐丧失。20年后，是时候重新评估当今世界的敏捷原则和实践了。

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

敏捷的简单性和灵活性是使其如此引人注目的原因。然而，这也是一个潜在的弱点。在那些今天使用它的人中，有些敏捷是难以的痛苦和应该是卑鄙的。虽然许多人现在将术语应用于自己的工作，但很少有人在基础上流利。

这导致了许多项目的共同投诉仅在名称中敏捷 - 以瀑布法运行这些实践或专注于仪式而不是实际结果。

与此同时，COVID-19促使各组织全面接受云架构和远程工作。这种现象同时增加了对灵活和快速开发的需求，同时挑战了敏捷宣言中关于团队如何协作的一些核心原则。

因此，这篇论文充当了敏捷的人的底漆以及对那些觉得它失去途径的人的历史和进化的进修和进化。

实践与原则

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

然而，随着时间的推移，这些做法的使用和仪式化导致一些敏捷的项目过度依赖于目的方法 - 这是敏捷应该修复的关键问题之一。

今天，商业领袖经常抱怨认为，敏捷从业者在应用这些方法时是过度的。这常常疏远大型企业内的其他团队，而不是作为改变的力量。

另一方面，采用敏捷思维精神的项目和团队 - 专注于敏捷性，响应能力和灵活性 - 通常会在组织上挣扎。这些类型的团队倾向于依赖于拟订合适的文化的特定成员或领导者，但往往不再拥抱足够的文档方法来复制。

将这两个挑战视为单独但相互关联的能力，这些挑战是有助于磨练的 - 而且平衡 - 以便在整个企业中提供真正的变革结果。

我们的敏捷框架将“坚持工具集”与“坚持思维模式”置于对立面(图1)。那些擅长支持敏捷项目的方法和实践的人就是在做敏捷，而那些擅长思维模式和文化元素的人就是在做敏捷。那些能够平衡两者的人正在通过扩展敏捷实践真正地改变他们的企业。

图1.要了解敏捷中的工具集和心态之间平衡的框架

来源：Infosys.

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

敏捷的根源

从三种不同的根源开发的敏捷实践和原则：制造，软件开发和项目团队管理。

制造业

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

软件开发

肯特贝克于1996年开发了极端的编程，同时领导了克莱斯勒的工资单申请。极限编程负责引入小型早期代码发布，自动化测试，对编程，重构和代码的团队所有权的思想作为所有项目的标准。虽然它达到敏捷，但它已经纳入了灵活的值和原则。

团队管理

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

心态 - 敏捷的基础

2001年，17名程序员在犹他州瓦萨奇山脉的一个滑雪胜地会面，分享软件开发的最佳实践。每个人都有不同的编程背景，但都热衷于为自己的手艺开发一种新的轻量级方法。会议产生了敏捷宣言，它包含了四个价值(图2)，并由12条原则支持。

这是软件开发社区的一个精彩时刻。宣言是革命性的，其隐藏的信息标志着20世纪受到的商业智慧的深刻转变。敏捷不是关于装配线上的一尺寸适合的批量生产的产品。它是关于释放工程师，成为可以探索其工艺的创造者，并灵活且快速地应对最终用户和客户的需求。

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

来源：敏捷宣言

敏捷的12条原则

虽然激励的起点，但敏捷价值仍然模糊不清，而不是任何特定实践或方法的规范。12次敏捷原则有助于提高清晰度，并专注于使敏捷成功所需的组织文化类型。

我们发现将它们组织成四类：优先事项，文化，团队组织和工作流程有用。优先原则专注于提供质量和有价值的软件。文化原则确保业务对齐，重点是持续改进，以及团队成员亲自见面的必要性。团队组织原则和工作流程原则侧重于有效性，透明度和问责制。

优先级

• 我们的最优先级是通过早期和连续交付有价值的软件来满足客户。
• 我们频繁地交付工作软件，从每两周到几个月，优先选择较短的时间尺度。
• 可工作的软件是进度的主要度量标准。

文化

• 我们欢迎新的需求，即使是在开发的后期。敏捷过程利用变化来获得竞争优势。
• 商务人员和开发人员必须在整个项目中共同努力。
• 在开发团队中传达信息的最有效和有效的方法是面对面的对话。

团队组织

• 项目围绕有动机的个人建造。组织应该为他们提供他们需要的环境和支持，并相信他们完成的工作。
• 来自自组织团队的最佳架构，要求和设计。

工作流程

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

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

当团队应用敏捷原则时，特定的实践就会成为这种方法的同义词。最主要的是Scrum和看板，它们可以应用于广泛的技术和非技术项目。但是随着业务需求的改变和对敏捷的理解的加深，其他的实践开始占据中心地位。值得注意的是，伸缩敏捷框架(SAFe)的设计目的是使大型软件项目变得敏捷，而DevOps作为一种增加自动化的方法已经变得越来越流行。

然而，这些工具的流行可能会超过其他可能更适合今天的企业的工具，即使这些工具最初没有抓住公众的想象力。下面的列表提供了对这些实践的简要介绍，以及来自25名资深敏捷实践者的内部调查和他们在90多个客户中的经验的使用说明。

我们将这些分为三个主要项目组：规划，执行和跟踪。

项目计划

项目规划是所有软件开发的主要特点。然而，敏捷旨在以重大方式重新设计该过程。利用这种方法，要求不必在最早的阶段彻底定义。这一重要的好处降低了交货时间，并启用快速释放循环。

CRC卡

班级责任合作者（CRC）卡是最早形式的软件开发规划之一。1988年推出，CRC卡在物理上显示了面向对象编程的不同类别之间的关系。一支团队通常会将这些卡片创建为群体练习，以设计软件曲线如何交互并配合在一起。

规划扑克

规划扑克是项目规划的最早元素之一。它是2002年首次描述的一种方法，以估计任务的长度和难度，没有成员互相影响。在规划扑克中，团队成员收到具有不同点值的卡（通常在Fibonacci序列中）。产品所有者描述了用户故事后，每个团队成员默默地选择一个卡，其中应该思考用户故事，并将卡面向下。一旦所有团队成员投票，透露了卡片，并且具有最高和最低估计的团队成员解释了他们的推理。然后，该团队通过汇集额外的回合来试图通过共识的点价值。

魔法估计

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

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

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

用户故事

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

投资清单

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

故事映射

在2008年，故事映射的概念被引入，以帮助团队考虑一组特性是否对每种类型的用户都有用。这通常采取的形式是根据复杂性和优先级的独立维度绘制用户场景。这样做的目的是避免有价值的业务特性因为依赖于其他优先级较低的特性而被延迟的情况。

域驱动设计

在2003年创建的域驱动设计的核心是通过使用所讨论的特定业务的命名法命名函数和类别来拥有代码更“人类可读”。

完成的定义

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

准备的定义

2008年，完成的定义扩展到“准备好的定义”，它包含了用户故事的开头。这有助于确定是否已准备好开发功能。目的是避免开始工作没有明确定义的完成标准的功能。这有助于避免返工。

项目包机

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

项目执行

虽然敏捷中有关项目计划和跟踪的元素是有用的，但主要目标是改变关于项目执行的态度。敏捷并没有坚持在编写第一行代码之前就定义所有的特性，而是采用了一种心态，即变化是不可避免的，应该受到欢迎。团队应该每天与业务部门一起工作，以确保程序特性具有价值，而不是将客户视为要争吵的对手。为了执行这些想法，团队需要更好地定义这是什么样子的例子。

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

持续集成

敏捷软件开发的最着名的特征之一是持续集成。该术语在美国软件开发商和公共演讲者中，Martin Fowler前多年来一直在使用，给出了更完整的描述¹2000年。早些时候，由于在持续整合中缺乏彻底的测试，最佳实践是“计划”的集成。当为自动测试开发工具时，持续集成变得更加流行。自动集成代码是一个密钥驱动程序敏捷中的一个用于在短时间内生成工作代码之一。

持续交付

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

连续部署

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

德沃斯

德沃斯⁴是微服务，连续集成和交付，监控和记录以及代码的基础架构的组合。这是在2009年开发的⁵以解决开发团队和运营团队试图实现敏捷实践之间的摩擦。从那时起，DevOps就成为了敏捷最流行的风格之一。

对编程

成对编程于1996年开始作为极端编程的元素。编码成对完成，其中一个开发人员键入代码，而另一个有助于直接写它。这种做法始终有一个混合的接待。一些开发人员喜欢前后头脑风暴。然而，与人们合作一直在对许多程序员的角色来说，并且通常被拒绝作为一种惯例。

平乒乓

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

验收测试

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

反映车间

反映车间⁸在2001年开发，很快就会流行⁹．这些旨在帮助团队确定何时结束当前的发布迭代或开始新的次数。目的是作为一个团体反映出来的迭代或冲刺的部分顺利，哪个部分没有成功。使用来自研讨会或回顾的信息，团队可以对其进程进行调整。

精益软件开发

精益在《精益软件开发:敏捷工具包》一书中首次被描述^10.2002年。原则是消除浪费，放大学习，决定尽可能迟到的代码，尽早交付，授权团队，建立诚信进入产品，并优化整体。

Fitness.

Fitness.^11.是2003年开发的工具，以促进自动集成测试并支持验收测试，而不是仅限于单元测试。Fitnesse允许软件最终用户创建测试，然后将其变为代码，可以自动运行以测试新功能。

验收测试驱动开发

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

待办事项列表

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

行为驱动开发

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

安全的

安全的^16.起源于2007年作为大型软件项目问题的解决方案。它是一套实践和组织结构，指导企业在缩放倾斜中^17.和敏捷^18.．SAFe是一个说明性框架，它创建了敏捷团队中的敏捷团队。SAFe通常很适合已建立的层次结构。医生有时批评^19.由于其规范性，框架是“不敏捷”。但它的流行度已经受到普及，也许是因为这些原因而不是尽管他们。根据敏捷报告的状态^20.SAFe于2020年发布，它的受欢迎程度大约是第二流行的伸缩框架Scrum的两倍。

敏捷测试

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

项目跟踪

为了确保软件能够按时交付，跟踪sprint或项目的进展是必要的。这与敏捷的第一条原则紧密相连——最高的优先级是通过早期和持续交付有价值的软件来满足客户。

速度

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

燃尽

烧毁^22.速率是2000年首次描述的，是一种看一支团队是目前Sprint或项目的目标。它显示了剩余的工作量与剩余时间的时间，以及任何未来点的预期位置。Burndown图表的缺点是Sprint或项目范围的变化不是捕获的，并且按预期工作的团队可能看起来像他们落后。

烧掉

燃耗图通过显示相对于团队表现的理想燃耗率以及整个范围，解决了未捕获范围变化的问题。

Five-column任务板

2003年，五栏^23.任务委员会由Mike Cohn，程序员和Scrum Anliance的创始人之一正式描述。列包括故事，在流程中进行验证和完成。

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

三列任务板

之前的任务板在2007年被三栏任务板取代，删除了“故事”和“验证”两栏。任务板在大多数敏捷实现中占有重要地位，因为它们让团队在日常会议中关注进展和障碍。重要的是在物理空间中有一个物理任务板，以不断提醒团队的进展。虚拟电路板很容易被遗忘。看板也是在2007年引入的，它与三栏板非常相似。看板的关键区别在于，团队限制了允许进行中的项目的数量。这迫使团队在开始一个新的用户故事之前完成一个用户故事，从而使他们能够在sprint的末尾发布工作代码。我们调查的受访者表示，他们普遍使用看板。

日常会议

每日一次会议的想法是在1994年通过计算机科学研究员詹姆斯“COPE”普洛恩在Borland Quattro Pro团队的观察中描述，其中他描述了频繁会议对团队过程，质量和生产力的影响。1997年，Ken Schwaber，一个软件开发商和行业顾问，描述了“每日Scrum^24.．” And by 1998, the daily “standup” meeting was a core practice of Extreme Programming. In 2004, daily meetings were generalized as a core Agile practice. This practice has not changed, as daily meetings are a large part of Agile teams. Sometimes a lack of effectiveness in carrying out Agile lies with who is in the daily meetings. Less than half of our respondents indicated they work with the relevant businesspeople on a daily basis.

卡班

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

敏捷提供了大量的工具和实践。然而，要想成功，就不能把它们硬塞进现有的流程中。相反，敏捷必须在整个组织中大规模运作，员工可以自由地使用适合特定环境的技术和技术。为了整体地工作，所有的人、过程和技术都必须与敏捷宣言一起工作，这需要重大的文化变革。事实上，做好敏捷更多的是关于心态，而不是对其技术的严格调整。对不断发展和学习的文化的需求是至关重要的。

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

参考

1. 持续集成，马丁福勒，2000年9月10日，Martinfowler.com
2. 持续集成、持续部署和持续交付之间的区别是什么?， Marko Anastasov, 2017年7月27日，Semaphore
3. 部署生产线，JEZ Humble＆Chris Read＆Dan North，2006年7月，ACM数字图书馆
4. DevOps是什么, AWS
5. Devops的起源：什么是名字？，史蒂夫Mezak，2018年1月25日，Devops.com
6. 乒乓模式配对编程, WikiC2.com
7. 验收测试敏捷联盟,
8. 敏捷软件开发亚马逊(Amazon)的阿利斯泰尔·考克伯恩(Alistair Cockburn)
9. 极限编程和敏捷软件开发，Mary Poppendieck，Wayback机器
10. 精益软件开发:一个敏捷的工具包，亚马逊(Amazon)的Mary Poppendieck
11. Fitnesse用户指南， Robert C. Martin & Micah D. Martin & Patrick Wilson-Welsh, FitNesse
12. 验收测试驱动开发敏捷联盟,
13. 引入BDD， 2006年3月，Dan North & Associates
14. 行为驱动发展（BDD）敏捷联盟,
15. 5个为什么,维基百科
16. 按比例缩小的敏捷框架,维基百科
17. 创新缩放,维基百科
18. 敏捷软件开发,维基百科
19. 当心安全(企业伸缩敏捷框架)，黑暗的邪恶化身，肖恩德克斯特，1月1日，2020年，中等
20. 第14届敏捷报告, stateofagile.com
21. 我们对“敏捷测试”的定义，Janet Gregory＆Lisa Crispin，2017年6月30日，敏捷测试仪
22. 燃尽图敏捷联盟,
23. Scrum任务板， Mountain Goat Software
24. 每日Scrums.,机器Wayback
25. 看板解释初学者，完整的指南，Kanbanize.