como un miniproyecto de no más de un mes (ciclos de ejecución muy cortos -entre una y cuatro semanas), cuyo objetivo es conseguir un incremento de valor en el producto que estamos construyendo. Una vez que se tienen las historias de usuario, el equipo puede descomponerlas en subtareas que van acometiendo y que pueden visualizarse en JIRA en una pizarra. Una vez que todas las subtareas de una historia de usuario estén cerradas, la historia podrá resolverse y pasar a ser validada. Las historias de usuario deben tener siempre una entidad origen. Lo habitual es que sea una mejora, pero también puede ser una incidencia, una no conformidad o un bug (son los errores detectados por la Oficina de Calidad como se ve más tarde). Es importante destacar que sólo pueden tener una entidad origen en el caso de que ésta sea una mejora, una incidencia o una no conformidad. En el caso de los bugs, es posible que una historia de usuario tenga como origen más de uno, siempre teniendo en cuenta que la mejora origen de todos los bugs que se agrupan en una misma HU debe ser la misma. Es decir: HU<- BUG<-Test<-HU<-MEJORA o HU<- BUG<-Test<-HU<-NC<-MEJORA La MEJORA de la que parte todo debe ser la misma. Si una historia de usuario no tiene identificada su entidad origen no podrá incluirse en un sprint. Por otra parte, las historias de usuario se clasifican en los siguientes tipos: - No definida
- Funcional
- Técnica
- Bugs y desuda técnica
- Operación
Cuando se crea una historia de usuario siempre por defecto el tipo es no "No definida". Mientras no se clasifique la historia de usuario no podrá ser incluida en un sprint. Es posible establecer relaciones de dependencia en historias de usuario. Image Modified
Pulsando dos veces en Incidencia Jira Image Modified Podrán incluirse todo tipo de enlaces entre la historia de usuario y cualquier registro de Jira, teniendo en cuenta la restricción en la relación "originada por" indicada anteriormente. Esta funcionalidad podrá mostrarse en las pizarras (incluyendo en la configuración de las mismas que sea visible el campo DEPENDENCIAS). Puede mostrarse en el trabajo pendiente, en las historias en el sprint activo o en ambos.
Image Modified
Image Modified
La gestión de los costes de un sprint se hace mediante una especie de proyecto (en JIRA la entidad se llama subproyecto ágil) al que se da un horizonte temporal y en el que se van sumando los costes de los diferentes sprints creados en el tiempo de ejecución del proyecto. La gestión de costes en un sprint se controla mediante la creación en la reunión de planning de una OTAgil, que es una orden de trabajo de crédito disponible en la que se controlan los costes del equipo durante el tiempo que dure el sprint y que debe estar relacionada con el subproyecto en el que se quieran controlar los costes de ese equipo. En el manual de JIRA podrás encontrar una guía detallada del las historias de usuario, de las subtareas ágiles y de los errores técnicos así como de la configuración de las pizarras. Es importante destacar que cuando se crea un sprint y a lo largo de su duración pueden informarse propiedades del mismo, por parte del Responsable de producto, Responsable funcional y del Proveedor Image Modified
Las propiedades que pueden informarse son: - Capacidad: número entero entre 1 y 100
- Satisfacción DT: número entero entre 1 y 10 que representa la satisfacción del equipo de desarrollo
- Satisfacción PO: número entero entre 1 y 10 que representa la satisfacción del product owner
- Satisfacción STIC: número entero entre 1 y 10 que representa la satisfacción del Responsable de producto
En la configuración de la pizarra aparecerá una sección denominada Evolución sprints donde aparecerán los datos de las propiedades de los sprints que hayan sido informados.
En la metodología ágil se contempla el papel de la Oficina de Calidad en cada uno de los sprints. Normalmente el miembro de OCA que está trabajando con el equipo ágil realiza una serie de tareas que van destinadas a verificar todo lo que conlleva la entrega que se hace en el sprint. Este trabajo se modela en el Servicio de verificación de sprint (SVS). A través de este servicio, el equipo de la Oficina de Calidad realiza una labor de acompañamiento y detección temprana de errores. El objetivo es agilizar la solución a los posibles problemas detectados en fase de desarrollo, y ofrecer una una visión del estado en que se encuentra el proyecto en cada etapa, para facilitar el aseguramiento de un producto de calidad que logre la satisfacción del usuario final. El alcance de este servicio incluye: - Verificación del repositorio de código.
- Verificación y validación de la calidad estática de código.
- Revisión de las pruebas (.feature).
- Organización del plan de pruebas para su ejecución en el entorno de pruebas.
- Verificación del cumplimiento del DoR.
- Verificación del cumplimiento del DoD.
Entradas: - Taller concepción del producto (al inicio del proyecto en esta metodología)
- Entrevistas y acuerdos en la STIC (al inicio del proyecto en esta metodología)
- Manual usuario
- Historias de usuario
- Casos de prueba en archivos .feature
- Código en el repositorio correspondiente
- Entornos para las pruebas
Salidas: - Informe de verificación.
- Alta en JIRA de los Bugs detectados durante la ejecución de las pruebas en el entorno de desarrollo.
Los bugs o fallos encontrados por la Oficina de Calidad en un sprint deben ser analizados por el proveedor y en caso de que realmente se trate de fallos deberán ser corregidos. Para ello deberán crearse historias de usuario originadas por esos bugs (siempre con la misma mejora origen), de manera que cuando dichas historias sean validadas, deberán validarse por la Ofician de Calidad que la resolución de los bugs ha sido satisfactoria. Puedes encontrar aquí el ciclo de vida de un bug.
Cuando es necesario hacer un despliegue, es necesario crear una versión como las que se crean en la metodología en cascada. En cuanto a la Gestión del Conocimiento en este tipo de proyectos, se hace de manera ligeramente diferente. En el espacio de cada producto debe haber una página denominada "Metodología ágil" en la que se debe crear una pagina con el "Definition of Done" y "Definition of Ready" siguiendo las plantillas definidas. Además por cada sprint que se cree, será necesario crear una página con la planificación del sprint (plantilla Sprint Planning) y otra de retrospectiva (con la plantilla del mismo nombre) el día que se haga la review. Es aconsejable usar una macro de calendario de CONFLUENCE para controlar la disponibilidad del equipo durante el sprint (vacaciones, formación, dedicaciones parciales, etc.) Dentro del espacio se deja libertad al equipo para ir colocando prototipos o documentación funcional relativa a las historias de usuario. |