Una vez le preguntaron a un matemático joven:
¿Por qué has avanzado tanto en tu carrera en tan poco tiempo?
A lo que el joven estudiante, respondió.
Es que yo estudio a los maestros, no a los alumnos.
-Anécdota del El Viejo.
Pues con Mike Beedle, tuvimos la fortuna de estudiar a una maestro. Hace tiempo quería certificarme como SCRUM MASTER de manera oficial. Es uno de las cosas que El Viejo, me recomendó para el desarrollo de mi carrera. Al fin, hace un par de meses me llegó un correo sobre un curso de certificación avalado por el SCRUM Alliance y apoyado por México First en Aguascalientes! Así que ni tardo ni perezoso me inscribí (estás oportunidades se presentan pocas veces). Softlogik, empresa zacatecana, también envío a dos de sus integrantes, ya tenían 4 certificados como SCRUM MASTER, pero ahora enviaron a dos representantes (Karina y Kike).
El curso tuvo que posponerse un par de semanas, por la agenda del instructor, Mike Beedle. Yo no sabía hasta ese momento que Mike es uno de los co-autores del manifiesto ágil, con 18 AÑOS de experiencia en el uso de SCRUM, en sus propias palabras, después de Jeff Sutherland, el creador de SCRUM fue él quien comenzó a utilizarlo en proyectos de desarrollo de software.
Al iniciar el curso, y hablar un poco de lo que había hecho. De entrada es programador de LISP y Doctor en Física.
Del curso me gustaron varias cosas, a pesar de "haber utilizado SCRUM" durante un par de años y haber leído un par de libros del tema... aprendí mucho del curso... por lo que lo recomiendo ampliamente. Tanto así que creo que es algo que todas las personas relacionadas con el desarrollo de productos de software o de otro tipo de proyectos deben llevar".
INTRO DE SCRUM, porque un marco adaptativo empírico es más adecuado que un marco rígido.
EL CURSO:
1) El argumento científico de que el desarrollo de productos es más eficiente con un marco adaptativo empírico para sistemas abiertos que con un marco rígido definido para sistemas quasi cerrados.
Thomas Kun autor de "The structure of scientific revolution".
- Existe una teoría establecida (los procesos rígidos como PMI, CMMi, RUP, etc.).
- Está teoría tiene problemas y anomalías (Sólo el 16% de estos proyectos tiene éxito).
- Emerge una nueva teoría (los procesos adaptativos empíricos como SCRUM).
- Se prueba que la teoría funciona (El 42% de estos proyectos tiene éxito, 3 veces más).
2) Los antecedents históricos de SCRUM basados en el Sistema de Producción Toyota, en Taichi Ohno en el área de manufactura y los gurús de administración japoneses Nonaka y Takeuchi.
3) La gestión de riesgos en SCRUM.
Mike habló de las siguientes variables de proyecto:
- Tiempos y materiales. Aquí se obtiene el costo por iteración del equipo y se multiplica por el número de operaciones. Riesgo posible: no pago, recursos insuficientes o que el proyecto se alargue.
- Fecha fija. Se establece un porcentaje de para los requisitos obligatorios y se deja un buffer para los deseables. Se agrega un o un buffer adicional al proyecto. Riesgos posibles por no terminar en tiempo: multas, reputación de la empresa, rescisión del contrato o no pago.
- Precio fijo. En el costo fijo una regla es 2 veces la desviación estándar. En un proyecto tiene una probabilidad de terminarse en un 50%, a través de una curva normal se determina en base al histórico y se agrega un buffer de dos veces la desviación estándar. Para el ejemplo, queda casi el doble de tiempo para minimizar el riesgo de no terminar el proyecto. 90% de probabilidad de terminar en tiempo.
- Y proyecto de gobierno (fecha fija, costo fijo y alcance variable). Estos son los proyectos se festeje ahora, llore después. Por el precio más bajo + fecha fija + alcance variable. Para sobrevivir se podría agregar una claúsula de "los cambios" los paga el cliente y no están incluidos y negociar que % de manejo de cambios. En Softlogik el porcentaje es del 35% de lo que resta.
4) La gestión de defectos con SCRUM.
En SCRUM, a través de la integración continua se asegura que se cumplan las pruebas de aceptación del usuario. Según Mike, un equipo que no hace integración continua no hace scrum. Y para ello recomienda contratar a un experto, que ya haya utilizado test driven development. No a un teórico, a alguien que ya lo haya hecho.
En la típica rivalidad contra los modelos de calidad estándar como CMMi, PSP-TSP o RUP, entre otros. Mike siempre tuvo el comentario puntilloso a las preguntas u observaciones de los asistentes:
- He implementado CMMi, PSP... "lo siento por ti".
- PSP es lo mismo que SCRUM... "no, no es li mismo. En SCRUM haces planeación en base a la productividad del equipo en PSP es individual".
- "Da coraje cuando tienes que customizar un marco el 90%".
- "Riesgos se manejan diferente en SCRUM que en PMI".
- "SCRUM es un sistema de retroalimentación"
- "En distintas empresas ya se está pidiendo SCRUM como requisito para subcontrtación de servicios".
- "Del porcentaje total del desarrollo mundial de software menos del 1% se hace con SCRUM, sin embargo en 10 años más del 80% de estos proyectos se realizarán con SCRUM".
- "Scrum se mejora usando Scrum"
- "Como un marco de trabajo de 6 pasos, 3 roles, 2 reportes y 1 documento es tan poderoso".
- "Scrum es una estrategia de 3M para vender más postits".
UN SCRUM MASTER debe de tener un perfil...
"Tiene un ojo social".
"Es mala idea que sea parte del equipo de desarrollo".
ALGUNOS DATOS
Las historias de usuarios son utilizadas el 90% de las empresas que utilizan SCRUM.
99.9% de los clientes requieren un plan de entrega
LIBROS RECOMENDADOS por Mike
- Succeding with Agile de Mike Cohn (me falta por leer)
- Death March... (me falta por leer)
- Blue Ocean... (ya lo leí)
- Lean startup... (he leído algo)
- Entre otros. Pero si los recomienda alguien que sabe, hay que tomarlo en cuenta ;)
La verdad vale la pena la certificación y además, vale la pena desarrollar utilizando SCRUM. Estén atentos, porque primero Dios gestionaremos un curso de SCRUM para los alumnos de Maestría de CIMAT.
