Sysmana 2017 metodologías gestión ágil de proyectos

Gestión ágil de proyectos
Nacho Álvarez
Área de Pagos Inmediatos
31 enero 2017
Redsys, Servicios de Procesamiento, SL.
www.redsys.es
Tel.: +34 91 346 53 00
Fax.: +34 91 346 54 82
Francisco Sancha 12
28034 Madrid – España

Ingeniero en Informática por la UCO
Certificado Scrum Manager en 2012 (96/100)
Trayectoria profesional:
• Soporte Servicio Informática UCO
• Desarrollo Web
• Desarrollo / Integración distribuciones GNU/Linux
• Android mobile + backend developer (WUL4)
• Técnico especialista Área de Innovación (Redsys)
• Analista de Pagos Inmediatos (Redsys)
Acerca de mi
2Gestión ágil de proyectos – 31 enero 2017

Involucrado en la Innovación de soluciones de medios de pago
Acerca de mi

Acerca de mi
> 300.000 usuarios
> 338.000 transacciones
> 45€ de importe medio
> 15 millones de euros en movimiento
95% cuota de mercado en España
ALGUNOS DATOS DE ESTOS TRES MESES…

GDG Córdoba
https://www.facebook.com/GDGCordobaESP/
Hack&Beers Córdoba
https://twitter.com/hackandbeers
BetaBeers Córdoba
https://twitter.com/betabeersODB
Codemotion Madrid
https://www.facebook.com/Codemotion-Madrid-505998872792272/
FOSDEM (Free and Open Source Software Devs’ European Meeting)
https://fosdem.org
Eventos

Eventos

Índice
7
1. Gestión de proyectos predictiva
2. El manifiesto ágil
3. Ciclo de desarrollo y modelos de gestión ágil
4. Scrum: control de la evolución del proyecto
• Elementos
• Roles
• Reuniones
5. Medición: unidades y herramientas
• Velocidad, trabajo y tiempo
• Burn-up, burn-down y estimación póquer
6. Gestión visual: kanban
Gestión ágil de proyectos – 31 enero 2017

El origen
8
Fuente: Standish Group

1. GESTIÓN DE PROYECTOS
PREDICTIVA

1) Gestión de proyectos predictiva
• Premisas gestión predictiva:
• Proyectos => Características y comportamientos regulares
• Objetivo => on time, on cost, on quality
• Nos cuestionamos:
• No hay una forma única y válida para gestionar cualquier tipo de
proyecto
• Hay proyectos en los que no se quiere solamente “hacer el producto
descrito en las fechas y con costes estimados”
• Queremos entregar el mayor valor en cada momento
• Gestión predictiva => pide al equipo cumplimiento exhaustivo de un plan
• Gestión adaptable => pide al equipo el mayor valor posible para una visión
de producto

NO PLAN??? RELAX TIME!!!

:’(

2. EL MANIFIESTO ÁGIL

2) El manifiesto ágil
“Estamos poniendo al descubierto mejores métodos para desarrollar software,
haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a
valorar:
• A los individuos y su interacción por encima de los procesos y las herramientas
• El software que funciona, por encima de la documentación exhaustiva
• La colaboración con el cliente, por encima de la negociación contractual
• La respuesta al cambio, por encima del seguimiento de un plan
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda”
http://agilemanifesto.org/iso/es/
Kent Beck, Robert C. Martin,
Steve Mellor, Martin Fowler,
y 12+1 más – 17/02/2001

3. CICLO DE DESARROLLO Y
MODELOS DE GESTIÓN ÁGIL

3) Ciclo de desarrollo y modelos de gestión ágil
17
• El equipo produce de forma continua incrementos en la dirección
apuntada por la visión, en el orden de prioridad que necesita el negocio
• Ciclos breves de desarrollo => iteraciones hasta que el producto esté OK

