Metodología Ágil

Desarrollo

Marzo 2019
Versión 1 – 04/03/2019
 Índice

• INTRODUCCIÓN

• PRINCIPIOS

• CONCEPTOS

• ESTIMACIÓN ÁGIL

• GUÍA DE ADAPTACIÓN AL MÉTODO ÁGIL

• AMENAZAS A LA AGILIDAD

• MAS ALLÁ…

• CONCLUSIONES

2
Principios

Estamos descubriendo mejores formas de desarrollar software

y hemos aprendido a valorar:

• Individuos e interacciones sobre procesos y herramientas.

• Software funcionando sobre documentación extensiva.

• Colaboración con el cliente sobre negociación contractual.

• Respuesta ante el cambio sobre seguir un plan.

http://agilemanifesto.org/iso/es/manifesto.html

3
Principios

Detrás de los principios, se busca

• descubrir la solución correcta experimentando, sobre la

definición formal desde el principio.

• el fallo barato, permitiendo pivotar hacia otra solución lo

antes posible

• que el valor del producto sea la medida del avance, en

lugar del tiempo.

• la construcción de un equipo cuajado de alto rendimiento.

4
Conceptos

CEREMONIAS ARTEFACTOS
Impact mapping Épicas
User Stories Mapping Historias de usuario
Sprint Planning Backlog de producto
Daily Meeting Sprints
Sprint Review MVP
Retrospectiva Friends and Family
Grooming sessions

ROLES
Product Owner
Scrum Master
Equipo Scrum
Stakeholders

5
Roles.
Product Owner

Responsable de
• El proyecto ante negocio
• Decidir qué se hace y qué no se hace en base a las necesidades
de negocio
• Definir qué se hace, de la mejor forma posible y más completa
buscando la ayuda que necesite
• Fijar los criterios de aceptación para cada funcionalidad.
• Priorizar lo que se hace tomando el valor generado como guía.
• Estar disponible para resolver las dudas al equipo de desarrollo
• Otorgar la visión estratégica al equipo
• Participar en las reuniones diarias, de planificación y
retrospectivas

6
Roles.
Scrum Master / Agile Coach

Ayuda al product owner a:

• entender la agilidad
• maximizar el valor de negocio
• gestionar las funcionalidades (backlog) de forma eficiente.

Ayuda al equipo ágil a:

• Resolver los impedimentos
• Implantar las mejoras que aparecen en las retrospectivas
• Actualizar el trabajo en curso.
• Promover buenas prácticas de programación.

En resumen, se ocupa de que:

• Las cosas se hagan rápido
• Se cumpla con los valores ágiles
• Se minimice el desperdicio
7
Roles.
Equipo de desarrollo

Es responsable de:
• construir el software con calidad
• cumplir los compromisos adoptados en las reuniones de planificación
• estimar las funcionalidades (historias de usuario)
• indicar al product owner que debe dividir las funcionalidades en caso
de complejidad alta.
• identificar y transmitir al scrum master o en la dailies los
impedimentos aparecidos o por aparecer
• hacer una demo en los plazos acordados en las reuniones de
planificación con los incrementos funcionales
• participar en las reuniones diarias, de planificación y retrospectivas

8
Artefactos.
Épica

• Requisitos de alto nivel y alto grado de indefinición

• Representa a una acción estratégica a implementar (ver impact

mapping).

• La estrategia se desglosará en acciones concretas llamadas

historias de usuario, que son las susceptibles de definirse e
implantarse.

• Son los requerimientos en clarity

9
Artefactos.
Historias de usuario

• Una historia de usuario es una definición de un requisito en un formato sencillo. El product owner
debe definirla formalmente.

• Cada historia de usuario:

• Tiene una conversación asociada
• Tiene un responsable técnico único
• Es lo suficientemente pequeña
• Debe aportar valor por sí misma
• Puede ser estimada.
• Se define qué es lo necesario para que se le pueda dar comienzo (definition of ready)
• Se define qué es lo necesario para que se entienda que está finalizada (definition of done)
• Puede tener una relación de dependencia con otra historia.
• Se puede descomponer en tareas técnicas.
• Pertenece a una épica
• Puede ser modificada hasta que empieza el sprint en el que está planificada

• Para cada historia de usuario se definen las condiciones de aceptación. Son los llamados “Tests de
historias de usuario”. El formato suele ser del tipo (existe incluso un lenguaje formal llamado Gherkin):
• Dado que <Condición>
• Y que <condición 2>
• Cuando <acción del usuario>
• Entonces <ocurre una respuesta>
10
Artefactos.
Backlog de producto

• El conjunto de historias de usuario registradas constituyen el backlog de producto.

• El product owner es el responsable de mantener el backlog de producto actualizado y

priorizado.

