Gestion proyectos, metodología ágiles y SCRUM
-
Upload
alejandro-marin -
Category
Technology
-
view
2.603 -
download
5
description
Transcript of Gestion proyectos, metodología ágiles y SCRUM
Metodología ágiles y SCRUMGestión de proyectos
Noviembre 2012Este documento ha sido creado con el fin de servir como introducción a los técnicos y personas que están interesadas en la gestión de proyectos.
Manifiesto ágil:
• “Individuals and interactions over processes and tools”• “Working software over comprehensive documentation”• “Customer collaboration over contract negotiation”• “Responding to change over following a plan”
Jeff Sutherland (a guru) states:
• “Scrum assumes that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression.”
• “Scrum is an enhancement of the commonly used iterative/incremental object-oriented development cycle”
Page 4
Principios y valores ágiles
La prioridad mayor es la satisfacción del cliente haciendo
entregas continuas de software valioso para él
Los cambios son bienvenidos siempre
La medida principal de progreso es el software funcionando
El gestor es un facilitador no un controlador
Equipos auto-organizados y multidisciplinares
Inspeccionar y adaptar
Mejora continua
Respeto, claridad y comunicación
Ritmo sostenible
La arquitectura y diseño emergen
Page 5
Declaración de valores
Individuos e interacciones
Procesos y herramientas
Software que funciona
Documentación exhaustiva
Sobre
Fuente: www.agilemanifesto.org
Page 6
Declaración de valores
Colaboración con el cliente
Negociación de contratos
Responder ante el cambio
Seguimiento de un plan
Sobre
Fuente: www.agilemanifesto.org
Page 7
Nivel de ruido
Fuente: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.
Page 8
Ágil no es hacer lo que quiera
Page 9
Estimación y planificación ágil
Page 10
¿Qué es SCRUM?
No es un acrónimo…
Page 11
¿Qué es SCRUM?
Es el arte de lo posible
Page 12
Scrum significa melé
Melé es un tipo de jugada del deporte Rugby, donde todos los jugadores de ambos equipo se agrupan en una formació, actuando como una unidad y en la cual lucharán por obtener el balón.
¿Qué significa SCRUM?
Page 13
¿Qué significa SCRUM?
La complejidad de una melé hace que:
Si un miembro del equipo se viene abajo, se cae toda le melé.
En consecuencia, los jugadores deben estar bien coordinados, apoyarse en sus compañeros para empujar al mismo tiempo y con ello, avanzar a la misma velocidad.
Page 14
¿Cómo lo definimos?
La Wikipedia define SCRUM una metodología para la gestión y desarrollo de SW basada en un proceso iterativo incremental utilizando comunmente en entornos basados en el desarrollo ágil de SW.
Page 15
• Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de negocio en el menor tiempo.
• Nos permite rápidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes).
• El negocio fija las prioridades. Los equipos se auto-organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad.
• Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorándolo en otro sprint.
Scrum en 100 palabras
Page 16
Sólo abarca prácticas de
gestión sin entrar en las prácticas de
desarrollo como puede hacer XP.
Delega completamente en el equipo la
responsabilidad de decidir la mejor manera de
trabajar para ser lo más productivos posibles y, le
da gran protagonismo a las reuniones que realicen a lo
largo del proyecto.
Sus raíces teóricas están en las teorías
de la auto organización.
Contexto SCRUM
Page 17
Roles
Development Team
Scrum Master
Product Owner
Artefactos
Product Backlog
Sprint Backlog
Burndown Chart
Ceremonias
The Daily Scrum
The Planning meeting
The Sprint Review
The Retrospective
Modelo de referencia
Page 18
Ken Schwaber: “En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el
negocio del cliente y trabajen con malas herramientas...
producirán incrementos periódicos... de basura. ”
Page 19
Cada persona que interviene en el proceso de creación de un producto tiene un rol específico en Scrum.
Roles
• Rol = puesto en la organización• Distinguir entre gallinas y cerdos
Page 20
Roles
Chickens
No son parte formal de los procesos, pero debenser tenidos en cuenta.
Marcan el rumbo del proyecto.
Page 21
Chickens
• Usuarios
• Stakeholders
• Managers
Page 22
Roles
Pigs
Están comprometidos con el proyecto y con elproceso de Scrum.
Hacen que las cosas sean posibles.
Page 23
Pigs
Dueño de Producto
• Recopila especificaciones
• Gestiona la visión
• Prioriza y gestiona la pila de producto (Backlog)
• Acepta las entregas
• Gestiona el roadmap
• Responsable económico
• Interfaz de la organización con Scrum
• “Cerdo con plumas” Cliente
Page 24
Pigs
Scrum Master
Equipo
- Es un facilitador
- Asegura que el proceso se cumple de forma correcta
- Debe ayudar a desbloquear las tareas del equipo
- Mantiene el proceso en marcha
- Estiman el esfuerzo necesario
- Comprometidos con la entrega del producto
terminado
- 5 a 9 personas
- Cubren los roles necesarios para el desarrollo del
proyecto
- Multifuncionales, autónomos y autogestioados
pero responsables ante el dueño del producto
Page 25
Ciclo de vida
Retrospective
Page 26
En Scrum los proyectos avanzan en una serie de “Sprints”
La duración típica es 2–4 semanas o a lo sumo un mes calendario
La duración constante conduce a un mejor ritmo
El producto es diseñado, codificado y testeado durante el Sprint
Sprints
Page 27
Desarrollo secuencial vs superpuesto
Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.
Requisitos Diseño Código Test
En lugar de hacer todo de una cosa a la vez… ...los equipos Scrum
hacen un poco de todo todo el tiempo
Page 28
1. Toma de requisitos al cliente. Para cada requisito principal se crea un bloque de trabajo, llamado historia
2. El cliente ordena los bloques de trabajo en una pila de producto según su prioridad de entrega.
3. El equipo de trabajo toma un grupo de historias, con el que trabajan durante una iteración o sprint.
4. Una vez finalizado un sprint entregan al cliente el resultado del trabajo. Se vuelve al punto 2º hasta terminar la pila de producto.
Page 29
Ciclo de vida
Nueva funcionalidad
Producto. Back log priorizado
Producto. Back log seleccionado
Sprint backlog
Revisión diaria
Iteración
Page 30
Planificación
Predecir el futuro es fácil.
Lo difícil es saber qué es lo que está pasando
ahora
Page 31
Ceremonias
Page 32
Reuniones
Sprint Planning Daily Scrum Sprint Review
Objetivo: Planificación del Sprint
Objetivo: Seguimiento del Sprint
Objetivo: Revisión del Sprint
Reunión previa al inicio de cada sprint donde tomando como base las prioridades y necesidades del producto se determina cuáles y cómo van a ser las funcionalidades que se deben cubrir con esa iteración, en esta se genera el Sprint Backlog
Reunión diaria y breve, de no más de 15 minutos en las que todos los integrantes del equipo dicen las tareas en las que están trabajando, si se han encontrado o prevén encontrarse con algún impedimento, para poder actualizar sobre el Sprint Backlog las tareas realizadas o los tiempos de trabajo que les restan.
Esta reunión se realiza al final del Sprint, de carácter informal con una duración máxima de cuatro horas; el equipo presenta al propietario del producto el incremento construido en el Sprint.
Page 33
Reuniones
Sprint Retrospective
Reunión que se efectúa al finalizar el sprint, esta posee una duración entre 15 a 30 minutos, en ella participa el ScrumMaster, el product owner, el equipo y puede participar los clientes
Continuar haciendo
Dejar de hacer
Comenzar a hacer
Page 34
Evaluación
Si siempre haces lo que siempre has hecho,Casi siempre conseguirás
lo que siempre has conseguido
Page 35
Planificación Sprint
Condiciones para realizar la reunión• El área de Sistemas u organización tienen determinados los recursos
posibles para realizar el sprint• El propietario del producto tiene preparado el backlog del mismo• De ser posible el propietario del producto ya trabajó previamente con el
equipo• El equipo cuenta con un conocimiento de las tecnologías empleadas y del
negocio del producto, suficiente para comprender los conceptos del negocio y poder realizar estimaciones asertivas.
Elementos de entrada• El Producto Backlog• El producto desarrollado hasta la fecha de esta reunión a través de los
sucesivos incrementos (exceptuando esto si se trata del primer Sprint)• Puntos sobre las condiciones de negocio del cliente• Escenario tecnológico empleado
Elementos de salida• Sprint Backlog
• Cada miembro cuenta:- ¿Qué ha hecho el día
anterior?- ¿Qué va a hacer?- ¿Qué problemas o bloqueos
se ha encontrado?• 15 minutos
• Se realizan diariamente• La reunión comienza a su hora (9h.)• Solo hablan los cerdos
Daily Meeting
• Seleccionar el trabajo a realizar
• Identificar todas las tareas del Sprint Backlog
• Lo realiza el equipo basándose en Prioridades marcadas por el product owner y en los esfuerzos que estas requieren.
• De 2 a 4 horas
Sprint planning meeting
• Revisar el trabajo completado
• Demo
• Entorno a las 2 horas
Sprint review meeting
• Impresiones sobre el Sprint
• Lo positivo y negativo
• El Scrum Master debe facilitar que el proceso mejore en el próximo Sprint.
Sprint retrospective
Page 40
Artefactos
Page 41
Product Backlog
• Los requisitos y funcionalidades son capturados como elementos de una lista para planificar el proyecto.
• Divididos en items autocomprobables.
• No es una lista completa y definitiva. Es sólo una estimación inicial de los requisitos, importancia y esfuerzo.
• El Product Owner prioriza.
• Es un documento dinámico que incorpora las constantes necesidades del sistema y se mantiene durante todo el ciclo de vida (hasta la retirada del Sist.).
Page 42
Sprint Backlog
• Se detallan los requisitos del Sprint
• Especifica la serie de tareas que se van a desarrollar según los requisitos señalados.
• Estas tareas se intentan que no excedan de las 8 horas de trabajo.
• Las de mayor duración intentar descomponerlas en Sub-Tareas dentro de ese rango de tiempo.
• Al final del sprint se busca un incremento en la funcionalidad.
Page 43
Burndown Chart
Page 44
Artefactos
Page 45
Conclusiones
Page 46
Conclusiones
• Valor para la organización ante todo,
representado en software funcional
• Es preferible tener el 70% de funcionalidad a
tiempo que tratar de lograr el 100% y fallar.
• No requiere herramientas especiales.
• Requiere disciplina y autogestión.
• Transparencia en los procesos.
Page 47
Conclusiones
• Fomenta el aprendizaje.
• Fácil y rápido de aprender e implementar.
• Facilita la mejora continua.
• Incrementa la productividad.
• Metodología sencilla pero efectiva.
• Visibilidad durante todo el proyecto.
• No existe sorpresas.
Page 48
Scrum no dice como desarrollar, el equipo de desarrollo escoge
la metodología.
Page 49
Compañías que aplican Scrum
Page 50
Más Información…
Page 51
En Internet…
• www.scrumalliance.org
• www.controlchaos.com
• www.chileagil.cl
• www.proyectosagiles.org
Page 52
Literatura…
Agile and Iterative Development: A Manager’s Guide by Craig Larman
Agile Estimating and Planning by Mike Cohn
Agile Project Management with Scrum by Ken Schwaber
Agile Retrospectives by Esther Derby and Diana Larsen
Agile Software Development Ecosystems by Jim Highsmith
Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
Scrum and The Enterprise by Ken Schwaber
User Stories Applied for Agile Software Development by Mike Cohn
Artículos semanales en www.scrumalliance.org
Page 53
Ruegos y Preguntas
Page 54
La persona razonable se adapta al mundo; la no razonable insiste en cambiar el mundo.
Así pues, todo progreso depende de las personas no razonables.
En el momento de la definición…
Page 55
Lo malo de hacer sugerencias inteligentes es que uno corre el riesgo de que se le asigne el
proyecto de llevarlas a cabo.
En el momento de la definición…
Page 56
Para la mente innovadora y creativa, siempre es posible encontrar diez problemas
para cada solución.
En el momento de la definición…
Page 57
No dejes para mañana lo que dejaste para hoy.
En el momento de la definición…
Page 58
Incorporando nueva gente a un proyecto atrasado…
Lo atrasarás aun más.
En el momento de la definición…
Page 59
La gente siempre está dispuesta a haber hecho el trabajo que ya está terminado.
En el momento de la definición…
Page 60
Cuando todo falle, intenta lo que sugirió el jefe del proyecto.
En el momento de la definición…
Page 61
Si te comprometes a algo que es imposible, sigue siendo imposible
aún después de tu compromiso.
En el momento de la planificación…
Page 62
Una estimación exacta es un contrasentido en los términos.
En el momento de la planificación…
Page 63
Lo agradable de NO PLANIFICAR es que los fracasos llegan por sorpresa,
y no están precedidos por semanas de angustia y depresión.
En el momento de la planificación…
Page 64
alexismarin.wordpress.com