Capítulo 12: El cliente cambia de opinión
Capítulo 12: El cliente cambia de opinión
Jueves de la segunda semana. Ana llega con una expresión que el equipo ya empieza a reconocer: la de “tengo noticias”. Los stakeholders quieren swimlanes. Nadie en el equipo las había mencionado hasta ahora. En XP, los cambios no son sorpresas desagradables: son oportunidades de demostrar que el proceso funciona.
Anterior: Collective Code Ownership | Siguiente: Segundo Small Release
El cambio
Ana se sienta con el equipo después del stand-up de la mañana.
Ana (PO): “Los stakeholders quieren swimlanes. Filas horizontales que separen las tarjetas por equipo o por proyecto dentro del mismo tablero.”
Diego (Dev): “¿Swimlanes? Eso cambia toda la estructura del tablero.”
Elena (Dev): “No es trivial. Ahora un tablero tiene columnas. Con swimlanes, tiene columnas Y filas. La tarjeta no está solo en una columna, está en la intersección de una columna y una fila.”
Ana (PO): “Lo sé. Pero el director de operaciones lo pidió en la reunión de ayer. Es importante para él.”
Evaluando el impacto
Carlos pide calma antes de reaccionar.
Carlos (TL): “Ok. Antes de decir que sí o que no, evaluemos. ¿Cuánto esfuerzo representan las swimlanes?”
Elena (Dev): “El dominio necesita un concepto nuevo: la fila o swimlane. La tarjeta necesita saber en qué fila está además de en qué columna. La pantalla necesita un layout de grilla en vez de columnas simples. Yo digo cinco puntos mínimo.”
Diego (Dev): “De acuerdo. Cinco o seis puntos. Es más grande que cualquier story que hayamos hecho.”
Carlos (TL): “Nuestra velocity es cinco puntos por semana. Las swimlanes solas consumen una iteración completa.”
La negociación
Carlos mira a Ana directamente.
Carlos (TL): “Ana, podemos hacer swimlanes. Pero necesito que entiendas el costo. Si metemos swimlanes esta semana, sacamos todo lo demás. La asignación de personas que casi terminamos, los bugs que encontraste ayer, la mejora visual que pediste. Todo se pospone.”
Ana (PO): “¿No pueden hacer todo?”
Carlos (TL): “No. Nuestra velocity es cinco puntos. Las swimlanes son cinco puntos. Cinco más cinco son diez, y nosotros hacemos cinco.”
Diego (Dev): “Es matemática, no negatividad.”
Ana piensa. El equipo espera en silencio. No la presionan. No le dicen qué decidir.
Ana (PO): “¿Y si hacemos una versión simple de swimlanes? ¿Lo más básico que podría funcionar?”
Carlos (TL): “¿Qué es lo más básico?”
Ana (PO): “Que las tarjetas tengan una etiqueta de equipo y se puedan filtrar por equipo. No es una swimlane visual de verdad, pero da la misma información.”
Elena (Dev): “Eso es mucho más simple. Una etiqueta en la tarjeta y un filtro en la pantalla. Dos puntos como mucho.”
Carlos (TL): “Dos puntos. Eso podemos absorberlo esta semana si sacamos la mejora visual.”
Ana (PO): “Hecho. Etiquetas de equipo y filtro esta semana. Swimlanes visuales reales las evaluamos para una iteración futura.”
Re-planning a mitad de iteración
Carlos actualiza el tablero en la pizarra. Saca la tarjeta de mejora visual. Agrega dos tarjetas nuevas: “etiqueta de equipo en tarjeta” y “filtro por equipo en pantalla”.
Diego (Dev): “¿Es normal cambiar el plan a mitad de semana?”
Carlos (TL): “En XP, sí. Kent Beck dice que el plan es una hipótesis, no un contrato. Si la realidad cambia, el plan cambia. Lo que no cambiamos es la disciplina: tests, pair, CI, sustainable pace.”
Elena (Dev): “¿Y si Ana cambia de opinión todos los días?”
Carlos (TL): “Entonces tenemos una conversación sobre cómo eso afecta la velocity. Pero hoy es un cambio legítimo: nueva información de los stakeholders. No es capricho.”
Ana (PO): “Agradezco que me digan la verdad sobre los costos. En mi proyecto anterior, el equipo decía ‘sí, sí’ a todo y después no entregaban nada a tiempo.”
Courage para decir no (y sí)
Carlos reflexiona con el equipo al final del día.
Carlos (TL): “Hoy practicamos Courage de dos formas. Primero, tuvimos el coraje de decir ‘no podemos hacer todo’. Segundo, tuvimos el coraje de decir ‘sí, podemos hacer una versión simplificada’. Courage no es decir no a todo. Es ser honesto sobre lo que es posible.”
Diego (Dev): “Y Ana tuvo coraje al aceptar la versión simple en vez de insistir en lo imposible.”
Ana (PO): “Es más fácil ser valiente cuando confías en el equipo.”
Práctica XP del capítulo
Courage + Planning Game: Kent Beck dedica un capítulo entero al coraje en XP. El coraje en XP no es heroísmo: es honestidad bajo presión. Cuando el cliente pide algo grande, el equipo tiene el coraje de explicar el costo real y ofrecer alternativas. Cuando el cliente acepta la alternativa, demuestra confianza en el equipo. El Planning Game permite re-planificar en cualquier momento porque el plan es ligero: tarjetas en una pizarra, no un documento de 100 páginas.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Trae el cambio, negocia scope, acepta la versión simple |
| Carlos | Evalúa impacto, presenta alternativas, facilita negociación |
| Diego | Estima, apoya la evaluación técnica |
| Elena | Propone la estimación detallada, valida la alternativa simple |
Anterior: Collective Code Ownership | Siguiente: Segundo Small Release