Participando en el curso Certified ScrumMaster...

Los días martes y miércoles, participé del curso de certificacion internacional: Certified ScrumMaster (CSM), impartido por el facilitador (como asi dicen ahora a la 'nueva' generacion de instructores :)) Alan E. Cyment, en Cochabamba - Bolivia.

Si quieren saber más de la certificacion pueden ver el link arriba, y si quieren saber más de Scrum encuentren información basica acá.

Bueno el curso en si consta de 2 dias (8 horas por día), bastante interactivo al comienzo, que ayuda al asistente (o en mi caso, a mí) a entender mucho mas los problemas actuales y como los procesos ágiles y scrum pueden ayudar en algunas cosas.

Claro que el 'goal' o la meta final es que tu cambies de paradigmas (o forma de pensar) como así todo tu grupo de trabajo también para que pueda aplicarse correctamente, y una vez realizado este cambio yo creo que si es una forma muy interesante y eficiente de llevar a cabo un proyecto.
Acá paso algunas notas de lo que ocurrió estos 2 dias (recuerden que cada curso de SCM es diferente asi que estas son notas de lo que yo vivi estos dias):

Día 1:

Empieza con un juego entre todos, para que todos sepan que es organizarse y como es la estimacion, se observa los problemas de tener muchos hablando y pocos escuchando, es interesante ver cuando los que no hablan toman la palabra y dan sus ideas y al final optimizar el proceso para poder dar una estimacion mejor con una organizacion mucho mejor.

Con esto se da paso al curso para entender lo que se llevara y se dan conceptos básicos pero fundamentales de Scrum y sobre la visión.

Resumiendo Scrum es: es simple, funciona y es dificil (que se ve esto a lo largo del curso)

Sobre la visión, se da una interesante actividad para luego colocar la visión que quiere el equipo (o asistentes) sobre el curso y siempre se revisa si lo que se está haciendo en el curso es para llegar a esa visión.

Otro punto interesante es sobre la teoría de los cuadrantes de William E. Schneider, en su libro The Reingeneering Alternative: A Plan for making your current Culture work. Que en resumen trata que cada organizacion debe situarse en uno de los cuadrantes definidos por: presente-futuro y por los objetivos-personas, en si la teoria dice que una organizacion debe sacar provecho del cuadrante que se encuentra y no intentar cambiar, sino expotar su potencionalidad en ese mismo, como se ve en el grafico (foto) scrum se situaria en el cuadrante superior izquierdo, en el de la cooperacion.

Otra actividad muy interesante es sobre el error, como uno se siente cuando comete el error y como esto debe cambiar (en la organizacion y en el equipo) para que uno se sienta libre de cometer y aprender de estos.

Bueno después de esto, se continua con una teoría más extensa de scrum llamado el "espíritu de scrum" que enumero a continuación:

• Confianza
• Auto-organizacion
• Empirismo
• Priorizacion
• Pragmatismo
• Idealismo
• Excelencia (Tecnica)
• Compromiso
• Transparencia
• Ritmo (sostenible)
• Disciplina
• Honestidad
• Colaboracion
• Feedback positivo

y el lubricante de todo esto es el error.

Acá la actividad siguiente fue interesante porque había que encontrar de cada uno que es lo que esta fallando (personalmente) en cada uno de estos puntos del espíritu de scrum. Es interesante porque te dá la oportunidad de ver si realmente entendiste cada uno de estos, solo citare algunos como ejemplo: en la Auto-Organizacion: dejas al equipo que se autoorganize?, o tu buscas organizarlos como mejor te parece?, estas siempre queriendo decidir quien es el lead o lider del grupo?, o esperas a que un lider salga del equipo para una situacion particular?, etc. Estas son preguntas que te puedes hacer para ver en que fallas.

Otro ejemplo en el idealismo, en general se refiere a que uno acepta las cosas como estan aunque saben que no estan correctas, no se animan a dar el paso, quiza porque nos encontramos en una zona de comfort, y hacerlo (para mejorar) dara un mayor esfuerzo. Se resume en saber que esta mal pero no te animas a hacerlo. Personalmente creo que esto pasa un monton de veces y es una forma de actuar (como se dijo antes de Scrum) que desafia los paradigmas actuales.