18
• El esquema lo forman cinco fases:
• Concepto
=> Se necesita tener concepto + alcance y compartirlo con todos
• Especulación
=> Requisitos, funcionalidades, plan de entrega, gestión del riesgo
• Exploración
=> Se desarrolla un inc. del producto en base a las funcionalidades
• Revisión
=> Equipo y usuarios revisan el producto contrastando el objetivo
• Cierre
=> Es presumible que el producto necesitará versiones y mejoras

• Métodos que cubren áreas de la Ingeniería del Software:
• AM – Agile Modeling
• FDD – Feature Driven Development
• Lean Software Development
• TDD – Test-Driven Design
• XP – eXtreme Programming
• Métodos que se centran en la gestión del proyecto:
• ASD – Adaptative Software Development
• AUP – Agile Unified Process
• Crystal
• DSDM – Dynamic Systems Development Method
• Scrum
• Xbreed – Agile Enterprise (Scrum + XP)

4. SCRUM

4) Scrum
• Marco para la ejecución de prácticas ágiles en el desarrollo de proyectos
• Propuesto por Takeuchi y Nonaka a mediados de los 80
• En el 95, Ken Schwaber presentó en OOPSLA Scrum para software

4) Scrum
• Control de la evolución del proyecto
• Revisión de las iteraciones
=> Tiempo en detectar una desviación: UN SPRINT
• Desarrollo incremental
=> Al final de cada iteración: parte de producto operativa
• Desarrollo evolutivo
=> Inestabilidad: premisa; arquitectura evolutiva (ciclo, no fases)
• Auto-organización
=> No auto-dirigidos, sino con margen para tomar decisiones
• Colaboración
=> Colaboración abierta según capacidades y no según el puesto
• Visión general del proceso
=> Gracias a los sprints y a herramientas de control visual

4.1 ELEMENTOS DE SCRUM

4) Scrum: elementos
24
HISTORIAS DE USUARIO
Título
Como <rol>
Quiero <funcionalidad>
Para <beneficio>
• Lenguaje coloquial (recordatorio conversación cliente)
• Primero hay que identificar los roles del sistema que se va a construir
• Criterios de Aceptación de las Historias de Usuario: pruebas que debe superar para
ser aceptada como completada
• Son priorizadas por el cliente y estimadas en coste por el equipo
• En la reunión de planificación del Sprint, su desglose en tareas lo realiza el equipo

4) Scrum: elementos
25
HISTORIAS DE USUARIO: EJEMPLOS

4) Scrum: elementos
26
PILA DEL PRODUCTO – PRODUCT BACKLOG
• Inventario de funcionalidades, mejoras, tecnología y corrección de errores que
deben incorporarse al producto a través de las sucesivas iteraciones
• Representa lo que esperan los clientes, usuarios y en general los interesados
• La pila del producto no se da por terminada, está en continua evolución
• Se inicia con un proceso de exploración donde colabora todo el equipo a partir
de la visión del propietario del producto
• No es un documento de requisitos sino una herramienta de referencia
• Al menos debe incluir:
• Identificador único de la funcionalidad
• Descripción de la funcionalidad en lenguaje comercial
• Campo o sistema de priorización
• Estimación

4) Scrum: elementos
27
PILA DEL PRODUCTO – PRODUCT BACKLOG

4) Scrum: elementos
28
PILA DEL SPRINT – SPRINT BACKLOG
• Descompone las funcionalidades de la pila del producto en tareas necesarias
para construir un incremento
• La realizan todos los miembros del equipo, y solo ellos pueden tocarla
• Es visible para todo el equipo en pizarra, hoja de cálculo o herramienta Web
• Incluye lista de tareas, responsable, estado y tiempo de trabajo para cada una

4) Scrum: elementos
29
INCREMENTO
• Parte de producto producida en un sprint
• Está completamente terminada y operativa
• Excepto en el primer sprint, cada funcionalidad de la pila de producto se
refiere a entregables
• Se produce un “incremento” en cada iteración
• Si el proyecto requiere documentación o procesos de validación, es necesario
terminar esto para considerar el incremento finalizado

