Solicitud de nueva funcionalidad/cambios

Si necesitas que en la aplicación se implemente una nueva funcionalidad o una alteración en una funcionalidad ya existente, a continuación se indican los puntos a tener en cuenta.

 Premisas

1. Será únicamente a través de un documento que se puedan solicitar nuevas funcionalidades. Se puede utilizar cualquier plantilla estándar de petición de requisitos o bien específica del cliente.

2. Cuando el equipo de Lleego realice el análisis, si se requiere se podrá solicitar al cliente una reunión para aclarar dudas estas reuniones no serán para hablar de la funcionalidad sino únicamente para aclarar dudas puntuales.

3. Si el documento no reúne toda la información necesaria, se rechazará. Para llevar a cabo un análisis correcto de la tarea y su posterior implementación se necesitan peticiones con alcances de funcionalidad cerrados y claros.

4. Una vez realizado el desarrollo por Lleego, se informará al cliente a través del ticket relacionado para que realice las pruebas de UAT (user acceptance test) en staging/producción , el cliente deberá de dar el visto bueno al desarrollo implementado, una vez dado el visto bueno, se dará por entregada la tarea.

5. Si pasado un tiempo, se vuelve a solicitar cambios relacionado con algo ya implementado, se deberá abrir como otra petición, el UAT debe servir para dar por válido el desarrollo solicitado y cualquier error sobre el desarrollo implementado se tratará propiamente como un error.

6. En los análisis, se incluirá una estimación en horas que conllevará abordar la tarea, en ocasiones puede ocurrir que en el momento de llevar a cabo la tarea se detecten inconvenientes, bloqueos, complicaciones, … que puedan provocar desviaciones de tiempo, esto se informaría en todo caso al cliente.

 Tiempos de trabajo

Las tareas se llevarán a cabo en los denominados “sprints”, ciclos de trabajo que duran 2 semanas por norma general .

→ El análisis de una petición de desarrollo implica ciertas horas de trabajo, por lo que llevar este análisis a cabo tiene que ser incluido en un sprint, esto se acordará con el cliente en función de prioridad.

→ Dependiendo de la funcionalidad, esta podrá abordarse en un sprint o más de uno, si es una tarea “grande” o asumible dentro de un sprint, también dependerá de la capacidad de Lleego en tal sprint. En cualquier caso esta información siempre será compartida con el cliente para que pueda hacer su planificación interna.

→ Las peticiones se planificarán a 2 sprints vista. Esto quiere decir:

lo acordado hoy día 6 de mayo (viernes) se abordará en el sprint 2

• lunes 9 de mayo comienzo sprint 1 - finalización 20 de mayo

• lunes 23 de mayo comienzo sprint 2 - finalización 3 de junio (subida a producción 8 de junio)

Por lo que las reuniones entre Lleego y cliente se efectuarán cada 2 semanas, en donde en una reunión el cliente informa a Lleego de las tareas priorizadas para el sprint 2.

En esta reunión se hará una retrospectiva del sprint 1 con las tareas entregadas, el detalle siempre se indicará en la tarea.

→ Una vez analizada la tarea y con la aprobación del cliente de presupuesto y el trabajo a abordar, se comenzará a abordar en el siguiente sprint por norma general.

→ Lleego se guarda el derecho de realizar un “freeze”, congelar durante el sprint peticiones de desarrollos para realizar tareas internas de mantenimiento. Se informará al cliente en cualquier caso.

→ En el caso de solicitar un Hotfix (petición de cambio a abordar en el mismo día o al día siguiente), tendrá que ser justificado por el cliente el motivo de la urgencia. Los viernes por norma general no se realizan hotfixes.

→ Una vez comenzado un sprint (sprint 1) no se podrá solicitar inclusión de una nueva tarea en el mismo (sprint 1). Tendrá que esperar al siguiente (sprint 2)