Diferencia entre revisiones de «Divide Story»
De productpatterns_wiki
| Línea 5: | Línea 5: | ||
}} | }} | ||
<p style="text-align: right;"><span style="font-size: x-small;">[[Archivo:Spanish.jpg|16px|Spanish.jpg]][[Dividir Historia | Español]]</span></p> | <p style="text-align: right;"><span style="font-size: x-small;">[[Archivo:Spanish.jpg|16px|Spanish.jpg]][[Dividir Historia | Español]]</span></p> | ||
| − | <div style="border: 1px solid rgb(204, 204, 204); padding: 10px; width: | + | <div style="border: 1px solid rgb(204, 204, 204); padding: 10px; width: 450px; float: right; background-color: rgb(239, 239, 239); margin-left: 20px; min-height: 500px;"> |
<div id="section_1"> | <div id="section_1"> | ||
Revisión de 02:01 15 abr 2015
Entries
- Business Story
Entries
- Business Story
Solution
Process
Development time
- To acquire the necessary knowledge to develop the software product:
- To create the Product Pattern: 15 minutes.
- To apply the Product Pattern:
Explanatory video
- None
Related Patterns
Quality Controllers
- None
Templates
Historias_Negocio.doc
Examples
- None
Support Tools
- It will be necessary a text editor such as OpenOffice Writer o Microsoft Word.
- As well as a tool Visual Paradigm for UMLfor performing the exposed diagrams.
Initial Context
This product can be used on any project in which once written the story and delivered to the area of development, they can not estimate it due to it is very complex to be treated unitarily, which should be divided into smaller ones.
The user story should be able to be scheduled at a time between one and three weeks. If the estimate is greater than three weeks, should be divided into two or more story. If less than a week, should be combined with another record.
Result Context
A new set of records (2 to n) for each initial story is obtained that could not be estimated by the technology area.
Problem
The business area should be able to split the stories no estimated in a number of specific stories than can be reflected unitarily. They should be as simple as possible.
Restrictions (Forces)
- 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.
Roles
- Area of business Users(2 at most)
Lessons Learned
- Stories should be as atomic as possible, if not it should be returned by the technology area. A feature story.
- To establish meetings which always involved the business area along with the development team (developers included).
Capability Level
- Not applicable.
Basic Knowledge and Skills
Knowledge
- 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.
Abilities
- 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.
Information Resources
- Á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.
