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”

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

Declaración de valores

Individuos e interacciones

Procesos y herramientas

Software que funciona

Documentación exhaustiva

Sobre

Fuente: www.agilemanifesto.org

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

Nivel de ruido

Fuente: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

Ágil no es hacer lo que quiera

Estimación y planificación ágil

¿Qué es SCRUM?

No es un acrónimo…

¿Qué es SCRUM?

Es el arte de lo posible

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?

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

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

• 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

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

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

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

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

Roles

Chickens

No son parte formal de los procesos, pero debenser tenidos en cuenta.

Marcan el rumbo del proyecto.

Chickens

• Usuarios

• Stakeholders

• Managers

Roles

Pigs

Están comprometidos con el proyecto y con elproceso de Scrum.

Hacen que las cosas sean posibles.

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

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

Ciclo de vida

Retrospective

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

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

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.

Ciclo de vida

Nueva funcionalidad

Producto. Back log priorizado

Producto. Back log seleccionado

Sprint backlog

Revisión diaria

Iteración

Planificación

Predecir el futuro es fácil.

Lo difícil es saber qué es lo que está pasando

ahora

Ceremonias

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.

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

Evaluación

Si siempre haces lo que siempre has hecho,Casi siempre conseguirás

lo que siempre has conseguido

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

Artefactos

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

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.

Burndown Chart

Artefactos

Conclusiones

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.

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.

Scrum no dice como desarrollar, el equipo de desarrollo escoge

la metodología.

Compañías que aplican Scrum

Más Información…

En Internet…

• www.scrumalliance.org

• www.controlchaos.com

• www.chileagil.cl

• www.proyectosagiles.org

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

Ruegos y Preguntas

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…

Lo malo de hacer sugerencias inteligentes es que uno corre el riesgo de que se le asigne el

proyecto de llevarlas a cabo.


Para la mente innovadora y creativa, siempre es posible encontrar diez problemas

para cada solución.


No dejes para mañana lo que dejaste para hoy.


Incorporando nueva gente a un proyecto atrasado…

Lo atrasarás aun más.


La gente siempre está dispuesta a haber hecho el trabajo que ya está terminado.


Cuando todo falle, intenta lo que sugirió el jefe del proyecto.


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…

Una estimación exacta es un contrasentido en los términos.


Lo agradable de NO PLANIFICAR es que los fracasos llegan por sorpresa,

y no están precedidos por semanas de angustia y depresión.


[email protected]

alexismarin.wordpress.com

http://www.presentationpoint.de/

http://www.ppt-vorlagen.de/

gestion proyectos, metodología ágiles y scrum

Technology