Guía

Proceso de trabajo para desarrolladores y uso de herramienta Monda

2023
 Guía
Proceso de entrega de requerimientos y uso de herramienta
Monday
Tabla de Contenido
Aspectos Generales.....................................................................................................................3
Metodología y herramienta de trabajo.................................................................................3
Proceso de asignación de requerimientos al desarrollador...........................................3
Fecha máxima de entrega del reporte de los requerimientos........................................3
Horarios de trabajo...................................................................................................................3
Medios de comunicación con los coordinadores de proyectos de Portalnet............4
Proceso de reporte de horas por requerimiento...............................................................4
Proceso en Monday para reportes de requerimientos.........................................................4
Descripción de su tablero en Monday..................................................................................4
Pasos para crear reportes sobre actualizaciones del requerimiento...........................6
Registrar avance del requerimiento......................................................................................7
Cronograma de atención de requerimientos......................................................................7
Requerimientos permanentes del negocio (RedMotors).....................................................7
Mejores prácticas: Requerimientos permanentes de Portalnet.........................................8
Aspectos Generales
Metodología y herramienta de trabajo
 La metodología para la atención de requerimientos es por medio de sprints, estos
son de una semana.
 Una vez a la semana se realizará una reunión de seguimiento de 10 a 15 minutos
aproximadamente con el desarrollador.
 La herramienta de trabajo para el seguimiento del avance de los requerimientos es
Monday, en esta herramienta cada desarrollador tendrá un tablero donde el
coordinador de proyectos creará los grupos correspondientes a los sprints, las
tareas que tiene asignadas y allí deberá crear el reporte tanto de avance
(dificultades, impedimentos) como de la entrega final (reportar evidencia,
comentarios y horas)

Proceso de asignación de requerimientos al desarrollador

 El lunes de cada semana se realiza una sesión de planning para crear el sprint de
la semana.
 El martes de cada semana se citará a reunión a cada desarrollador para proceder
a la entrega de los requerimientos que le corresponden del sprint, esto es una
presentación oral de lo que se busca lograr con la tarea asignada, comentar
detalles que el cliente indica, pero adicionalmente los requerimientos, así como la
descripción de estos se les registra en un tablero propio en la herramienta
Monday.

Fecha máxima de entrega del reporte de los requerimientos

 A más tardar la entrega del reporte de finalización de los requerimientos por parte
de los desarrolladores se debe realizar los viernes o a más tardar los lunes a las 8
a.m.
 Las horas de trabajo empleadas en realizar los requerimientos deberán ser
actualizadas a más tardar las 10 a.m. de cada lunes. Si a la fecha y hora queda
pendiente algún requerimiento que el desarrollador estima que finalizará el mismo
lunes, es decir, no es un requerimiento que entrará al sprint siguiente, igualmente
debe reportar las horas que corresponden a ese trabajo pendiente. Ejemplo:
o El lunes a las 10 a.m. tengo 20 horas realizadas de trabajo del sprint, falta
por terminar un requerimiento, pero no es tan extenso como para que
ingrese al sprint siguiente, lo puedo terminar el lunes como parte del sprint
al que corresponde, en ese caso, estimo que tardaré 3 horas más para
realizarlo/terminarlo. De esta forma, aunque no haya terminado aún,
estimando el tiempo faltante a las 10 a.m. más tardar no reportaría 20
horas de trabajo sino 23 horas. Una vez completado el requerimiento
procedo a comunicar al coordinador de proyectos que está lista la tarea.
Nota: Es crítico el cumplimiento de estos tiempos para reportar porque es una
petición estrictamente solicitada por el cliente.
Horarios de trabajo
 Por servicios profesionales el desarrollador puede acomodar sus tiempos de
trabajo, es decir no debe trabajar en un horario establecido.
 Sin embargo, se solicita disponibilidad lunes y martes en la mañana para entrega
de requerimientos, el lunes para que el desarrollador entregue sus reportes y el
martes para que se le asigne nuevos requerimientos. Además, disponibilidad para
una reunión de seguimiento a la semana, para estimados de propuestas y para
eliminar incidentes urgentes.

Medios de comunicación con los coordinadores de proyectos de Portalnet

 Un grupo de WhatsApp es el canal de comunicación con el equipo de Portalnet, en
este grupo se pactarán reuniones, se mantendrá comunicación sobre los
requerimientos (seguimiento, atención de consultas, atención de incidentes),
cuando se realizan pruebas y surjan dudas, para mostrar evidencia de algún
aspecto solicitado o que el desarrollador considere necesario mostrar podrá
enviarlo al grupo pero adicionalmente toda la evidencia (videos, fotos de la
funcionalidad) debe ser registrada en Monday.

