EL PROCESO

El desarrollo se realiza de forma iterativa e incremental, es decir cada iteración se denominada sprint, la cual tiene una duración preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versión del software con nuevas prestaciones listas para ser usadas.

En cada nuevo sprint, se va ajustando la funcionalidad ya construida y se añaden nuevas prestaciones priorizándose siempre aquellas que aporten mayor valor de negocio. (Guía SBOK™, Tridibesh Satpathy, 2013), (Essential Scrum, Rubin, K. S. 2012).

PRODUCT BACKLOG

Conjunto de requisitos denominados historias, descritos en un lenguaje no técnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversión considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares.

SPRINT PLANNING

Reunión durante la cual el Product Owner (Representante del Cliente) presenta las historias del Product Backlog (requisitos del sistema) por orden de prioridad.

De esta forma el equipo determina la cantidad de historias a las que puede comprometerse a completar en ese sprint, para que en una segunda parte de la reunión, se pueda decidir y organizar cómo lo va a conseguir.

SPRINT

Iteración de duración prefijada (2 a 4 semanas), durante la cual el equipo trabaja para convertir las historias del Product Backlog (requisitos del sistema) a las que se ha comprometido, en una nueva versión del software totalmente operativo. (Guía SBOK™, Tridibesh Satpathy, 2013), (Essential Scrum, Rubin, K. S. 2012).

SPRINT BACKLOG

Lista de las tareas necesarias para llevar a cabo las historias del sprint.

DAILY SPRINT MEETING

Reunión diaria que dura cómo máximo 15 minutos al comienzo de la jornada. En ella el equipo se sincroniza para trabajar de forma coordinada.

Durante es proceso cada miembro comenta que hizo el día anterior, que hará el día de hoy y si hay impedimentos para realizar la lista del Sprint Backlog.

DEMO Y RETROSPECTIVA

Reunión que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una demonstración del producto.

Posteriormente, en la retrospectiva, el equipo analiza qué se hizo bien, qué procesos serían mejorables y se discute acerca de cómo perfeccionarlos. (Guía SBOK™, Tridibesh Satpathy, 2013), (Essential Scrum, Rubin, K. S. 2012).

PRODUCT BACKLOG

Es una lista ordenada que contiene todo lo que podría ser necesario en el producto y es la única fuente de requisitos para hacer cambios en el producto.

El único responsable del Product Backlog es el Product Owner (representante del cliente), además es el encargado de ordenar y añadir ítems (historias o requisitos de usuario agregados al sprint backlog).

Por definición, ésta lista nunca está completa, sino que es un ente vivo y dinámico, que va cambiando según lo hace el entorno y el propio producto para ser adecuado, competitivo y útil.

A medida que el producto va siendo usado y se recibe feedback, la lista se va haciendo más larga y detallada.

Los elementos o ítems que están ordenados más arriba, normalmente son los más detallados y claros, ya que serán los más próximos a ser desarrollados.

SPRINT BACKLOG

Son los ítems o elementos del Product Backlog seleccionados para ser ejecutados durante el Sprint en curso. Así pues, el Sprint Backlog es un plan para entregar un Incremento de producto “Terminado” al final del Sprint.

Debemos recordar que estos ítems o elementos son los requisitos del sistema o historias del usuario que son administrados por el Product Owner (representante del cliente), priorizándolos o descartándolos en el Product Backlog, según sea el caso.

A medida que se va trabajando sobre el producto, va apareciendo nuevo trabajo, que el equipo de desarrollo va añadiendo al Sprint Backlog, generando de esta forma una lista actualizada de los ítems a elaborar.

Solo el Development Team puede modificar o eliminar el Sprint Backlog pero solo durante la ejecución del Sprint.

INCREMENTO

Terminado o hecho, significa que puede ser utilizado y que además cumple con la “Definición de Terminado” o “Hecho”, es decir, lo que todo el mundo entiende dentro del equipo por terminado.

El concepto Hecho es definido universalmente y significa, diseñado, implementado, integrado, probado, documentado y puesto en explotación. (Guía SBOK™, Tridibesh Satpathy, 2013), (Essential Scrum, Rubin, K. S. 2012).

PRODUCT OWNER (PO)

Es quien representa al cliente frente al equipo de desarrollo, teniendo muy claro el proceso de negocio y es quien tiene redacta todos los requisitos a través de historias de usuario y llevar la acumulación del producto.

Es quien tiene que ordenar y priorizar los requisitos, fijar los criterios de aceptación para cada historia de usuario.

Además, es el encargado de definir el “PMV” Producto Mínimo Viable y revisar la demostración del incremento del producto de cada sprint.

También vela por los intereses de los stakeholders, que se verán beneficiados por el software. Se focaliza en la parte de negocio y él es responsable del ROI (retorno de inversión, para entregar un valor superior al dinero invertido) del proyecto.

Traslada la visión del proyecto al equipo, formaliza las prestaciones en historias a incorporar en el Product Backlog y las reprioriza de forma regular.

SCRUM MASTER

Es el encargado de evangelizar, es decir, generar fe y convicción del modelo elegido dentro equipo de desarrollo para que conozca y entienda las ventajas y beneficios de utilizar la metodología scrum, de igual forma vela porque que apliquen la metodología correctamente.

Debe ayudar al equipo de desarrollo a adoptar la metodología de desarrollo y a convertirse en un equipo auto organizado y multifuncional.

Es la persona que lidera al equipo guiándolo para que cumpla las reglas y procesos de la metodología.

