极限编程 - 简介
本章概述了极限编程。
什么是敏捷?
“敏捷”这个词的意思是 -
能够快速轻松地移动身体。
能够快速而清晰地思考。
在商业中,“敏捷”用于描述规划和工作的方式,其中根据需要进行更改是工作的重要组成部分。商业“敏捷性”意味着公司始终能够考虑市场变化。
参考:剑桥在线词典。
在软件开发中,“敏捷”一词被用来表示“响应变化的能力——来自需求、技术和人员的变化”。
敏捷宣言
一个软件开发团队于 2001 年发布了敏捷宣言,强调了开发团队、适应不断变化的需求和客户参与的重要性。
敏捷宣言指出 -
我们通过实践并帮助他人开发软件,从而发现更好的软件开发方法。通过这项工作,我们认识到了价值 -
个人以及流程和工具上的交互。
工作软件胜过全面的文档。
客户协作 胜过合同谈判。
响应变化而不是遵循计划。
也就是说,虽然右侧的项目有价值,但我们更看重左侧的项目。
敏捷的特点
以下是敏捷的特点 -
敏捷软件开发中的敏捷性侧重于整个团队的文化,其中包括多学科、跨职能的团队,这些团队被授权和自组织。
它促进共同的责任和问责。
促进有效沟通和持续协作。
整个团队的方法避免了延误和等待时间。
频繁和持续的交付可确保快速反馈,从而使团队能够满足需求。
协作有助于在实施、缺陷修复和适应变更时及时结合不同的观点。
进步是持续的、可持续的和可预测的,强调透明度。
软件工程趋势
在软件工程中观察到以下趋势 -
在开发开始之前收集需求。但是,如果稍后要更改要求,通常会注意到以下内容 -
对发展后期变化的抵制。
需要严格的变更流程,其中涉及变更控制委员会,甚至可能将变更推送到以后的版本。
交付的产品具有过时的要求,无法满足客户的期望。
无法在预算内适应不可避免的领域变化和技术变化。
在开发生命周期的早期发现并消除缺陷,以降低缺陷修复成本。
测试仅在编码完成后开始,并且测试被视为测试人员的责任,尽管测试人员不参与开发。
测量并跟踪流程本身。这变得昂贵是因为 -
在任务级别和资源级别进行监视和跟踪。
定义衡量标准以指导开发并衡量开发中的每项活动。
管理干预。
在开发之前详细阐述、分析和验证模型。
模型应该用作框架。然而,只关注模型而不关注至关重要的开发不会产生预期的结果。
作为开发核心的编码没有得到足够的重视。原因是 -
负责生产的开发人员通常不会与客户保持持续沟通。
编码被视为设计的翻译,代码中的有效实现几乎不会循环回到设计中。
测试被认为是交付前检查缺陷的门户。
开发早期阶段的进度超支可以通过忽略测试要求来补偿,以确保及时交付。
这会导致交付后修复缺陷的成本超支。
测试人员虽然没有参与整个开发过程,但他们要对产品质量负责。
限制资源(主要是团队)以适应预算会导致 -
资源过度分配
团队倦怠。
无法有效利用团队能力。
磨损。
极限编程——解决常见缺点的方法
软件工程涉及 -
创造力
通过尝试和错误来学习和改进
迭代
极限编程建立在这些活动和编码的基础上。它是详细的(不是唯一的)设计活动,通过持续有效的实施、测试和重构,具有多个紧密的反馈循环。
极限编程基于以下值 -
沟通
简单
反馈
勇气
尊重
什么是极限编程?
XP 是一种轻量级、高效、低风险、灵活、可预测、科学且有趣的软件开发方式。
e X treme编程(XP) 的构思和开发是为了满足小型团队在面对模糊和不断变化的需求时的软件开发特定需求。
极限编程是敏捷软件开发方法之一。它提供了指导团队Behave的价值观和原则。该团队有望自组织。极限编程提供了具体的核心实践,其中 -
每个练习都是简单且自我完成的。
实践的结合会产生更复杂和更紧急的Behave。
迎接改变
极限编程的一个关键假设是,随着时间的推移,更改程序的成本可以基本保持不变。
这可以通过以下方式实现 -
强调来自客户的持续反馈
短迭代
设计和重新设计
经常编码和测试
尽早消除缺陷,从而降低成本
让客户参与整个开发过程
向客户交付工作产品
简而言之极限编程
极限编程涉及 -
在编程之前编写单元测试并保持所有测试始终运行。单元测试是自动化的,可以尽早消除缺陷,从而降低成本。
从一个简单的设计开始,足以对手头的功能进行编码,并在需要时重新设计。
结对编程(称为结对编程),两个程序员在一个屏幕上,轮流使用键盘。当其中一个人坐在键盘上时,另一个人不断地审查并提供输入。
每天对整个系统进行多次集成和测试。
将最小工作系统快速投入生产并在需要时进行升级。
让客户始终参与并获得持续的反馈。
随着软件随着需求的变化而发展,迭代有助于适应变化。
为什么叫“极限”?
极限编程将有效的原则和实践提升到了极限。
代码审查是有效的,因为代码一直在审查。
测试是有效的,因为有持续的回归和测试。
设计是有效的,因为每个人都需要每天进行重构。
集成测试很重要,因为每天要集成和测试多次。
短迭代对于发布计划和迭代计划来说是有效的计划游戏。
极限编程的历史
Kent Beck、Ward Cunningham 和 Ron Jeffries 在 1999 年提出了极限编程。其他贡献者是 Robert Martin 和 Martin Fowler。
80 年代中期,Kent Beck 和 Ward Cunningham 在 Tektronix 发起了结对编程。在 80 年代和 90 年代,Smalltalk 文化产生了重构、持续集成、持续测试和密切的客户参与。这种文化后来被推广到其他环境。
20 世纪 90 年代初,Hillside Group 的模式社区开发了核心价值观。1995 年,Kent 在《Smalltalk 最佳实践》中总结了这些内容,1996 年,Ward 在剧集中总结了这些内容。
1996 年,Kent 在 Hewitt 增加了单元测试和隐喻。1996年,肯特接手了克莱斯勒C3项目,罗恩·杰弗里斯被任命为该项目的教练。这些实践在 C3 上进行了完善并发布在 Wiki 上。
Scrum 实践被纳入并调整为规划游戏。1999 年,肯特出版了他的书《极限编程解释》。同年,福勒出版了他的书《重构》。
从那时起,极限编程就一直在发展,并且这种发展一直持续到今天。
行业成功
遵循极限编程实践的项目的成功是由于 -
快速发展。
立即响应客户不断变化的需求。
专注于低缺陷率。
系统为客户返回持续一致的价值。
客户满意度高。
降低成本。
团队凝聚力和员工满意度。
极限编程的优势
极限编程解决了软件开发项目中经常遇到的以下问题 -
进度落后和可实现的开发周期确保及时交付。
取消的项目- 注重客户的持续参与,确保客户的透明度并立即解决任何问题。
变更产生的成本- 广泛且持续的测试可确保变更不会破坏现有功能。运行中的工作系统始终确保有足够的时间来适应变化,从而不影响当前的操作。
生产和交付后缺陷:重点是- 单元测试以尽早检测和修复缺陷。
误解业务和/或领域- 让客户成为团队的一部分可确保持续的沟通和澄清。
业务变化- 变化被认为是不可避免的,并且可以在任何时间点进行调整。
员工流动- 密集的团队合作确保了热情和良好意愿。多学科的凝聚力培养团队精神。