Juegos de pruebas
- Detalles
- Publicado: Domingo, 31 Agosto 2008 00:00
- Escrito por Leonardo De Seta
Sin lugar a dudas, una de las formas más originales de probar un producto, y que he tenido la oportunidad de experimentar este año, es la de jugar con él. Sí, jugar, habéis leido bien. Intentaré explicar el concepto en los siguientes párrafos.
Cuando un producto está llegando a su fecha de lanzamiento empieza el periodo estresante de pruebas exhaustivas. Normalmente, el producto se cerrará en cuando a código fuente y a partir de ahí entrará en proceso de integración y pruebas por parte del equipo de tests. Una vez que termine este período, podremos lanzar nuestra tan esperada versión. Obviamente, nos interesa que cuando el producto llegue a manos del cliente, éste se encuentre impecable y totalmente libre del más mínimo error, problema de rendimiento, agujero de memoria, o cualquier otro efecto indeseable.
Hace un tiempo leí que una de las medidas que Mike Clark promovía en el libro Pragmatic Project Automation es la de mostrar el resultado de las diferentes build de la manera más visible que se pueda.
En muchos artículos sobre scrum, el grafico tradicional 
¿Quién no asisitó alguna vez a alguna presentación que parecería interminable? El tiempo se estira hasta romper cualquier límite físico, el orador divaga sobre cuanto tema crea dominar, y las horas van pasando y pasando. A veces el presentador parece quedar tildado en una diapositiva, hablando y hablando sin parar, exprimiendo los conceptos al máximo (mientras, el público empieza a rogar, silenciosamente, que termine de una buena vez esa bendita diapositiva, con la secreta esperanza de que además sea la última y se de por terminada la 
Un kanban (en kanji 看板 donde kan (看) significa "visual", y ban (板) significa "tarjeta" o "tablero") es un concepto de producción justo-a-tiempo.
Con este artículo pretendo ayudar a aclarar la importancia del 
Se tiene que programar por parejas si se sigue un proceso ágil.
En marzo de 2001 
La recolección, interpretación y medición de los procesos tiene que tener un criterio simple y además tiene que ser de utilidad, esto último quiere decir que si una organización se toma el trabajo de recolectar, interpretar y medir los procesos, entonces seguramente es porque piensa hacer algo con el resultado de ello, o no?
En un día claro y soledado de pronto comenzó un proyecto de desarrollo ágil . El día anterior, alguien imaginó un nuevo sistema y decidió que se debería armar un equipo ágil para construirlo. Esta persona contó la idea a sus colegas, y todos decidieron que sería una excelente idea hacerlo. Afortundamente, había financiamiento disponible y un equipo de desarrollo ágil formado por personas capacitadas estaba esperando para comenzar el trabajo. Con todo el apoyo de los esponsores, financiamiento y la gente adecuada para el trabajo, en medio de un maravilloso acto inaugural el proyecto despegó.
