xp 极限编程_极限编程（XP）简介

xp 极限编程

这篇文章介绍了极限编程（XP），这是用于软件应用程序实现的另一种敏捷方法。 阅读这篇文章是这篇文章的先决条件。

极限编程的基本原理是吸收软件工程的最佳元素，并将它们带入“极端”水平。 如果一点点好，更多的必然会更好。 XP认为，在项目实施中不可避免地要进行更改。 因此，定义一组稳定的需求是没有意义的。

核心实践与价值观

极限编程基于12条核心原则：

1. 计划游戏 –这是在会议上进行的计划过程，该过程在迭代的开始时发生。 它包括发行计划和迭代计划。
2. 小批量发布 -迭代周期为1-3周。
3. 系统隐喻 –用户对系统应该做什么的描述。 它有助于推动项目的方向和期望。 在UML范式中，这将是用例集。
4. 简单设计 –这是Occam Razor应用于项目实施的原则。 该代码的作用不应该超过要求。 如果不需要某些内容，请不要实施。
5. 测试 – XP支持测试驱动的开发，在该开发中，经常执行单元测试以检查任何回归。 用户还定义了接受测试，以确保所需的功能满足期望。 这些应该是自动化的，不需要人工干预。
6. 频繁重构 –重构是关于生成越来越清晰的代码，或者对其进行修改以响应新的或修订的要求。
7. 结对编程 –所有代码都是由在同一工作站上工作的两个人（一个创意思维和一个务实思维）创建的。 这与指导无关。 配对不是固定的，可以重新组织。 一个目的是提高生产力，另一个目的是传播已实施项目的知识。
8. 团队代码所有权 –每个人应对所有代码负责。
9. 持续集成 –所有开发人员都在同一代码库上工作，以防止出现集成问题。
10. 可持续的步伐 –避免过多的压力，这通常会导致质量低下或错误的代码。 总体而言，过快地加快处理过程会导致调试和改进不良质量代码的成本增加。 必须找到最佳速度。 XP不会促进加班。
11. 整个团队在一起 –团队应在同一房间进行操作。 这不仅与开发团队有关，而且客户应始终在身边，并可以提出问题。
12. 编码标准 –在整个应用程序中看起来相同的代码更易于阅读和理解。

XP的4个价值是：沟通，简单，反馈和勇气。

概念

• 故事是由客户写的，描述了他作为工作的一部分所做的事情。 UML中最接近的概念将是一个用例。
• XP中有6个主要角色：
  • 客户编写故事和验收测试。
• 发布计划游戏是定义哪些功能应成为下一个软件应用程序发布的一部分的过程。 应该包括哪些故事？ 程序员估计每个任务的难度。
• 迭代计划游戏是选择故事以在下一次迭代中实施的过程。
• 任务列表是每个开发人员在下一次迭代之前必须执行的任务集。

实践

• XP不会促进整体设计规范文档的创建。
• 保持文档最少。
• 团队最多应由10名开发人员组成。
• 项目不应超过一年。
• 代码审查应该经常进行。
• XP项目的生命周期分为几个阶段：
  • 探索 –为第一个发行版准备足够的故事卡，确保项目可行（原型）。

结论

极限编程假设客户是高度可用的并且能够表达其所有需求。 故事不如UML案例那么精确。 在许多项目中，必要时拒绝进行详细分析可能适得其反。 让客户非正式地提出请求更改也无助于设定可持续的步伐。

XP使工作职责和角色的划分最大化。 它消耗大量资源。 它往往更注重效率而不是有效性。 结对编程也不适合每个人的心理，在大多数项目中，让每个人负责所有代码是过分的。 人们的时间并不总是有效地消耗掉。

为了提高效率，XP需要一个拥有大量资源且愿意生活在边缘的环境（例如一级方程式赛车）。 它不适用于迁移项目或实施复杂系统（包括高安全性）的项目。 瀑布或Scrum会更合适。

参考： 技术说明博客上的JCG合作伙伴 Jerome Versrynge提供的极限编程（XP）简介 。

翻译自: https://www.javacodegeeks.com/2012/11/introduction-to-extreme-programming-xp.html

xp 极限编程