1.2. Proceso de Desarrollo Extremo

[[Nombre de la institución]]
Proceso de Desarrollo Extremo
[[fecha]]
Versión 1.0
[[Nombre del proyecto]]
1
1.1
Introducción
Propósito del documento
El presente documento define y describe la implementación del proceso de desarrollo extremo
dentro de la [[institución]], con el propósito de apoyar a los responsables, al equipo de desarrollo
y a los clientes. La herramienta define solo de forma superficial el proceso, para un mayor detalle
se recomienda ver: Proceso_Desarrollo_Extremo.doc
2
Descripción del proceso
<Descripción global del proceso de desarrollo extremo>
El proceso de desarrollo extremo presentado en el documento “Introducción a la Programación
Extrema”, distingue dentro de las fases mencionadas cuatro grandes actividades como lo son: la
planificación, el diseño, las pruebas y el desarrollo, cada una de las prácticas se encuentra inserta
en alguna de estas fases.
El proceso comienza cuando el cliente redacta las historias de usuario, el desarrollador las estima y
se realiza la priorización de ellas por parte de los clientes y de los desarrolladores, los primeros
priorizan por valor mientras que los segundos lo hacen según el grado de riesgo de la
implementación; si una historia no puede ser estimada ésta debe ser dividida por los clientes.
Los desarrolladores se encargan de fijar la velocidad para cada historia y los clientes
posteriormente fijaran el alcance de cada liberación, una vez que ocurre esto se escogen las
historias que serán implementadas y se comienza con la iteración para la liberación, esto es, se
realiza el diseño, la codificación y se ejecutan los casos de prueba (lo anterior se debe realizar
tantas veces como historias de usuario existan para satisfacer los requerimientos del cliente). En
esta etapa se lleva a cabo una integración continua y la codificación es desarrollada por pares de
programadores teniendo siempre en cuenta que el código es de todos, por lo cuál es de suma
importancia tener siempre presente la estandarización del código.
Cada una de las pequeñas liberaciones debe tener la aprobación del cliente, si éste no las aprueba
deben realizarse las modificaciones respectivas, para terminar se entrega la liberación final.
3
Fases
<Descripción de las fases del proceso de desarrollo extremo>
A continuación se describen las fases del proceso de desarrollo extremo de acuerdo a las prácticas
que cada fase toca, los objetivos, los criterios de entrada o salida y las actividades propias de cada
una. Es importante mencionar que ellas no se construyen bajo el paradigma secuencial, razón por
[[Nombre del Proyecto]]
Página 1 de 5
[[Nombre de la institución]]
Proceso de Desarrollo Extremo
Versión 1.0
[[Autor]]
la cuál algunas actividades deben ser realizadas al comienzo aún cuando forman parte de alguna
fase como el desarrollo.
3.1
Planificación
Las prácticas que tocan esta fase son:


El Juego de la Planificación
Pequeñas Liberaciones
3.1.1


Criterios de Entrada
Haber aprobado la implantación de la programación extrema como metodología en el
equipo de desarrollo para un proyecto particular.
El equipo de desarrollo debe designar los roles a cada uno de los miembros de acuerdo a
lo señalado en el documento: “Introducción a la Programación Extrema”.
3.1.2
Actividades
1. El cliente redacta las historias de usuario.
2. Los desarrolladores estiman las historias de usuario.
3. Los clientes deben dividir las historias de usuario.
4. Se priorizan las historias de usuario.
5. Los desarrolladores fijan la velocidad del proyecto.
6. Los clientes fijan el alcance del proyecto.
7. Desarrollar el plan de entregas.
8. Realizar seguimiento al plan de entregas.
9. Realizar reuniones de planificación para la liberación.
10. Los desarrolladores definen las tareas de programación.
11. Desarrollar plan de liberación.
12. Realizar seguimiento al plan de liberación.
13. El cliente aprueba la liberación.
3.1.3





Criterios de Salida
Tener un plan de entregas que incluya las historias de usuario que serán desarrolladas en
la próxima entrega.
Aceptar el seguimiento del plan de entregas.
Tener un plan de liberación que incluye una lista de las tareas de programación a
implementar.
Aceptar el seguimiento del plan de liberación.
Aceptar las liberaciones por parte del cliente.
[[Nombre del Proyecto]]
[[Nombre de la institución]]
Página 2 de 5
Proceso de Desarrollo Extremo
Versión 1.0
3.2
[[Autor]]
Diseño
Las prácticas que la tocan son:


Metáfora
Diseño Simple
3.2.1