4) Scrum: elementos
30
RESUMEN
• Historias de usuario
• Pila de producto
• Pila de sprint
• Incremento

4.2 ROLES EN SCRUM

4) Scrum: roles => Product owner
32
• Una única persona del cliente que se integra en el equipo de desarrollo
• Debe conocer el entorno de negocio del cliente, necesidades y objetivos
• Debe poder tomar decisiones
• Debe conocer Scrum para:
• Desarrollar y administrar la pila del producto
• Participar en la reunión de planificación de cada sprint
• Decide cómo será el resultado final, el orden de los incrementos y la prioridad
de las funcionalidades de la pila del producto
• Es responsable de la financiación del proyecto y de las decisiones sobre fechas
y funcionalidades de las versiones

4) Scrum: roles => El equipo
33
• Recomendado entre 4 y 8 personas
• Equipo multidisciplinar en el que no hay un gestor que delimite, asigne y
coordine tareas: todos los miembros participan en las decisiones
• Todos conocen y comprenden la visión del propietario del producto y colaboran
con él en el desarrollo de la pila del producto
• Comparten el objetivo y la responsabilidad de cada sprint
• Todos conocen el modelo de trabajo con Scrum
• Hay un líder del equipo que vela por el cumplimiento de Scrum: el Scrum Master

4) Scrum: roles => Scrum master
34
• Responsable del funcionamiento de Scrum en el proyecto, cubriendo:
• Asesoría y formación al P.O y al equipo
• Revisión y validación de la pila del producto
• Moderación de las reuniones
• Resolución de impedimentos que entorpezcan la ejecución de las tareas
• Gestión de la “dinámica de grupo” en el equipo
• Configuración, diseño y mejora continua de las prácticas de Scrum
Compromiso
Vs
Implicación

4) Scrum: roles
35
RESUMEN
• Product Owner
• Equipo
• Scrum Master

4.3 REUNIONES EN SCRUM

4) Scrum: reuniones

4) Scrum: planificación del sprint
38
• Se planifica el sprint dividiendo la reunión en dos partes
• Primera parte: QUÉ elementos de la pila de producto vamos a incluir
=> Máximo 1 hora
• Segunda parte: se desglosan los elementos para
• Determinar tareas necesarias
• Estimar el esfuerzo de cada una
• Asignarlas a las personas del equipo
=> Máximo 24 horas en las dos partes
• El Scrum Master es responsable de dinamizar esta reunión
• El propietario del producto ya dispone de esta pila y la debate con el equipo

4) Scrum: seguimiento del sprint
39
• Reunión diaria breve de no más de 15 minutos
• Cada miembro del equipo da respuesta a 3 preguntas:
• ¿Qué hiciste ayer?
• ¿Qué vas a hacer hoy?
• ¿Tienes algún impedimento?
• Se recomienda hacer de pie y con el gráfico de avance
• Asiste todo el equipo y pueden asistir oyentes, pero no intervenir
• Al final de la reunión:
• Con las estimaciones actualizadas, el equipo refresca el gráfico de avance
• El Scrum Master se ocupa de gestionar las necesidades y resolver los
impedimentos

4) Scrum: revisión del sprint
40
• La duración máxima es de 4 horas
• Es una reunión informativa que no tiene una misión orientada a tomar
decisiones ni a criticar el rendimiento
• El objetivo es revisar el incremento (prohibido PowerPoint)
• No se debe invertir más de una hora en prepararla
• El P.O. obtiene información sobre el progreso
=> El equipo obtiene feedback clave para la siguiente iteración

4) Scrum: retrospectiva
41
• Reunión opcional que se da al final de cada sprint o al final de cada versión, o
incluso del final del proyecto
• El objetivo de la revisión de sprint es analizar “QUÉ” se está construyendo
=> la retrospectiva se centra en “CÓMO” se está construyendo y trabajando

