Documentación
Tabla de Contenidos
¿Qué es FLEXIN?
FLEXIN es una metodología ágil orientada al líder técnico.
Como ya se conoce, las metodologías ágiles nos permiten adaptar la forma en la que trabajamos a las condiciones del proyecto. Nos permiten también presentar el proyecto en etapas que contienen funcionalidades para que en el corto plazo se pueda comenzar a utilizar la aplicación. Esta documentación brinda todos los conocimientos para la implementación de la Metodología Flexin en sus proyectos.
FLEXIN se ha creado para el desarrollo de software. No se ha probado en ninguna otra área de momento. Solamente podemos aplicar FLEXIN si existe una persona con la capacidad para cumplir el rol de líder. En nuestra metodología, el líder técnico es una persona con conocimiento sobre el área de negocio para la que se desarrollará la aplicación y con la capacidad técnica de entrar en el código de la programación a punto tal de evaluarlo o modificarlo.
Comenzando
¿FLEXIN KANBAN O FLEXIN SCRUM?.
Para comenzar a trabajar con FLEXIN necesitamos saber con qué tipo de proyecto nos encontramos.
Cuando los proyectos requieren respuestas rápidas hacia incidencias, como puede ser el caso de un proyecto en mantenimiento, lo mejor es utilizar FLEXIN CANBAN; también podemos utilizarlo para proyectos cortos hacia aplicaciones cerradas o muy específicas.
Si el proyecto tiene muchas funcionalidades y se cuenta con un equipo de más de 3 personas (incluyendo al líder técnico), convendría utilizar FLEXIN SCRUM.
Resumiendo, a continuación se describen algunas variantes de proyectos para tener como referencia.
Documentación Flexin
FLEXIN KANBAN
Proyectos:
En mantenimiento.
Con tickets de soporte.
Mientras los equipos sean de menos de 3 personas.
Que tengan funcionalidades muy específicas, siempre que sean de corta duración.
Documentación Flexin
FLEXIN SCRUM
Proyectos:
Cuales sus equipos sean de más de 3 personas. (Requerimiento obligatorio)
Donde hayan muchas funcionalidades.
Indefinidos técnicamente.
De duración indeterminada.
Documentación Flexin
FLEXIN KANBAN
Descripción
Si ya conoces KANBAN te será muy familiar. Lo que hacemos en FLEXIN KANBAN es identificar a través de un tablero los pasos por los cuales debe pasar una tarea hasta que esté terminada.
En Kanban tradicional no se definen roles, pero en FLEXIN sí lo haremos. El único rol que definiremos es el del líder técnico, quien desempeñará tareas fundamentales para optimizar los tiempos de desarrollo y análisis.
Documentación Flexin
¿Cómo Funciona?
El primer paso a seguir es el de crear un tablero digital. En este caso nosotros recomendamos el uso de JIRA, herramienta que permite gestionar proyectos y crear tableros para los mismos. Además, JIRA se integra perfectamente con nuestra plataforma FLEXIN Teams.
El tablero que vamos a crear para trabajar con FLEXIN es de 6 columnas. Si algún equipo necesita alguna columna adicional se puede agregar. Estas 6 columnas nos van a indicar el flujo por los que las tareas deberán pasar para que estas sean completadas. A continuación detallamos qué contendrán dichas columnas:
Documentación Flexin
Backlog:
En esta columna se crearán las tareas a partir de las funcionalidades que el sistema necesita. Estas tareas tienen que estar divididas en pequeñas funcionalidades. Es importante que cada una de ellas cumpla con alguno de los siguientes conceptos:
Agregar una funcionalidad al sistema.
Modificar una funcionalidad del sistema.
Resolver una incidencia del sistema.
Documentación Flexin
Para desarrollar:
Una vez que haya sido estimada por el líder técnico y que el cliente haya aprobado, la tarea se desarrolla.
Es muy importante en esta columna que las tareas estén ordenadas por prioridad de realización. Esto quiere decir que la de arriba del todo es la primera que hay que realizar y la de abajo del todo la última.
Documentación Flexin
En progreso:
Esta columna no tiene mucha explicación: básicamente muestra las tareas que se están desarrollando.
Documentación Flexin
Revisión de código:
Finalizada la tarea, la misma pasa a esta columna. Luego el líder técnico se encargará de hacer las validaciones sobre el código realizado junto con algunas pruebas manuales. Esto se realiza con el fin de asegurarse que la funcionalidad es la correcta.
Documentación Flexin
Aprobación del cliente:
Es muy importante que el cliente sea quien de la tarea por completada, para asegurarse de que la funcionalidad es la correcta, pero hasta ese entonces esta columna tendrá las tareas que el cliente aún no ha dado por aprobadas.
Documentación Flexin
Finalizadas:
Donde se encuentran las tareas finalizadas y aprobadas por el cliente.
Documentación Flexin
Recomendaciones
En los tableros digitales se pueden crear alertas visuales: pondremos en la columna de “Listas para desarrollar” una alerta que se mostrará cuando esta columna tenga menos tareas que el doble del número de personas trabajando. Esto servirá para que el líder técnico pueda ver que tiene que estimar más tareas para que se puedan desarrollar.
Por otro lado, lo recomendado es que una persona no tenga “en progreso” más de 2 tareas. Pondremos también una alerta cuando la cantidad de tareas supere el doble de la cantidad de desarrolladores. También recomendamos que todos los participantes e interesados en el proyecto de software tengan acceso a la visualización del tablero.
Estimando
Como líder técnico hay que encargarse de estimar y analizar las tareas a realizar, para eso nos pararemos en las tareas creadas de la columna backlog e iremos estimando según podamos aportarle nuevas funcionalidades al proyecto, pero también priorizando siempre lo que el cliente más necesita.
Cuando comencemos a estimar una tarea, lo primero que hay que reconocer son los criterios de aceptación. Estas son las características funcionales imprescindibles que deben ser realizadas para completar la tarea.
Una vez que tengamos los criterios de aceptación definidos, deberemos estimarlos. Para ello utilizaremos la siguiente tabla:
La tabla nos va a servir para indicar el esfuerzo del criterio de aceptación basándonos en SIZE (cantidad de cosas que se necesitan hacer) y COMPLEXITY (la dificultad de esas cosas).
Por ejemplo: si tenemos que crear una nueva tabla en base de datos, suponemos que tenemos 1 SIZE (una sola cosa que realizar) y la dificultad dependerá de cómo afecte esta nueva tabla a la base de datos: si fuera sencilla decimos que COMPLEXITY es 1 y el resultado del esfuerzo nos daría 1. Una vez que hayamos estimado los criterios de aceptación, el esfuerzo total de la tarea será la sumatoria de todos los esfuerzos.
En nuestra plataforma FLEXIN Teams, el sistema permite, a través de inteligencia artificial, saber cuánto se puede tardar en hacer una tarea tomando como ejemplo tareas realizadas anteriormente con los mismos esfuerzos en los criterios de aceptación.
Calculando
Esta sección es propia de FLEXIN, ya que normalmente, en las metodologías ágiles no se suele calcular el tiempo real que puede llevar una tarea en realizarse. Esta es una gran ventaja que le puede servir a cualquier freelancer para calcular cualquier presupuesto o a las grandes empresas para evaluar sus costos de antemano. La manera en que calculamos el tiempo es basándonos en experiencias previas de tareas anteriores.
Dicha funcionalidad ya está integrada en nuestra plataforma FLEXIN Teams gracias a la inteligencia artificial, por lo cual es altamente recomendable utilizarla. Si no fuera posible, lo que hacemos es lo siguiente: buscamos experiencias previas que hayan tenido estimaciones iguales a la tarea que estamos estimando, pero no basándonos en el esfuerzo total, sino comparando las estimaciones sobre cada criterio de aceptación (cantidad de cosas + dificultad). Por ejemplo: si tenemos una tarea con un criterio de aceptación de una COMPLEXITY de 2 y un SIZE de 3, no buscaremos una tarea que en total tenga 6 de esfuerzo, sino que buscaremos una tarea que tenga un criterio de aceptación con la misma COMPLEXITY y SIZE que esta.
Una vez encontrada esa tarea, veremos cuánto tiempo llevó en realizarse y lo usaremos como tiempo aproximado de realización para la tarea que estamos estimando.
Reuniones
Daily
Es una reunión diaria de no más de 15 minutos en la que tienen que estar todos los desarrolladores del equipo y cada uno de ellos tiene que contestar tres preguntas:
- ¿Qué hice ayer?
- ¿Qué haré hoy?
- ¿Tengo algún impedimento o dificultad?
Demo
Participan todos los interesados en el proyecto. Por lo general aquí es donde se presentan las funcionalidades desarrolladas en el último período. Cuantas más personas participen, mejor será, ya que habrá más opiniones y propuestas de mejoras. Esta reunión es para realizar entregas de producto. Pueden ocurrir cuando se alcanza un hito determinado por el cliente o se pueden pactar entregas cada determinado tiempo.
Líder Técnico
En FLEXIN Kanban, el líder técnico desempeñará las siguientes tareas:
- Analizar las funcionalidades necesarias para la aplicación y pasarlas a tareas en el tablero: Lo recomendado es ir haciendo esto por secciones o por pequeñas partes de la aplicación, ya que hay que hacer un análisis descriptivo de cada tarea de una manera técnica. Por ejemplo: si la tarea consiste en crear una tabla en base de datos, indicar el nombre de los campos y los tipos de los mismos. Gracias a la descripción técnica, el desarrollador tendrá más claro lo que tiene que hacer dando lugar a muchas menos confusiones.
- Crear los criterios de aceptación de las tareas: Esta es la parte más importante del líder técnico, ya que no sólo tenemos que crear los criterios de aceptación para las tareas, sino que además, estimar los mismos para poder pasar la tarea a la columna de “listas para desarrollar”.
- Liderar las reuniones diarias, de ser posible hacer participar al cliente para que tenga una visión diaria sobre el desarrollo.
- Desarrollar junto con los programadores si fuese requerido.
- Revisar la tarea una vez completada por el desarrollador: Hay que verificar que se cumplan los criterios de aceptación y que la funcionalidad sea la solicitada. Si se cuenta con un equipo de QA hay que intentar hacer llegar la nueva funcionalidad lo más rápido posible, sin importar que sea en el mismo entorno de desarrollo.
- Realizar las entregas de las nuevas funcionalidades al cliente: Siempre a través de versiones para que el cliente sepa qué es lo que se le está presentando. Si se cuenta con un equipo de DEVOPS, el líder técnico le tiene que dar las indicaciones de cómo desplegar la aplicación.
QA
Si se cuenta con un equipo de calidad, lo mejor será crear una columna entre revisión de código y aprobación del cliente. Es importante tener al equipo de QA lo más rápido y accesible a las nuevas funcionalidades, para que cuando el cliente las vea ya estén probadas. También hay que destacar que el equipo de QA debería poder probar funcionalidades en el entorno de desarrollo y hacer pruebas de regresión en el entorno de pre-producción.
DEVOPS
Si se cuenta con un equipo de DEVOPS, lo aconsejable es tener dos entornos previos a producción. Un entorno de desarrollo, que no debe tener integración continua para que cada desarrollador pueda subir lo que necesite probar, y un entorno de pre-producción que se suba de manera continua la última versión generada.
FLEXIN SCRUM
Descripción
FLEXIN Scrum es una optimización del Scrum tradicional, que cuenta con un cambio radical, quitando al scrum master y dándole mucha responsabilidad al líder técnico para que se haga cargo de que se aplique la metodología de trabajo y además para dar soporte al equipo de desarrollo. Es por eso que NO será sencillo encontrar un profesional con estas disciplinas bien desarrolladas. Lo que se suele hacer es preparar al miembro técnico con mayor capacidad de análisis y competencias técnicas e instruirlo sobre la metodología, si es que no la conoce.
En FLEXIN Scrum se respetan todas las reuniones de Scrum, pero modificando los participantes y las formas de llevarlas a cabo.
¿Cómo Funciona?
En FLEXIN Scrum tenemos un backlog, que es donde estarán las tareas por realizarse, un ciclo donde se pondrán tareas para realizarse y también un producto que será incrementado al finalizar cada iteración del ciclo. Cada iteración recibe el nombre de Sprint.
El líder técnico estará presente en todas las etapas, ayudará al product owner a crear y estimar tareas, dará soporte técnico a los desarrolladores y puede escribir código si es requerido.
Para comenzar el sprint se realizan dos reuniones previas: una de refinamiento, que es donde se analizan y estiman las tareas, y otra de planificación, para saber cuáles de las tareas estimadas se realizarán en el sprint. Una vez planificadas las tareas, los desarrolladores se comprometen a completarlas en el tiempo que dura el sprint.
El sprint se finaliza con una reunión de demostración de las tareas terminadas y luego de eso, otra de retrospectiva, para afianzar el equipo y evaluar mejoras sobre el rendimiento.
Recomendaciones
Para llevar el seguimiento de los sprint se utilizan plataformas digitales como puede ser JIRA, la cual recomendamos ampliamente ya que tiene integración con nuestra plataforma FLEXIN Teams, y así utilizar la funcionalidad de pre-estimación, en donde gracias a la inteligencia artificial, brinda detalles aproximados de horas de realización de las tareas, para poder hacerlas coincidir con las horas del equipo en el sprint.
Si existe un arquitecto en el equipo, debe estar coordinado con el líder técnico y participar en las reuniones de refinamiento, pero lo ideal sería que el líder técnico tenga la capacidad de trabajar la arquitectura de la aplicación.
Reuniones
Refinamientos
En esta reunión estarán presentes el product owner y el líder técnico. La finalidad es analizar y estimar las tareas que ya están listas para realizarse. Es importante analizar una cantidad de tareas mayor a la que el equipo podría hacer en un sprint por si el desarrollo va muy bien.
El líder técnico debe crear los criterios de aceptación de las tareas analizadas y a su vez debe estimar los mismos en esfuerzo para lo cual puede utilizar la plataforma FLEXIN Teams.
Planificaciones
En esta reunión estarán presentes el Product Owner, el líder técnico y todos los desarrolladores del equipo. La finalidad es que el líder técnico presente las tareas analizadas para que los desarrolladores puedan discutir las estimaciones e indicar las tareas que se realizarán en el sprint. Es importante que los desarrolladores se comprometan a terminar las tareas del sprint, ya que es la clave de esta metodología.
Daily
Es una reunión diaria de no más de 15 minutos en la que tienen que estar todos los desarrolladores del equipo y cada uno de ellos tiene que contestar tres preguntas:
- ¿Qué hice ayer?
- ¿Qué haré hoy?
- ¿Tengo algún impedimento o dificultad?
Demo
Participan todos los interesados en el proyecto. Por lo general aquí es donde se presentan las funcionalidades desarrolladas en el último período. Cuantas más personas participen, mejor será, ya que habrá más opiniones y propuestas de mejoras. Esta reunión es para realizar entregas de producto. Pueden ocurrir cuando se alcanza un hito determinado por el cliente o se pueden pactar entregas cada determinado tiempo.
Retrospectiva
Esta reunión se realiza luego de la demostración del sprint. Solamente participan el Product Owner, el líder técnico y los integrantes del equipo de desarrollo. Se utiliza para dar un Feedback del sprint, viendo cuáles han sido los aspectos buenos y los aspectos en los que se debería mejorar. También se podrían evaluar mejoras técnicas o humanas para mejorar la sintonía del equipo.
Líder Técnico
El líder técnico es la mayor ventaja de esta metodología con respecto a SCRUM tradicional, ya que debe programar junto a los desarrolladores de ser necesario. Debe también tener un buen conocimiento sobre las tecnologías trabajadas para dar soporte a los desarrolladores. Es el responsable de realizar el análisis y las estimaciones en el refinamiento. También debe enseñar la metodología a los miembros del equipo.
QA
El equipo de calidad en FLEXIN Scrum debe participar una vez terminado el Sprint, verificandeo las funcionalidades entregadas y en caso de que alguna no sea la correcta, generar un bug en el nuevo Sprint.
Aquí lo ideal es que el equipo de QA tenga un entorno propio de QA al que se puedan subir versiones terminadas y así realizar las pruebas que requieran sin interrumpir a nadie.
DEVOPS
El equipo de DEVOPS debe asegurarse de lo siguiente:
- Tener un entorno de desarrollo en el que los desarrolladores puedan subir lo que necesite, sin integración continua.
- Tener un entorno de QA en el que el equipo de pruebas pueda subir las versiones creadas, sin integración continua.
Además, debe coordinar con el líder técnico la forma de subida hacia pre-producción y producción.
¡Gracias!
Gracias a la empresa LMV Software por la oportunidad de hacer crecer esta metodología y aplicarla en todos los proyectos que realiza.
A todas las personas que han optado por esta metodología innovadora para llevar sus proyectos y facilitar su trabajo en el día a día.
Por leer esta documentación y aprender sobre Flexin.
EN