Surely you have heard about “sustained rhythm” or “work of 40 hours per week” or perhaps you have not heard of any of these terms if so then it will be easier to get to know extreme programming but, if you’ve heard about this methodology surely the You consider as “the dark Side” of agility. Why? All those who already know about the methodology met with this practice in which the teams had to carry a sustained job, that is to say a way of working without losing the concentration and fulfilling the delivery times. Because of this, it was considered that the best way to accomplish with the objectives was that the work teams should be sitting in front of a computer more than 8 hours a day, when the reality is another.

Extreme programming as Agile methodology does not consider that it should be carried out 40, 35 or 42 hours per week on the contrary the idea of taking a sustained pace is that the teams find the best way to carry out their work without stress or exhaustion , and this is accomplished under good work planning. If the project is delayed, nothing guarantees that working overtime gives satisfactory results you may be able to deliver a punctual delivery of a product that may work but what about your work team? If we remember the values of the Agile manifesto, we should mention that we give more value to individuals than to the processes because it is the people who will take care of the product, and when an individual works overtime it is discouraged, exhausted and Stressed out and the only result you’ll get is a poor quality product, functional Yes, but not quality and probably less people on your team.

So what is Extreme programming? Let me tell you it’s not “extreme programming” that is, it’s not sitting more than 8 hours a day and “kicking code without stopping” No! Extreme programming is an agile methodology based on the principles of the Agile Manifesto, whose sole purpose is to help us to make quality products beyond a plan to strictly follow, is to welcome the changes. Extreme programming or XP has its origin in the Smalltalk community, in particular in the collaboration between Kent Beck and Ward Cunningham in the late 80, both refined their practices during the 90, extending the idea that software development is a process Adaptive and people-oriented. Kent Beck worked as a consultant and applied these techniques in multiple projects, but specifically in Chrysler’s C3 project (1993-1997) that can be considered the XP creation project. Kent Beck coined the name of Extreme programming in 1997 born with him, the first book on this methodology which shows 12 practices and values important to carry out the success in our projects.

Values in XP

In order for the project to succeed, the XP methodology presents four fundamental values in which work teams must be governed:

  •        Communication: Many of the problems that exist in software projects (as well as in many other areas) are due to problems of communication between people. Permanent communication is fundamental in XP. Since the documentation is scarce, the frontal, face-to-face dialogue between developers, managers and the client is the basic means of communication. A good communication has to be present throughout the project.
  •        Simplicity: XP, betting on simplicity, at its best. Simplicity in design, code, processes, etc. Simplicity is essential so that everyone can understand the code, and it is about improving through continuous recoding.
  •        Feedback: feedback must work permanently. The customer must provide feedback on the functions developed, so that they can take their comments for the next iteration, and to understand, more and more, their needs. The results of unit tests are also a permanent feedback that developers have about the quality of their work.
  •        Courage: When you encounter serious problems in design, or in any other aspect, you must have the courage to face your solution, no matter how hard it is. If it is necessary to completely change part of the code, it must be done, no matter how long it has previously been invested in it.

XP practices or rules

In this methodology we find between 12 and 13 general practices that will help us to achieve our goal, Ojo! is not to follow the plan, or follow the practices to the letter with a good orientation you can choose the practices that best suit your need, here I present the rules in a generic and grouped form:

1. Planning rules and practices the XP methodology raises planning as a continuous dialogue between the parties involved in the project, including the client, programmers and coordinators or managers. The project begins by compiling “User Stories”, which replace the traditional “use cases”. Once the “user stories” have been obtained, the programmers quickly evaluate the development time of each one. Once these estimations have been made, a planning meeting is organized, with the various actors of the project (client, developers, managers), in order to establish a plan or schedule of deliveries (“Release plan”) in which everyone agrees. Once this schedule has been agreed, a phase of iterations begins, where each one of them develops, tests and installs a few “user stories”.

