Scrum: El Señor de los Pardillos

2010 Proyectalis Gestión de Proyectos S.L. Imágenes © 2001–2003 New Line Productions

Scrum y Desarrollo Ágil Santiago, Marzo 2010


Ángel Medinilla Teleco, informático vocacional Trece años en TIC, once como

Project Manager Emprendedor, Blogger, Peregrino Motos, Aikido, WoW, libros,

música, viajes, cocina, cine, comics…

Certified Scrum Master - miembro PMI - Cofundador Agile Spain - Patrocinador Agile Open Spain – Patrocinador Conferencia Agile Spain 2010

[email protected] http://twitter.com/angel_m

http://es.linkedin.com/in/angelm


Consultoría en Gestión de Proyectos de Telecomunicaciones y

Tecnologías de la Información

Nuestra misión es mejorar los resultados de las iniciativas y proyectos desarrollados por

nuestros clientes


Nuestro negocio es

crear diferencias

…


…Y aumentar la Ventaja Competitiva


Algunas referencias


Suficiente con la cuña…


Introducción a Scrum y al desarrollo Ágil

(Gutiérrez, que le veo…)


Presentando…


El Señor Lo quiero para ayer

Incluid 20 cambios gratis

No, esto no es lo que yo quería

Se suponía que esto estaba incluido

No se bien lo que quiero, proponed algo y ya veremos


Los pardillos

Vaya marrón


El producto

¡Grunt!

¡Mi tener que ser compatible IE6!

Yo solo hablar Cobol…

Yo querer cuarto kilo de “dospuntocero”


Rellenad los partes de horas El jefe de

proyecto

El cliente lo quiere para ayer

El cliente quiere 20 cambios gratis

Necesito informes de progreso

Se tiene que poder

Esto lo hacéis en dos “patás” Esto no es lo que

el cliente quería

Se suponía que esto estaba incluido


Hay que acabar con la tiranía del proceso

El Mago Tenemos que incluir calidad en el producto

Hay que eliminar la deuda técnica

Debemos formarnos en nuevas tecnologías

Tenemos que mejorar la vida del equipo


¡Ooops! Los derechos de autor…

Buen rollito, tío, es para la XGN…

Menos mal, gracias Mr. Jackson


En el origen del mundo… Los programadores son desorganizados e indisciplinados… Crearemos una metodología para atarlos a todos en las tinieblas


En el origen del mundo… Tal vez añadamos alguna que otra para causar más confusión aun…

Prince2:


En el origen del mundo…

Ummm… Un poquito más

PMBOK


En el origen del mundo…

Eeeh… Sólo un poquito más

CMMI-ITIL:


En el origen del mundo… Vale, de verdad, sólo otra más… El control es bueno, ¿no?

MétricaV3


Durante eones…

Los proyectos software son un caos, ¡Mwaaa-hahaha!

Plazos excedidos

Presupuestos sobrepasados

Clientes insatisfechos

Funcionalidades no usadas


La revolución

Algo tiene que cambiar. Debemos acabar con la tiranía de la cascada y la creencia de que “esto es asín en tos laos” y “pos se tiene que podé”.

Debemos analizar bien el problema al que nos enfrentamos y proponer soluciones realistas

Tenemos que encontrar el paso sostenible y ser mejores que la competencia para así poder defender el modelo


Primer problema

¡Después de seis meses de desarrollo, me traen algo que no es lo que yo quería…!


Primer problema

Aunque claro, el documento no era muy específico sobre algunas cosas…

Hemos hecho lo que ponía el documento

Hemos tenido que hacer suposiciones

Se ha colado algún malentendido

El cliente no estaba disponible para aclaraciones


Enfoque erróneo

Necesitamos más documentos ¡OMG!


Solución Los desarrolladores y los responsables de negocio deben trabajar juntos a lo largo de todo el proyecto

Hagamos pequeños avances y enseñemos el producto frecuentemente al cliente para detectar desviaciones

El cliente se explicará mejor sobre un producto tangible que sobre un documento escrito


Manifiesto Ágil


Segundo problema:

Lo quiero todo, y lo quiero ya!!

En producción


Segundo problema

Estamos cambiando el contexto constantemente

No podemos hacer dos cosas a la vez

No sabemos por donde empezar

Las prioridades cambian


Solución En realidad una persona sólo puede hacer una cosa cada vez. Mejor que se concentren en hacer lo más importante bien hecho y cuanto antes, y sólo entonces pasar a otra cosa