4) Scrum: reuniones
42
RESUMEN
• Planificación del sprint
• Seguimiento del sprint
• Revisión del sprint
• Retrospectiva

4.4 FICHA RESUMEN DE
SCRUM

4) Scrum: resumen
Ficha mejor calidad: http://bit.ly/1Ijqu67
Scrumen 120 seg: http://bit.ly/1F3wcYL

5. MEDICIÓN, UNIDADES Y
HERRAMIENTAS

5) Medición: unidades y herramientas
46
VELOCIDAD, TRABAJO Y TIEMPO
• El desarrollo ágil emplea la técnica “timeboxing” para la gestión de tiempo
• La unidad de tiempo para cada incremento de producto es el Sprint
• La gestión ágil no mide el trabajo ya realizado, sino el pendiente de realizar
• La gestión ágil suele llamar a las unidades que emplea para medir el trabajo
PUNTOS DE HISTORIA
• Los puntos de historia definen exclusivamente la dificultad de una tarea
• En España, se tiende a trabajar más con horas/persona o días/persona
Velocidad = Trabajo / Tiempo

47
BURN-UP: Gráfico de producto
Velocidad del equipo:
300 puntos de historia

48
Burn-down: Monitorización del sprint

49
Estimación póquer
• James Grenning, de Wingman Software, ideó una práctica ágil para conducir
las reuniones en las que se estima el esfuerzo y la duración de las tareas
• En principio, el modelo inicial se usaba en eXtreme Programming
=> Unidad de esfuerzo: días de trabajo de cada par de programadores

¿Por qué Scrum?
• No todos los proyectos encajan en metodologías ágiles
• Silicon Valley – Scrum:
https://www.youtube.com/watch?v=oyVksFviJVE

6. KANBAN

6) Gestión visual: kanban
52
• La gestión visual introduce en el escenario de trabajo información con
instrucciones para su ejecución o sobre su estado
• Kanban es un sistema de señalización (tablero) para comunicar información
relativa y necesaria en la ejecución o monitorización de un trabajo
• Origen => finales de los 40 en los centros de producción de Toyota en Japón
• A partir de 2005, se populariza como práctica de programación ágil
• No es un modelo o marco de gestión, es una herramienta de señalización. No
tiene formato cerrado de tarjetas o tablero.
• Detección temprana de problemas
• Produce un flujo continuo de trabajo cuyo ritmo no está marcado por una
planificación temporal (procrastinación al inicio, presión al final)

6) Gestión visual: kanban (WIP)
53
• El incremento en kanban ya no es el resultado de un sprint, sino cada historia
que se termina
• Para lograr un flujo continuo de funcionalidades, hay que limitar la cantidad
de trabajo que hay en proceso
• Esto significa limitar el número de tareas que pueden estar simultáneamente
en los diferentes estados de desarrollo (pérdida de foco)
• WIP: número máximo de tareas en un área del tablero
é Cuellos de botella
ê Tiempos muertos

6) Gestión visual: kanban

Gestión ágil de proyectos
Nacho Álvarez
Área de Pagos Inmediatos
31 enero 2017
Redsys, Servicios de Procesamiento, SL.
www.redsys.es
Tel.: +34 91 346 53 00
Fax.: +34 91 346 54 82
Francisco Sancha 12
28034 Madrid – España
RELEASE OFTEN,
RELEASE EARLY

Sysmana 2017 metodologías gestión ágil de proyectos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (19)

Similar a Sysmana 2017 metodologías gestión ágil de proyectos

Similar a Sysmana 2017 metodologías gestión ágil de proyectos (20)

Más de José Ignacio Álvarez Ruiz

Más de José Ignacio Álvarez Ruiz (11)

Último

Último (20)

Sysmana 2017 metodologías gestión ágil de proyectos