This product can be used in projects where the technology area must notify the business area the speed with which the development team can schedule the ideal engineering time per month, in order to enable the latter to establish the scope of a particular version of the application to be developed.
The speed is set as the user stories completed at each iteration by the team.
The business area knows the number of stories points (a point of story is a week in the estimation of each story) that will be delivered at the end of the 3 highest estimates story weeks.
- Characteristics of organizations: This pattern can be used in existing projects in any company.
- System Type to develop This product can be used in projects in which user requirements are changing.
- Type of Customer: It must exist or be achieved, the target area development business being involved in achieving it.
- Heuristics of use:: It should be obtained as long as the business area requires this data to establish a scope of a version of the application to be developed.
- The rate serves to the area of technology to limit requests business area in establishing the scope of a release. If speed is not set correctly the development team can not meet deadlines. The best to set the speed is to assign each programmer a point of story, so if they are 6 programmers, the speed will be 6 points of story each week. If the speed is multiplied by the 3 weeks of estimation the number of points maximun for setting up the story of a version field is obtained.
- Input document is an internal document for development. It should contain a table with the classification of business records as a function of value and risk. In this document the speed is recorded.
- The output document must have the filling velocity field.
- Knowledge of coding standard that defines the shared code ownership and the rules for writing and documenting code and communication between different pieces of code developed by different teams. Programmers have to follow the so that the code in the system look like if it had been written by one person.
- Knowledge of the common vision of how the program works in which the activities take place.
- Ability to work in group. All on an XP computer contribute in any way they can.
- Predicting what will be completed by the deadline, and determining what to do next.
- Programming capability in pairs. Besides to generate better code and tests, used to communicate knowledge through teams.
- Álvarez, José R. y Arias Manuel. Método Extreme programming.Recuperado el 2010-03-05 de http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node61.html
- Anaya Villegas, Adrian. A proposito de programación extrema XP(extreme Programming).Recuperado el 2010-02-10 de http://www.monografias.com
- Beck, K.(2000), Una explicación de la programación extrema. Aceptar el cambio. Ed. Addisson Wesley.
- De Seta, Leonardo. Una introducción a Extreme Programming.Recuperado el 2010-03-02 de http://www.dosideas.com/noticias/metodologias/822-una-introduccion-a-extreme-programming.html
- Extreme Programming: A gentle introduction. Recuperado el 2010-03-15 de http://www.extremeprogramming.org/
- Joskowicz, José. Reglas y prácticas en Xtreme Programming. Recuperado el 2010-03-15 de http://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf
- Letelier, Patricio y Panadés Mª Carmen. Metodologías Ágiles en el desarrollo de software: extreme programming. Recuperado el 2010-03-15 de http://www.willydev.net/descargas/masyxp.pdf
- Newkirk, James y Martin, Robert C.(2001), La programación Extrema en la Práctica.Ed Addisson Wesley.