你熟悉编程，但极限编程（简称XP）对你来说还是有点神秘。
不要让这个名字让您失望，您可能会错过有用的信息。
在本文中，我们将涵盖您需要了解的有关极限编程的所有信息，以便您可以充分利用它。
极限编程是一种软件开发方法，是统称为敏捷方法的一部分。 XP 建立在价值观、原则和实践之上，其目标是使中小型团队能够生产出高质量的软件并适应不断变化和发展的需求。
XP 与其他敏捷方法的区别在于 XP 强调软件开发的技术方面。 极限编程精确地描述了工程师的工作方式，因为遵循工程实践允许团队以可持续的速度交付高质量的代码。
简而言之，极限编程就是将好的实践发挥到极致。 由于结对编程很好，所以我们一直这样做吧。 由于提前测试很好，我们甚至在编写生产代码之前就进行了测试。
XP 与其他方法不同，它基于工程实践方面重要且相关的价值观和原则。
价值观为团队提供目标。 他们充当“北极星”，在高层次上指导您的决策。 但是，这些值是抽象的，对于具体的指导来说过于模糊。 例如：说你重视沟通会导致许多不同的结果。
从某种意义上说，实践与价值观是对立的。 他们是具体的、脚踏实地的， defi设定要做什么的细节。 实践帮助团队对价值观负责。 例如，信息工作空间的实践促进了透明和简单的沟通。
原则是特定领域的指导方针，弥合了实践和价值观之间的差距。
XP价值观：沟通、简单、反馈、勇气和尊重。 让我们更详细地看看它们中的每一个。
起草 BlogInnovazione.它的图像 亚历克斯软件网
沟通：缺乏沟通会阻止知识在团队内流动。 通常，当出现问题时，有人已经知道如何解决它。 但是缺乏沟通会阻止他们了解问题或为解决问题做出贡献。 因此，问题最终被解决了两次，产生了浪费。
简单: 简单意味着你总是努力做最简单有效的事情。 它经常被误解并被视为最简单的事情，句号，忽略了“有效”的部分。
同样重要的是要记住，简单是高度相关的。 对一个团队来说简单的事情对另一个团队来说很复杂，并且完全取决于每个团队的技能、经验和知识。
反馈：在更传统的级联软件开发方法中，反馈通常“太少，太晚”。
然而，XP 拥抱变化，XP 团队努力争取及时和持续的反馈。 如果需要更正路线，XPers 希望尽快知道。
起草 BlogInnovazione.它的图像 亚历克斯软件网
反馈有多种形式和大小。 当您进行合作编程时，同事的评论是至关重要的反馈。 其他团队成员对一个想法的意见也是如此，包括理想情况下是团队成员的客户。
测试是除了测试结果之外的另一个有价值的反馈来源。 无论编写测试是容易还是困难，反馈也是如此。 如果您在编写测试时遇到问题，您的项目可能太复杂了。 听取反馈并简化您的设计。
听起来不错的想法在实践中可能效果不佳。 因此，完成的代码也是反馈的来源，就像分布式产品一样。
最后，请记住反馈太多。 如果一个团队产生的反馈多于它可以处理的数量，那么重要的反馈可能会被忽视。 因此，必须放慢速度并找出导致过多反馈的原因并进行修复。
勇气：肯特·贝克 defi勇气表现为“面对恐惧的有效行动”。 作为一名软件工程师，您有很多恐惧，因此有很多机会展现勇气。
说实话需要勇气，尤其是那些不愉快的，比如诚实的估计。 提供和接受反馈也需要勇气。 避免陷入沉没成本谬误并放弃已获得大量投资的失败解决方案需要勇气。
相比：XP 的一个基本前提是每个人都关心他们的工作。 如果没有关心和尊重，再多的技术卓越也无法挽救一个项目。
每个人都值得尊严和尊重，当然，这包括参与软件开发项目的人。 当你和你的团队成员相互尊重和关心对方、客户、项目及其未来的用户时，每个人都会受益
原则比价值观提供更具体的指导。 它们是阐明价值观并使价值观更明确、更明确的指导方针。
起草 BlogInnovazione.它的图像 亚历克斯软件网
例如，仅基于勇气的价值，您可能会得出结论，建议立即对您的日程安排进行重大更改。 然而，Baby Steps 原则告诉我们，大的改变是有风险的。 所以，更喜欢小的。
人性：人类为人类创造软件，这是一个经常被忽视的事实。 但考虑到人类的基本需求、优势和劣势，创造出人类想要使用的产品。 一个能为您提供成就感和成长机会、归属感和基本安全感的工作环境，是您更容易考虑他人需求的地方。
经济：在 XP 中，团队始终关注软件开发的经济现实，不断评估经济风险和项目需求。
例如，他们会根据业务价值而不是技术问题来实施用户故事。
互惠互利：在 XP 之后，您会避免以牺牲另一方为代价使一方受益的解决方案。 例如，扩展规范可能会帮助其他人理解它，但它会分散您对实现它的注意力并延迟它对您的用户的实现。
一个互惠互利的解决方案是使用自动验收测试。 获得关于您的实施的即时反馈，您的同行获得精确的代码规范，而用户首先获得他们的功能。 另外，你们所有人都会有一个防止倒退的安全网。
利益（互利）：如果给定的解决方案在一个级别上工作，它也可能在更高或更低的级别上工作。 例如，在 XP 中，获得早期和持续的反馈在不同程度上处于危险之中。
改进：根据改进的原则，团队的目标不是在最初的实施中完美，而是为了一个足够好的实施，然后根据真实用户的反馈不断学习和改进。
多元化：您和您的同事受益于多元化的观点、技能和态度。 这种多样性往往会导致冲突，但这没关系。
当每个人都秉承勇气和尊重的价值观时，冲突和分歧是产生更好想法的机会。 敢于表达相反的观点，以文明和同理心的方式表达尊重。 所有这些都是有效的沟通练习。
反射：伟大的团队会反思他们的工作并分析如何做得更好。 XP 为此提供了许多机会。 不仅在每周和每季度的周期中，而且在它促进的每项实践中。
除了逻辑分析之外，感觉也很重要。 在您推理任何事情之前，您的直觉会告诉您。 这样他就可以与非技术人员交谈，他们可以提出开辟全新可能性的问题。
流：传统的软件开发方法有不同的阶段，持续很长时间并且很少有机会获得反馈和过程修正。 相反，XP 中的软件开发发生在持续发生的活动中，发生在一致的“价值流”中。
机会: 问题在软件开发中是不可避免的。 然而，每一个问题都是改进的机会。 学会以这种方式看待它们，你就更有可能想出创造性的、以目标为导向的解决方案，这些解决方案也有助于防止它们再次发生。
冗余：冗余原则说，如果给定的问题很关键，则必须采用多种策略来应对它。
抓住缺点。 没有一种策略可以防止所有缺陷从生产中逃脱。
所以 XP 的解决方案是叠加一套质量措施。 结对编程、测试、持续集成。 每一道防线，共同构成一道几乎坚不可摧的墙。
失败：当失败转化为知识时，失败并不浪费。 采取行动并迅速了解什么是行不通的，这比在众多选项中做出选择时优柔寡断导致的不作为更有成效。
质量: 人们通常认为质量和速度之间存在两难选择。
恰恰相反：努力提高质量会让你走得更快。
例如，重构——改变代码结构而不改变其行为——是一种使代码更易于理解和更改的实践。 因此，您不太可能引入代码缺陷，这让您无需修复错误即可首先交付更多价值。
小步骤: 大的变化是有风险的。 XP 通过在每个级别进行小步更改来减轻这种风险。
程序员使用测试驱动开发以小步骤编写代码。 他们每天多次将代码集成到主线中，而不是每隔几周甚至几个月一次。 该项目本身发生在较短的周期而不是长期的阶段。
接受责任: 在 XP 中，责任应该被接受，而不是分配。
问责制应该伴随着对你负责的事情做出决定的权力。 反之亦然。 你不希望人们在不必承担后果的情况下做出决定。
极限编程作为一种敏捷的方法论，可以被接受并开始采用它，而无需遵循严格的计划。 这是一个迭代设计，而不是一个大的初始项目。
XP 与传统方法显着不同，即级联，避免持久阶段。
XP 与其他敏捷方法有何不同？
极限编程，就其本质而言，与其他敏捷方法有很多共同点，但在它们之间也很独特。
大多数其他开发方法并没有过多地说明如何完成工作。 另一方面，XP 在这方面非常自以为是，非常强调软件工程实践。
Scrum 是一个帮助团队以适应性方式开发复杂项目的框架。 Scrum 不规定开发人员如何工作。 如前所述，XP 非常重视良好的编程实践。
起草 BlogInnovazione.en 图片 网络解决方案
另外，XP 显然是关于编程的。 另一方面，Scrum 可以应用于任何受益于迭代方法的项目。
XP 接受对其组件的更改。 团队被授权甚至鼓励根据他们的特定需求修改实践。 另一方面，《Scrum 指南》坚持认为“虽然只能实施 Scrum 的一部分，但结果不是 Scrum”。
此外，Scrum 是一个框架，需要辅以方法和实践来完成工作。
这意味着强烈建议使用极限编程和 Scrum。
根据 Kent Beck 的说法，一个成熟的 XP 团队不应该分配严格的角色，而是要认识到角色对刚起步的团队是有用的，直到他们开始放慢速度或使协作变得困难。
让我们看看一些关键角色：
这些是XP中采用的做法。 他们分为三个主要组：软件工程、工作场所和项目管理。
结对编程: 在 XP 中，你在一台机器上成对地编写代码。 您和您的夫妇在分析、实施和测试您正在开发的功能时互相交谈。 结对编程特别擅长生成错误更少的代码，同时仍然具有吸引力、乐趣和累人。
十分钟限制：必需 允许 10 分钟构建整个项目，包括运行所有自动化测试，最多 XNUMX 分钟。 这个限制是为了保持测试的精简和有效。
编程前测试：使用测试优先方法实现功能，也称为 测试驱动开发 (TDD). TDD 包括使用简单迭代过程的开发：
TDD 带来了几个好处。
第一，反馈。 如果很难编写测试，那么您正在寻找的或继承的设计可能太复杂，您需要对其进行简化。
其次，TDD 允许程序员信任他们编写的代码并创建一个很好的循环节奏，下一步总是很清楚。
最后但同样重要的是，从一开始就使用 TDD 可确保 100% 的代码覆盖率。 然后，测试套件真正成为未来更改的安全网，鼓励代码重构并创建质量的良性循环。
增量设计：增量设计的实践意味着您每天都需要在应用程序设计上进行投资，寻找机会消除重复并进行小的改进，以实现当今系统所需的最佳设计。
持续集成: 在 XP 中，您每天多次将您的工作集成到主共享存储库中，触发整个系统的自动构建。 尽早和尽可能频繁地集成可显着降低集成成本，因为它使合并和逻辑冲突不太可能发生。 它还暴露了环境和成瘾问题。
共享代码（集体所有）: XP提倡共享代码，或集体所有权：每个开发人员对所有代码负责。 如果我们考虑多样性原则，它会鼓励信息交流，降低团队总线因素并提高每个模块的整体质量。
单一代码库: 单一代码库也称为“基于主干的开发”。 这意味着只有一个真理来源。 因此，与其长时间孤立地开发，不如尽早并经常将您的贡献合并到一个流中。 功能标志有助于限制您对功能的使用，直到它们完成为止。
每日派送：每天至少在生产中部署一次是持续集成的合乎逻辑的结果：。 事实上，今天，许多团队走得更远，实践持续实施。 也就是说，只要有人加入主线，应用程序就会部署到生产环境中。
代码和测试：这种做法意味着源代码（包括测试）是软件项目的唯一永久工件。 参与其他类型的工件（包括文档）的生成通常是一种浪费，因为它不会为客户产生真正的价值。
如果您需要其他工件或文档，请努力从生产代码和测试中生成它们。
根本原因分析：每当将缺陷投入生产时，不要只是纠正缺陷。 确保首先弄清楚是什么原因造成的，为什么你和你的队友未能阻止打滑。 然后，采取措施确保它不再发生。
坐在一起：在 XP 中，团队更喜欢在开放空间中一起工作。 这种做法促进了沟通和团队归属感。
整个团队：项目成功所需的每个人都是 XP 团队的成员。 这是高度相关的——每个团队都不同——而且是动态的，它可以在团队内部发生变化。
信息工作空间：信息工作空间利用团队的物理空间来展示信息，让任何人都能一目了然地了解项目的进展情况。 这是如何完成的，从物理笔记和图表到显示项目管理软件的看板和仪表板的屏幕截图。
充满活力的工作: 在 XP 中，只要您能干精力充沛的工作，您就可以工作。 工作时间必须限制在每周最多 40 小时。
Analisi- 以称为用户分析的格式编写用户需求。 用户分析有一个简短的描述性名称，还有一个对需要实施的内容的简短描述。
松弛：在规划周期时，添加团队可以在需要时放弃的次要任务。 如果团队交付太多，总是可以添加更多故事。
周期（每月和每周）: XP 中的开发有两个主要周期：每周周期和每月周期。
会议、周期、预定发布: XP 中的开发工作有两个主要周期：每周周期和季度周期。 最初，肯特·贝克 (Kent Beck) 建议以两周为周期，但在他的书的第二版中对此进行了更改。
每周循环：每周周期是 XP 项目的“脉搏”。 这个周期从一个会议开始，客户在会上选择他想在一周内创作的故事。 此外，团队会回顾他们的工作，包括上周的进展，并思考改进流程的方法。
每月周期：每个月，团队都会反映并确定流程中的改进机会。 客户选择当月的一个或多个主题，以及对这些主题的分析。
如何开始使用极限编程？
技术技能和 XP 习惯可能很难学习。 有些做法对于不习惯它们的程序员来说可能看起来很陌生。
Ercole Palmeri