Después de esta actividad ya se pasa a muchas más teoría de Scrum revisando la dinámica de Scrum (3 roles: Scrum Master, Equipo y el Product Owner), los Artefactos (Product Backlog, user stories, ROI), la Planificacion (Iteration, slices), la estructura de Scrum (sprint, como se encuentra la visión, etc. etc.). Los puntos más interesantes para mí:

1) El daily meeting no resuelve problemas sino se deriva a un meeting especial donde se va a resolver los problemas
2) Daily meeting solo debe durar maximo 15 minutos.
3) El equipo es el que decide caunto puede hacer en un lapso fijo de tiempo
4) No existe el 'no pude hacer porque no tuve tiempo'.
5) Potentially Shippable Product Increment

Después de la teoría y discusión, se hizo interesante plantear desde ese momento las siguientes 'clases' o charlas utilizando Scrum, asi que cada uno (como también el facilitador) escribe todos los siguientes temas en posticks, nosotros (cada uno de los inscritos) coloca un punto (de 4) a cada uno de los tópicos y al final el tópico que más puntos tenga es el más importante o el que se desarrollara de acá en adelante.

Y asi que de toda la priorizacion que hicieron se decidio comenzar con la Estimación.

Este tópico de Estimación es muy interesante ya que dicen que lo mejor es no estimar con tiempo (ya que pueden fallar facilmente) sino mas bien por pesos (Kg.!), asi saben que mayor peso es mas complejo, en general el equipo se inventa su medida relativa y las estimaciones de un equipo es totalmente diferente a otro equipo asi que no se puede comparar. Recordar entonces que las estimaciones las realiza el equipo, se presento como se realiza (votación) pero todos tienen que estar de acuerdo en esto y luego discutir esto para evitar que se influencien antes de tiempo. El tema de Estimación va mas allá de lo que se puede escribir pero lo que hay que recordar que es un tema bastante complejo y como enfoca Scrum es muy interesante solo falta saber cómo se hace para convertir en medida de tiempo al final :D.

Termina el día con una actividad de estimación, donde se ve la aplicabilidad de usar los pesos (Kg.) para este como así llegar a la unanimidad del equipo para tareas especificas.

Día 2:

Ultimo día del curso y empezó mostrando las cartas del planning poker, que se utiliza para las estimaciones, muy util y pueden ver los detalles de las cartas que se utiliza aca.

Luego se dio paso a lo que es Open Space que es una manera "nueva" (ágil) de hacer conferencias o congresos donde no hay un temario definido y realmente es un cambio de paradigma grande, sin embargo me parece que si puede representar a lo que pasara en un futuro y es bueno saber las bases. Este video (gracias a Alan que me permitió presentarlo en el blog) lo publicare en los proximos dias.

Se continuó con el Release Planning, otro tema donde observa 2 charts que son utiles en Scrum, el Velocity Chart donde se representa la velocidad que tiene el equipo en el tiempo, graficando lo estimado y lo real, no se espera que ambas lineas sean iguales pero por lo menos que vayamos acercadonos a la estimacion que se realizo.

Otro Gráfico es el Burn Down Stories (en Kg.), para ver cuanto faltaría para acabar representado en pesos. Donde en este grafico la pendiente de la recta marcara la velocidad del equipo.

Lo más importante yo creo es saber cuánto el equipo soporta de carga o su capacidad de carga del equipo (como ejemplo saber que el equipo puede hacer 20Kg. por sprint) y así pueden estimar mucho mejor y acercarnos más a la productividad que realmente hace el equipo especifico. Hay que recordar que este valor no se compara con otros equipos, es único del equipo y solo sirve al equipo.

Otro tema interesante es el del Daily Meeting, que para ejemplificar se realizo una actividad (como teatro) donde 2 integrantes representaban al equipo de desarrollo, otros 3 al equipo de QE (testers) 1 Product Owner y 1 Scrum Master, con roles definidos que el facilitador nos decia. Muy interesante ver la obra para saber cómo no deberia llevarse un daily meeting. Ya se hablo del daily meeting el dia anterior (Ver notas anteriormente), asi que fue llevado mas a una actividad esta vez.

