Estás familiarizado coa programación, pero a programación extrema (XP para abreviar) aínda é un pouco misterio para ti.
Non deixes que o nome te desanime, corres o risco de perderte información útil.
Neste artigo, imos cubrir todo o que necesitas saber sobre a programación extrema para que poidas usalo ao teu favor.
A programación extrema é unha metodoloxía de desenvolvemento de software que forma parte do que se coñece colectivamente como metodoloxías áxiles. XP baséase en valores, principios e prácticas e o seu obxectivo é permitir que equipos pequenos e medianos produzan software de alta calidade e se adapten aos requisitos en constante cambio e evolución.
O que distingue a XP doutras metodoloxías áxiles é que XP fai fincapé nos aspectos técnicos do desenvolvemento de software. A programación extrema é precisa sobre como traballan os enxeñeiros xa que seguindo as prácticas de enxeñería permite aos equipos ofrecer código de alta calidade a un ritmo sostible.
A programación extrema é, en poucas palabras, boas prácticas levadas ao extremo. Xa que a programación por parellas é boa, imos facelo todo o tempo. Dado que probar con antelación é bo, probamos antes de que se escriba o código de produción.
XP, a diferenza doutras metodoloxías, baséase en valores e principios que son importantes e relevantes, en termos de prácticas de enxeñería.
Os valores proporcionan un propósito aos equipos. Actúan como unha "estrela do norte" para guiar as súas decisións a un alto nivel. Non obstante, os valores son abstractos e demasiado difusos para unha orientación específica. Por exemplo: dicir que valoras a comunicación pode levar a moitos resultados diferentes.
As prácticas son, en certo sentido, o contrario dos valores. Son de formigón e de terra, defiestablecer as especificacións do que facer. As prácticas axudan aos equipos a responsabilizarse dos valores. Por exemplo, a práctica dos espazos de traballo de información promove unha comunicación transparente e sinxela.
Os principios son directrices específicas de dominio que salvan a brecha entre prácticas e valores.
Valores XP: comunicación, sinxeleza, feedback, coraxe e respecto. Vexamos cada un deles con máis detalle.
elaboración BlogInnovazione.iso da imaxe alexsoft.com
Comunicazione: A falta de comunicación impide que o coñecemento fluya dentro dun equipo. Moitas veces, cando hai un problema, alguén xa sabe como solucionalo. Pero a falta de comunicación impídelles coñecer o problema ou contribuír á súa solución. Así, o problema acaba solucionándose dúas veces, xerando residuos.
Semplicidade: A simplicidade di que sempre te esforzas por facer o máis sinxelo que funciona. Moitas veces non se entende e tómase como a cousa máis sinxela, punto, ignorando a parte "que funciona".
Tamén é vital lembrar que a sinxeleza é moi contextual. O que é sinxelo para un equipo é complexo para outro e depende enteiramente das habilidades, experiencia e coñecementos de cada equipo.
Suxestións: A retroalimentación en metodoloxías de desenvolvemento de software máis tradicionais e en cascada adoita ser "demasiado pouco, demasiado tarde".
XP, con todo, abraza o cambio e os equipos XP esfórzanse por obter comentarios oportunos e constantes. Se é necesaria a corrección do curso, os XPers queren sabelo canto antes.
elaboración BlogInnovazione.iso da imaxe alexsoft.com
Os comentarios teñen moitas formas e tamaños. Cando estás coa programación asociada, os comentarios do teu colega son comentarios fundamentais. Tamén o son as opinións doutros membros do equipo sobre unha idea, incluído o cliente que, idealmente, é un membro do equipo.
As probas son outra fonte de comentarios valiosos que van máis alá dos resultados das probas. Se escribir probas é fácil ou difícil, tamén o son os comentarios. Se tes problemas para escribir probas, probablemente o teu proxecto sexa demasiado complexo. Escoita comentarios e simplifica o teu deseño.
Algo que parece unha gran idea pode non funcionar tan ben na práctica. Polo tanto, o código acabado tamén é unha fonte de comentarios, así como un produto distribuído.
Finalmente, teña en conta que hai demasiados comentarios. Se un equipo xera máis comentarios dos que pode manexar, os comentarios importantes poderían caer do radar. Polo tanto, é esencial diminuír a velocidade e descubrir o que está causando o exceso de feedback e solucionalo.
Coraxe: Kent Beck defia coraxe xorde como "acción eficaz fronte ao medo". Como enxeñeiro de software, tes moito que temer e, polo tanto, moitas oportunidades para mostrar coraxe.
Fai falla coraxe para dicir a verdade, especialmente as desagradables, como as estimacións honestas. Dar e recibir comentarios tamén require coraxe. E fai falla coraxe para evitar caer na falacia dos custos hundidos e descartar unha solución fallida que recibiu un investimento substancial.
Respecto: Unha premisa fundamental de XP é que todos se preocupan polo seu traballo. Ningunha cantidade de excelencia técnica pode salvar un proxecto se non hai coidado e respecto.
Toda persoa é digna de dignidade e respecto, e iso inclúe, por suposto, as persoas implicadas nun proxecto de desenvolvemento de software. Cando ti e os membros do teu equipo respectas e coidásense mutuamente, o cliente, o proxecto e os seus futuros usuarios, todos se benefician
Os principios proporcionan unha orientación máis específica que os valores. Son pautas que iluminan os valores e os fan máis explícitos e menos ambiguos.
elaboración BlogInnovazione.iso da imaxe alexsoft.com
Por exemplo, baseándose só no valor da coraxe, podes concluír que é recomendable facer un gran cambio no teu horario de inmediato. Non obstante, o principio Baby Steps dinos que os grandes cambios son arriscados. Entón, prefire os pequenos.
Humanidade: Os humanos creamos software para humanos, un feito que moitas veces se pasa por alto. Pero tendo en conta as necesidades humanas básicas, as fortalezas e as debilidades, crea produtos que os humanos queren usar. E un ambiente de traballo que che ofreza a oportunidade de realización e crecemento, o sentimento de pertenza e de seguridade básica, é un lugar no que tes en conta máis facilmente as necesidades dos demais.
Economía: En XP, os equipos sempre prestan atención ás realidades económicas do desenvolvemento de software, avalían constantemente os riscos económicos e as necesidades do proxecto.
Por exemplo, implementarían historias de usuarios en función do seu valor comercial en lugar de preocupacións técnicas.
Beneficio mutuo: Despois de XP, evita solucións que benefician a unha parte en detrimento doutra. Por exemplo, as especificacións ampliadas poden axudar a outra persoa a entendela, pero distrae a súa implementación e retrasa para os usuarios.
Unha solución mutuamente beneficiosa é utilizar probas de aceptación automatizadas. Obtén comentarios instantáneos sobre a túa implementación, os teus compañeiros obteñen especificacións precisas no código e os usuarios obteñen primeiro as súas funcións. Ademais, todos vostedes terán unha rede de seguridade contra as regresións.
Beneficio (beneficio mutuo): Se unha determinada solución funciona nun nivel, tamén pode funcionar nun nivel superior ou inferior. Por exemplo, recibir comentarios anticipados e constantes está en xogo en diferentes graos en XP.
Mellora: Segundo o principio de mellora, os equipos non pretenden a perfección nunha implementación inicial, senón unha implementación que sexa suficientemente boa, para despois aprendela e mellorala continuamente cos comentarios de usuarios reais.
Diversidade: Ti e os teus colegas benefícianse dunha diversidade de perspectivas, habilidades e actitudes. Tal diversidade adoita levar a conflitos, pero está ben.
O conflito e o desacordo son oportunidades para que xurdan mellores ideas cando todos xogan cos valores de coraxe e respecto. Coraxe para expresar puntos de vista opostos, respecto ao expresalos de xeito civil e empático. E todo isto é un exercicio de comunicación eficaz.
Reflexión: Os grandes equipos reflexionan sobre o seu traballo e analizan como ser mellores. XP ofrece moitas oportunidades para iso. Non só nos seus ciclos semanais e trimestrais, senón en todas as prácticas que promove.
Os sentimentos son importantes a ter en conta ademais da análise lóxica. O teu intestino pode informarte antes de que poidas razoar sobre calquera cousa. E para que poida falar con persoas non técnicas, poden facer preguntas que abren posibilidades completamente novas.
Fluxo: As metodoloxías tradicionais de desenvolvemento de software teñen fases distintas, que duran moito tempo e teñen poucas oportunidades de retroalimentación e corrección do curso. Pola contra, o desenvolvemento de software en XP ocorre en actividades que ocorren de forma continua, nun "corrente" consistente de valor.
Oportunidade: Os problemas son inevitables no desenvolvemento de software. Non obstante, cada problema é unha oportunidade de mellora. Aprende a miralos deste xeito e é moito máis probable que che deas solucións creativas e orientadas a obxectivos que tamén serven para evitar que volvan ocorrer.
Redundancia: O principio de redundancia di que se un determinado problema é crítico, debes empregar moitas tácticas para contrarrestalo.
Toma os defectos. Non hai unha única táctica que poida evitar que todos os defectos escapen da produción.
Entón, a solución de XP é apilar un conxunto de medidas de calidade. Programación de pares, probas, integración continua. Cada unha unha única liña de defensa, xuntos un muro practicamente impenetrable.
Fallo: o fracaso non é un desperdicio cando se traduce en coñecemento. Actuar e aprender rapidamente o que non funciona é moito máis produtivo que a inacción causada pola indecisión á hora de escoller entre moitas opcións.
Calidade: A xente adoita pensar que hai un dilema entre calidade e velocidade.
É ao revés: presionar para mellorar a calidade é o que che fai ir máis rápido.
Por exemplo, a refactorización (cambiar a estrutura do código sen cambiar o seu comportamento) é unha práctica que facilita a comprensión e o cambio do código. Como resultado, é menos probable que introduza defectos de código, o que lle permite ofrecer máis valor primeiro ao non ter que corrixir erros.
Pequenos pasos: Os grandes cambios son arriscados. XP mitiga ese risco facendo cambios en pequenos pasos, en todos os niveis.
Os programadores escriben código en pequenos pasos usando o desenvolvemento dirixido por probas. Integran o seu código na liña principal varias veces ao día, en lugar de só cada poucas semanas ou incluso meses. O proxecto en si realízase en ciclos curtos e non en fases de longa duración.
Responsabilidade aceptada: En XP, a responsabilidade debe ser aceptada, nunca asignada.
A responsabilidade debe vir coa autoridade para tomar decisións sobre o que é responsable. O contrario tamén é certo. Non queres que as persoas tomen decisións se non teñen que vivir coas súas consecuencias.
A programación extrema, ao ser unha metodoloxía áxil, pódese aceptar e comezar a adoptala sen seguir plans ríxidos. Este é un deseño iterativo máis que un gran proxecto inicial.
XP difire significativamente das metodoloxías tradicionais, é dicir, en cascada, evitando fases de longa duración.
En que se diferencia XP doutras metodoloxías áxiles?
A programación extrema, pola súa natureza, ten moito en común con outras metodoloxías áxiles pero tamén é única entre elas.
A maioría das outras metodoloxías de desenvolvemento non din moito, se nada, sobre como facer o traballo. XP, por outra banda, é moi obstinado cando se trata disto e fai gran énfase nas prácticas de enxeñería de software.
Scrum é un marco para axudar aos equipos a desenvolver proxectos complexos de forma adaptativa. Scrum non dita como os desenvolvedores fan o seu traballo. XP, como se mencionou, fai moita énfase nas boas prácticas de programación.
elaboración BlogInnovazione.gl Imaxe solucións netas
Ademais, XP é obviamente sobre programación. Scrum, por outra banda, pódese aplicar a calquera proxecto que se beneficie dun enfoque iterativo.
XP acepta cambios nos seus compoñentes. Os equipos son empoderados e mesmo animados a modificar as prácticas en función das súas necesidades específicas. A Scrum Guide, pola súa banda, está firme en que "Aínda que só se poden implementar partes de Scrum, o resultado non é Scrum".
Ademais, Scrum é un marco que debe ser complementado con metodoloxías e prácticas para facer o traballo.
Isto significa que é moi recomendable traballar en programación extrema e Scrum.
Segundo Kent Beck, un equipo de XP maduro non debería asignar roles ríxidos, pero recoñecer que os papeis poden ser útiles para os equipos incipientes ata que comecen a ralentizar ou dificultar a colaboración.
Vexamos algúns papeis clave:
Estas son as prácticas adoptadas en XP. Divídense en tres grandes grupos: enxeñaría de software, posto de traballo e xestión de proxectos.
Programación de pares: En XP, escribe código en parellas sentado nunha máquina. Ti e a túa parella falas mentres analizas, implementas e probas a función na que estás a traballar. A programación por parellas é especialmente boa para producir código con menos erros, aínda que resulta atractiva, divertida e cansativa.
Límite de dez minutos: Obrigatorio Permite 10 minutos para construír todo o proxecto, incluída a execución de todas as probas automatizadas, nun máximo de dez minutos. Este límite é para manter as probas simplificadas e eficaces.
Probas antes da programación: implementar funcións usando o enfoque de proba primeiro, tamén chamado desenvolvemento guiado por probas (TDD). TDD consiste no desenvolvemento mediante un procedemento iterativo sinxelo:
TDD trae varios beneficios.
En primeiro lugar, comentarios. Se é difícil escribir unha proba, o deseño que estás a buscar ou que herdaches probablemente sexa demasiado complexo e teñas que simplificalo.
En segundo lugar, TDD permite aos programadores confiar no código que escriben e crea un ritmo agradable onde o seguinte paso está sempre claro.
Por último, pero non menos importante, usar TDD desde o principio garante unha cobertura do código do 100%. O conxunto de probas convértese realmente nunha rede de seguridade para cambios futuros, fomentando a refactorización do código e creando un círculo virtuoso de calidade.
Deseño incremental: A práctica do deseño incremental significa que debes investir no deseño da túa aplicación todos os días, buscando oportunidades para eliminar a duplicación e facer pequenas melloras para conseguir o mellor deseño posible para o que o teu sistema necesita hoxe.
Integración continua: En XP, integras o teu traballo no repositorio compartido principal varias veces ao día, desencadeando unha compilación automática de todo o sistema. A integración tan pronto como sexa posible reduce drasticamente o custo da integración xa que fai menos probable que se produzan fusións e conflitos lóxicos. Tamén expón problemas ambientais e de adicción.
Código compartido (propiedade colectiva): XP promove código compartido, ou propiedade colectiva: cada desenvolvedor é responsable de todo o código. Fomenta o intercambio de información, reduce o factor bus do equipo e aumenta a calidade global de cada módulo se temos en conta o principio de diversidade.
Base de código único: unha única base de código tamén se coñece como "desenvolvemento baseado no tronco". Significa que só hai unha fonte de verdade. Polo tanto, en lugar de desenvolverse de forma illada durante longos períodos de tempo, fusiona as túas contribucións nun único fluxo de xeito precoz e frecuente. As marcas de funcións axudan a limitar o uso das funcións ata que estean completas.
Distribución diaria: o despregue en produción polo menos unha vez ao día é unha consecuencia lóxica da integración continua:. De feito, hoxe en día, moitos equipos van aínda máis aló e practican a implementación continua. É dicir, sempre que alguén se une á liña principal, a aplicación desprégase na produción.
Código e probas: Esta práctica significa que o código fonte, incluídas as probas, é o único artefacto permanente dun proxecto de software. Participar na xeración doutro tipo de artefactos, incluída a documentación, adoita ser un despilfarro porque non xera valor real para o cliente.
Se necesitas outros artefactos ou documentos, esfórzate para xeralos a partir do código de produción e das probas.
Análise da causa raíz: Sempre que un defecto entra en produción, non só corrixa o defecto. Asegúrate de descubrir o que o causou en primeiro lugar, por que ti e os teus compañeiros non lograstes evitar o derrape. Despois, toma medidas para asegurarte de que non volva ocorrer.
Sentade xuntos: En XP, os equipos prefiren traballar xuntos nun espazo aberto. Esta práctica promove a comunicación e o sentimento de pertenza a un equipo.
Todo o equipo: Todos os que sexan necesarios para o éxito do proxecto forman parte do equipo XP. Isto é moi contextual (diferente para cada equipo) e dinámico, pode cambiar dentro dun equipo.
Espazos de traballo de información: Un espazo de traballo de información utiliza o espazo físico do equipo para mostrar información que permite a calquera persoa coñecer, dunha ollada, o avance do proxecto. Como se fai isto pode variar, desde notas físicas e gráficos ata capturas de pantalla que mostran cadros Kanban e paneis do software de xestión de proxectos.
Traballo energizado: En XP, só traballas mentres poidas facer un traballo enerxético. A xornada laboral debe limitarse a 40 horas semanais, como máximo.
Analisi- Escribir os requisitos dos usuarios nun formato coñecido como análise de usuarios. Unha análise de usuario ten un nome breve e descritivo e tamén unha breve descrición do que hai que implementar.
Neglixente: Á hora de planificar un ciclo, engade tarefas menores que o equipo poida abandonar se é necesario. Sempre se poden engadir máis historias se o equipo ofrece demasiado.
Ciclos (mensuais e semanais): O desenvolvemento en XP prodúcese en dous ciclos principais: o ciclo semanal e o ciclo mensual.
Reunións, ciclos, estreas programadas: O desenvolvemento en XP funciona en dous ciclos principais: o ciclo semanal e o ciclo trimestral. Inicialmente, Kent Beck recomendou un ciclo de dúas semanas, pero cambiou isto na segunda edición do seu libro.
Ciclo semanal: o ciclo semanal é o "pulso" dun proxecto XP. O ciclo comeza cunha reunión na que o cliente elixe que historias quere crear durante a semana. Ademais, o equipo revisa o seu traballo, incluído o progreso da semana pasada, e pensa en formas de mellorar o seu proceso.
Ciclo mensual: Cada mes, o equipo reflexiona e identifica oportunidades de mellora no seu proceso. O cliente escolle un ou varios temas para ese mes, xunto coas análises destes temas.
Como comezar a traballar cunha programación extrema?
As habilidades técnicas e os hábitos de XP poden ser difíciles de aprender. Algunhas das prácticas poden parecer estrañas para os programadores que non están afeitos a elas.
Ercole Palmeri
Froito da constante innovación tecnolóxica e do compromiso co medio ambiente e o benestar das persoas. Bandalux presenta Airpure®, unha carpa...
Os patróns de deseño son solucións específicas de baixo nivel para problemas recorrentes no deseño de software. Os patróns de deseño son...
Magica é a aplicación para iPhone que fai que a xestión de vehículos sexa sinxela e eficiente, axudando aos condutores a aforrar e...
Un gráfico de Excel é un elemento visual que representa datos nunha folla de cálculo de Excel...
