Extreme Programming (XP)

Extreme Programming (XP)

• Extreme Programming or eXtreme Programming (XP) is an agile software development framework with an extreme focus on programming and taking engineering practice to an extreme in order to create and release high quality code.
  • eXtreme Programming (XP) is a programmer-centric agile framework that focuses on small, ongoing releases.
  • eXtreme Programming (XP) is generally considered to be the originator of User Stories. [User Stories Applied: For Agile Software Development. Mike Cohn.]
  • The best role for a customer in eXtreme Programming (XP) is to write well-defined User Stories. [User Stories Applied: For Agile Software Development. Mike Cohn.]
• Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.
  • As a type of agile software development, it advocates frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
• Other elements of extreme programming include: programming in pairs or doing extensive code review, Unit Testing (UT) of all code, not programming features until they are actually needed, a flat management structure, code simplicity and clarity, expecting changes in the customer’s requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers.
  • The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to “extreme” levels.
    • As an example, code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously (i.e. the practice of pair programming).

Extreme Programming goal

• Extreme Programming Explained describes extreme programming as a software-development discipline that organizes people to produce higher-quality software more productively.
  • XP attempts to reduce the cost of changes in requirements by having multiple short development cycles, rather than a long one. In this doctrine, changes are a natural, inescapable and desirable aspect of software-development projects, and should be planned for, instead of attempting to define a stable set of requirements.
  • Extreme programming also introduces a number of basic values, principles and practices on top of the agile programming framework.

Extreme Programming (XP) values

• Extreme Programming (XP) is based on 5 values :
  • Communication
  • Simplicity
  • Feedback
  • Courage
  • Respect.
• Just like Scrum, EXTREME PROGRAMMING values Courage and Respect.

eXtreme Programming (XP) principles

• eXtreme Programming (XP) highlights several principles :
  • whole team,
  • pair programming,
  • sustainable pace,
  • ongoing automated testing,
  • effective communication,
  • collective ownership,
  • continuous integration,
  • energized work,
  • shared workspaces,
  • on-site customer representation,
  • and the use of metaphor to describe concepts.
  • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Extreme programming practices

• Extreme programming has been described as having 12 practices, grouped into four areas:
  • Fine-scale feedback
    • Pair programming
      • production code is written by two developpers working as a pair to write and provide real-time reviews of the software as it emerges so the pairs catch issues early upon a larger knowlegde base of two people working together.
    • Planning game
      • by example, Planning poker
    • Test-driven development
      • critical practice to XP, the team writes the test prior to developing the new code.
      • see Test Driven Development (TDD)
    • Whole team
  • Continuous process
    • Continuous integration
      • Continuous Integration (CI) is critical practice to continuously compile & test the code before new one is added.
    • Refactoring or design improvement
      • improves the design of the code, increases the cohesion of the code by removing duplicated code, lowering coupling (dependent connections between code modules).
    • Small releases
  • Shared understanding
    • Coding standards
      • the team has to follow a consistent coding standard so that all the code looks like it has been written by one programmer
      • See Version Control, branching and Merging and Standards
    • Collective code ownership
      • multiple people work on all the code, which results in increased visibility and knowledge of the code base
    • Simple design
      • by keeping the design simple but adequate, the code can be quickly adapted.
      • the design is kept appropriate for what the project currently.
    • System metaphor
      • to assimilate and explain to customer the working entity of each module (use cases metaphor)
  • Programmer welfare
    • Sustainable pace
      • the practice of maintaining a sustainable pace of development optimizes the delivery of long-term value

Whole Team

• Whole Team means that all skills that are required to turn the selected User Stories into a releasable software must be on the team, present across all the team members.

Energized work

• (work only as many hours as you can be productive and only as many hours as you can sustain.)

Extreme Programming practices

• Extreme Programming takes the engineering practices to an extreme, in order to create and release high quality code.
  • Extreme (XP) is highly complementary to the Scrum framework.
• Agile software development practices popularized by Extreme Programming :
  • Continuous Integration (CI)
  • Pair Programming
  • Refactoring
  • User Stories
  • Collective Code Ownership

Continuous Integration (CI)

• Continuous Integration (CI) is a software development practice where members of a development team integrate and verify their work frequently, often multiple times each day to detect integration errors as quickly as possible.
  • Continuous Integration and Build
    • The goal of Continuous Integration (CI) is to provide rapid feedback of build and test results so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible.
    • So, with any check in of new or changed code into version control, the build should be executed
    • Newly checked-in code is built, integrated, and tested frequently, generally multiple times a day.
    • When a Continuous Integration (CI) build fails with a check in, the person who is in the context and knows what is happening is the best one to fix it.
      • Hence, the person who broke the build is the ideal source to fix the failure.
      • In addition, the person who is in the context and knows what is happening is the best one to fix it.

Pair Programming

• Pair programming is a technique in Agile Software Development where two engineers share a single workstation.
  • In this technique, one engineer is the driver, who has control of the mouse and keyboard to write the code, while the other serves as the navigator, reviewing the code that the other is writing while providing tactical and analytical feedback.
  • This pair will trade‐off on these roles at regular intervals, giving each other equal chance to both execute on the work or direct it.
• Pair programming is two developers writing code together, providing constant peer review.

Pair Programming practices

• Pair programming is an agile software development technique in which two programmers work together at one workstation.
  • One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in.
  • The two programmers switch roles frequently.
• Pair programming configuration may be two developers working with one machine or a programmer and a tester working together.
• Pair programming is just two people programming using one computer.
• Pair programming is a micro feedback loop.
  • Pair programming is about live code review.
  • XP teams want to capture problems or dirtiness in their code earlier by having a live code review.
  • Pair programming is about two people collaborating to solve a problem together because two heads are better than one.

Pair Programming benefits

• Fewer Coding Mistakes
• An effective way to share knowledge
• Solve Problems Faster and Quicker
• Train New People Joins
• Improve Interpersonal and Social Skills.

Refactoring

• Code Refactoring is an agile software development practice popularized by Extreme Programming in which code is adjusted within the code base without impacting the external, functional behavior of that code.
  • Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
• In addition, there are no special Sprints in Scrum such as Hardening Sprint, Stabilization Sprint, and Refactoring Sprint …

Refactoring benefits

• There are two general categories of benefits to the activity of refactoring :
  • Maintainability :
    • It is easier to fix bugs because the source code is easy to read, and the intent of its author is easy to grasp.
    • This might be achieved by reducing large monolithic routines into a set of individually concise, well-named, single-purpose methods.
    • It might be achieved by moving a method to a more appropriate class, or by removing misleading comments.
  • Extensibility :
    • It is easier to extend the capabilities of the application if it uses recognizable design patterns, and it provides some flexibility where none before may have existed.
• Advantages also include improved code readability and reduced complexity.

Refactoring practice

• Code Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior
  • Refactoring does “not” include :
    • Rewriting the entire code
    • Fixing bugs
    • Improving observable aspects of software such as its interface
• Refactoring is included in Test Driven Development (TDD)

User Story

• Agile software development practice to express requirements from an enduser perspective, emphasizing verbal communication.
  • User Stories often used to express functional items on the Product Backlog.
  • User Stories are requirements or feature which has to be implemented.

User Story practice

• User Stories typically have a format like :
  As a
  I want to
  To achieve

Collective Code Ownership

Collective Code Ownership practice

• Extreme Programming does not allow the iteration to be more than one week.
  • Extreme Programming mandates the iteration to be only one week long.
• Extreme programming (XP) is highly complementary to the Scrum framework.
  • Scrum Teams practicing Extreme Programming will have their Increment deployed to production daily (Continuous Deployment (CD)).
• While Scrum does not require the customer to be on-site, Extreme Programming requires the customer on-site and continuously test with the team.
  • For Scrum Team practicing EXTREME PROGRAMMING, during Sprint Review the customer, Product Owner and Developers will review the product that is already in production.
  • The Sprint Review will not be the first time the Product Owner and the customer has seen the product.
  • Scrum Team will assess what is possible for the next week Sprint based on what has already been delivered to production.

Extreme Programming Activities

• XP describes four basic activities that are performed within the software development process: coding, testing, listening, and designing. Each of those activities is described below.

Coding

• The advocates of XP argue that the only truly important product of the system development process is code – software instructions that a computer can interpret.
  • Without code, there is no working product.
• Coding can be used to figure out the most suitable solution.
  • Coding can also help to communicate thoughts about programming problems.
  • A programmer dealing with a complex programming problem, or finding it hard to explain the solution to fellow programmers, might code it in a simplified manner and use the code to demonstrate what they mean.
  • Code, say the proponents of this position, is always clear and concise and cannot be interpreted in more than one way.
  • Other programmers can give feedback on this code by also coding their thoughts.

Testing

• Testing is central to extreme programming.
  • Extreme programming’s approach is that if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws. Unit tests determine whether a given feature works as intended.
  • Programmers write as many automated tests as they can think of that might “break” the code; if all tests run successfully, then the coding is complete.
  • Every piece of code that is written is tested before moving on to the next feature.
• Acceptance Tests verify that the requirements as understood by the programmers satisfy the customer’s actual requirements.
• System-wide Integration Testing was encouraged, initially, as a daily end-of-day activity, for early detection of incompatible interfaces, to reconnect before the separate sections diverged widely from coherent functionality.
  • However, system-wide integration testing has been reduced, to weekly, or less often, depending on the stability of the overall interfaces in the system.
• See Test Driven Development (TDD)

Listening

• Programmers must listen to what the customers need the system to do, what “business logic” is needed.
  • They must understand these needs well enough to give the customer feedback about the technical aspects of how the problem might be solved, or cannot be solved.
  • Communication between the customer and programmer is further addressed in the planning game.

Designing

• From the point of view of simplicity, of course one could say that system development doesn’t need more than coding, testing and listening.
• If those activities are performed well, the result should always be a system that works. In practice, this will not work.
  • One can come a long way without designing but at a given time one will get stuck.
  • The system becomes too complex and the dependencies within the system cease to be clear.
  • One can avoid this by creating a design structure that organizes the logic in the system.
  • Good design will avoid many dependencies within a system; this means that changing one part of the system will not affect other parts of the system.[citation needed]

Ten Minute Build

• Ten-minutes Build Principle is non-negotiable rule from EXTREME PROGRAMMING.
  • When the build runs more than ten minutes, the developers may need to refactor their tests code.
  • When the build runs longer than ten minutes, developers are reluctant to continuously integrate their code.
  • When developers are not continuously integrating their code, they will lose feedback.
  • EXTREME PROGRAMMING highly values feedback, faster build means faster feedback.

Technical debt

• Technical Debt is not an eXtreme Programming (XP) practice.
  • Technical Debt is total sum of less than perfect design and implementation decisions in the product,
  • Technical Debt needs to be monitored and controlled.

Sit together

• eXtreme Programming (XP) advocates an open space big enough for the whole team.

Slack

• eXtreme Programming (XP) recommends that in any plan it is better to include some minor tasks that can be dropped if you get behind.
  • You can always add more stories later and deliver more than you promised.

Extreme Programming Rules

• The first version of rules for XP was published in 1999 by Don Wells at the XP website. 29 rules are given in the categories of planning, managing, designing, coding, and testing.
  • Planning, managing and designing are called out explicitly to counter claims that XP doesn’t support those activities.
• Here are some of the rules (incomplete):
  • Coding
    • The customer is always available
    • Code the Unit Test first
    • Only one pair integrates code at a time
    • Leave optimization until last
    • No overtime
  • Testing
    • All code must have Unit Tests
    • All code must pass all Unit Tests before it can be released.
    • When a bug is found, tests are created before the bug is addressed (a bug is not an error in logic; it is a test that was not written)
    • Acceptance Tests are run often and the results are published

More informations for the Scrum PSD certification here.

More informations at PMI-ACP exam

Updated : 24/10/2021