This product can be used in any project for workload of programmers, decisions must be made to balance the workload on the team.
The controller, based on the rolling established by each developer, and the result reflected in the status report with the progress story, assess the situation and recommend decisions to ensure the achievement of the project on schedule.
- 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::If you need urgent application or dispose of some of their funcionalidades.
- The controller will reflect in the progress report the recommendation for the successful development of the project in case the team is overcommitted. The recommendations include:
- Reduce the scope of some tasks.
- Ask the customer to reduce the scope of some story.
- Remove non-essential tasks.
- Programmers who obtain more and better aid and as a last resort.
- Ask the customer to delay some story to a later iteration.
- Input document Story Tasks version X contains tasks related with the technical field stories of that version. Both the field responsible for performing each task such as the time spent on task and time remaining to complete it, have to be filled.
- Input document Story Task version X Developer Y is exclusive to the developer in question and contains the tasks that have been assigned. The document header is filled with the rolling established by the developer in question.
- The output document Situation report contains recommendations to restore balance to the team in case of delays by overwork.
- The development of the status report is based on balancing each programmer and progress of each in the implementation of the tasks that were assigned to them.
- 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.