Recuerda, el examen tiene tres bloques principales, en la parte 2 hemos visto las métricas, ahora vamos a ver las prácticas.
- Teoría de Scrum
- Prácticas de Kanban
- Métricas de Kanban (En la parte II)
Recuerda, el examen tiene tres bloques principales, en la parte 2 hemos visto las métricas, ahora vamos a ver las prácticas.
Ahora que ya te has leído la parte 1 vamos a profundizar en la estructura del examen.
El examen tiene tres bloques principales:
Así que si vienes del mundo Scrum, ya ves que tienes mucho ganado.
Recuerda la regla principal de la parte I de este artículo:
La guía de Kanban para equipos Scrum va de Scrum, no de Kanban. Esto es vital de cara al examen y a entender conceptos:
Regla fundamental: La guía Scrum no se cambia. No se alteran roles, no se alteran artefactos y no se alteran ceremonias*
* en lo esencial
Esto viene de una historia en Linkedin, De un fallo de mi ego y de ser idiota.
Me empeñé en que sería un examen fácil de superar, al fin y al cabo he estudiado Kanban y estoy certificado en Scrum, ¿Qué podía ir mal? La respuesta es que fallé mi primer intento por poco y la aventura de certificarme acabó costándome el doble.
Así que te voy a evitar el dolor de pagar 400$ por dos intentos, ayudándote un poco con el estudio.
Esto está inspirado en una charla que dí hace poco en la UPV titulada: ¿puedes freír un huevo usando métodos predictivos? Si VUCA y Cynefin no te son familiares, vale la pena que hagamos una breve introducción a ambos:
Voy a intentar demostrarte por qué yo creo que no funciona. Y voy a intentar ser agnóstico en cuanto a metodología y ceñirme a lo más estrictamente necesario del manifiesto ágil.
Bien: las metodologías ágiles implican que el equipo que desarrolla el producto y el cliente trabajen de forma conjunta, esto implica cierto nivel de reuniones de coordinación.
Casi todos los márcos de trabajo ágiles te van a implicar en reuniones de planificación de un ciclo corto y en reuniones de validación de lo producido (ya sea un sprint plan y un sprint review o un replenishment y un delivery planning).
Los Simpson nos regalan escenas épicas que quedan grabadas en nuestra memoria, como la de Skinner con Charlmers y los jamones al vapor.
Imagen de: https://www.flickr.com/photos/luigimengato/ original aquí.
La teoría de Tuckman lleva entre nosotros desde 1965, viene a decir que todos los equipos pasan inevitablemente por una serie de etapas de rendimiento cíclicas:
¿Y qué pinta Scrum en todo esto?
Cuando hacemos algo solemos hacerlo porque creemos en ello y que es algo bueno. Pensamos en el «happy path», en que las cosas irán bien.
En ocasiones la realidad nos da un zasca y nos topamos con efectos y realidades no deseados de nuestras acciones bien intencionadas:
Recientemente he concluido un programa de training como product owner de la Scrum Alliance. No difiere mucho del programa de Scrum máster y me deja más dudas que respuestas.
Sí, la figura del Product Owner está clara (no lo está) su responsabilidad ordenando el backlog, hablando con diferentes stakeholders…
Pero Scrum se centra en el equipo de desarrollo, en sus interacciones, habla de la entrega de valor por parte del equipo, pero se deja cosas importantes.
Si consideramos Scrum parte de un todo tendría dos interfaces claramente definidas, entrada y salida. La entrada es el backlog (y desde aquí tendríamos el upstream) y en la salida tendriamos el «Potentially shippable product increment» o increment directamente. El increment sería el downstream, la entrega, le seguiría el despliegue y la explotación (downstream).
Pequeño juego antes de empezar:
4 frases y cinco nombres comerciales, con más o menos tino, pero sirven para ilustrar que algunas marcas superan al concepto.
Con la agilidad me pasa un poco igual. Vamos a ello, igual te abro los ojos.