No sobre-analicen todo. No importa si no saben exactamente cuánto les va a llevar hacer algo, o cómo van a escribir pruebas unitarias perfectas, o cómo van a manejar los datos para las pruebas X, Y, Z. Simplemente, empiecen a hacer. Tomen una serie de tareas pequeñas y empiecen. Lo mejor de tener iteraciones cortas es que tienen la próxima semana van a poder cambiar sus expectativas!
No se vuelvan locos pensando quién será el Scrum Master. De hecho, hagan que este rol rote en todo el equipo. Al principio, cada miembro del equipo tiene que ser Scrum Master por una iteración antes de volver a ser Scrum Master por segunda vez.
Aprendan la votación con cinco dedos. El equipo entero vota cualquier sugerencia que alguien hace. Un dedo significa que odio esa sugerencia y no puedo aceptarla. Cinco dedos significa que me encanta totalmente. Los dedos en medio reflejan distintos niveles de aceptación. Tres dedos muestran que nos resulta indiferente. Buscamos soluciones que junten respuesta de "Me encanta" o "Puedo aceptarlo". Ninguna de las sugerencias son permanentes; en cambio, usaremos experimentos de entre una y tres iteraciones. Siéntanse libres de probar cosas nuevas, y dejar que otros prueben cosas nuevas. No va a durar por siempre, y los buenos equipos eliminan las prácticas que no funcionan.
Tengan reuniones diarias cortas. El Scrum Master las lidera. Usen algún token sencilla (una lapicera, una pelotita) que se pasa entre los miembros. Si lo tienen, pueden hablar. Sino el resto del equipo puede callarnos por no hablar en nuestro turno (¡y hasta puede resultar divertido!). Debemos asegurarnos que cada persona responda las 3 preguntas: ¿Qué hiciste ayer? ¿Qué vas a hacer hoy? ¿Qué problemas tenés?
Usar integración continua para la compilación (¡como mínimo!). Si no tienen builds automáticos, o un servidor de integración continua, usen una "iteración cero" para configurar esta infraestructura. No dejen de hacerlo, los beneficios para el equipo son enormes y es una de los pasos más importantes.
Sólo trabajen en requerimientos estimados rápidamente entre uno y tres días. ¿Tienen una tarea de 6 semanas? Hay que dividirla en piezas más manejables.
Armen un equipo con desarrolladores y testers. Trabajen de a pares cuando escriban pruebas (¡ambos!). Los desarrolladores van a aprender a escribir mejores pruebas, y también los testers.
Tengan una reunión de planificación. El Dueño del Producto, el líder del producto (o quien cumpla con este rol) trae suficiente trabajo para una o dos iteraciones. Rechacen una tarjeta cuando no se pueden poner de acuerdo sobre qué significa la característica, o cómo se prueba que dicha característica. Hagan que el Dueño del Producto tenga la idea más en claro y traiga la tarjeta en una iteración futura.
Todo el trabajo se realiza tiene que realizarse con dos pares de ojos. Pueden lograrlo trabajando de a pares, o con revisiones de compañeros, pero nadie trabaja solo. Esto es tanto para la calidad de código como para compartir el conocimiento (por cierto, si piensan que sus compañeros no son lo suficientemente inteligentes para "entender" nuestro trabajo, el problema es nuestro. Siempre es nuestro. No sean ese tipo de desarrollador).
Agenden una demostración para mostrarle a los demás lo que hicieron durante la iteración. Es una oportunidad para mostrarnos, y dejar que otras partes de la empresa sepan lo que viene.
Por último, relájense. Los miembros del equipo que se viven preocupando con "¿Y qué pasaría si...? ¿Y qué pasa con...? ¿¿Y eso otro?? ¡¡¡Y que vamos a hacer si ocurre aquello!!!"... estos miembros son los que terminan haciendo menos. Simplemente empiecen a trabajar con equipo, y ajusten las iteraciones. Estoy seguro que no sólo lo van a encontrar muy productivo, sino sumamente divertido.
No hay comentarios.:
Publicar un comentario