Proceso de reporte de horas por requerimiento

 Para el reporte de horas además de agregarlas como parte de un comentario en
Monday, se le asignará un Excel a cada desarrollador. En este Excel deberá
escribir el nombre de la tarea tal cuál se le asignó en Monday, después de escribir
el nombre del requerimiento debe desglosar en subtareas para especificar en qué
empleó las horas a reportar y a cada subtarea indicarle la cantidad de horas de
trabajo.
 Si existe una misma tarea en más de un sprint se debe crear un nombre distinto,
es decir no pueden existir tareas con el mismo nombre aún en sprints distintos.
 Diferenciar con colores el cliente al que pertenece la tarea, ejemplo: Áltica – azul,
RedMotors – blanco, Mercadeo – naranja.
Proceso en Monday para reportes de requerimientos
Descripción de su tablero en Monday
 En su tablero Monday el desarrollador encontrará tres vistas: vista Kanban, vista
tabla principal y vista tabla. A continuación, se describirá lo que representa todo lo
que corresponde a cada vista:
Vista Kanban

 En esta vista podrá ver un listado de los requerimientos según el estado en el que
se encuentran, Portalnet maneja los estados: no iniciada, en curso, detenido, en
pruebas nuestro equipo, en pruebas softland, pasar a producción, revisión
producción y listo. Con forme actualice el estado de la tarea en la tabla principal,
se observará como automáticamente las tareas se cambian de estado en esta
vista Kanban.

Vista tabla principal

 En esta vista podrá visualizar “Grupos” los cuales corresponden a cada sprint, el
título es el número del sprint y el número de semana a la que pertenece.
 La tabla posee las siguientes columnas:
o Tarea: corresponde al nombre de la tarea, deberá ser utilizado de manera
textual para reportar las horas en el Excel asignado al desarrollador.
o La nube: situada al lado del nombre de la tarea, es para registrar
actualizaciones, ahí podrá encontrar la descripción de la tarea y debe ser
utilizado para aportar comentarios, cargar evidencias, dar el reporte final de
cumplimiento del requerimiento. Los comentarios pueden ser editados y/o
eliminados.
o Persona: usuario al que se le asigna la tarea.
o Estado: esta columna es para que el desarrollador mantenga actualizado
en qué estado se encuentra la tarea: no iniciada, en curso, detenido, en
pruebas nuestro equipo, en pruebas softland, pasar a producción, revisión
producción o listo.
 o Fecha: esta columna corresponde a un registro de la fecha en que fueron
asignados los requerimientos.
o Menú desplegable: en esta columna el coordinador de proyectos indica a
que área/backlog pertenece la tarea.
o Link to…: La última columna es de manejo interno, es un enlace al tablero
del equipo de Portalnet desde donde se monitorea el avance de cada
requerimiento de todos los desarrolladores.

Nota: el objeto señalado corresponde a “la nube”, lo que debe presionarse para crear
actualizaciones/comentarios.
Vista tabla

 En esta vista los grupos en lugar de corresponder a los sprints corresponden a los
distintos estados, es en otras palabras, una vista alternativa al Kanban.

Pasos para crear reportes sobre actualizaciones del requerimiento

 Paso 1: ingresar al tablero en Monday que le corresponde al desarrollador y abrir
la vista “Tabla principal”.
 Paso 2: presionar la nube ubicada al lado del nombre del requerimiento en la
columna “Tarea” de la tabla principal.
 Paso 3: puede crear la actualización aparte desde el cuadro que contiene el texto
“Escribir una actualización…” o bien, puede hacerlo como una respuesta a la
actualización que corresponde a la asignación de la tarea.
  Paso 4: tener los datos para crear el reporte a mano de manera que puedan crear
un solo comentario para la entrega.
 Paso 5: redactar el comentario/actualización de reporte de finalización del
requerimiento.
o En el comentario/actualización debe redactar una descripción de qué
realizó para atender el requerimiento.
o Debe crear un video o tomar una foto de la evidencia del cumplimiento del
requerimiento asignado y adjuntarlo en el comentario.
o Debe agregar el total de horas de trabajo empleadas en la tarea.
 Adicional: si el comentario o actualización no corresponde al reporte de
finalización de la tarea.

Registrar avance del requerimiento