Criterios de Entrada
El gestor y el entrenador autorizan comenzar la fase de diseño.
El plan de entregas y de liberación ha sido aprobado.
3.2.2
Actividades
En la programación extrema las tareas de diseño se realizan a lo largo de todo el proyecto y a
distintos niveles. Por ello, es normal utilizar tanto sesiones de diseño pequeñas en las que
interviene una pareja de desarrolladores, como sesiones generales donde interviene todo el
equipo. Es necesario advertir que conservar un diseño simple a lo largo de todo el desarrollo no es
una tarea trivial.
Es necesario dejar en claro que en programación extrema los desarrolladores deben realizar de
forma simultánea diseño y codificación, generando una elevada interdependencia entre ambos
tipos de tareas.
1. Buscar una metáfora efectiva.
2. Implementar tarjetas CRC en sesiones de diseño.
3. Crear soluciones puntuales.
4. No agregar funcionalidad en las primeras etapas.
3.2.3


3.3
Criterios de Salida
Metáfora que perfilará el sistema.
Diseño simple del sistema, a través de las tarjetas CRC y las soluciones puntuales.
Pruebas
La práctica que toca esta fase es:

Pruebas automatizadas.
3.3.1




Criterios de Entrada
Plan de entregas que incluya las historias de usuario que serán desarrolladas en la
próxima entrega.
Plan de liberación que incluye una lista de las tareas de programación a implementar.
Cada historia de usuario escrita por el cliente debe estar acompañada de un conjunto de
escenarios que verifiquen que ésta ha sido implementada correctamente.
Diseño simple del sistema que permitirá a los desarrolladores pensar en la codificación.
[[Nombre del Proyecto]]
[[Nombre de la institución]]
Página 3 de 5
Proceso de Desarrollo Extremo
Versión 1.0
3.3.2
[[Autor]]
Actividades
Las actividades de esta fase se pueden clasificar en dos, las pruebas de unidad y las pruebas de
aceptación, aún cuando para llevar a cabo algunas de ellas (por ejemplo la verificación) se
necesitan de las actividades que serán presentadas en el punto 3.4.3, se muestran a continuación
para darle un formato específico a lo que es la fase como conjunto.
Pruebas de unidad.
1. Escribir e implementar las pruebas unitarias.
2. Verificar que las pruebas son pasadas con éxito.
Pruebas de aceptación.
1. Escribir las pruebas de aceptación.
2. Implementar las pruebas de aceptación.
3. Verificar que la historia de usuario está completa.
3.3.3




3.4
Criterios de Salida
Casos de pruebas, para las pruebas unitarias.
Pruebas de aceptación con sus respectivas historias de usuarios.
Aprobación de las pruebas unitarias. (Se espera que se obtenga una vez desarrollado el
código)
Aprobación de las pruebas de aceptación. (Se espera que se obtenga una vez desarrollado
el código)
Desarrollo
Las prácticas que tocan esta fase son:







Programación por Pares.
Refactoring.
Propiedad Colectiva del Código.
Estándares de Codificación.
Integración Continua.
Cuarenta Horas Semanales.
Cliente en el Lugar.
3.4.1






Criterios de Entrada
Plan de entregas que incluya las historias de usuario que serán desarrolladas en la
próxima entrega.
Plan de liberación que incluye una lista de las tareas de programación a implementar.
Metáfora que perfilará el sistema.
Casos de pruebas, para las pruebas unitarias.
Pruebas de aceptación con sus respectivas historias de usuarios.
Diseño simple del sistema que permitirá a los desarrolladores pensar en la codificación.
3.4.2
[[Nombre del Proyecto]]
[[Nombre de la institución]]
Actividades
Página 4 de 5
Proceso de Desarrollo Extremo
Versión 1.0
[[Autor]]
Muchas de las actividades que serán nombradas a continuación no tienen un orden específico
dado el carácter evolutivo de la programación extrema, por lo tanto la mayoría deben llevarse a
cabo de forma frecuente durante cada liberación de forma cíclica. Más que actividades ellas deben
ser tratadas como convenciones de la XP, ya que de su utilización depende el éxito de la
metodología.
1. Buscar estándares de codificación.
2. Realizar reuniones al comienzo de cada día.
3. Desarrollar la unidad de pruebas primero.
4. Todo el código debe ser escrito por un par de programadores.
5. Llevar a cabo el proceso de refactoring.
6. Integrar frecuentemente.
7. Todo el código es propiedad de todos.
8. Optimizar al final.
9. No trabajar más de cuarenta horas semanales.
10. El cliente debe estar siempre disponible.
3.4.3
Criterios de Salida
Como primera etapa se espera como criterio de salida que todas las convenciones presentadas en
esta fase se cumplan a cabalidad, aún cuando puede existir el caso que algo falle para un proyecto
en particular y deba ser cambiado, lo cuál debe ser comunicado a la [[institución]] y a todos los
miembros del equipo.
Se espera que al finalizar esta fase el sistema ya se encuentre al cien por ciento por lo tanto los
criterios de salida específicos serían:



4
Aprobación del sistema por parte del Gestor y del Entrenador.
Entrega del sistema al cliente.
Aprobación del sistema por parte del cliente.
Referencias
<Lista bibliográfica utilizada para la definición del proceso de desarrollo extremo. Es recomendable
ser lo más específico posible para evitar confusiones posteriores>
[[Nombre del Proyecto]]
[[Nombre de la institución]]
Página 5 de 5