This product can be used in any project in which the process of collecting the functional requirements of the business is done receiving written stories, as atomic as possible, from the business. In addition, it is used in projects where requirements are changing and we must deliver the project result in a date that involves high risk to achieve itself.
A set of stories will be detained, written by the business, which will be described, in the most possible atomic manner, the functionalities of the application to be developed.
The user stories represent a brief description of system behavior, customer terminology used without technical language, one is done for each main feature of the system. They are used to estimate time and plan releases, replacing a large requirements document and preside over the creation of functional testing.
The technological area should be able to get that the business deliver the most simple and atomic stories possible.
- 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 must be set up meetings between business and technology areas where communication is smooth and has mutual trust. The workspace should be organized according to the guidelines of the methodology. It is important to keep food and drink to ensure meetings are relaxed.
- Users area of business (2 at most)
- Developers (2-12)
- Director of Development Project (1)
- Trainer (1)
- Controller (1)
Note: The trainer and driver can be the same person.
Meetings should be short and must be directed by a preparer technology area. It should be enjoyable meeting with food, drink, anecdotes, etc .... The business user should be entirely devoted to the project. To establish meetings which always involved the business area along with the development team (developers included).
- 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.