Cuando el Scrum Diario de 15 minutos dura más de 15 minutos

Hace unos años llegué como primer día para dar una clase de capacitación de Scrum para una organización que estaba con bastantes problemas en su transición Ágil. Había decidido que debían empezar de nuevo, esta vez con capacitación y coaching, y me pidieron su ayuda. Mientras me estaba presentando, uno de los líderes de proyecto me interrumpió. "Ya probamos Scrum", exclamó, "y no nos gusta".

Leer más...

Consejos y sugerencias para tu primer iteración

Empezar a trabajar por iteraciones puede ser un cambio muy grande (¡y que asusta!) cuando llevamos mucho tiempo desarrollando con otros métodos. Scrum dice cómo llevar adelante el proceso, pero a muy alto nivel. En este artículo, Jared Richardson comparte varios consejos para un equipo que recién comienza a formarse en Scrum, y está a punto de empezar su primera iteración.

Leer más...

TDD no trata sobre las pruebas

Muchas personas confunden a las "metodologías de probar primero" con TDD; es bastante común escuchar comentarios como "la esencia de TDD es escribir primero las pruebas". Y están completamente equivocados, ya que estas afirmaciones no describen para nada a TDD, y sólo hablan sobre el desarrollo con pruebas primero.

Leer más...

Las historias de usuario son más que una tarjeta

Supongamos una tarjeta con la siguiente historia de usuario:

Estadísticas en CSV
Como administrador quiero descargar las visitas a las páginas en formato CSV, para poder graficarlas en Excel.
Estimación: 2

¿Qué está mal en esta historia? Parecería tener todo lo necesario: a) un título corto, b) un tamaño (en este caso, 2), y c) una historia bien escrita usando el formato estándar "Como... quiero... para...". Entonces, ¿qué está mal? ¡Nada! Bueno, casi nada. La tarjeta de la historia de usuario es el punto inicial, pero no es suficiente por si misma.

Leer más...

Programación de a pares: preguntas frecuentes y conclusiones

pregunta-y-lapiz

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.

Leer más...

Programación de a pares: conduciendo, navegando

VWCuando 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.

Leer más...

Programación de a pares: consejos útiles

estrellaEn el primer artículo de esta serie vimos una introducción a la Programación de a Pares, una de las prácticas más conocidas (¡y difíciles!) de Extreme Programming. En el segundo artículo exploramos más en detalle los roles de conductor y navegante, y la relación entre ambos.

En esta continuación, James Shore nos resume un interesante listado de consejos y desafíos que deberemos superar para implementar con éxito esta práctica de desarrollo de software.

Leer más...

Programación de a pares: ayudándonos entre nosotros

Paquete de programasEs 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.

El conductor tipea. Se enfoca en las tácticas - escribir código limpio que compile y funcione. El navegante se enfoca en la estrategia - cómo encaja este código en el diseño general, qué pruebas harán que el código avance, y qué refactors mejorarán la base de código.

Las parejas se auto-gestionan, seleccionan compañeros que puedan ayudar con la tarea en curso. Rotan cada un par de horas para compartir perspectivas y conocimiento.

Leer más...

Kaizen y Kaikaku: ¿cuál usar?

IntercambioHay 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.

Kaizen (conocido como "mejora continua") es un enfoque más suave, progresivo. Se cambia algo aquí, algo allá. Podemos pensarlo como ir agregando una práctica nueva por vez.

Leer más...

Una introducción a Extreme Programming

programaciónExtreme 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.

Vamos a repasar algunos de los conceptos y prácticas más importantes de Extreme Programming.

Leer más...

10 consejos para el Scrum diario

3 personasUna 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: 

Leer más...

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw