Agile project management with XP Manual

MANUAL GESTIÓN DE PROYECTOS ÁGILES

the implemented functionality, so that he can give feedback to the developers if they have not understood correctly what he wanted. It may also happen that the customer wants to refine the functionality once he has started using it or even change his mind completely. So far, it may seem that extreme programming is a compendium of principles that are present in the agile methodologies we already know. But this is where the significant contribution of Extreme Programming begins. XP describes and recommends a set of best practices for the development team to "program well" and therefore produce "quality software". There are many techniques for determining the quality of a software product. Some are more quantitative (e.g. measuring the percentage of duplicate code), and others are more qualitative (e.g. reviewing the code among team members). There are some techniques that focus on more technological aspects (software architecture, design patterns...) to measure quality. Other techniques measure quality in terms of customer satisfaction, compliance with deadlines, etc. We will go into detail on these aspects later, but at this point, we can consider a software to have been developed "well", i.e. to be of quality, if it meets the following criteria: • The product is free from defects, i.e. it does not fail. • The product does what the customer expects it to do . • The product can be maintained, i.e. functionalities can be added and it can be adapted to new platforms or environments at acceptable costs. • The product is developed in a predictable timeframe. • XP is a methodology that focuses especially on describing the good practices that the development team should follow to produce quality software. Although it mentions some aspects related to project management, other methodologies such as scrum are more developed. In this sense it can be said that XP is mainly focused on software developers. • This methodology is called extreme programming because when it was proposed, its best practices were a way of taking to the extreme tasks that developers were already doing, but on a much less frequent basis. • If reviewing the code is good, then we take it to the extreme and the code will be reviewed by another partner when it is being created. In other words, the code will be programmed and reviewed all the time and in pairs. (Pair programming) . • If the tests are good because they automatically tell if the software does what it is supposed to do and without defects, then everyone involved in the project will perform tests, including the customers. (Unit, integration and acceptance tests). Also, if running tests gives me confidence that everything works, let's run tests at every code change (continuous integration). • If well-designed code is important, then let's design every day and change our code so that it always has a good design (Refactor). • If simple is best, it will always try to be developed in the simplest way possible

13

European Open Business School