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 mas de 3 integrantes?
Metodologías Ágiles
¿Se va a trabajar con iteraciones de tiempo fijo?
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 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.
Más info
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.
Más info
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.
Más info
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.
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!
EN