Metodología de Trabajo

Metodología de Trabajo

Para el desarrollo de los proyectos se aplicará la metodología ágil Scrum.

Scrum

Scrum es un proceso que a través de la aplicación de un conjunto de buenas prácticas, para trabajar de manera colaborativa, en equipo, permite realizar entregas parciales y regulares del producto, priorizadas por el beneficio que aportan a los stakeholders.

Buenas prácticas

Se adoptarán las siguientes prácticas tomando como base el proceso de Scrum y, teniendo en cuenta que los proyectos se desarrollan bajo GitHub, se usarán las capacidades proporcionadas por la herramienta para el desarrollo de dicho proceso.

Sprint

El proyecto se ejecutará en ciclos o iteraciones de 2 semanas (15 días), comenzando un lunes y finalizando el viernes de la semana siguiente. A continuación, se detalla cómo se van a representar los sprints en GitHub.

Milestones

A través de los milestones se van a definir los sprints a desarrollarse. Cada proyecto/producto contará con los siguientes milestones:

• Backlog: milestone único que contendrá las issues correspondientes al Product Backlog, que serán desarrolladas en el transcurso de los sprint, y también contendrá toda issue que surja durante dichos sprints.
• Sprint [fecha_inicio-fecha_fin]: milestone que contendrá las issues correspondientes al Sprint Backlog y que serán desarrolladas en el transcurso del sprint actual. Existirá un milestone por cada sprint, el cual se creará al inicio de la iteración y se cerrará al finalizar la misma.

Projects

A través de los projects se va a controlar el avance del sprint actual. Cada proyecto/producto contará con un project por cada nuevo sprint, cuyo nombre se definirá según el siguiente formato: Sprint [fecha_inicio-fecha_fin] Cada project contará con las siguientes columnas:

• To Do: toda nueva issue que se agrega al project, automáticamente se muestra la tarjeta correspondiente en esta columna. Tener en cuenta que el project corresponde a un sprint en particular.
• In progress: cuando un developer tome una issue, antes de comenzar a trabajar debe mover la tarjeta correspondiente a esta columna.
• Ready for review: cuando la issue esté terminada, y su Pull Request asociado esté listo para ser revisado, la issue se debe mover a esta columna.
• Ready for deploy: una vez aprobado el Pull Requests, y probada la funcionalidad por el Analista Funcional, la issue se debe mover a esta columna.
• Done: una vez llevada a producción, la issue se cierra, y automáticamente se mueve la tarjeta correspondiente a esta columna.

Planificación del Sprint

El primer día del sprint, se realiza la planificación del mismo en dos etapas:

• Se deberán seleccionar los requerimientos más prioritarios, según la valoración del cliente, los cuales debe comprometerse a completar el equipo durante el sprint.
• El equipo deberá elaborar la lista de issues a desarrollar para cubrir los requerimientos, también deberán estimarlas y autoasignárselas. Al listado de issues se sumarán aquellas correspondientes al último sprint que no se hayan cerrado, y las contenidas en el Backlog que sea necesario agregar.

El listado de issues obtenido, será cargado al repositorio de GitHub, correspondiente al proyecto/producto, por el PM.

Ejecución del Sprint

Se realizarán Dailies de 5-15 minutos, durante las cuales, cada miembro del equipo deberá responder las siguientes preguntas:

• ¿Qué he hecho desde la última daily?
• ¿Qué voy a hacer a partir de ahora?
• ¿Qué impedimentos tengo o voy a tener?

Dichas dailies se realizarán, inicialmente, los días lunes, miércoles y viernes, y cuyo horario será sincronizado por el PM con los developers correspondientes.

Revisión del Sprint

El último día de la iteración se realiza la reunión de revisión del sprint. Tiene dos partes:

• El equipo presenta al cliente los requisitos completados en la iteración, si así se establece con el mismo. En función de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias, refinando los requerimientos.
• El equipo realiza una retrospectiva, analizando cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad.

Creación de issues

Se debe colocar el nombre más significativo posible de la tarea, además de una descripción adecuada de ser necesario para la correcta interpretación de la misma, sin dejar posibles ambigüedades en su entendimiento.

Para cada nueva issue se debe indicar además:

• Assignees: en lo posible, tratar siempre de asignar un único developer.
• Labels: indicar según corresponda, estado, prioridad, tamaño, etc.
• Projects: asignar el project correspondiente al sprint actual, o no indicar nada si se trata de una issue que se desarrollará en sprints posteriores.
• Milestone: asignar el milestone correspondiente al sprint actual, o indicar el milestone Backlog si la issue se desarrollará en sprints posteriores.

Labels

Los labels permitirán indicar algunos aspectos de la issue que darán una visualización rápida y clara de la misma, los mismos a considerar de forma general para todo proyecto/producto son:

• Estado de progreso de la issue:
  • status:in progress
  • status:review
  • status:deploy
• Prioridad de la issue:
  • priority:low
  • priority:mid
  • priority:high.
• Tamaño de la issue:
  • size:1
  • size:2
  • size:3
  • size:5
  • size:8
  • size:13
  • size:20
  • size:40
  • size:100
• Tipo de issue:
  • type:bug
  • type:enhancement
  • type:fix

Puede que en cada proyecto/producto existan labels propios definidos dentro del mismo.

Creación de Pull Requests

Se deberá crear el PR con el número de la issue y luego el nombre de la misma: 1800 Fix error backend cursos

En la descripción hay que tener en cuenta lo siguiente:

• Indicar closes #[n° de la issue] para que se referencie a la issue correspondiente.
• Darse una breve descripción de lo que se está resolviendo.
• Realizar lista de ítems a considerar: en caso de ser necesario la instalación de un paquete, migraciones, reinicio de colas o alguna condición particular debe de dejarse anotado para que el encargado de deploy no tenga problemas al realizarlo.
• En el caso particular de frontend, mostrar que es lo que se ha realizado con algunas capturas.
• En caso de que necesite que se pruebe de alguna manera en particular por el reviewer dejar marcado en ítems al igual que los pedidos anteriores.

Para cada nueva PR se debe indicar además:

• Reviewers: se debe tratar de asignar un único reviewer, pero si amerita por ser muy grande o por involucrar áreas diferentes en las que se considera mejor asignar 2, por ejemplo backend/frontend, aclarar el por qué de la asignación de más recursos a ese y qué le corresponde a cada uno, para que quede claro qué debe hacer cada uno.

  Ejemplo:
  @joseperez revisión de frontend ReactJs y Sass
  @solgomez revisión de backend php y sql

• Assignees

• Labels: indicar según corresponda.

  • ready for review: en caso de que ya se pueda revisar y se asignen los recursos reviewers/assignees.
  • ready for deploy: en caso que todos los reviewers involucrados hayan dado el Approved al PR, la funcionalidad debe ser probada por el Analista Funcional, quien colocará esta etiqueta si está listo para realizar el deploy a producción o stage, en caso de existir el entorno de pruebas.

• Projects: no es necesario indicarlo, de hacerlo no se incluirá en el tablero del project correspondiente

• Milestones: se debe indicar el mismo milestone de la issue asociada.