Diseño Emergente, que estuvo bajo el nombre de Diseño y Programación, lo interesante acá es la analogía que presenta desde la perspectiva de lo que es la metodología cascada con una forma muy ágil de realizar. El ejemplo que se presentó es sobre pintar/crear un cuadro, imagínense si tendría que hacer un cuadro que consiste de una cara con un fondo donde esta un árbol y un rio. Si primero se haría con metodología de cascada se tendría todo el diseño listo y cuando se empezaría a pintar (o implementar) y se acaba el tiempo no se tendría un valor de negocio, es decir que al cliente no le serviría todo el trabajo realizado, de la misma manera si uno piensa sin hacer un previo análisis (o una arquitectura) y empieza a dibujar los ojos, la boca, nariz, etc., de una manera “buena”, pero sin un orden se tendría todo menos una cara (un ojo donde debería ser la boca, la nariz donde estaría la oreja, etc.), es así que un diseño ágil es una mezcla donde se realiza el Zoom-in y el Zoom-out. Entonces Cuando se hace diseño/arquitectura en scrum?, la respuesta es todo el tiempo o permanentemente. Así en nuestro ejemplo se haría un enfoque sobre solo un ojo y un bosquejo de cómo sería la cara, y así en cada sprint podría entregarse al cliente y el ver un valor de negocio y ver si es lo que realmente quiere o no, luego se va completando el otro ojo y se hace un bosquejo de la boca y las orejas, luego se completa la boca y las orejas y se realiza el bosquejo del fondo (árbol, rio), etc., y así sucesivamente.
Otro consejo fue que sería bueno utilizar lenguajes de desarrollo con menor complejidad accidental. Como por ejemplo smalltalk. Donde teóricamente te olvidas del código fuente, de compilar, etc.
Finalmente unas pequeñas ayudas que vienen de XP:
YAGNI: You Aren't Gonna Need It - No codificar algo que no van a utilizar hoy. (sólo lo mínimo indispensable que cumple con el user story).
KISS: Keep it Simple, Stupid.
No hacer Gold platting, donde se pretende que cuando esta terminado no lo vayan a sacar un poco ‘mas de brillo’, es decir que sean espartanos (-vivir con lo mínimo indispensable-)Y recordad que código ágil no quiere decir código malo.

Ya sobre el final se toca la planificación táctica, que lo realiza el equipo y acá se muestra el taskboard como su nombre lo indica es un cuadro donde se colocan los estados de las tareas. Esto se divide: A la izquierda todos los user stories que está trabajando el equipo y luego las columnas en estados de pendiente, en progreso y listo. El objetivo es que cada una de esas tareas (que se ven con diferentes colores usando post-it – ver foto) y que tienen duración de ½ o 1 día, los ingenieros del grupo lo toman y lo van pasando (manualmente y cada uno) del estado pendiente a En progreso, para así al día siguiente (en su daily scrum) puedan revisar la tarea y pasarla a la columna de Listo. Es interesante separar por colores (solo ejemplo) siendo el amarillo testeo, el verde desarrollo, etc. Así con una visión rápida al taskboard te puedes dar cuenta que es lo que está faltando o donde están los problemas o los posibles problemas, esto terminara cuando todos los post-it pasen a la columna “Listo”. Por lo que hay que trabajar bastante en la granularidad de las tareas. Otra herramienta que hay que tomar en cuenta y ver como se podría adaptar para algunos proyectos que cada uno de nosotros está trabajando.

Algunas actividades en medio de estas charlas incluyen la de criterio de listo (en las fotografías verán un montón de sillas) donde cada grupo tenia un objetivo pero no podían hablar así que cada uno jalaba a su lado, cuando en si todos los equipos tenían un objetivo que se podía alcanzar si hablábamos.

Otra actividad el de Auto-Organización donde se realizo la actividad llamada "spaguetti", muchas fotografías se incluyen en el álbum de CSM.

Y termina el curso con una actividad de simulación de Scrum que es como un resumen de lo que uno aprendió e intenta aplicar scrum para explicar scrum :D.

Con esto termina esta ayuda memoria o resumen de lo que fue este curso. Más fotografías del curso CSM, lo encontraras acá en el album de CSM.