Cuándo XP funciona

XP fue diseñado para proyectos donde los requisitos cambian con frecuencia. Si no sabes exactamente qué construir, XP te ayuda a descubrirlo.

Señales de alta incertidumbre:

• Los clientes no pueden articular sus necesidades con precisión
• El mercado está cambiando
• Estás construyendo algo nuevo, no replicando algo conocido
• La retroalimentación de los usuarios cambia regularmente las prioridades
• Los competidores están innovando, obligándote a adaptarte

En estos entornos, los enfoques tradicionales fallan. El diseño detallado por adelantado se vuelve obsoleto antes de la implementación. Los lanzamientos grandes no dan en el blanco porque los requisitos cambiaron.

XP abraza el cambio. Los lanzamientos pequeños obtienen retroalimentación rápida. El diseño simple evita la sobreinversión. El juego de planificación se ajusta continuamente. La incertidumbre no es un problema—es esperada.

Si tus requisitos son verdaderamente estables y bien entendidos, XP aún funciona, pero la propuesta de valor es diferente. Obtienes calidad y salud del equipo, pero los beneficios de adaptabilidad son menos pronunciados.

XP brilla cuando el código vivirá por años. La inversión en prácticas técnicas se paga con el tiempo.

Por qué los sistemas de larga duración se benefician de XP:

• Pruebas: Detectan regresiones a medida que el sistema evoluciona
• Refactorización: Mantienen el diseño limpio a medida que los requisitos cambian
• Propiedad colectiva: Distribuyen el conocimiento a medida que los miembros del equipo van y vienen
• Diseño simple: Evitan acumular complejidad
• CI: Mantienen la disciplina de integración a medida que el equipo crece

Si estás construyendo un prototipo que será desechado, la inversión de XP en calidad puede no valer la pena. Pero la mayoría de los "prototipos" se convierten en sistemas de producción. La mayoría del código "temporal" vive por años.

La apuesta: Asume que tu código vivirá más de lo que piensas. Invierte en calidad desde el principio. Si te equivocas, has perdido un poco de tiempo. Si tienes razón (y usualmente la tienes), has ahorrado años de dolor.

XP requiere colaboración cercana. La programación en pares, los juegos de planificación y la propiedad colectiva solo funcionan cuando las personas trabajan bien juntas.

Señales de que tu equipo está listo:

• Las personas se comunican abiertamente, incluso sobre problemas
• Hay confianza entre los miembros del equipo
• Las personas se ayudan entre sí sin que se les pida
• Los desacuerdos se resuelven de manera constructiva
• El equipo tiene seguridad psicológica

Si tu equipo carece de estas cualidades, las prácticas de XP se sentirán forzadas e incómodas. Puede que necesites construir la salud del equipo antes de adoptar XP—o usar las prácticas de XP para construir la salud del equipo gradualmente.

XP puede mejorar la colaboración, pero no puede forzarla. Un equipo de personas que no compartirán código no abrazará repentinamente la propiedad colectiva. Un equipo con miedo de admitir errores no se beneficiará de la transparencia.

La cultura tiene que apoyar las prácticas—o al menos estar dispuesta a cambiar.

XP requiere un cliente disponible—alguien que pueda responder preguntas, tomar decisiones de prioridad y proporcionar retroalimentación.

Sin disponibilidad del cliente:

• Los desarrolladores adivinan los requisitos (a menudo incorrectamente)
• Las prioridades no están claras (todo parece importante)
• La retroalimentación llega demasiado tarde (las funcionalidades se construyen mal)
• El juego de planificación no puede funcionar

Disponibilidad del cliente significa:

• Preguntas respondidas en horas, no días
• Decisiones de prioridad tomadas cuando se solicitan
• Retroalimentación regular sobre el trabajo entregado
• Compromiso con el proceso de planificación

Si tus clientes no están disponibles, XP se vuelve difícil. Puedes usar un propietario de producto como intermediario, pero alguien debe desempeñar el rol de cliente de manera efectiva.

La disfunción organizacional a menudo previene la disponibilidad del cliente. El cliente está demasiado ocupado, demasiado político o demasiado distante. Estos son problemas organizacionales a resolver, no problemas de XP.

Algunas prácticas de XP asumen contextos modernos de desarrollo de software. Pueden necesitar adaptación en otros entornos.

TDD asume:

• Puedes escribir pruebas automatizadas (no todos los entornos lo soportan fácilmente)
• Las pruebas se ejecutan rápidamente (las pruebas lentas hacen que TDD sea doloroso)
• Existe la cultura de pruebas (el equipo cree en las pruebas)

CI asume:

• El código puede integrarse con frecuencia
• La construcción y las pruebas pueden automatizarse
• El desarrollo basado en trunk es factible

La programación en pares asume:

• El trabajo ocurre en una computadora
• Dos personas pueden ver la misma pantalla
• El trabajo se beneficia de la colaboración en tiempo real

En la mayoría del desarrollo de software, estos supuestos se cumplen. Pero sistemas embebidos, código dependiente de hardware o entornos altamente regulados pueden necesitar adaptación de prácticas.

Los principios permanecen. Las prácticas específicas pueden cambiar.