Charla orientada a cualquier informático para que vean cómo se gestionan los proyectos en startups y empresas serias, no es una charla técnica al uso, Introducción a la metodología SCRUM. Casos reales y aplicaciones prácticas.
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
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 2 Gestión ágil de proyectos – 31 enero 2017
enero 2017 > 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…
Madrid https://www.facebook.com/Codemotion-Madrid-505998872792272/ FOSDEM (Free and Open Source Software Devs’ European Meeting) https://fosdem.org Eventos 5 Gestión ágil de proyectos – 31 enero 2017
á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
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 10 Gestión ágil de proyectos – 31 enero 2017
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 15 Gestión ágil de proyectos – 31 enero 2017
• 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 Gestión ágil de proyectos – 31 enero 2017
• 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 ágil de proyectos – 31 enero 2017
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) 19 Gestión ágil de proyectos – 31 enero 2017
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 21 Gestión ágil de proyectos – 31 enero 2017
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 22 Gestión ágil de proyectos – 31 enero 2017
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 ágil de proyectos – 31 enero 2017
• 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 ágil de proyectos – 31 enero 2017
• 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 ágil de proyectos – 31 enero 2017
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 ágil de proyectos – 31 enero 2017
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 ágil de proyectos – 31 enero 2017
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 Gestión ágil de proyectos – 31 enero 2017
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 Gestión ágil de proyectos – 31 enero 2017
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 ágil de proyectos – 31 enero 2017
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 ágil de proyectos – 31 enero 2017
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 ágil de proyectos – 31 enero 2017
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 Gestión ágil de proyectos – 31 enero 2017
• 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 ágil de proyectos – 31 enero 2017
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 ágil de proyectos – 31 enero 2017
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) Gestión ágil de proyectos – 31 enero 2017
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 Gestión ágil de proyectos – 31 enero 2017
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
neonigma
salaboy
yoshidashingo
smt7174
hogelog
eijikominami
oracle4engineer
sadnessojisan
minorun365
sansantech
shigashiyama
kitsuya0828
shumei_ito
csswizardry
philhawksworth
jlugia
keathley
62gerente
rasmusluckow
samanthasiow
reverentgeek
skipperchong
kastner
swwweet
shlominoach
