Post on 20-Mar-2017
Gestión ágil de proyectos
Nacho ÁlvarezÁrea de Pagos Inmediatos
31 enero 2017
Redsys,ServiciosdeProcesamiento,SL.www.redsys.es
Tel.:+34913465300Fax.:+34913465482
FranciscoSancha1228034Madrid– 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ágildeproyectos– 31enero2017
Involucrado en la Innovación de soluciones de medios de pago
Acerca de mi
3Gestiónágildeproyectos– 31enero2017
Acerca de mi
4Gestiónágildeproyectos– 31enero2017
> 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órdobahttps://www.facebook.com/GDGCordobaESP/
Hack&Beers Córdobahttps://twitter.com/hackandbeers
BetaBeers Córdobahttps://twitter.com/betabeersODB
Codemotion Madridhttps://www.facebook.com/Codemotion-Madrid-505998872792272/
FOSDEM (Free and Open Source Software Devs’ European Meeting)https://fosdem.org
Eventos
5Gestiónágildeproyectos– 31enero2017
Eventos
6Gestiónágildeproyectos– 31enero2017
Índice
7
1. Gestión de proyectos predictiva2. El manifiesto ágil3. Ciclo de desarrollo y modelos de gestión ágil4. 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ágildeproyectos– 31enero2017
El origen
8
Fuente: Standish Group
Gestiónágildeproyectos– 31enero2017
1. GESTIÓN DE PROYECTOS PREDICTIVA
9Gestiónágildeproyectos– 31enero2017
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
10Gestiónágildeproyectos– 31enero2017
1) Gestión de proyectos predictiva
NOPLAN???RELAXTIME!!!
11Gestiónágildeproyectos– 31enero2017
1) Gestión de proyectos predictiva
:’(
12Gestiónágildeproyectos– 31enero2017
1) Gestión de proyectos predictiva
13Gestiónágildeproyectos– 31enero2017
2. EL MANIFIESTO ÁGIL
14Gestiónágildeproyectos– 31enero2017
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
15Gestiónágildeproyectos– 31enero2017
3. CICLO DE DESARROLLO Y MODELOS DE GESTIÓN ÁGIL
16Gestiónágildeproyectos– 31enero2017
3) Ciclo de desarrollo y modelos de gestión ágil
17
• El equipo produce de forma continua incrementos en la direcciónapuntada por la visión, en el orden de prioridad que necesita el negocio
• Ciclos breves de desarrollo => iteraciones hasta que el producto esté OK
Gestiónágildeproyectos– 31enero2017
3) Ciclo de desarrollo y modelos de gestión ágil
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
Gestiónágildeproyectos– 31enero2017
3) Ciclo de desarrollo y modelos de gestión ágil
• 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)
19Gestiónágildeproyectos– 31enero2017
4. SCRUM
20Gestiónágildeproyectos– 31enero2017
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
21Gestiónágildeproyectos– 31enero2017
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
22Gestiónágildeproyectos– 31enero2017
4.1 ELEMENTOS DE SCRUM
23Gestiónágildeproyectos– 31enero2017
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
Gestiónágildeproyectos– 31enero2017
4) Scrum: elementos
25
HISTORIAS DE USUARIO: EJEMPLOS
Gestiónágildeproyectos– 31enero2017
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
Gestiónágildeproyectos– 31enero2017
4) Scrum: elementos
27
PILA DEL PRODUCTO – PRODUCT BACKLOG
Gestiónágildeproyectos– 31enero2017
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
Gestiónágildeproyectos– 31enero2017
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
Gestiónágildeproyectos– 31enero2017
4) Scrum: elementos
30
RESUMEN• Historias de usuario• Pila de producto• Pila de sprint• Incremento
Gestiónágildeproyectos– 31enero2017
4.2 ROLES EN SCRUM
31Gestiónágildeproyectos– 31enero2017
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
Gestiónágildeproyectos– 31enero2017
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 MasterGestiónágildeproyectos– 31enero2017
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
CompromisoVs
Implicación
Gestiónágildeproyectos– 31enero2017
4) Scrum: roles
35
RESUMEN• Product Owner• Equipo• Scrum Master
Gestiónágildeproyectos– 31enero2017
4.3 REUNIONES EN SCRUM
36Gestiónágildeproyectos– 31enero2017
4) Scrum: reuniones
37Gestiónágildeproyectos– 31enero2017
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
Gestiónágildeproyectos– 31enero2017
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
Gestiónágildeproyectos– 31enero2017
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
Gestiónágildeproyectos– 31enero2017
4) Scrum: retrospectiva
41
• Reunión opcional que se da al final de cada sprint o al final de cada versión, oincluso 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
Gestiónágildeproyectos– 31enero2017
4) Scrum: reuniones
42
RESUMEN• Planificación del sprint• Seguimiento del sprint• Revisión del sprint• Retrospectiva
Gestiónágildeproyectos– 31enero2017
4.4 FICHA RESUMEN DE SCRUM
43Gestiónágildeproyectos– 31enero2017
4) Scrum: resumenFicham
ejorcalidad:http://bit.ly/1Ijqu67Scrum
en120seg:http://bit.ly/1F3wcYL
44Gestiónágildeproyectos– 31enero2017
5. MEDICIÓN, UNIDADES Y HERRAMIENTAS
45Gestiónágildeproyectos– 31enero2017
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
Gestiónágildeproyectos– 31enero2017
5) Medición: unidades y herramientas
47
BURN-UP: Gráfico de producto
Velocidad del equipo:300 puntos de historia
Gestiónágildeproyectos– 31enero2017
5) Medición: unidades y herramientas
48
Burn-down: Monitorización del sprint
Gestiónágildeproyectos– 31enero2017
5) Medición: unidades y herramientas
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
Gestiónágildeproyectos– 31enero2017
¿Por qué Scrum?
• No todos los proyectos encajan en metodologías ágiles• Silicon Valley – Scrum:
https://www.youtube.com/watch?v=oyVksFviJVE
6. KANBAN
51Gestiónágildeproyectos– 31enero2017
6) Gestión visual: kanban
52
• La gestión visual introduce en el escenario de trabajo información coninstrucciones para su ejecución o sobre su estado
• Kanban es un sistema de señalización (tablero) para comunicar informaciónrelativa 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)
Gestiónágildeproyectos– 31enero2017
6) Gestión visual: kanban (WIP)
53
• El incremento en kanban ya no es el resultado de un sprint, sino cada historiaque se termina
• Para lograr un flujo continuo de funcionalidades, hay que limitar la cantidadde trabajo que hay en proceso
• Esto significa limitar el número de tareas que pueden estar simultáneamenteen los diferentes estados de desarrollo (pérdida de foco)
• WIP: número máximo de tareas en un área del tablero
é Cuellosdebotella
ê Tiemposmuertos
Gestiónágildeproyectos– 31enero2017
6) Gestión visual: kanban
54Gestiónágildeproyectos– 31enero2017
Gestión ágil de proyectos
Nacho ÁlvarezÁrea de Pagos Inmediatos
31 enero 2017
Redsys,ServiciosdeProcesamiento,SL.www.redsys.es
Tel.:+34913465300Fax.:+34913465482
FranciscoSancha1228034Madrid– España
RELEASE OFTEN,RELEASE EARLY