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 pueda desarrollar.
Por otro lado, lo recomendado es que una persona no tenga «en proceso» 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 aportar 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 imprescindible que deben ser realizadas para completar la tarea.

Una vez que tengamos los criterios de aceptación definidos, debemos estimarlos. Para ello utilizaremos la siguiente tabla:

Esta tabla nos va 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 para 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 la 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.

Esta funcionalidad ya está integrada en nuestra plataforma FLEXIN Teams gracias a la inteligencia artificia, 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 5 de esfuerzo, sino que buscaremos una tarea que tenga un criterio de aceptación con la misma COMPLEXITY y SIZE que está.

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.

Daily

Es una reunión diaria de no de 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 presentas las funcionalidades desarrolladas en el último período. Cuando 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.

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 hacia 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 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.

• 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á presentado. 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.

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 aprobadas. 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.

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. 

Descripción

FLEXIN Scrum es una optimización del Scrum tradicional, que cuanta con un cambio radical, quitando al scrum master y dándoles 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 que 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 prepara 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 realizaran 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 realiza 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 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.

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 de 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

En esta reunión deben participar todos los interesados en el proyecto. Por lo general, aquí es donde se presenta el nuevo agregado al producto, el cual se estuvo desarrollando en el sprint; cuantas más personas participen mejor será, ya que habrá más opiniones y propuestas de mejoras. Se realiza al cumplir el tiempo de sprint. Si se pospone esta reunión se considera como un incumplimiento del mismo; también se consideraría un incumplimiento si alguna de las tareas no hubiese sido terminada. 

Retrospectiva

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 cuales 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 miembro del equipo. 

DEVOPS

El equipo de devops debe asegurarse de los siguiente: 

• Tener un entorno de desarrollo en el que los desarrolladores puedan subir lo que necesiten, 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 la pre-producción.

QA 

El equipo de calidad en FLEXIN Scrum debe participar una vez terminado el Sprint, verificando 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.