Gestiona la reducción de impedimentos del proyecto y trabaja con el Product Owner para maximizar el ROI.

SCRUM DEVELOPMENT TEAM

Grupo de profesionales con los conocimientos técnicos necesarios que desarrollan el proyecto de manera conjunta llevando a cabo las historias a las que se comprometen al inicio de cada sprint.

GESTIÓN REGULAR DEL CLIENTE

El cliente establece sus prioridades indicando al equipo de desarrollo la importancia que le aporta cada requisito del proyecto y cuando espera que esté listo.

El cliente comprueba de manera regular si se van cumpliendo sus expectativas, da feedback, ya desde el inicio del proyecto puede tomar decisiones informadas a partir de resultados objetivos y dirige estos resultados del proyecto, iteración a iteración, hacia su meta.

Una de las características principales de la metodología ágil, en donde el cliente tiene una participación activa en el proyecto. Esto no quiere decir que el cliente este físicamente en el equipo de desarrollo, sino que es representado por alguien experto en el negocio y que asume el rol del cliente, ya que están en estrecho contacto y el representante vela por los intereses del cliente.

RESULTADOS ANTICIPADOS (TIME TO MARKET)

El cliente puede empezar a utilizar los resultados más importantes del proyecto antes de que esté finalizado por completo.

Siguiendo la ley de Pareto (el 20% del esfuerzo proporciona el 80% del valor), (Koch, R. 2015), el cliente puede empezar antes a recuperar su inversión, comenzando a utilizar un producto al que sólo le faltan características poco relevantes (prototipo de características seleccionadas), puede sacar al mercado un producto antes que su competidor, puede hacer frente a urgencias o nuevas peticiones de clientes, etc. Es decir puede comenzar a producir mucho antes y con menor espera.

REDUCCIÓN DE LA OCURRENCIA DE RIESGOS

Desde la primera iteración, el equipo es quien tiene que gestionar los problemas que pueden aparecer en una entrega del proyecto. Al hacer presente estos riesgos, es posible iniciar su mitigación de manera anticipada.

Si hay que equivocarse o fallar, mejor hacerlo lo antes posible.

El feedback temprano permite ahorrar esfuerzo y tiempo en errores técnicos, y la cantidad de riesgo a la que se enfrenta el equipo está limitada a los requisitos que se puede desarrollar en una iteración. La complejidad y riesgos del proyecto se dividen de manera natural en iteraciones.

TIME BOXING

Cada actividad de Scrum siempre tiene la misma duración (1 mes, 2 semanas, 4 horas, etc.), con lo que el equipo aprende lo que pueden conseguir en este tiempo, cómo organizarse, priorizar tareas y tomar decisiones.

Los equipos trabajan mucho más enfocados y de manera más eficiente cuando hay una fecha límite a corto plazo para entregar un resultado al que se han comprometido.

La consciencia de esta limitación temporal favorece la priorización de las tareas y fuerza la toma de decisiones.

Las iteraciones (sprints) son regulares y de un mes como máximo, para facilitar la sincronización sistemática con otros equipos, con el resto de la empresa y con el cliente.

EQUIPO COMPROMETIDO

En el inicio de cada iteración el equipo selecciona los requisitos que se compromete a completar y entregar al final de la iteración (responsabilidad). El propio equipo se organiza (autogestión) identificando las tareas necesarias, su esfuerzo y auto-asignándose cada uno de ellos, las tareas que se compromete a realizar.

Las personas trabajan de manera más eficiente y con mayor calidad cuando ellas mismas se han comprometido a entregar un resultado en un plazo determinado y deciden cómo hacerlo, no cuando se les ha asignado una tarea e indicado el tiempo necesario para realizarla. (Tridibesh Satpathy, 2013)

EQUIPO AUTO GESTIONADO Y MOTIVADO

El equipo es quien se compromete a completar unos requisitos determinados en una iteración y quien mejor sabe cómo desarrollarlos. Por ello es el equipo quien se auto organiza y quien planifica cómo trabajará en la iteración.

Los integrantes del equipo de desarrollo están más motivados cuando pueden usar su creatividad para resolver problemas y cuando pueden decidir organizar su trabajo. Las personas se sienten más satisfechas cuando pueden mostrar los logros que consiguen. (Tridibesh Satpathy, 2013).

DEMOSTRACIÓN DE RESULTADOS

Al final de cada iteración, el equipo demuestra al cliente los requisitos que ha conseguido completar, de manera que están completamente operativos.

Para tener una velocidad de desarrollo sostenida, el equipo necesita desarrollar cada incremento de producto sin tener que revisitar aspectos mal resueltos en iteraciones anteriores. De esta forma, se asegura la calidad del producto de manera sistemática y objetiva, a nivel de satisfacción del cliente, requisitos listos para ser utilizados y calidad interna del producto.

CLIENTE Y EQUIPO TRABAJANDO EN ARMONÍA

En cada iteración (sprint) el equipo y el cliente trabajan juntos en la creación de los requisitos del proyecto (en la estimación de la lista priorizada de requisitos del proyecto), en darles detalle (en la reunión de planificación de la iteración) y en el análisis del resultado obtenido (en la demostración de los requisitos completados).

Los resultados y esfuerzos del proyecto se miden en forma de objetivos y requisitos entregados al negocio. Todos los participantes en el proyecto conocen cuál es el objetivo a conseguir. El producto se enriquece con las aportaciones de todos. (Guía SBOK™, Tridibesh Satpathy, 2013), (Essential Scrum, Rubin, K. S. 2012).