Release plan — the delivery schedule establishes which user stories will be grouped together to form a delivery, and the order of the deliverables. This schedule will be the result of a meeting between all the actors of the project (client, developers, managers, etc.). XP calls this meeting “planning game”, but it can be called in the way that is most appropriate to the type of business and customer (for example, planning meeting, “Planning meeting” or “Planning Workshop”) typically the customer will order and group user stories according to their priorities. The schedule of deliveries is based on the estimates of development times made by the developers. After some iterations it is advisable to reassemble a meeting with the actors of the project, to re-evaluate the delivery plan and adjust it if necessary.        

Iteration Plan — the stories of selected users for each submission are developed and tested in an iteration cycle, according to the preset order. At the beginning of each cycle, an iteration planning meeting is performed. Each user story translates into specific scheduling tasks. Acceptance tests are also established for each user story. These tests are performed at the end of the cycle in which they are developed, but also at the end of each of the following cycles, to verify that subsequent iterations have not affected the previous ones. The acceptance tests that have failed in the previous cycle are analyzed to evaluate their correction, as well as to anticipate that they do not occur again.       

Stand-Up meeting (daily follow-up meetings): The goal of having daily meetings is to maintain communication between the team, and to share problems and solutions. In most of these meetings, a large part of the participants simply listen, without having much to contribute. In order not to remove unnecessary time from the equipment, it is suggested that these meetings be held in a circle and standing.       

 User Stories — User stories, replace functional requirement documents, or “use cases,”. These “stories” are written by the client, in their own language, as short descriptions of what the system should do. The stories of users should be able to be programmed in a time between one and three weeks. If the estimate is more than three weeks, it should be divided into two or more stories. If it’s less than a week, it should be combined with another story

.2) Design rules and practices the XP methodology makes special emphasis on simple and clear designs. The most important design concepts in this methodology are the following:        

Simplicity: A simple design is implemented faster than a complex one. That’s why XP proposes to implement the simplest possible design that works. It is suggested that you never advance the implementation of functionality that does not correspond to the iteration in which you are working.

Recoding: recoding consists of re-writing part of the code of a program, without changing its functionality, in order to make it simpler, concise and/or understandable. The XP methodology suggests recoding every time it is necessary. While it may seem like an unnecessary waste of time in the immediate term, the results of this practice bear fruit in the following iterations, when functionality needs to be expanded or changed. The philosophy pursued is, as already mentioned, trying to keep the simplest possible code that implements the desired functionality.

Metaphors: A “metaphor” is something that everyone understands, without the need for further explanations. The XP methodology suggests using this concept as an easy way to explain the purpose of the project, and to guide the structure and architecture of it. In a work done at Carnegie Mellon’s School of Computer Science, the usefulness of its use is questioned.

Spike Solutions: When technical problems appear, or when it is difficult to estimate the time to implement a user story, small test programs (called “Spike”) can be used to explore different solutions that after your Evaluation are discarded.

 

3) Rules and practices for customer DesarrolloDisponibilidad: one of the requirements of XP is to have the customer available throughout the project. Not only as a support to the developers, but as part of the group. The client’s involvement is fundamental so that a project can be developed with the XP methodology.        

Use of standards: While this is not a new idea, XP promotes standards-based programming, so that it is easily understood by the entire team, and facilitates recoding.        

Test-driven programming: in traditional methodologies, the testing phase, including the definition of the tests, is usually performed on the end of the project, or on the end of the development of each module. The XP methodology proposes an inverse model, in which, the first thing that is written are the tests that the system must pass. Then development must be the minimum necessary to pass the previously defined tests. The tests referred to in this practice are the unit tests carried out by the developers. The definition of these tests at the beginning, conditions or “directs” the development.        

Programming in pairs: XP proposes that it be developed in pairs of programmers, both working together on one computer. While it seems that this practice doubles the time allocated to the project (and thus costs in human resources), working in pairs minimizes errors and achieves better designs, compensating for investment in hours. The product obtained is generally of better quality than when the development is done by individual programmers.

