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

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


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ó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


Eventos


Í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


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



NOPLAN???RELAXTIME!!!



:’(


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ó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



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 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


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, 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


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: resumenFicham

ejorcalidad:http://bit.ly/1Ijqu67Scrum

en120seg: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 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)


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


6) Gestión visual: kanban


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

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

Business