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

¿Y dónde juega un analista de negocio en Scrum?

carpeta de documentosDurante 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? 

Leer más...

Consejos para una buena demo

demoEn nuestro grupo trabajamos con Scrum o Kanban, según la dimensión del cambio o proyecto. Con Scrum, al terminar un Sprint convocamos a todos los participantes del proyecto: desarrolladores, arquitecto, dueño del producto, certificadores. Y hacemos una demostración del software que estamos entregando. Con Kanban, hacemos lo mismo al dar por terminada una tarjeta de nuestro tablero.

Llevamos más de un año haciendo demostraciones de nuestros Sprints y algunos meses haciendo demostraciones de lo planificado en nuestro tablero Kanban. ¿Qué aprendimos hasta ahora?

Leer más...

Enójese con los impedimentos

Hacer frente a los impedimentos se convirtió en algo relativamente popular a través de la adopción de la filosofía ágil en las organizaciones. Este texto pretende generar una reflexión sobre cómo los equipos están tratando los impedimentos que aparecen en lo cotidiano. Por lo tanto, en los siguientes párrafos descubrimos porqué se recomienda que se tenga un verdadero sentimiento de enojo de los impedimentos.

Leer más...

Sobrecarga de proyectos: un enemigo invisible

Invisible"Hacer dos cosas a la vez es no hacer ninguna de ellas". - Publilius

"El cerebro es muy similar a un ordenador. Puede tener varias ventanas abiertas en su escritorio, pero sólo puede pensar en ellas una a la vez." - William Stixrude, Doctor en Neuropsiquiatría

Continuando con la serie sobre la gestión de cartera de proyectos, en este artículo trataremos de uno de los principales impedimentos para una mayor generación de valor por parte de los proyectos de IT: la escasez de profesionales y la sobrecarga de personas y recursos financieros.

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