Áxil

Para información sobre o adxectivo, visite o Galizionario: áxil
Co termo áxil (ou a miúdo coñecido co seu nome en inglés Agile) recóllense un conxunto de principios, prácticas e metodoloxías de xestión de proxectos, e especificamente, de xestión de proxectos de desenvolvemento de software. Ao longo das tres fases do desenvolvemento áxil de software, a saber, iniciación do proxecto, planificación do sprint e demostracións, os usuarios teñen a oportunidade de realizar modificacións baseadas no contexto empresarial e nos cambios na demanda dos clientes. Isto mellora a comprensión mutua entre desenvolvedores e usuarios mediante a avaliación dos módulos da solución para determinar se se están a satisfacer as necesidades empresariais, garantindo así resultados de calidade. Este conxunto de metodoloxías e prácticas, explicitadas en 2001, e espalladas polas comunidades de desenvolvedores de software a partir desa data, avogan por unha planificación adaptativa, a creación de versións provisionais do software e o desenvolvemento continuo.

 Orixes 
A xestión de proxectos é unha disciplina que procura que os proxectos industriais, independentemente do seu sector, sexan executados con éxito. Porén, a industria do software enfrontábase a finais do século XX a unha serie de peculiaridades que, se ben eran tamén comúns a outras disciplinas, tiñan neste sector unha importancia especial. Seguindo o modelo clásico do triángulo da xestión de proxectos, as diferenzas principais eran estas:

 O tempo 
O carácter habitualmente innovador dos proxectos de desenvolvemento de software, o feito de que fosen adoito proxectos de medio e longo prazo, e a velocidade do mercado en comparación con outras industrias, facía que o resultado dos proxectos finais fose bastante diferente de como se concibiran no seu comezo. Iso era así ben porque o contexto tecnolóxico mudara durante a execución do proxecto (novos estándares, novas linguaxes, novos sistemas), ben porque as solucións de desenvolvemento que se propuñan en determinadas fases do proxecto, polo seu carácter innovador, obrigaban a unha revisión do proxecto, ou ben porque as necesidades comerciais (prazos) do cliente que encargara o proxecto variaran desde o inicio ata o final dos traballos. Ademais, unha boa parte dos proxectos de desenvolvemento de software facíanse (fanse) cunha idea de continuidade, de maneira que co paso dos anos, e ás veces sen que o proxecto se detivese, unhas versións construíanse enriba das outras.

 O orzamento 
Esta dificultade para construír un calendario pechado a longo prazo levaba aparellada a dificultade de elaborar un orzamento: dado que non era sinxelo predicir canto levaría desenvolver un produto, creábase unha fricción entre os clientes e as súas previsións de custos e investimentos, e as provedoras de software. Iso afectaba tanto cara a fóra, na comercialización dos produtos de software, como cara a dentro, na xestión interna, no tamaño e na estrutura da empresa ou comunidade de software.

 O alcance do produto final 
Producir software para clientes que a miúdo eran organizacións complexas significaba tamén unha dificultade, por parte desa organización, para prover unha lista pechada de necesidades ou de características que debía ter ese software: o que os clientes querían que fixese o software variaba a medida que pasaba o tempo, e iso obrigaba a repensar as características, engadir outras non previstas, ou descartar liñas de traballo xa comezadas.

Desta necesidade de adaptar a metodoloxía da xestión de proxectos a unha contorna rapidamente cambiante e innovadora naceu o Manifesto Áxil, e del, as distintas prácticas e metodoloxías áxiles.

Historia: o Manifesto áxil

No inverno de 2001, dezasete desenvolvedores de software reuníronse na estación de esquí de Snowbird, en Utah (Estados Unidos) para debater sobre metodoloxías de desenvolvemento de software, co propósito de estandarizar unhas prácticas que se adaptasen a esta contorna mudante.

Os asinantes
Os asinantes foron Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas.

Os asinantes procedían de distintas metodoloxías do desenvolvemento de software: Beck, Cunningham, Fowler, Grenning e Jeffries, da programación extrema e da refactorización; Beedle, Schwaber e Sutherland, de scrum; Van Bennekum, do método dinámico de desenvolvemento de sistemas (MDDS); Cockburn, de crystal; Highsmith, de desenvolvemento adaptativo; Kern, de desenvolvemento iterativo; e Mellor, do método Shlaer-Mellor. Ademais, Hunt e Thomas coescribiran The Pragmatic Programmer, obra onde, sen seguir unha metodoloxía única, defendían unha serie de prácticas resolutivas de programación, e Marick estaba especializado en procesos de testaxe.

Os asinantes traballaban todos (agás Van Bennekum) como programadores informáticos nos Estados Unidos, fóra das universidades, en consultorías e empresas de software. A maioría deles eran estadounidenses de nacenza, e só Fowler e Mellor naceran no Reino Unido, e Van Bennekum nos Países Baixos. Todos eran homes e tamén todos eran brancos.