Solución Dicho de otra forma: ¡todos al Abismo de Helm!


Tercer problema:

Quiero hacer algunos cambios…


Tercer problema

Afectará a nuestra arquitectura

Los cambios son malos, son malos, son malos, son malos, mumblemumble…

El cliente no sabe lo que quiere

Los cambios cuestan y retrasan el proyecto


Enfoque erróneo

No hay problema, tenemos gestión de cambios…

Utilice el formulario A-21 sobre sugerencias de cambios para que nuestros analistas determinen el impacto, emitiendo un informe E-37, que una vez aprobado generará una orden de diseño F-56 y una presupuestación adicional código Carlos-Chorizo-Picante, que a su vez se enviará al cliente para una validación de partida prespuestaria, que se incluirá en la analítica contable del proyecto y en la lista de desviaciones de la línea de base, así como el el registro de lecciones aprendidas y en la base de datos de riesgos…


Enfoque erróneo:

????????????


Solución Cualquier parte del proyecto que no se haya iniciado aún puede ser sustituida por otra de complejidad equivalente


Solución Para ello nuestra ingeniería debe estar preparada para un enfoque ITERATIVO e INCREMENTAL

1 2 3

1 2 3


Solución Pero yo NO PUEDO ESPERAR a la siguiente iteración, necesito los cambios YA!!!!!

El aamo quieeereee, yaaaa, mi tessssoooorooo…


Solución Si interrumpimos al equipo durante la iteración, rompemos el ritmo y la concentración, perdemos productividad, generamos deuda técnica… ¡ESPERA a la siguiente iteración! Si es necesario, haremos iteraciones más cortas

¡Defendamos al equipo!


Cuarto problema

Ya, pero nunca hay tiempo de nada

Podríamos ser mucho mejores; podríamos aprender, investigar, desarrollar herramientas, refactorizar…

No tenemos tiempo, no tenemos tiempo, no tenemos tiempo, mumblemumblemumble…

Siempre cometemos los mismos errores

“Habría que” hacer algunas cosas…


Solución Es necesaria una MEJORA CONTINUA. A intervalos regulares, el equipo debe reflexionar sobre cómo ser más efectivo y productivo. Esto es bueno para el equipo y para el cliente.


Quinto problema

¡Yo necesito mis informes!

¿Cómo voy a imputar costes a los proyectos?

¿Cómo voy a saber si algo va mal?

¿Qué le digo al cliente durante el Sprint?


Quinto problema

Bueno, yo directamente me las invento el viernes por la tarde…

Estamos hartos de hacer informes e imputar horas a los proyectos

¿Desarrollamos o hacemos informes?

Nos pasamos la vida en reuniones…


Solución Esto nos tiene que servir a todos o será eliminado. Informaremos a diario al Jefe de Proyecto, y para ello haremos una reunión diaria de sincronización

Ayer encontré el anillo único, hoy voy a llevarlo a Mordor, mi principal impedimento es un ejército de orcos…


Solución Para no tener que hacer informes todos los días, mantendremos herramientas SIMPLES de gestión visual, de forma que con un simple vistazo se pueda conocer el estado del proyecto

Jeff Sutherland @ Google!


En resumen…

SCRUM


En resumen…

Retrospective


Algunas compañías haciendo Scrum


¿Qué usan las empresas ágiles?

2nd Annual ”State of Agilee Development”

Survey Jun-Jul 2007

3rd Annual ”State of Agile Development” Survey Jun-Jul 2008


Decálogo Scrum 1. Personas 2. No es una bala de plata 3. Retrospectivas, retrospectivas, retrospectivas 4. Control Diario, Scrum diario 5. El producto que funciona es la medida de progreso.

Medimos lo que nos queda, no lo que llevamos hecho 6. El equipo se autogestiona, se autodisciplina y responde

del proyecto – Scrum Master no es un Jefe 7. Desarrollo iterativo e incremental 8. Sólo equipo maneja pila de Sprint, sólo Dueño de

Producto maneja pila de producto 9. Duración fija de Sprints 10. Definir “terminado”


Pendiente Desarrollo Test Terminado Historia Proyecto:

Equipo: Scrum, Demo:

Burn-down::

Release Plan:

Impedimentos:


Y en nuestra próxima charla…


¿Preguntas?

[email protected]


¡Gracias!

[email protected]

Scrum: El Señor de los Pardillos

Business

Transcript of Scrum: El Señor de los Pardillos