planificación del juego
la planificación de XP aborda dos preguntas clave en el desarrollo de software: predecir lo que se logrará antes de la fecha de vencimiento y determinar qué hacer a continuación. El énfasis está en dirigir el proyecto – que es bastante sencillo – en lugar de en la predicción exacta de lo que será necesario y cuánto tiempo tomará-que es bastante difícil., Hay dos pasos clave de planificación en XP, abordando estas dos preguntas:
La planificación de versiones es una práctica donde el cliente presenta las características deseadas a los programadores, y los programadores estiman su dificultad. Con las estimaciones de costos en la mano, y con el conocimiento de la importancia de las características, el cliente establece un plan para el proyecto. Los planes de lanzamiento iniciales son necesariamente imprecisos: ni las prioridades ni las estimaciones son realmente sólidas, y hasta que el equipo comience a trabajar, no sabremos qué tan rápido Irán., Sin embargo, incluso el primer plan de lanzamiento es lo suficientemente preciso para la toma de decisiones, y los equipos de XP revisan el plan de lanzamiento regularmente.
La planificación de iteración es la práctica mediante la cual se da dirección al equipo cada dos semanas. Los equipos de XP crean software en «iteraciones» de dos semanas, entregando software útil al final de cada iteración. Durante la planificación de iteraciones, el cliente presenta las características deseadas para las próximas dos semanas. Los programadores las desglosan en tareas y estiman su costo (a un nivel de detalle más fino que en la planificación de versiones)., Basado en la cantidad de trabajo realizado en la iteración anterior, el equipo se inscribe para lo que se llevará a cabo en la iteración actual.
estos pasos de planificación son muy simples, pero proporcionan muy buena información y un excelente control de dirección en manos del cliente. Cada dos semanas, la cantidad de progreso es totalmente visible. No hay un «noventa por ciento hecho» en XP: una historia de fondo se completó, o no lo fue., Este enfoque en la visibilidad resulta en una pequeña paradoja: por un lado, con tanta visibilidad, el cliente está en condiciones de cancelar el proyecto si el progreso no es suficiente. Por otro lado, el progreso es tan visible, y la capacidad de decidir lo que se hará a continuación es tan completa, que los proyectos de XP tienden a entregar más de lo que se necesita, con menos presión y estrés.
pruebas del cliente
como parte de la presentación de cada característica deseada, el cliente XP define una o más pruebas de aceptación automatizadas para mostrar que la característica está funcionando., El equipo construye estas pruebas y las utiliza para demostrar a sí mismos, y al cliente, que la función se implementa correctamente. La automatización es importante porque en la prensa del tiempo, las pruebas manuales se omiten. Es como apagar las luces cuando oscurece la noche.
los mejores equipos de XP tratan las pruebas de sus clientes de la misma manera que hacen las pruebas de programador: una vez que se ejecuta la prueba, el equipo la mantiene funcionando correctamente a partir de entonces. Esto significa que el sistema solo mejora, siempre muescas hacia adelante, nunca retrocede.,
lanzamientos pequeños
los equipos de XP practican lanzamientos pequeños de dos maneras importantes:
primero, los lanzamientos del equipo se ejecutan, el software probado, entregando valor de negocio elegido por el cliente, cada iteración. El cliente puede utilizar este software para cualquier propósito, ya sea evaluación o incluso lanzamiento a los usuarios finales (muy recomendable). El aspecto más importante es que el software es visible, y el cliente, al final de cada iteración. Esto mantiene todo abierto y tangible.
en segundo lugar, los equipos de XP también lanzan a sus usuarios finales con frecuencia., Los proyectos web de XP se lanzan tan a menudo como diariamente, en proyectos internos mensualmente o con más frecuencia. Incluso los productos con envoltura retráctil se envían tan a menudo como trimestralmente.
Puede parecer imposible crear buenas versiones con esta frecuencia, pero los equipos de XP de todo el mundo lo están haciendo todo el tiempo. Consulte Integración Continua para obtener más información sobre esto, y tenga en cuenta que estas versiones frecuentes se mantienen confiables debido a la obsesión de XP con las pruebas, como se describe aquí en pruebas de clientes y desarrollo basado en pruebas.
diseño Simple
los equipos de XP crean software con un diseño simple pero siempre adecuado., Comienzan de manera simple, y a través de las pruebas de programación y la mejora del diseño, lo mantienen de esa manera. Un equipo de XP mantiene el diseño exactamente adecuado para la funcionalidad actual del sistema. No hay movimiento desperdiciado, y el software siempre está listo para lo que sigue.
El diseño en XP no es una cosa de una sola vez, o una cosa inicial, es una cosa de todo el tiempo. Hay pasos de diseño en la planificación de versiones y la planificación de iteraciones, además de que los equipos participan en sesiones de diseño rápidas y revisiones de diseño a través de la refactorización, a lo largo de todo el proyecto., En un proceso incremental e iterativo como la programación extrema, un buen diseño es esencial. Es por eso que hay tanto enfoque en el diseño a lo largo de todo el desarrollo.
programación de pares
todo el software de producción en XP está construido por dos programadores, sentados uno al lado del otro, en la misma máquina. Esta práctica asegura que todo el código de producción sea revisado por al menos otro programador, y da como resultado un mejor diseño, mejores pruebas y mejor código.
Puede parecer ineficiente tener dos programadores haciendo «el trabajo de un programador», pero lo contrario es cierto., La investigación sobre la programación por pares muestra que el emparejamiento produce mejor código en aproximadamente el mismo tiempo que los programadores que trabajan solos. Así es: ¡dos cabezas son mejor que una!
algunos programadores se oponen a emparejar la programación sin siquiera intentarlo. Se necesita un poco de práctica para hacerlo bien, y es necesario hacerlo bien durante unas semanas para ver los resultados. El noventa por ciento de los programadores que aprenden programación en pareja lo prefieren, por lo que lo recomendamos encarecidamente a todos los equipos.
El emparejamiento, además de proporcionar un mejor código y pruebas, también sirve para comunicar conocimientos a todo el equipo., A medida que los pares cambian, todos obtienen los beneficios del conocimiento especializado de todos. Los programadores aprenden, sus habilidades mejoran, se vuelven más valiosos para el equipo y para la empresa. El emparejamiento, incluso por sí solo fuera de XP, es una gran victoria para todos.
desarrollo basado en pruebas
La programación extrema está obsesionada con la retroalimentación, y en el desarrollo de software, la buena retroalimentación requiere buenas pruebas. Los mejores equipos de XP practican el «desarrollo basado en pruebas», trabajando en ciclos muy cortos de agregar una prueba y luego hacerla funcionar., Casi sin esfuerzo, los equipos producen código con una cobertura de prueba de casi el 100 por ciento, lo que es un gran paso adelante en la mayoría de las tiendas. (Si sus programadores ya están haciendo pruebas aún más sofisticadas, más poder para usted. ¡Sigue así, solo puede ayudar!)
no es suficiente escribir pruebas: tienes que ejecutarlas. Aquí, también, la Programación Extrema es extrema. Estas «pruebas de programador», o «pruebas unitarias» se recopilan todas juntas, y cada vez que cualquier programador libera cualquier código al repositorio (y los pares normalmente liberan dos veces al día o más), cada una de las pruebas de programador debe ejecutarse correctamente., El cien por ciento, todo el tiempo! Esto significa que los programadores obtienen comentarios inmediatos sobre cómo les va. Además, estas pruebas proporcionan un apoyo invaluable a medida que se mejora el diseño del software.
mejora del diseño (refactorización)
La programación extrema se centra en ofrecer valor empresarial en cada iteración. Para lograr esto a lo largo de todo el proyecto, el software debe estar bien diseñado. La alternativa sería reducir la velocidad y, en última instancia, atascarse., Así que XP utiliza un proceso de mejora continua del diseño llamado refactorización, del título del libro de Martin Fowler, «refactorización: mejorar el diseño del Código existente».
el proceso de refactorización se centra en la eliminación de la duplicación (un signo seguro de diseño pobre), y en el aumento de la «cohesión» del código, mientras que la reducción del «acoplamiento». La alta cohesión y el bajo acoplamiento han sido reconocidos como las señas de identidad de un código bien diseñado durante al menos treinta años. El resultado es que los equipos de XP comienzan con un diseño bueno y simple, y siempre tienen un diseño bueno y simple para el software., Esto les permite mantener su velocidad de desarrollo, y de hecho generalmente aumentar la velocidad a medida que el proyecto avanza.
la refactorización es, por supuesto, fuertemente apoyada por pruebas exhaustivas para asegurarse de que a medida que el diseño evoluciona, nada se rompe. Por lo tanto, las pruebas del cliente y las pruebas del programador son un factor de habilitación crítico. Las prácticas de XP se apoyan entre sí: son más fuertes juntas que por separado.
Integración Continua
Los equipos de programación extrema mantienen el sistema completamente integrado en todo momento. Decimos que las compilaciones diarias son para wimps: los equipos de XP construyen varias veces al día., (¡Un equipo de XP de cuarenta personas construye al menos ocho o diez veces al día!)
el beneficio de esta práctica se puede ver al pensar en proyectos de los que puede haber oído hablar (o incluso haber sido parte) donde el proceso de construcción era semanal o con menos frecuencia, y generalmente conducía a un «infierno de integración», donde todo se rompía y nadie sabía por qué.
la integración infrecuente conduce a problemas serios en un proyecto de software., En primer lugar, aunque la integración es fundamental para enviar un buen código de trabajo, el equipo no se practica en él, y a menudo se delega a personas que no están familiarizadas con todo el sistema. En segundo lugar, el código integrado con poca frecuencia es a menudo – diría que por lo general – código con errores. Los problemas se arrastran en el momento de la integración que no son detectados por ninguna de las pruebas que se llevan a cabo en un sistema no integrado. En tercer lugar, el proceso de integración débil conduce a largas congelaciones de código., Los bloqueos de código significan que tiene largos períodos de tiempo en los que los programadores podrían estar trabajando en características importantes que se pueden enviar, pero que esas características deben ser retenidas. Esto debilita su posición en el mercado, o con sus usuarios finales.
propiedad colectiva de código
en un proyecto de programación extrema, cualquier par de programadores puede mejorar cualquier código en cualquier momento. Esto significa que todo el código obtiene el beneficio de la atención de muchas personas, lo que aumenta la calidad del código y reduce los defectos., También hay otro beneficio importante: cuando el código es propiedad de individuos, las características requeridas a menudo se colocan en el lugar equivocado, ya que un programador descubre que necesita una característica en algún lugar del código que no posee. El propietario está demasiado ocupado para hacerlo, por lo que el programador pone la característica en su propio código, donde no pertenece. Esto conduce a un código feo, difícil de mantener, lleno de duplicación y con baja (mala) cohesión.
la propiedad colectiva podría ser un problema si la gente trabajaba ciegamente en un código que no entendía., XP evita estos problemas a través de dos técnicas clave: las pruebas del programador detectan errores, y la programación de pares significa que la mejor manera de trabajar en código desconocido es emparejar con el experto. Además de garantizar buenas modificaciones cuando sea necesario, esta práctica extiende el conocimiento a todo el equipo.
estándar de codificación
los equipos de XP siguen un estándar de codificación común, de modo que todo el código en el sistema parece como si hubiera sido escrito por un solo individuo, muy competente., Los detalles del estándar no son importantes: lo importante es que todo el código parezca familiar, en apoyo de la propiedad colectiva.
Metaphor
Los equipos de programación extrema desarrollan una visión común de cómo funciona el programa, que llamamos la «metáfora». En su mejor momento, la metáfora es una simple descripción evocadora de cómo funciona el programa, como «este programa funciona como una colmena de abejas, saliendo a buscar polen y llevándolo de vuelta a la colmena» como una descripción para un sistema de recuperación de información basado en agentes.
A veces no surge una metáfora suficientemente poética., En cualquier caso, con o sin imágenes vívidas, los equipos de XP utilizan un sistema común de nombres para asegurarse de que todos entiendan cómo funciona el sistema y dónde Buscar para encontrar la funcionalidad que está buscando, o para encontrar el lugar correcto para poner la funcionalidad que está a punto de agregar.
ritmo sostenible
Los equipos de programación extrema están en ti a largo plazo. Trabajan duro y a un ritmo que puede mantenerse indefinidamente. Esto significa que trabajan horas extras cuando es eficaz, y que normalmente trabajan de tal manera como para maximizar la productividad semana tras semana., Hoy en día se entiende muy bien que los proyectos de la marcha de la muerte no son productivos ni producen software de calidad. Los equipos de XP están en él para ganar, no para morir.
conclusión
La programación extrema es una disciplina de desarrollo de software basada en valores de simplicidad, comunicación, retroalimentación y coraje. Funciona al reunir a todo el equipo en presencia de prácticas simples, con suficiente retroalimentación para permitir al equipo ver dónde están y ajustar las prácticas a su situación única.