Predecesores
Ademais dos traballos destas persoas, convocadas a Snowbird porque formularan, na teoría e na práctica, metodoloxías que compartían o mesmo espírito, xa dende mediados do século XX se estaba traballando con metodoloxías de desenvolvemento iterativoGerald M. Weinberg, citado en  "Nós xa facíamos desenvolvemento incremental por volta de 1957, nos Ánxeles, dirixidos por Bernie Dimsdale, na Service Bureau Corporation [, unha filial de IBM]. Dimsdale fora compañeiro de John von Neumann, e se cadra aprendera esta metodoloxía del, ou asumíraa como algo totamente natural. Lembro a Herb Jacobs (sobre todo a el, aínda que participáramos todos) a desenvolver unha simulación grande para Motorola usando esta metodoloxía, polo que me acorda... Todos nosoutros, ou así o lembro eu, pensabamos que a programación en fervenza era bastante parva, ou que polo menos ignoraba a realidade dos proxectos. De feito, creo que o que fixo por nós a programación en fervenza foi facer que nos decatásemos de que nós faciamos algo distinto, algo que non tiña máis nome có de desenvolvemento de software"., e a partir dos anos setenta con xestión dinámica de proxectos  e con desenvolvemento adaptativo.

Na década dos noventa, as metodoloxías lixeiras (lightweight, en inglés) comezaron a gañar tracción en oposición ás metodoloxías pesadas, ou heavyweight, aquelas que tiñan unha planificación estrita e exhaustiva (microxestión) e que se apoiaban en documentación moi ampla e sólida. Entre esas novas metodoloxías lixeiras estaba o DAR, ou desenvolvemento de aplicación rápida (RAD nas súas siglas en inglés), que aparecera en 1991; os procesos unificados (UP polas súas siglas en inglés) e o método dinámico de desenvolvemento de sistemas (MDDS, ou DSDM en inglés, a partir de 1994; scrum, desde 1995; crystal e a programación extrema (XP), os dous desde 1996; e o desenvolvemento orientado a funcionalidades, desde 1997. Aínda que estas metodoloxías e prácticas eran coñecidas antes da publicación do Manifesto áxil, na actualidade considéranse todas elas metodoloxías áxiles.

 O Manifesto áxil 

O Manifesto compúxose de catro valores centrais, que se concretaron nunha ducia de principios complementarios. Os catro valores centrais establecen unha priorización de obxectivos para o que debe ser un bo desenvolvemento de software:
 os individuos e as interaccións son máis importantes cós procesos e as ferramentas
 un software que funcione é máis importante ca unha completa documentación
 a colaboración cos clientes é máis importante cá negociación contractual con eles 
 a capacidade de resposta a cambios é máis importante que seguir un plan preestablecido.
Estes valores marcan unha prioridade; mais loxicamente non é a intención do Manifesto áxil negar a importancia, secundaria, que teñen os catro elementos non priorizados (procesos e ferramentas, documentación, contratos e plans).

Os principios son 12. Deles existe unha versión en inglés e unha tradución xa establecida en galego. O que aquí se ofrece é unha paráfrase deses doce principios.
 A prioridade é a satisfacción do cliente, e por iso hai que facilitarlle versións de proba valiosas do traballo, canto antes mellor, e canto máis a miúdo mellor. O termo "valiosas" refírese a que é o cliente quen determina as prioridades do traballo, aquilo que lle é máis importante e o que lle é máis secundario.
 Estas versións teñen que ser frecuentes, polo menos cada dous meses, pero se é cada dúas semanas aínda mellor. 
 O avance do proxecto mídese nas versións do software que somos capaces de presentar.
 Os cambios nas necesidades son bos, aínda cando chegan nas fases finais do proceso. O produto que se adapte mellor ao contorno será un mellor produto.
 A excelencia técnica e o bo deseño son bos para a adaptabilidade.
 Os procesos áxiles procuran un desenvolvemento sustentable, é dicir, que se poida manter o mesmo ritmo de desenvolvemento ao longo do tempo.
 A simplicidade é unha virtude importante : hai que desenvolver o que é necesario e descartar o que é accesorio.
 Cómpre ter persoal motivado, e hai que darlles apoio e confiar neles e nelas.
 Os mellores resultados conséguense en equipos que se autoorganizan.
 A parte comercial e o grupo de desenvolvemento teñen que traballar xuntos ao longo do proxecto.
 O mellor xeito de comunicarse é cara a cara.
 O equipo ten que revisar, cada certo tempo, as súas metodoloxías de funcionamento como tal.

Desenvolvementos posteriores
Nos anos que seguiron á distribución do Manifesto áxil publicárose distintas obras que desenvolvían os seus principios. Por exemplo, en 2005, un grupo liderado por Cockburn e Highsmith escribiron unha engádega aos principios de xestión de proxectos, a Declaración de Interdependencia , para aplicar a metodoloxía de desennvolvemento de software á xestión de proxectos. En 2009 outro grupo, neste caso onde traballaba Martin, publicou unha ampliación dos principios de desenvolvemento de software, chamada Manifesto da artesanía do software, para guiar o desenvolvemento de software áxil en parámetros de excelencia e boas prácticas.

E en 2011 a Alianza Áxil creou a Guía de prácticas áxiles, que en 2016 pasaría a chamarse Glosario áxil, unha escolma en continua evolución, e de código aberto, que recolle definicións de prácticas, termos e elementos áxiles, coas súas interpretacións e guieiros de uso, extraídos do coñecemento da comunidade de practicantes de metodoloxía áxil.

Notas

 Véxase tamén 
 Ligazóns externas 
 Movemento polo Desenvolvemento Áxil de Software ,tradución por Pablo Lago 

Categoría:Metodoloxía
Categoría:Software
Categoría:Programación