Viernes 12 de Marzo de 2010 09:08
En esta serie de artículos de James Shore ya vimos de qué trata la programación de a pares (una de las técnicas de Extreme Programming más conocidas y debatidas), la relación entre los roles de conductor y navegante, y un conjunto de consejos útiles al momento de aplicar esta técnica.
En este artículo final James Shore responde varias preguntas que suelen surgir al momento de querer implementar la Programación de a Pares, terminando con una conclusión y alternativas para probar.
En el 
Cuando se comienza a trabajar en programación de a pares, es normal sentirse extraño cuando se conduce. Los conductores suelen sentir que el navegante tiene ideas e identifica problemas mucho más rápido que ellos. Y es cierto - el navegante tiene más tiempo para pensar que el conductor. La situación se invertirá cuando el conductor cambie de rol y se convierta en navegante. La programación de a pares se sentirá natural con el tiempo.
Es más divertido de lo que parece: dos programadores en una computadora. Uno conduce, el otro navega. Los roles cambian con fluidez, se comunican constantemente. Juntos, logran terminar el trabajo más rápido de lo que podrían estando solos.
A punto de sentarme junto a mi equipo para otra retrospectiva, estuve leyendo y analizando algunas notas de retrospectivas anteriores en las que participé. Y mirando muchas de estas notas, especialmente de las malas, empecé a darme cuenta de algunos patrones de comportamiento que pueden ayudar o destruir una retrospectiva. Veamos los puntos más importantes.
Hay dos formas conocidas para incorporar métodos ágiles en las organizaciones. Kaikaku (también conocido como "cambio radical") es un método de fuerza bruta para empular todos los cambios que se quiren. Básicamente se tiran las formas viejas y se presenta todo el conjunto de nuevas prácticas.
Extreme Programming (XP) es una disciplina para el desarrollo de software basada en los valores de simpleza, comunicación, feedback y coraje. Reune al Equipo Completo junto a prácticas simples, con el feedback suficiente feedback para permitirle al equipo ver en dónde está y ajustar las prácticas a su situación única.
Una vez que hayamos empezado con la práctica del Scrum Diario, es hora de empezar a darle forma al proceso un poquito más. Veamos 10 consejos para mejorar el Scrum Diario:
Durante los últimos años, la popularidad que alcanzó Scrum generó varios preguntas sobre cómo funciona esta práctica. Y una pregunta recurrente es: ¿existe un lugar para el analista de negocio dentro de una organización Ágil? 
Entre todos armamos Dos Ideas. ¡Gracias por tu colaboración!