Estás familiarizado con la programación, pero la Programación Extrema (XP para abreviar) sigue siendo un misterio para ti.
No deje que el nombre lo desanime, corre el riesgo de perderse información útil.
En este artículo, cubriremos todo lo que necesita saber sobre la Programación Extrema para que pueda usarla a su favor.
La programación extrema es una metodología de desarrollo de software que forma parte de lo que se conoce colectivamente como metodologías ágiles. XP se basa en valores, principios y prácticas, y su objetivo es permitir que los equipos pequeños y medianos produzcan software de alta calidad y se adapten a los requisitos en constante cambio y evolución.
Lo que distingue a XP de otras metodologías ágiles es que XP enfatiza los aspectos técnicos del desarrollo de software. La programación extrema es precisa sobre cómo trabajan los ingenieros, ya que seguir las prácticas de ingeniería permite a los equipos entregar código de alta calidad a un ritmo sostenible.
La programación extrema es, en pocas palabras, buenas prácticas llevadas al extremo. Como la programación en pareja es buena, hagámoslo todo el tiempo. Dado que probar por adelantado es bueno, probamos incluso antes de que se escriba el código de producción.
XP, a diferencia de otras metodologías, se basa en valores y principios que son importantes y relevantes, en términos de prácticas de ingeniería.
Los valores brindan propósito a los equipos. Actúan como una "estrella del norte" para guiar sus decisiones a un alto nivel. Sin embargo, los valores son abstractos y demasiado confusos para una orientación específica. Por ejemplo: Decir que valoras la comunicación puede conducir a muchos resultados diferentes.
Las prácticas son, en cierto sentido, lo opuesto a los valores. Son concretos y con los pies en la tierra, defiestablecer los detalles de qué hacer. Las prácticas ayudan a los equipos a responsabilizarse de sus valores. Por ejemplo, la práctica de espacios de trabajo de información promueve una comunicación transparente y sencilla.
Los principios son pautas específicas de dominio que cierran la brecha entre las prácticas y los valores.
Valores XP: comunicación, sencillez, feedback, valentía y respeto. Veamos cada uno de ellos con más detalle.
Redacción BlogInnovazione.eso de la imagen alexsoft.com
Comunicación: La falta de comunicación impide que el conocimiento fluya dentro de un equipo. A menudo, cuando hay un problema, alguien ya sabe cómo solucionarlo. Pero la falta de comunicación les impide conocer el problema o contribuir a su solución. Así, el problema se acaba resolviendo por partida doble, generando residuos.
Sencillez: La simplicidad dice que siempre te esfuerzas por hacer lo más simple que funcione. A menudo se malinterpreta y se toma como la cosa más simple, y punto, ignorando la parte de "eso funciona".
También es vital recordar que la simplicidad es altamente contextual. Lo que es simple para un equipo es complejo para otro y depende enteramente de las habilidades, experiencia y conocimiento de cada equipo.
Comentarios: La retroalimentación en metodologías de desarrollo de software en cascada más tradicionales a menudo es "demasiado poca, demasiado tarde".
XP, sin embargo, acepta el cambio y los equipos de XP se esfuerzan por obtener comentarios oportunos y constantes. Si es necesario corregir el rumbo, los usuarios de XP quieren saberlo lo antes posible.
Redacción BlogInnovazione.eso de la imagen alexsoft.com
La retroalimentación viene en muchas formas y tamaños. Cuando está programando asociado, los comentarios de su colega son comentarios vitales. También lo son las opiniones de otros miembros del equipo sobre una idea, incluido el cliente que, idealmente, es un miembro del equipo.
Las pruebas son otra fuente de información valiosa que va más allá de los resultados de las pruebas. Ya sea que escribir pruebas sea fácil o difícil, también lo es la retroalimentación. Si tiene problemas para escribir pruebas, es probable que su proyecto sea demasiado complejo. Escuche los comentarios y optimice su diseño.
Algo que suena como una gran idea puede no funcionar tan bien en la práctica. Por lo tanto, el código terminado también es una fuente de retroalimentación, al igual que un producto distribuido.
Por último, tenga en cuenta que hay demasiados comentarios. Si un equipo genera más comentarios de los que puede manejar, los comentarios importantes podrían pasar desapercibidos. Por lo tanto, es esencial reducir la velocidad y descubrir qué está causando el exceso de retroalimentación y solucionarlo.
alegrar: Kent Beck defiel coraje surge como “acción eficaz frente al miedo”. Como ingeniero de software, tienes mucho que temer y, por tanto, muchas oportunidades para demostrar valentía.
Se necesita coraje para decir la verdad, especialmente las desagradables, como las estimaciones honestas. Dar y recibir retroalimentación también requiere coraje. Y se necesita coraje para evitar caer en la falacia del costo irrecuperable y descartar una solución fallida que ha recibido una inversión sustancial.
Respeto: Una premisa fundamental de XP es que todos se preocupan por su trabajo. Ninguna cantidad de excelencia técnica puede salvar un proyecto si no hay cuidado y respeto.
Toda persona es digna de dignidad y respeto, y eso incluye, por supuesto, a las personas involucradas en un proyecto de desarrollo de software. Cuando usted y los miembros de su equipo se respetan y cuidan mutuamente, el cliente, el proyecto y sus futuros usuarios, todos se benefician
Los principios proporcionan una guía más específica que los valores. Son pautas que iluminan los valores y los hacen más explícitos y menos ambiguos.
Redacción BlogInnovazione.eso de la imagen alexsoft.com
Por ejemplo, basándose únicamente en el valor del coraje, podría concluir que es recomendable hacer un gran cambio en su agenda de inmediato. Sin embargo, el principio de Baby Steps nos dice que los grandes cambios son riesgosos. Por lo tanto, prefiera los pequeños en su lugar.
humanidad: Los humanos crean software para humanos, un hecho que a menudo se pasa por alto. Pero teniendo en cuenta las necesidades humanas básicas, las fortalezas y debilidades crea productos que los humanos quieren usar. Y un ambiente de trabajo que te ofrece la oportunidad de realización y crecimiento, el sentimiento de pertenencia y la seguridad básica, es un lugar donde consideras más fácilmente las necesidades de los demás.
Economía: En XP, los equipos siempre prestan atención a las realidades económicas del desarrollo de software, evalúan constantemente los riesgos económicos y las necesidades del proyecto.
Por ejemplo, implementarían historias de usuarios en función de su valor comercial en lugar de preocupaciones técnicas.
Beneficio mutuo: Después de XP, evita soluciones que benefician a una parte a expensas de otra. Por ejemplo, las especificaciones extendidas pueden ayudar a que alguien más las entienda, pero lo distraen de implementarlas y las retrasan para sus usuarios.
Una solución mutuamente beneficiosa es utilizar pruebas de aceptación automatizadas. Obtenga comentarios instantáneos sobre su implementación, sus pares obtienen especificaciones precisas en el código y los usuarios obtienen sus características primero. Además, todos tendréis una red de seguridad contra las regresiones.
Beneficio (Beneficio mutuo): Si una solución determinada funciona en un nivel, también puede funcionar en un nivel superior o inferior. Por ejemplo, obtener retroalimentación temprana y constante está en juego en diversos grados en XP.
mejora: De acuerdo con el principio de mejora, los equipos no buscan la perfección en una implementación inicial, sino una implementación que sea lo suficientemente buena, y luego aprenden y mejoran continuamente con comentarios de usuarios reales.
diversidad: Usted y sus colegas se benefician de una diversidad de perspectivas, habilidades y actitudes. Tal diversidad a menudo conduce a conflictos, pero está bien.
El conflicto y el desacuerdo son oportunidades para que surjan mejores ideas cuando todos juegan con los valores de coraje y respeto. Coraje para expresar puntos de vista opuestos, respeto para expresarlos de manera civilizada y empática. Y todo esto es un ejercicio de comunicación eficaz.
reflexión: Los grandes equipos reflexionan sobre su trabajo y analizan cómo ser mejores. XP ofrece muchas oportunidades para esto. No solo en sus ciclos semanales y trimestrales, sino en todas las prácticas que promueve.
Es importante considerar los sentimientos además del análisis lógico. Tu instinto puede informarte antes de que puedas razonar sobre cualquier cosa. Y para que pueda hablar con personas no técnicas, pueden hacer preguntas que abren posibilidades completamente nuevas.
Fluir: Las metodologías tradicionales de desarrollo de software tienen distintas fases, que duran mucho tiempo y tienen poca oportunidad de retroalimentación y corrección de rumbo. En cambio, el desarrollo de software en XP ocurre en actividades que ocurren continuamente, en un "flujo" consistente de valor.
Oportunidad: Los problemas son inevitables en el desarrollo de software. Sin embargo, cada problema es una oportunidad de mejora. Aprende a verlos de esta manera y es mucho más probable que encuentres soluciones creativas y orientadas a objetivos que también sirvan para evitar que vuelvan a suceder.
Redundancia: El principio de redundancia dice que si un problema determinado es crítico, debe emplear muchas tácticas para contrarrestarlo.
Toma los defectos. No existe una única táctica que pueda evitar que todos los defectos escapen a la producción.
Entonces, la solución de XP es apilar un conjunto de medidas de calidad. Par de programación, pruebas, integración continua. Cada uno una única línea de defensa, juntos un muro prácticamente impenetrable.
fracaso: el fracaso no es un desperdicio cuando se traduce en conocimiento. Pasar a la acción y aprender rápidamente lo que no funciona es mucho más productivo que la inacción causada por la indecisión al elegir entre muchas opciones.
CALIDAD: La gente suele pensar que hay un dilema entre calidad y velocidad.
Es al revés: presionar para mejorar la calidad es lo que te hace ir más rápido.
Por ejemplo, la refactorización (cambiar la estructura del código sin cambiar su comportamiento) es una práctica que facilita la comprensión y el cambio del código. Como resultado, es menos probable que introduzca defectos en el código, lo que le permite ofrecer más valor primero al no tener que corregir errores.
Pequeños pasos: Los grandes cambios son riesgosos. XP mitiga ese riesgo al realizar cambios en pequeños pasos, en todos los niveles.
Los programadores escriben código en pequeños pasos mediante el desarrollo basado en pruebas. Integran su código en la línea principal varias veces al día, en lugar de solo cada pocas semanas o incluso meses. El proyecto en sí tiene lugar en ciclos cortos en lugar de fases de larga duración.
Responsabilidad aceptada: En XP, la responsabilidad debe aceptarse, nunca asignarse.
La rendición de cuentas debe venir con la autoridad para tomar decisiones sobre lo que usted es responsable. Lo opuesto también es cierto. No quieres que las personas tomen decisiones si no tienen que vivir con sus consecuencias.
La programación extrema, al ser una metodología ágil, puede aceptarse y comenzar a adoptarla sin seguir planes rígidos. Este es un diseño iterativo en lugar de un gran proyecto inicial.
XP difiere significativamente de las metodologías tradicionales, es decir, en cascada, evitando fases de larga duración.
¿En qué se diferencia XP de otras metodologías ágiles?
La programación extrema, por su naturaleza, tiene mucho en común con otras metodologías ágiles, pero también es única entre ellas.
La mayoría de las otras metodologías de desarrollo no dicen mucho, si es que dicen algo, sobre cómo hacer el trabajo. XP, por otro lado, es muy obstinado cuando se trata de esto y pone gran énfasis en las prácticas de ingeniería de software.
Scrum es un marco para ayudar a los equipos a desarrollar proyectos complejos de forma adaptativa. Scrum no dicta cómo los desarrolladores hacen su trabajo. XP, como se mencionó, pone mucho énfasis en las buenas prácticas de programación.
Redacción BlogInnovazione.es Imagen soluciones netas
Además, XP obviamente se trata de programación. Scrum, por otro lado, se puede aplicar a cualquier proyecto que se beneficie de un enfoque iterativo.
XP acepta cambios en sus componentes. Los equipos están empoderados e incluso alentados a modificar las prácticas en función de sus necesidades específicas. La Guía de Scrum, por otro lado, insiste en que “Aunque solo se pueden implementar partes de Scrum, el resultado no es Scrum”.
Además, Scrum es un marco que debe complementarse con metodologías y prácticas para realizar el trabajo.
Esto significa que es muy recomendable trabajar en programación extrema y Scrum.
Según Kent Beck, un equipo de XP maduro no debe asignar roles rígidos, sino reconocer que los roles pueden ser útiles para equipos incipientes hasta que comiencen a ralentizarse o dificulten la colaboración.
Veamos algunos roles clave:
Estas son las prácticas adoptadas en XP. Se dividen en tres grupos principales: ingeniería de software, lugar de trabajo y gestión de proyectos.
Programación en pareja: En XP, escribes el código en pares sentados en una máquina. Usted y su pareja hablan entre sí mientras analizan, implementan y prueban la función en la que están trabajando. La programación en pares es especialmente buena para producir código con menos errores sin dejar de ser atractiva, divertida y agotadora.
Límite de diez minutos: Requerido Permite 10 minutos para compilar todo el proyecto, incluida la ejecución de todas las pruebas automatizadas, en un máximo de diez minutos. Este límite es para mantener las pruebas optimizadas y efectivas.
Pruebas antes de programar: implemente características utilizando el enfoque de prueba primero, también llamado desarrollo dirigido por pruebas (TDD). TDD consiste en el desarrollo utilizando un procedimiento iterativo simple:
TDD trae varios beneficios.
Primero, retroalimentación. Si es difícil escribir una prueba, el diseño que está buscando o que ha heredado es probablemente demasiado complejo y necesita simplificarlo.
En segundo lugar, TDD permite a los programadores confiar en el código que escriben y crea un buen ritmo de bucle donde el siguiente paso siempre es claro.
Por último, pero no menos importante, el uso de TDD desde el principio garantiza una cobertura de código del 100 %. El conjunto de pruebas se convierte realmente en una red de seguridad para futuros cambios, fomentando la refactorización del código y creando un círculo virtuoso de calidad.
diseño incremental: La práctica del diseño incremental significa que debe invertir en el diseño de su aplicación todos los días, buscando oportunidades para eliminar la duplicación y realizar pequeñas mejoras para lograr el mejor diseño posible para lo que su sistema necesita hoy.
Integración continua: En XP, integra su trabajo en el repositorio compartido principal varias veces al día, lo que activa una compilación automática de todo el sistema. La integración lo antes posible y con la mayor frecuencia posible reduce drásticamente el costo de la integración, ya que hace que sea menos probable que ocurran fusiones y conflictos lógicos. También expone problemas ambientales y de adicción.
Código compartido (propiedad colectiva): XP promueve el código compartido o la propiedad colectiva: cada desarrollador es responsable de todo el código. Fomenta el intercambio de información, reduce el factor de bus de equipo y aumenta la calidad general de cada módulo si tenemos en cuenta el principio de diversidad.
Base de código único: El código base único también se conoce como "desarrollo basado en troncales". Significa que sólo hay una fuente de verdad. Por lo tanto, en lugar de desarrollarse de forma aislada durante largos períodos de tiempo, combine sus contribuciones en un solo flujo temprano y con frecuencia. Los indicadores de funciones ayudan a limitar el uso de las funciones hasta que se completen.
Distribución diaria: la implementación en producción al menos una vez al día es una consecuencia lógica de la integración continua:. De hecho, hoy en día, muchos equipos van más allá y practican la implementación continua. Es decir, cada vez que alguien se une a la línea principal, la aplicación se implementa en producción.
Código y pruebas: Esta práctica significa que el código fuente, incluidas las pruebas, es el único artefacto permanente de un proyecto de software. Involucrarse en la generación de otros tipos de artefactos, incluida la documentación, a menudo es un desperdicio porque no genera un valor real para el cliente.
Si necesita otros artefactos o documentos, haga un esfuerzo para generarlos a partir del código de producción y las pruebas.
Análisis de raíz de la causa: Cada vez que un defecto entra en producción, no se limite a corregir el defecto. Asegúrese de averiguar qué lo causó en primer lugar, por qué usted y sus compañeros de equipo no lograron evitar el derrape. Luego, tome medidas para asegurarse de que no vuelva a suceder.
Sentarse juntos: En XP, los equipos prefieren trabajar juntos en un espacio abierto. Esta práctica promueve la comunicación y el sentido de pertenencia a un equipo.
todo el equipo: Todos los que se necesitan para el éxito del proyecto forman parte del equipo XP. Esto es muy contextual, diferente para cada equipo, y dinámico, puede cambiar dentro de un equipo.
Espacios de trabajo de información: Un espacio de trabajo de información utiliza el espacio físico del equipo para mostrar información que permite a cualquier persona conocer, de un vistazo, el progreso del proyecto. La forma en que se hace esto puede variar, desde notas físicas y gráficos hasta capturas de pantalla que muestran tableros y tableros Kanban del software de gestión de proyectos.
trabajo energizado: En XP, solo trabajas mientras puedas hacer un trabajo energético. Las horas de trabajo deben limitarse a 40 por semana, como máximo.
Análisis- Escribir los requisitos de los usuarios en un formato conocido como análisis de usuarios. Un análisis de usuario tiene un nombre breve y descriptivo y también una breve descripción de lo que debe implementarse.
Flojo: Al planificar un ciclo, agregue tareas menores que el equipo pueda abandonar si surge la necesidad. Siempre se pueden agregar más historias si el equipo entrega demasiado.
Ciclos (mensual y semanal): El desarrollo en XP ocurre en dos ciclos principales: el ciclo semanal y el ciclo mensual.
Reuniones, ciclos, comunicados programados: El desarrollo en XP funciona en dos ciclos principales: el ciclo semanal y el ciclo trimestral. Inicialmente, Kent Beck recomendó un ciclo de dos semanas, pero lo cambió en la segunda edición de su libro.
Ciclo semanal: el ciclo semanal es el "pulso" de un proyecto XP. El ciclo comienza con una reunión en la que el cliente elige qué historias quiere crear durante la semana. Además, el equipo revisa su trabajo, incluido el progreso de la semana pasada, y piensa en formas de mejorar su proceso.
Ciclo mensual: Cada mes, el equipo reflexiona e identifica oportunidades de mejora en su proceso. El cliente elige uno o más temas para ese mes, junto con los análisis de estos temas.
¿Cómo empezar a trabajar con programación extrema?
Las habilidades técnicas y los hábitos XP pueden ser difíciles de aprender. Algunas de las prácticas pueden parecer extrañas para los programadores que no están acostumbrados a ellas.
Ercole Palmeri
Coveware by Veeam seguirá brindando servicios de respuesta a incidentes de extorsión cibernética. Coveware ofrecerá capacidades forenses y de remediación...
El mantenimiento predictivo está revolucionando el sector del petróleo y el gas, con un enfoque innovador y proactivo para la gestión de plantas.…
La CMA del Reino Unido ha emitido una advertencia sobre el comportamiento de las Big Tech en el mercado de la inteligencia artificial. Allá…
El Decreto "Invernaderos", formulado por la Unión Europea para mejorar la eficiencia energética de los edificios, ha concluido su trámite legislativo con…