• El equipo debe aclarar las historias de usuario con el resto del equipo y el product
owner y estimadas antes de iniciarse el desarrollo de la historia de usuario.

• El equipo de desarrollo estimará y aclarará las historias de prioridad más alta (las que
aportan más valor), ya que entrarán en el proximo sprint con mayor seguridad.

• No hay que estimar todas las historias de usuario desde el principio. Lo ideal es tener
encajadas las historias de usuario en los sprints y tener estimados los dos sprints
siguientes.

• Es un proceso vivo, con refinamiento y detalle contínuo.

11
Artefactos.
Sprint 1/3

• El proyecto ágil se divide en miniproyectos partiendo del estado remanente

en el sprint anterior.

• Se encajan en cada sprint las historias de usuario que aportan mayor valor
teniendo en cuenta el coste de implementación.

• La duración del sprint debe ser acordada por el equipo, no siendo superior a
un mes, para poder garantizar entrega continua de valor.

• El contenido de un sprint en curso no se puede modificar, salvo que se incurra

en desperdicio.

• Se deben dejar espacio suficiente para

• la estimación del sprint siguiente
• resolución de incidencias del sprint anterior
• historias técnicas o de reducción de deuda

12
Artefactos.
Sprint 2/3

Dentro de los sprints se hacen dos tipos de trabajo en los que se llama
Dual-track

1. Equipo de descubrimiento: EL product owner, el scrum master, algún

técnico con experiencia y el diseñador de la experiencia de usuario (si
existe) trabajan en la definición de la historia antes del sprint planning del
sprint en el que se aborda la historia. Antes de iniciarse el desarrollo, la
implementación debe estar clara para todos y sin impedimentos.

2. Equipo de desarrollo: El equipo de desarrollo trabaja en la

implementación de la historia definida por el equipo de descrubrimiento

13
Artefactos.
Sprint 2/3

14
Artefactos.
Minimum Viable Product (MVP) y Friends and Family (F&F)

• Es el entregable producido en cierto sprint, con el mínimo número de

historias de usuario que lo hacen potencialmente usable

• Las historias de usuario que deben recogerse en ese MVP deben ser
seleccionadas por el Product Owner.

• Dicho producto con funcionalidad mínimo se expone a la utilización por parte

de un conjunto de usuarios de confianza.

• Se recoge el eco de los mismos de forma directa y se evalúan los resultados

para evaluar si la vía elegida es correcta o es necesario pivotar en algún punto
de la solución

• Dicha solución puede consistir en la creación de nuevas épicas o historias de

usuario o en el descarte de otras pendientes de implementar.

15
 Ceremonias
Inception: Impact mapping

Objetivo Actores Impactos Entregables

Conversación
Fidelización
Empleados
Ranking de
Mejorar la productos
venta de Vinculación
circulante
un 50%
Posición global
Mejora del
Clientes disponible
Duración: 2h Contratación
Convocante: Product Owner
Asistentes: Product Owner, Scrum
Master, Stakeholders
16
 Ceremonias
Inception: User Stories Mapping

Ranking de
Conversación Posición global Contratación
productos

Lista de Datos
Preguntas Datos de activo
productos conversación

Persistencia Recomendación Pasivos Apertura TF

Mejorar la venta de circulante un 50%
Acceso y SSO Operatoria BPM
Conversación
conf. pesos

Alta de cliente Inmuebles

Leyenda (MoSCoW)

Duración: 2h Must Do Should Do

Convocante: Product Owner
Asistentes: Product Owner, Scrum Could Do Won’t Do
Master, Stakeholders 17
Ceremonias.
Sprint Planning

• Es la reunión donde se planifica acuerda qué historias de usuario se abordan en el siguiente

sprint.

• Todas las historias en el top del backlog de producto deben estar totalmente claras para todo el
equipo y no tener impedimentos

• Se acuerdan fechas de inicio y fin del sprint. Normalmente tienen longitud fija y comienza al día
siguiente

• El product owner propone las historias que deben entrar en función del valor que aportan

• El equipo de desarrollo determina si tiene capacidad para ello y cuales puede abordar

Duración: 2h
Convocante: Scrum Master
Asistentes: Product Owner, Scrum Master, Equipo de desarrollo

18
Ceremonias.
Daily Meeting

Es una reunión diaria, normalmente a primera hora donde:

• Cada integrante del equipo de desarrollo expone:

• En qué trabajó el día anterior

• En qué va a trabajar hoy

• Impedimentos encontrados

• El Scrum Master:
• Anota los impedimentos para intentar resolverlos tras la reunión

• Cuida de no se extienda la reunión más alla de lo estrictamente necesario ni se convierta en

un monográfico por parte de algún integrante

Duración: 15 minutos
Convocante: Scrum Master
Asistentes: Product Owner, Scrum Master, Equipo de desarrollo
19
Ceremonias.
Sprint Review