Permanent integrations: All developers need to always work with the “latest version”. Making changes or improvements to older versions causes serious problems, delays the project. That’s why XP promotes publishing the new versions as soon as possible, even if they are not the last ones, as long as they are error-free. Ideally, every day there must be new versions published. To avoid mistakes, only a couple of developers can integrate their code at the same time.

  Collective ownership of the code: in an XP project, the whole team can contribute new ideas that apply to any part of the project. Also, any programer pair can change the code that is necessary to fix problems, add functions, or Recode

.4) Rules and practices for unitary PruebasPruebas: unit tests are one of the angular stones of XP. All modules must pass unit tests before being released or published. On the other hand, the tests must be defined before making the code (“Test-driven programming”).

Error detection and correction: When a bug is encountered, it must be corrected immediately, and precautions should be taken so that similar errors do not occur again. New tests are also generated to verify that the error has been resolved.

 Acceptance tests: Acceptance tests are created based on user stories, in each cycle of the iteration of development. The client must specify one or several scenarios to verify that a user history has been successfully implemented.

Roles and Computers in XP

If there are roles in the XP methodology!, in fact Beck Kent its main author in his book Extreme programming explained: Embrace Change, Second Edition tells us about the roles that must be present in the development team. Kent mentions that they should not be rigid and fixed when the methodology or development team is mature, ie when the methodology was completely adopted. On the contrary when it is beginning with the methodology if it is necessary to consider the roles that each member of the development team should have in this way the objectives can be better posed, in the orientation on the methodology and in the decision making When you have the right people for each role, but for XP each person who makes up the team is in the ability to “exercise” any function as the team matures, with this you can say that the developer can be the software architect , or the tester. The goal is for each person to contribute as much as he can to achieve the goal raised.

What are the roles in the methodology?

  • Tester: is in charge of supporting the client in the preparation/realization of functional tests is the one who executes the functional tests and publishes the results obtained and shares them with the developers so that they can make the changes.
  • Programmer: Programmers on an XP computer estimate stories and tasks, break stories into tasks, write tests, write code to implement functions, and gradually improve system design. Programmers work in close technical collaboration between them and the client, so they need to develop good social and relationship skills.
  • Client: The clients of an XP team help to write and choose stories and make domain decisions during development. Users are more valuable if they have extensive knowledge and experience with systems similar to the one being built and if they have strong relationships with the larger user community that will use the system once it is fully deployed. Coach: O coach If your computer is starting to apply XP, you may find it helpful to include a coach on your computer. This is usually an external consultant or someone from your organization who has previously used XP is included on the computer to help other team members in XP practices and to help their team maintain self-discipline. The main value of the coach is that he has gone through the methodology, knows it well and can help his team to avoid errors that most teams do when they are applying XP.
  • Project Manager: O project managers in an XP team facilitate communication within the team and coordinate communication with customers, suppliers and the rest of the organization. Project Managers act as team historians, reminding the team how much progress it has made.   With the number of roles, and with the practice of programming in pair you might wonder what is the capacity or how many people there must be on an XP computer? As an agile methodology, teams are required not to be very large it is considered that the teams must be formed between 5 and 9 people.   In the XP methodology although there is no consensus in the maximum number of developers, they all seem to coincide in numbers not greater than 20. Their own practices so require, because, for example, keep the “Stand-up meeting” with more than 20 people seems unreasonable, with this I do not want to say that with fewer people you can not apply XP but remember that certain practices you will not be able to carry Corporal everything will depend on your need and the complex of the project.  

XP or Extreme programming is not sitting down to “code” without stopping, is an agile methodology with values and practices that will help you to achieve success in your project. Do not be afraid of the methodology by what others tell you, know a little more and draw your conclusions, welcome the change and have the courage to carry it out.