Metodologías ágiles
Manifiesto ágil
Estamos descubriendo mejores formas de desarrollar software teniendo en cuenta nuestra propia experiencia y nuestro interés en ayudar a terceros.
| Kent Beck | James Grenning | Robert C. Martin |
| Mike Beedle | Jim Highsmith | Steve Mellor |
| Arie van Bennekum | Andrew Hunt | Ken Schwaber |
| Alistair Cockburn | Ron Jeffries | Jeff Sutherland |
| Ward Cunningham | Jon Kern | Dave Thomas |
| Martin Fowler | Brian Marick |

Principles behind the agile Manifesto
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
SCRUM

Que es?
Scrum es un marco que permite el trabajo colaborativo entre equipos. Al igual que un equipo de rugby (de donde proviene su nombre) cuando entrena para un gran partido, scrum anima a los equipos a aprender a través de las experiencias, a autoorganizarse mientras aborda un problema y a reflexionar sobre sus victorias y derrotas para mejorar continuamente.
SPRINTS

SPRINTS

SPRINTS
SPRINT CYCLE

Qué hacer
- Asegúrate de que el equipo defina y entienda el objetivo del sprint, y cómo se cuantificará el éxito. Esta es la clave para mantener a todos coordinados y avanzar hacia una meta común.
- Asegúrate de que tienes un backlog bien administrado con tus prioridades y dependencias en orden. Esto puede suponer un gran reto que podría entorpecer el proceso si no se gestiona adecuadamente.
- Comprueba que entiendas bien la velocidad y que esta refleje, por ejemplo, las bajas y las reuniones de equipos.
- Utiliza la reunión de planificación de sprints para concretar hasta el más mínimo detalle del trabajo que hay que hacer. Anima a los miembros del equipo a esbozar las tareas de todas las historias, los errores y los elementos que se incluyen en el sprint.
- Deja fuera el trabajo cuyas dependencias no puedas controlar, como el trabajo de otro equipo, los diseños y la aprobación legal.
- Por último, una vez que se tome una decisión o se concrete un plan, asegúrate de que alguien registre esa información en la herramienta de colaboración o gestión de proyectos, como los tickets de Jira. De ese modo, en el futuro todos podrán ver con facilidad tanto cuál fue la decisión que se tomó como el razonamiento que llevo a ella.
Qué no hacer
- No incorpores demasiadas historias (Requerimientos), no excedas la estimación de la velocidad ni incluyas tareas que no puedan completarse en el sprint. Debes evitar que tanto tú como tu equipo os aboquéis al fracaso.
- No te olvides de la calidad o de la deuda técnica. Asegúrate de incluir el tiempo necesario para el control de calidad y el trabajo que no esté relacionado con las funciones, como los errores y el estado de la ingeniería.
- No permitas que el equipo tenga una idea poco precisa de lo que hay en el sprint. Concrétala y no te centres exclusivamente en avanzar rápidamente, ya que podrías cometer el error de olvidar que todos deben ir en la misma dirección.
- Además, no asumas una gran cantidad de trabajo desconocido o de alto riesgo. Desglosa las historias (Requisitos/Casos de uso) que sean extensas o tengan un elevado grado de incertidumbre y no tengas miedo de dejar parte de ese trabajo para el siguiente sprint.
- Si los miembros del equipo te comentan preocupaciones sobre la velocidad, la incertidumbre de algunas tareas o el tamaño mayor de lo esperado de algunos elementos de trabajo, no las pases por alto. Aborda el problema y realiza ajustes cuando sea necesario.
Optimización de Sprints
- Incidencias (Issues) - Asignaciones - Tareas
- Chat (Ej: Slack) Semanalmente se envíe un recordatorio de que tareas está realizando cada miembro
- Cuando finalice un sprint, asignar las tareas pendientes o activas al próximo Sprint
Planificación de Sprints
La planificación de sprints es un evento en scrum que inicia el sprint. El objetivo de la planificación de sprints es definir lo que se puede entregar en el sprint y cómo se conseguirá ese trabajo. La planificación de sprints se hace en colaboración con todo el equipo de scrum.
Planificación de Sprints
El qué: El propietario del producto describe el objetivo (o propósito) del sprint y qué elementos del backlog contribuyen a dicho objetivo. El equipo de scrum decide qué se puede hacer en el próximo sprint y qué hará durante el sprint para conseguirlo.
El cómo: El equipo de desarrollo planifica el trabajo necesario para alcanzar el objetivo del sprint. En última instancia, el plan del sprint resultante es una negociación entre el equipo de desarrollo y el propietario del producto en función del valor y el esfuerzo.
Planificación de Sprints
El quién: no puedes planificar sprints sin el propietario del producto ni el equipo de desarrollo. El propietario del producto define el objetivo en función del valor que busca. El equipo de desarrollo tiene que entender cómo puede o no puede alcanzar dicho objetivo. Si alguno de los dos no está en este evento, la planificación del sprint será casi imposible.
Los elementos de trabajo: un buen punto de partida para el plan del sprint es el backlog del producto, ya que proporciona una lista de “cosas” que posiblemente podrían formar parte del sprint actual. Además, el equipo debería analizar el trabajo realizado en el incremento y tener visión de la capacidad.
Planificación de Sprints
El resultado: el resultado más importante de la reunión de planificación de sprints es que el equipo pueda describir el objetivo del sprint y cómo empezará a trabajar hacia ese objetivo. Esto se refleja en el backlog de sprint.
Planificación de Sprints
BACKLOG
El backlog de un producto es una lista de trabajo ordenado por prioridades para el equipo de desarrollo que se obtiene de la hoja de ruta y sus requisitos. Los elementos más importantes se muestran al principio del backlog del producto para que el equipo sepa qué hay que entregar primero. El equipo de desarrollo no trabaja con el backlog al ritmo que dicta el propietario del producto, y este no presiona al equipo de desarrollo para que saque el trabajo adelante. En su lugar, el equipo de desarrollo saca trabajo del backlog del producto en la medida de sus capacidades, ya sea de forma continua (kanban) o por iteraciones (scrum).
BACKLOG
La hoja de ruta y requisitos de un equipo son la base para el backlog del producto. Las iniciativas de hoja de ruta se dividen en varios epics, y cada epic tendrá varios requisitos e historias de usuario.
- Los epics son grandes cantidades de trabajo que se pueden desglosar en un número de tareas más pequeñas (llamadas "historias").
BACKLOG
Veamos la hoja de ruta de un producto ficticio llamado Equipos en el Espacio.

BACKLOG
TEAMS IN SPACE WEB SITE
Iniciativa / Modulo

Epic 1
Epic 2
Epic 3
Tareas
SCRUM
(Requisitos)
Sub Modulo
(Requisitos)
BACKLOG
A continuación, el propietario del producto organiza las historias de usuario (Requisitos) en una única lista para el equipo de desarrollo. El propietario del producto puede optar por entregar primero un epic completo (Izquierda), puede que sea más importante para el programa reservar un vuelo barato que requiera historias de diversos epics (Derecha). A continuación, puedes ver ambos ejemplos.

Metodologías ágiles
By Ricardo Bermudez Osorio
Metodologías ágiles
- 186