Extreme Programming (XP) - BogdanViblyy/Buketov GitHub Wiki

What Is Extreme Programming (XP)?

Extreme Programming (XP) is an Agile development approach that prioritizes technical excellence, close collaboration, and adaptability to change. It focuses on improving both software quality and development speed by applying core software engineering practices more rigorously—hence the name “extreme.”

  • Aims to enhance project outcomes through well-defined technical and team practices.
  • Focus areas include clean code, fast feedback, ongoing adjustment, user satisfaction, and sustainable developer pace.

Core Values of XP

XP is guided by five foundational values:

  1. Communication – Frequent and open interaction between team members and stakeholders (e.g., pair programming, constant access to the customer).
  2. Simplicity – Build only what’s needed for now; avoid unnecessary complexity ("You Aren’t Gonna Need It").
  3. Feedback – Get early and regular input from tests, integrations, and users to steer development.
  4. Courage – Be honest about progress, willing to refactor or revise direction when needed.
  5. Respect – Value the ideas, input, and contributions of every team member, building a culture of trust and cooperation.

Key XP Practices

XP employs a range of technical and collaborative practices:

  • Pair Programming – Two developers write code together at a single workstation.
  • Test-Driven Development (TDD) – Write tests before writing the code that passes them.
  • Continuous Integration (CI) – Frequently merge changes into the main codebase, with automated builds and tests on each integration.
  • Refactoring – Continuously improve the code’s internal design without changing its behavior.
  • Simple Design – Keep solutions minimal and focused on current needs.
  • Collective Code Ownership – Any team member can improve any part of the code at any time.
  • Coding Standards – Agree on consistent code style and conventions as a team.
  • Sustainable Pace – Maintain a healthy, long-term work rhythm (often defined as a 40-hour workweek).
  • On-Site Customer – Have a real customer or representative constantly available to the team.
  • Frequent Releases – Deliver working software in small increments to get early feedback.
  • Planning Practices – Use planning sessions to decide what to build next, based on customer value and technical input.