Metodologías Ágiles
¿Conoces algunas?
Metodologías Ágiles
Breve Introducción
Cuando hablamos de Metodologías Ágiles, nos referimos a un método de trabajo (en nuestro caso desarrollo de software), que potencia la rapidez y la flexibilidad en una nueva manera de organizar las tareas. Así, cada proyecto que se realiza bajo estas Metodologías es analizado en pequeñas partes que se van desarrollando y entregando en breves períodos de tiempo. Esto permite tener entregas parciales de unidades funcionales ya probadas facilitando la rápida puesta en marcha del proyecto con excelente calidad, dando respuesta a las necesidades de los clientes, para los que el tiempo es muy valioso.
Metodologías Ágiles más utilizadas
Scrum y Kanban
¿Que características definen tu proyecto?
Metodologías Ágiles
Empezando el Proyecto
¿Se trabaja en un proyecto cuyo alcance cambia rápidamente?
Metodologías Ágiles
¿Es un proyecto grande?
Metodologías Ágiles
¿El proyecto tiene más de 3 integrantes?
Metodologías Ágiles
¿Serán necesarios roles en el proyecto?
Metodologías Ágiles
¿Hay ambientes operativos cuyas prioridades cambian con mucha frecuencia?
Metodologías Ágiles
¿Los cambios en los requerimientos se pueden introducir en cualquier momento?
Scrum
El refinamiento Scrum consiste en el acto de actualizar el Product Backlog de manera colaborativa entre el Development Team y el Product Owner. Tiene varios objetivos, una parte es dejar items “ready” para el siguiente Sprint. Esto es cierto, pero cuidado, no se hace una división por tareas (eso es trabajo del Sprint Planning).
El Sprint Planning (o planificación del Sprint) es uno de los cinco eventos de Scrum y es el primero que haremos al comenzar cada Sprint.
En esta reunión vamos a planificar QUÉ es lo que vamos a hacer durante el Sprint y CÓMO lo vamos a hacer.
El Scrum Master es la persona dentro de Scrum que potencia al equipo y lo acompaña en la mejora continua, es uno de los 3 roles del marco de trabajo (Scrum).
El Product Owner es el miembro del equipo Scrum responsable de maximizar el valor del producto entregado por el equipo.
El objetivo del Product Owner es lograr que entreguemos el producto «correcto», el producto que quiere el mercado y stakeholders. Para ello contará con grandes responsabilidades como por ejemplo el ordenamiento del Product Backlog.
Los Developers (o Desarrolladores) es uno de los tres roles en Scrum y se compone de todas las personas que se encargar de construir el Incremento de Producto en cada Sprint. Hasta la Guía Oficial de Scrum del 2017 también se lo conocía con el nombre de «Equipo de Desarrollo».
El Sprint Backlog es la suma de el Objetivo del Sprint, los elementos del Product Backlog elegidos para el Sprint, más un plan de acción de cómo crear el Incremento de Producto.
Es uno de los 3 artefactos de Scrum y se construye durante el evento del Sprint Planning. Es un plan realizado por y para los Developers.
El Daily Scrum (o Scrum diario) es uno de los 5 eventos de Scrum con un bloque de tiempo de 15 minutos para que los Developers se sincronicen.
Esta reunión diaria se realiza a la misma hora y en el mismo lugar para reducir la complejidad. Aquí se busca la transparencia y la inspección de lo realizado para tener una oportunidad de adaptación para el día siguiente.
El SPRINT REVIEW (o Revisión del Sprint) es uno de los cinco eventos de Scrum y se realiza al final del Sprint. Durante esta ceremonia se revisa el Incremento, es decir, lo que se realizó durante el Sprint, y se analizan los cambios que tuvo el Product Backlog.
En Scrum la retrospectiva tiene lugar al final del Sprint, después de la Revisión de Sprint y antes de la siguiente Planificación de Sprint.
La duración de la retrospectiva es, como máximo, de tres horas para Sprints de un mes. En la práctica si trabajamos con Sprints de 2 semanas, la duración será a lo sumo de 1 hora y media.
El Product Backlog o pila de producto en un proyecto que sigue la metodología Scrum consiste en una lista con todos los requerimientos iniciales del producto que se va a desarrollar. Se trata de una lista dinámica, que irá evolucionando a medida que lo hace el producto y el entorno del proyecto. La finalidad de crear esta lista no es otra que identificar las necesidades del producto para lograr su máxima utilidad.
El Increment («Incremento» en español) o también conocido como Incremento de Producto es la suma de todos los ítems del Product Backlog (PBIs) completados durante un Sprint y el valor de los incrementos de todos los Sprints pasados. Es uno de los 3 artefactos de Scrum y se presenta en cada Sprint Review.
Kanban
El Backlog es una lista ordenada de todo el trabajo pendiente. Contenido. Dependiendo del método ágil utilizado, los elementos incluidos en el Backlog se denominan ítems, historias de usuario, unidades de trabajo, etc.
Cualquiera que se dedique o haya dedicado a implantar Scrum en una organización sin experiencia, sabe que suele haber problemas al introducir los roles: ¿Qué hace un Product Owner? ¿El Scrum Master es un Jefe de Proyectos ágil? Estos roles no existen en las organizaciones actuales, lo que provoca un cambio organizacional y nos dificulta la implantación de Scrum. El Método Kanban sin embargo, no prefija ninguno rol. Deja que los propios equipos se organicen en torno al trabajo y que ellos mismos sean los que consigan que el trabajo fluya.
El tablero Kanban es la herramienta para mapear y visualizar su flujo de trabajo y uno de los componentes claves del método Kanban. Originalmente, se utilizaba una pizarra blanca (o un tablero de corcho) que se dividía en columnas y filas.
Una tarjeta Kanban contiene información significativa sobre la tarea y su estado en el tablero Kanban, como por ejemplo el tiempo del ciclo, la fecha límite, etc. Toda esta información sirve como un canal de comunicación entre los diferentes miembros del equipo.
Otra de las señas de identidad de los tableros de kanban son las columnas. Cada columna representa una actividad específica que, en conjunto, conforman un “flujo de trabajo”. Las tarjetas van moviéndose por el flujo de trabajo hasta que este termina. Los flujos de trabajo pueden ser algo tan sencillo como “Por hacer”, “En curso” y “Terminado” o pueden ser mucho más complejos.
Cuando la información de la tarea se ha complementado, la tarjeta se mueve a esta lista. Esta es la señal para que el equipo empiece en trabajar en ella. En este punto, se asigna a un miembro del equipo como encargado de esa tarea y se fijan las fechas de entrega.
Cuando se mueven las tarjetas a esta lista significa que se está trabajando en ellas. Así, todo el equipo puede ver quién está trabajando en qué. Las tarjetas de Trello también facilitan la colaboración gracias a la función "Comentario", que permite hacer preguntas sobre las tareas.
Este es un tablero de ejemplo.
La clave del tablero en Kanban es visualizar de una manera rápida el estado de cada una de las tareas.
Cuando una tarea está casi terminada, se mueve a esta lista para que alguien más la revise. (En el ejemplo anterior, se usó como plantilla la lista "Revisión de Código", pero puede ser una revisión de cualquier trabajo)
Cuando la tarea se ha revisado y aprobado, se puede mover a esta lista. Es tiempo de celebrar porque tu equipo va hecho una bala con sus tareas!
Reunión Diaria (Daily Meeting)
El propósito de la Daily Meeting es inspeccionar el progreso hacia el Objetivo del Sprint según sea necesario. Se busca que los Developers logren sincronizarse. Para ello se planea el trabajo de las siguientes 24 horas.
Esto optimiza la colaboración y el desempeño del equipo inspeccionando el trabajo avanzado desde la última Daily Meeting y haciendo una proyección del trabajo restante del Sprint.
Los Developers usan el Daily Meeting para evaluar su progreso hacia el Sprint Goal y para evaluar qué tendencia sigue este progreso hacia la finalización del trabajo del Sprint en curso.
Ya que la reunión tiene un timebox de solo 15 minutos cada persona debe realizar una breve síntesis de lo que cree más importante para lograr sincronizarse con el resto de sus compañeros.
¿Qué es un Sprint en Scrum?
Un sprint es un período breve de tiempo fijo en el que un equipo de scrum trabaja para completar una cantidad de trabajo establecida. Los sprints se encuentran en el corazón de las metodologías scrum y ágil, y hacer bien los sprints ayudará a tu equipo ágil a lanzar mejor software con menos quebraderos de cabeza.
¿Qué es un Scrum Master?
Un Scrum Master es básicamente un entrenador y facilitador de equipos Scrum. Ayuda al equipo a mantenerse enfocado en los objetivos del proyecto y elimina los impedimentos que van apareciendo durante el camino.
Metodología Ágil Kanban
Kanban es algo más que notas adhesivas en la pared. La forma más fácil de entender Kanban es aceptar su filosofía y luego aplicarla a su trabajo diario.
Kanban es un método de gestión del flujo de trabajo para definir, gestionar y mejorar los servicios que proporcionan el trabajo del conocimiento. Su objetivo es ayudar a visualizar el trabajo, maximizar la eficiencia y mejorar continuamente. Procedente de la industria manufacturera, posteriormente se convirtió en un territorio reclamado por los equipos de desarrollo de software ágil.
Tablero Kanban
El tablero Kanban es la herramienta para mapear y visualizar su flujo de trabajo y uno de los componentes claves del método Kanban. Originalmente, se utilizaba una pizarra blanca (o un tablero de corcho) que se dividía en columnas y filas.
Cada columna visualiza una fase de su proceso y las filas representan diferentes tipos de actividades específicas (diseño, errores, deuda técnica, etc.).
Al mismo tiempo, cada tarea que entra en su flujo de trabajo aparece en el tablero como una tarjeta Kanban. El punto de entrada de cada tarjeta es la columna “Por hacer”.
Hoy en día, existen soluciones de tarjetas Kanban digitales más prácticas y accesibles a nivel global que son perfectas tanto para para los equipos remotos como para los equipos que desarrollan su actividad en el lugar donde se realiza el proyecto.
Te presentamos Flexin
Flexin es la Metodología Ágil que utilizamos en nuestra empresa.
Fue creada por Leonardo Mazzitelli y nos permite cumplir con plazos menores, optimizar la calidad de los proyectos y fidelizar a nuestros clientes.
Flexin trabaja modificando las Metodologías Ágiles KANBAN y SCRUM, por lo cual su implementación no implica grandes cambios difíciles de aplicar en los equipos que ya conocen estas Metodologías.
Lo imprescindible para comenzar a trabajar con FLEXIN, es contar con un Líder Técnico.
Él es quien se encarga de guiar al equipo de desarrolladores en esta Metodología, allanando el camino de todos los escollos que puedan presentarse para evitar distracciones o cuellos de botella y maximizar su rendimiento.
Aspectos diferenciales de Flexin
Nuestra Metodología Ágil FLEXIN tiene básicamente una característica que la diferencia claramente de las Metodologías Ágiles tradicionales, SCRUM y KANBAN.
Esta “característica”, nosotros la llamamos LÍDER TÉCNICO.
El Líder Técnico es una persona que conoce en profundidad una buena cantidad de lenguajes de programación (tecnologías), cosa que le confiere la capacidad de discernir cuál o cuáles de ellas son las más convenientes para desarrollar una tarea determinada.
Esto lo convierte en un personaje fundamental, tanto en Flexin Scrum como en Flexin Kanban, pero no es la única capacidad necesaria para su trabajo, pues debe conocer también en profundidad las Metodologías Ágiles en su forma tradicional.
De esta manera, enriquece estas Metodologías, transformándolas en Metodologías FLEXIN, aportando una guía (liderazgo) al equipo de desarrolladores, definiendo el mejor camino a recorrer, previendo y resolviendo las dificultades que puedan suscitarse y permitiendo así que el equipo sólo se dedique a programar.
Y no sólo eso, sino que, gracias a su capacidad técnica, también es capaz de trabajar codo a codo con su equipo apoyándolo ante las dificultades que los desarrolladores menos experimentados puedan tener. Esto tiene que ver con su capacidad de liderazgo, su empatía, logrando capacitar de una manera práctica a los programadores del equipo que lo necesiten, generando valor para ellos y para la empresa.
Flexin
Definiendo el Equipo
Conociendo Flexin Scrum
FLEXIN SCRUM está basada en la misma estructura de la Metodología Scrum, pero incorpora un nuevo rol (el del Líder Técnico), que reemplaza al Scrum Master.
Ésto, que puede parecer una modificación menor, es lo que produce una notable mejora en el rendimiento del equipo de desarrolladores, pues incorpora a alguien con mucha experiencia y un profundo conocimiento técnico que, además de llevar a cabo las tareas inherentes al Scrum Master, también guía y ayuda al equipo en su trabajo.
Su principal función no es trabajar como un desarrollador más, sino estar atento a sus necesidades para apoyarlos y aportarles conocimientos que les permitan ser cada vez más eficientes. En otras palabras: ser su líder.
Es él quien hace las estimaciones de las tareas a realizar basándose en los criterios de aceptación, lo cual, utilizando un procedimiento basado en inteligencia artificial, hace que estas estimaciones sean muy precisas y permiten asignar a cada integrante del equipo de desarrolladores una tarea específica.
La participación del Líder Técnico en los términos mencionados es lo que convierte a Scrum en FLEXIN SCRUM, posibilitando simultáneamente una mejora en los plazos de ejecución que según los casos fluctúa entre un 20% y un 30%, un mejor ambiente de trabajo por el menor estrés que resulta de saber que ante cualquier inconveniente hay alguien dispuesto a ayudar y enseñar, y un crecimiento profesional de los desarrolladores, que reciben conocimientos a medida que los necesitan para realizar su tarea.
Y por último, cabe destacar que un Líder Técnico está en condiciones de participar simultáneamente en más de un proyecto, ya que no necesita estar dedicado full time a uno solo de ellos, sino que una vez puesto en marcha, su participación es sólo de monitoreo y acompañamiento ante las dificultades que puedan aparecer durante su desarrollo.
El refinamiento Scrum consiste en el acto de actualizar el Product Backlog de manera colaborativa entre el Development Team y el Product Owner. Tiene varios objetivos, una parte es dejar items “ready” para el siguiente Sprint. Esto es cierto, pero cuidado, no se hace una división por tareas (eso es trabajo del Sprint Planning).
El Sprint Planning (o planificación del Sprint) es uno de los cinco eventos de Scrum y es el primero que haremos al comenzar cada Sprint.
En esta reunión vamos a planificar QUÉ es lo que vamos a hacer durante el Sprint y CÓMO lo vamos a hacer.
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.
El Product Owner es el miembro del equipo Scrum responsable de maximizar el valor del producto entregado por el equipo.
El objetivo del Product Owner es lograr que entreguemos el producto «correcto», el producto que quiere el mercado y stakeholders. Para ello contará con grandes responsabilidades como por ejemplo el ordenamiento del Product Backlog.
Los Developers (o Desarrolladores) es uno de los tres roles en Scrum y se compone de todas las personas que se encargar de construir el Incremento de Producto en cada Sprint. Hasta la Guía Oficial de Scrum del 2017 también se lo conocía con el nombre de «Equipo de Desarrollo».
El Sprint Backlog es la suma de el Objetivo del Sprint, los elementos del Product Backlog elegidos para el Sprint, más un plan de acción de cómo crear el Incremento de Producto.
Es uno de los 3 artefactos de Scrum y se construye durante el evento del Sprint Planning. Es un plan realizado por y para los Developers.
El Daily Scrum (o Scrum diario) es uno de los 5 eventos de Scrum con un bloque de tiempo de 15 minutos para que los Developers se sincronicen.
Esta reunión diaria se realiza a la misma hora y en el mismo lugar para reducir la complejidad. Aquí se busca la transparencia y la inspección de lo realizado para tener una oportunidad de adaptación para el día siguiente.
El SPRINT REVIEW (o Revisión del Sprint) es uno de los cinco eventos de Scrum y se realiza al final del Sprint. Durante esta ceremonia se revisa el Incremento, es decir, lo que se realizó durante el Sprint, y se analizan los cambios que tuvo el Product Backlog.
En Scrum la retrospectiva tiene lugar al final del Sprint, después de la Revisión de Sprint y antes de la siguiente Planificación de Sprint.
La duración de la retrospectiva es, como máximo, de tres horas para Sprints de un mes. En la práctica si trabajamos con Sprints de 2 semanas, la duración será a lo sumo de 1 hora y media.
El Product Backlog o pila de producto en un proyecto que sigue la metodología Scrum consiste en una lista con todos los requerimientos iniciales del producto que se va a desarrollar. Se trata de una lista dinámica, que irá evolucionando a medida que lo hace el producto y el entorno del proyecto. La finalidad de crear esta lista no es otra que identificar las necesidades del producto para lograr su máxima utilidad.
El Increment («Incremento» en español) o también conocido como Incremento de Producto es la suma de todos los ítems del Product Backlog (PBIs) completados durante un Sprint y el valor de los incrementos de todos los Sprints pasados. Es uno de los 3 artefactos de Scrum y se presenta en cada Sprint Review.
Conociendo Flexin Kanban
En Kanban, que es una metodología ágil mundialmente utilizada que permite organizar y monitorear en tiempo real las tareas que cada desarrollador lleva a cabo y que ha dado pruebas más que suficientes de su utilidad, no hay roles específicos.
Pero, mediante la incorporación de un Líder Técnico la convertimos en FLEXIN KANBAN, logrando mejorar visiblemente sus características y el plazo necesario para finalizar las tareas.
Si bien viendo el tablero de FLEXIN KANBAN no aparece reflejado el rol del Líder Técnico, su participación se centra en la estimación previa de los plazos de ejecución y la distribución de las tareas entre los desarrolladores, cosas que están a su alcance debido a sus profundos conocimientos técnicos.
También está atento al desarrollo fluido de los trabajos y a intervenir cada vez que alguno de los desarrolladores se encuentre con dificultades para seguir avanzando, ayudándolo a solucionar cada inconveniente.
Y por último, cabe destacar que un Líder Técnico está en condiciones de participar simultáneamente en más de un proyecto, ya que no necesita estar dedicado full time a uno solo de ellos, sino que una vez puesto en marcha, su participación es sólo de monitoreo y acompañamiento ante las dificultades que puedan aparecer durante su desarrollo.
Este es un tablero de ejemplo.
La clave del tablero en Kanban es visualizar de una manera rápida el estado de cada una de las tareas.
El Backlog es una lista ordenada de todo el trabajo pendiente. Dependiendo del método ágil utilizado, los elementos incluidos en el Backlog se denominan ítems, historias de usuario, unidades de trabajo, etc.
Cuando la información de la tarea se ha complementado, la tarjeta se mueve a esta lista.
Esta es la señal para que el equipo empiece en trabajar en ella. El líder técnico analiza las tareas y las pone en esta columna según la relevancia dentro del proyecto mismo.
Cuando se mueven las tarjetas a esta lista significa que se está trabajando en ellas. Así, todo el equipo puede ver quién está trabajando en qué. Las tarjetas de Trello también facilitan la colaboración gracias a la función "Comentario", que permite hacer preguntas sobre las tareas.
Cuando una tarea está casi terminada, se mueve a esta lista para que alguien más la revise. (En el ejemplo interior, se usó como plantilla la lista "Revisión de Código", pero puede ser una revisión de cualquier trabajo)
Cuando la tarea se ha revisado y aprobado, se puede mover a esta lista. Es tiempo de celebrar porque tu equipo va hecho una bala con sus tareas!
El tablero Kanban es la herramienta para mapear y visualizar su flujo de trabajo y uno de los componentes claves del método Kanban. Originalmente, se utilizaba una pizarra blanca (o un tablero de corcho) que se dividía en columnas y filas.
Una tarjeta Kanban contiene información significativa sobre la tarea y su estado en el tablero Kanban, como por ejemplo el tiempo del ciclo, la fecha límite, etc. Toda esta información sirve como un canal de comunicación entre los diferentes miembros del equipo.
Otra de las señas de identidad de los tableros de kanban son las columnas. Cada columna representa una actividad específica que, en conjunto, conforman un “flujo de trabajo”. Las tarjetas van moviéndose por el flujo de trabajo hasta que este termina. Los flujos de trabajo pueden ser algo tan sencillo como “Por hacer”, “En curso” y “Terminado” o pueden ser mucho más complejos.
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.
EN