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 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.
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.
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.
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.
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.
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).
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.
Veamos la hoja de ruta de un producto ficticio llamado Equipos en el Espacio.
TEAMS IN SPACE WEB SITE
Iniciativa / Modulo
Epic 1
Epic 2
Epic 3
Tareas
SCRUM
(Requisitos)
Sub Modulo
(Requisitos)
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.