Todos los tableros se encuentran sincronizados con un tablero principal para gestión del
equipo de Portal, desde el cuál los coordinadores de proyecto llevan un seguimiento de
avance en las tareas de esta forma, detectar si un desarrollador presenta alguna situación
con la realización de los requerimientos y además de esto, llevar control de cuáles tareas
están listas para pruebas o en qué estado de revisión se encuentran.
Por lo anterior, es crítico/altamente necesario que el desarrollador verifique que el avance
de sus requerimientos se encuentre en el estado correcto, para esto cada vez que avance
debe dirigirse a la tabla principal, a la columna de estado y seleccionar el que
corresponde.

Cronograma de atención de requerimientos

Como parte de asignación de requerimientos a los desarrolladores se deriva una actividad
que debe ser realizada por los desarrolladores, en la especificación del requerimiento se
les agregará una tabla con la lista de requerimientos que corresponden al sprint actual,
adicionalmente, esta tabla incluirá tres columnas más para ser completadas por el
desarrollador. Debe copiar la tabla y crear una actualización donde deberá pegar la tabla
copiada y completar las columnas: fecha de inicio, fecha pase a revisión, fecha en
producción. El significado de cada columna es el siguiente:

 Fecha de inicio: esta columna es para indicar que día iniciarán la tarea.
 Fecha pase a revisión: esta columna es para indicar que día estaría el
requerimiento listo para revisión.
  Fecha en producción: esta columna es para indicar que día quedaría el
requerimiento en producción.

Requerimientos permanentes del negocio (RedMotors)

Cuando se asignan los requerimientos a los desarrolladores, antes de iniciarlos, el
negocio ha establecido requerimientos permanentes que deben considerarse para realizar
la tarea adicional a la especificación que se brinda para cada uno. De esta manera,
además de cumplir lo descrito para cada requerimiento, deben verificar que se cumpla lo
siguiente al realizarlos:
 Etiquetas en español deben ser configuradas
 En los procesos de taller siempre la moneda prevalece de la orden de trabajo
 Revisión en producción del desarrollo realizado, grabar video y probar la
funcionalidad de lo solicitado y enviarlo como evidencia de cómo funciona
 Colocar el inicio y fin de los desarrollos fecha de creación y autor
 Si es una pantalla que involucra el artículo debe siempre mostrar el código y el
nombre del artículo
 Los nombres deben ir en letra capital, por ejemplo: Orden de trabajo
 Respetar el estándar de nombres de campos y no crear campos con números al
final como por ejemplo email2 (nombres internos y externos)
 Incluir validaciones de tipo de dato si es un nombre no permitir números y si es un
teléfono por ejemplo no permitir letras
 Todos los parámetros deben ser configurables o quemados en código
 Si se genera un pdf con la información, todo dato que se un monto debe contener
la moneda y ser separado por comas y punto por ejemplo 7,492.69 CRC
 Respetar el orden de los objetos en pantalla sean campos o related deben
consultarse con el negocio

Mejores prácticas: Requerimientos permanentes de Portalnet

Los desarrolladores deben cumplir con el lineamiento de mejores prácticas para el
proceso de desarrollo, estas prácticas son las siguientes:

 En una actualización de Monday el desarrollador debe indicar en qué sandbox

trabajará antes de desarrollar la tarea.
 Cuando trabajan desarrollo de código refrescar el repositorio antes de iniciar cada
tarea para asegurarse de trabajar sobre la última versión.
 Documentar el código para asegurar un control de cambios, debe incluir: nombre
del requerimiento para el cuál se hizo la modificación, quién lo realizó y la fecha de
realización.
 Para realizar los pases a producción utilizar la herramienta de copado, no utilizar el
gestor de cambios, la razón del uso de copado es para poder ver los cambios de
código entre lo que se va a pasar a producción y lo que está en producción, de
manera que no haya conflictos con los cambios.
 Los pagelayouts o permisos de campos no se pasan a producción para no inferir
en cambios/versiones anteriores.
 Utilizar un formato estándar para nombrar flujos, clases y/o apinames, este
formato abarca crear los nombres en inglés y redactar su nombre si espacios ni
con separación por guión bajo, además, si el nombre comprende más de una
 palabra cada una se debe escribir con mayúscula la primera letra, por ejemplo:
CreateDocument.
 Para realizar pruebas de QA estas se deben realizar en sandbox y crear evidencia
del funcionamiento, después, pasar a producción e igualmente crear evidencia.
 La preparación de los datos (datos de prueba) en el ambiente de desarrollo es
responsabilidad de desarrollo, pueden cargar datos a producción.
 Cuando realizan pases a producción deben verificar que los permisos de clase y/o
visualforce estén activados en producción y si son nuevos, una vez en producción
deben configurar los permisos.