En última instancia, Extreme Programming se trata de un conjunto de prácticas y metodologías que conducen a un valor comercial mejorado. La mejor ilustración de esto que he encontrado es de http://c2.com/cgi/wiki?ExtremeProgrammingEnablingChart
Todo en azul es parte del núcleo de XP.
Hay partes que están en el exterior que ayudan a habilitar cosas dentro del área azul y son parte de XP en su conjunto, pero no son críticas para él. Tenga en cuenta que personalmente no soy un profesional de XP y he leído una buena cantidad de críticas a las personas "casi" después de XP que varias personas han dicho que no es XP. Dejemos a un lado ese aspecto del dogma de XP por un momento y veamos lo que tenemos.
Tenga en cuenta que uno de los primeros y para la mayoría de las cosas es tener un compromiso con el proceso por parte del cliente. Un componente clave de XP es la participación del cliente. Esto se muestra en varios puntos, como la planificación de lanzamientos, lanzamientos pequeños, evaluación de clientes externos. Estas son cosas a las que sus clientes deberán suscribirse si va a tener éxito en XP como desarrollador en solitario. Si solicitan un diseño y luego un período de desarrollo y luego pruebas y demás, no tendrá el compromiso de ellos de ir más allá.
XP no significa que no hay planificación. Hay varios puntos en esto en los que la planificación forma parte de ella: priorización, estimación de la historia del usuario, planificación de iteración y definición de tareas. Aunque usted sea un desarrollador en esto, estas son cosas que necesitará para trabajar con su cliente en la entrega.
Puntos como la propiedad colectiva del código y la programación de pares son cosas que involucran a más de uno. Decidir sobre cosas como los estándares de codificación es mucho más fácil, pero eso no significa que no tenga que seguirlos. La propiedad del código colectivo aún se aplica, es solo que la propiedad es también el próximo desarrollador, no escriba código que sea solo para usted y para usted. Tenga en cuenta que esto está en cierto grado de conflicto con el 'código revela toda intención' que se habilita mediante la programación de pares: no tiene esa persona para verificar que está escribiendo un código mantenible, por lo que la documentación del código también es crítica.
Además de esas advertencias, todavía se aplican muchos de los principios de diseño de XP. Cosas como el primer diseño de prueba, integración continua, reuniones con el cliente, refactorización, YAGNI, soluciones puntuales: esas llamadas se pueden hacer en solitario.
Ten en cuenta que los XP en solitario requieren tanta o más disciplina que los XP normales. XP a menudo se considera una metodología de alta disciplina, ya que requiere que las personas mantengan una adherencia rigurosa a las mejores prácticas que intenta incorporar. Cuando no tienes un entrenador u otras personas para apoyar esa disciplina necesaria, puede caer en una mezcolanza de prácticas que tienen cierta semejanza con XP.
Lectura relacionada:
Me gustaría sacar una cita del primero de los enlaces de c2:
Notable luminaria de Perl Language, y científico loco, Damian Conway cree que Extreme Programming es en realidad un nombre inapropiado. Dado que incorpora muchas de las buenas prácticas de programación que se les enseña a los programadores pero que casi con toda seguridad ignoran, él cree que realmente debería haberse llamado Programación ultra conservadora