Formato tickets¶

Los tickets pueden estar divididos en 4 tipos:

• Nuevas funcionaliades. Historias de usuario.
• Correcciones. Historias de usuario.
• Mejoras. Historias de usuario.
• Errores.
• Refactorización.

Formato general de los tickets¶

El flujo de cada ticket sera el siguiente:

• Borrador. Descrito sin adecuarse a un formato.
• Definido. Descrito conforme a la la definición de formato de este documento.
• Dimensionado. Calculado el tiempo estimado que supondrá
• Planificado. Se encuentra incluido en una version.
• En proceso. Se ha realizado un determinado porcentaeje o se han empleado una serie de horas en el mismo.
• Realizado. Completado conforme a lo definido.
• Revisado. Ver a continuacion duda.
• Cerrado. Ver a continuacion duda

Duda sobre revision y cierre: 

La revision se plantea para los procesos de chequeo por parte del usuario al finalizar el sprint.
En ese momento no resulta claro si la posibilidad de abrir un ticket es interesante. 
Al asginarle una nueva version, no quedaria reflejado en el historico de la version.
Actualmente se ve como mejor opción abrir un nuevo ticket como mejora o revision aunque se referencia al ticket cerrado.

El contenido de cada ticket estará relacionado con su tipologia, pero ademas de esto tendrá los siguientes campos:

• Tiempo estimado.
• Horas empleadas.
• Fecha inicio. (No es muy necesaria)
• Fecha fin. (No es muy necesaria)

NOTA: Estos datos se pueden utilizar en futuros procesos de revision de las metodologias, planificacion o metricas.

Nuevas funcionalidades, Correcciones, Mejoras: Historias de usuario.¶

Titulo del ticket:

El titulo del ticket puede ser el propio objetivo del ticket o historia de usuario (como se detalla a continuación) o en caso de ser muy largo una reducción del mismo.

Si se trata de una historia de usuario asociada a una funcionalidad se incluida al final y entre paréntesis la referencia al código de la funcionalidad.
También se incluirá dicho código al tratarse de una corrección o mejora que se vincula a un ticket de nueva funcionalidad.

Objetivo o historias de uusario:

Se corresponden con historias de usuario. La historia de usuario se escriben con el siguiente formato: "Como xxx, quiero hacer yyy con el objetivo de zzz", donde, xxx es el tipo de Usuario (quien), yyy es lo que el sistema debe permitir realizar (el qué) y zzz es el beneficio o valor buscado (el por qué).

Condiciones:

Las condiciones de satisfacción de los objetivos se ponen en forma de pruebas de aceptación que se realizarán, indicando cómo debe comportarse el sistema (o BDD, Behaviour Driven Development) con el formato "Dado aaa, cuando se produzca bbb, entonces ccc", donde aaa es la situación en la que se encuentra el sistema, bbb es un evento que lo hará cambiar y ccc es el resultado.

Errores.¶

Titulo:

Se recomienda escribir el titulo después de la descripción.

Descripción

Es necesario que detalle:

• Donde: Seccion / menu / submenu.
• Con que informacion (Dado): Se podrá especificar al estar en produccion datos especificos de (proyecto concreto, dato concreto,..etc), o hacer una exposición generica.
• Cuando: Accion en la que se produce el error.
• Entonces: forma del error: error de la aplicacion (se puede/debe incluir un pantallazo), accion o resultado no correcto.

Al ser asignado deberá el tecnico incluira un comentario en forma de Condicion o condiciones que serán recogidas en los tests correspondientes.

Refactorizaciones.¶

Titulo:

Se recomienda escribir el titulo después de la descripción. Debe recoger el objetivo concreto del proceso de refactorización.

Descripción:

Debe incluir los siguientes campos:

Situación actual.
Problema difcultad u objetivo que se pretende.
Solución.