Permíteme que te hable un poco sobre cómo trabajamos construyendo el software de Laycos y cómo nuestra plataforma nos ayuda a conseguir objetivos.
Para nosotros es muy importante que todos, incluidas otras partes interesadas, como los equipos de marketing y soporte, entiendan lo que se está construyendo, su justificación, la temporización y cómo influirán los nuevos desarrollos en la plataforma completa.
Laycos nos permite trabajar en red, de una forma dinámica
No trabajamos de una manera estática. Esto significa que vamos adaptando nuestra metodología continuamente. Tratamos que la planificación y la comunicación no constituyan un desafío mayor y que el conocimiento no se pierda.
Recogemos, discutimos y planificamos todos los cambios utilizando redes. De hecho, lo hacemos con toda la información relevante.
Tenemos una red principal para el equipo de desarrollo y varias para captar el feedback (errores y sugerencias) de los usuarios.
Dependiendo de la red, organizamos la información en grupos temáticos (como Propuestas, Nuevas características, Errores, Mantenimiento de librerías o Documentación y monografías), de modo que cada área es accesible tanto por los interesados directos, como por cualquier otra persona que necesite saber qué está sucediendo.
En el caso de las redes destinadas a incidencias, utilizamos la unidireccionalidad, las identidades y la posibilidad de valorar el soporte, para ofrecer una experiencia adecuada al usuario.
Cuando un usuario nos comunica algo, un responsable de soporte lo valora, recaba cualquier información que pudiera ser de utilidad y enruta la tarea hacia la red de desarrollo.
De esta forma los desarrolladores no pierden el tiempo buscando información y no son necesarias tantas reuniones de estado, pues los interesados pueden verificar el punto en el que se encuentra el proyecto ellos mismos.
Sin duplicar, ahorrando tiempo que puede destinarse a tareas de innovación
Antaño, uno de los problemas a los que nos enfrentábamos era que las personas se desviasen tanto de la línea de trabajo que acabasen duplicando el trabajo de los demás.
Como es lógico, esta duplicidad desperdiciaba no sólo el tiempo, sino la oportunidad de generar nuevas ideas y conocimiento. Por suerte esta situación ya rara vez se nos da.
Aprender de la experiencia
Es vital que las lecciones aprendidas durante el tiempo no se pierdan.
Cuando se completa un proyecto, recopilamos las observaciones del equipo y las “lecciones aprendidas”. Son muy útiles como referencia, más adelante, para evitar repetir los errores del pasado o para ver qué hizo bien el equipo.
Procesando el trabajo de desarrollo
Como comentaba, todo el trabajo pendiente termina organizado por temáticas en la “red de desarrollo”. Ya sea una característica menor o el lanzamiento de una nueva funcionalidad, en el seno de la publicación se debate y se deja constancia de todo lo que tiene que ver con la misma, incluyendo enlaces a la incidencia original y documentos de texto.
Cuando comenzamos una nueva funcionalidad, normalmente un responsable del producto explica en una especie de resumen (que a veces es un documento) cuál es el problema que estamos resolviendo para los clientes, por qué debemos resolverlo, de qué manera va a resolverse, etc. y en común con el equipo de desarrollo, se establece la hoja de ruta (descomposición del problema en tareas, asignación de las mismas, prioridad, etc).
La persona responsable del desarrollo crea una rama para el nuevo desarrollo y la comunica como comentario.
Todos y cada uno de los cambios mínimos funcionales que compongan la tarea deberán ser un “commit” independiente en Git.
Odiamos los commits con decenas de cambios no explicados.
En el sistema de control de versiones comienza la documentación del proyecto.
Utilizando el sistema de gestión de tareas de Laycos, el equipo de desarrollo está “conectado”, colaborando ágilmente y puede ir planificando nuevos sprints.
Cuando un cambio está listo, se revisa y se integra en la rama “beta”, que contiene más o menos una imagen de lo que sería producción más las últimas novedades. Esta rama se convierte en la versión de Laycos que ven los empleados internos de nuestra empresa, nuestra primera línea de beta-testers. Esto se indica, obviamente, en la actividad, al igual que el paso a producción, el cual además supone “cerrar la actividad”.
¡Hasta la próxima!