• Es una reunión de negocio liderada por el product owner al final del sprint.

• En ella:

• El product owner expone el incremento funcional producido

• El equipo de desarrollo realiza una demo de la funcionalidades desarrolladas

• El product owner revisa y expone el estado del backlog de producto para que los
stakeholders invitados hagan las alegaciones o puntualizaciones necesarias

• Dichas opiniones serán procesadas después por el product owner

Duración: 1 hora
Convocante: Product Owner
Asistentes: Product Owner, Scrum Master, Equipo de desarrollo,
stakeholders
20
Ceremonias.
Retrospectiva

• Liderada por el scrum master

• Marca el final del sprint

• Se exponen fortalezas y debilidades del equipo que favorecen o ralentizan el aporte de

incrementos funcionales

• Existen múltiples modelos de retrospectiva:

• Deben responder, básicamente, a:

• ¿Funcionaron las acciones seleccionadas durante la última retrospectiva?

• Qué actividades o acciones hay que dejar de hacer.
• Qué actividades o acciones hay que hacer menos.
• Que actividades o acciones hay que seguir haciendo.
• Qué actividades o acciones que empezar a hacer.

Duración: 1 hora
Convocante: Scrum Master
Asistentes: Product Owner, Scrum Master, Equipo de desarrollo
21
Ceremonias.
Último día de sprint

Hora Actividad
9:00 – 10:00 Demo + Sprint Review
10:00 – 10:30 Café
10:30 – 11:30 Retrospectiva
11:30 – 12:30 Sprint planning

Duración: 1 hora
Convocante: Scrum Master
Asistentes: Product Owner, Scrum Master, Equipo de desarrollo
22
Ceremonias.
Grooming sessions

• Reunión de refinamiento de historias de usuario convocada bajo demanda del equipo a través
del scrum master

• Se utiliza para resolver dudas sobre las historias de usuario a implementar en los futuros sprints,
ya sean funcionales o visuales

• Las historias de usuario deben quedar claras antes de abordarse.

• La historia puede ser dividida en otras bajo demanda del equipo de desarrollo en caso de
excesivo tamaño.

Duración: 1 hora
Convocante: Scrum Master
Asistentes: Product Owner, Scrum Master, Equipo de desarrollo
23
Conclusiones.

•Las conclusiones aparecen experimentando

• https://www.youtube.com/watch?v=6uP2kg4JMIM

24
Adaptaciones para conversaciones de venta
Product Owner

• El product owner debería ser único, pero no es posible. Por ello, proponemos:

• Existencia de un product owner por conversación de venta, donde cada uno

prioriza las historias relativas a su conversación de venta.

• Existencia de un product manager global que priorice el backlog y que sea parte
activa y decisoria en la confección de cada sprint planning. Dicho product Manager
será Juliana Morcillo Mendoza

• El Agile Coach será María del Carmen Segura Torres.

• Para la confección de los sprints aconsejamos el “Swarming”, es decir, abordar las

historias de usuario de cada conversación de venta de una en una.

25
Adaptaciones para conversaciones de venta
Product Owner

• El product owner debería ser único, pero no es posible. Por ello, proponemos:

• Existencia de un product owner por conversación de venta, donde cada uno

prioriza las historias relativas a su conversación de venta. El product owner será el
Business Partner designado para cada una de ellas.

• Existencia de un product manager global que priorice el backlog y que sea parte
activa y decisoria en la confección de cada sprint planning. Dicho Product Manager
será Juliana Morcillo Mendoza

• Para la confección de los sprints aconsejamos el “Swarming”, es decir, abordar las

historias de usuario de cada conversación de venta de una en una.

• El Agile Coach será María del Carmen Segura Torres.

26
Adaptaciones para conversaciones de venta
Responsabilidades del Product Owner

Responsable de

• Cada proyecto de conversaciones de venta ante negocio

• Decidir qué se hace y qué no se hace en base a las necesidades de negocio

• Definir qué se hace, de la mejor forma posible y más completa buscando la ayuda
que necesite

• Fijar los criterios de aceptación para cada funcionalidad.

• Priorizar en el ámbito de cada conversación de venta lo que se hace tomando el

valor generado como guía.

• Estar disponible para resolver las dudas al equipo de desarrollo

• Otorgar la visión estratégica al equipo

• Participar en las reuniones diarias, de planificación y retrospectivas

27
Adaptaciones para conversaciones de venta
Responsabilidades del Product Manager

Responsable de

• Resolver los conflictos de prioridad entre conversaciones de venta

• Participar activamente en el sprint planning para decidir qué se hace en cada

sprint.

• Mantener priorizado el trabajo pendiente más próximo a realizar

28
Muchas
Gracias.

29