Áxil

Na Galipedia, a Wikipedia en galego.
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. 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[editar | editar a fonte]

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[1], as diferenzas principais eran estas:

O tempo[editar | editar a fonte]

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[editar | editar a fonte]

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[editar | editar a fonte]

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[editar | editar a fonte]

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[editar | editar a fonte]

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[editar | editar a fonte]

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 iterativo[2], e a partir dos anos setenta con xestión dinámica de proxectos[3][4] e con desenvolvemento adaptativo[5].

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[6][7]; 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.[8]

O Manifesto áxil[editar | editar a fonte]

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:

  1. os individuos e as interaccións son máis importantes cós procesos e as ferramentas
  2. un software que funcione é máis importante ca unha completa documentación
  3. a colaboración cos clientes é máis importante cá negociación contractual con eles
  4. 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)[9][10].

Os principios son 12. Deles existe unha versión en inglés e unha tradución xa establecida en galego[11]. O que aquí se ofrece é unha paráfrase deses doce principios.

  1. 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.
  2. Estas versións teñen que ser frecuentes, polo menos cada dous meses, pero se é cada dúas semanas aínda mellor.
  3. O avance do proxecto mídese nas versións do software que somos capaces de presentar.
  4. 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.
  5. A excelencia técnica e o bo deseño son bos para a adaptabilidade.
  6. Os procesos áxiles procuran un desenvolvemento sustentable, é dicir, que se poida manter o mesmo ritmo de desenvolvemento ao longo do tempo.
  7. A simplicidade é unha virtude importante : hai que desenvolver o que é necesario e descartar o que é accesorio.
  8. Cómpre ter persoal motivado, e hai que darlles apoio e confiar neles e nelas.
  9. Os mellores resultados conséguense en equipos que se autoorganizan.
  10. A parte comercial e o grupo de desenvolvemento teñen que traballar xuntos ao longo do proxecto.
  11. O mellor xeito de comunicarse é cara a cara.
  12. O equipo ten que revisar, cada certo tempo, as súas metodoloxías de funcionamento como tal.

Desenvolvementos posteriores[editar | editar a fonte]

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[12], 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[13], 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[editar | editar a fonte]

  1. Atkinson, Roger (decembro de 1999). "Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria". International Journal of Project Management 17 (6): 337–342. doi:10.1016/S0263-7863(98)00069-6. 
  2. Gerald M. Weinberg, citado en Larman, Basili & June 2003, pp. 47–56 "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".
  3. "Evolutionary Project Management (Original page, external archive)". Gilb. Arquivado dende o orixinal o 27-03-2016. Consultado o 30-4-2017.  Arquivado 27-03-2016 en Wayback Machine.
  4. "Evolutionary Project Management (New page)". Gilb. Consultado o 30-4-2017. 
  5. Edmonds, E. A. (1974). "A Process for the Development of Software for Nontechnical Users as an Adaptive System". General Systems 19: 215–18. 
  6. Martin, James (1991). Rapid Application Development. Macmillan. ISBN 0-02-376775-8. 
  7. Kerr, James M.; Hunter, Richard (1993). Inside RAD: How to Build a Fully Functional System in 90 Days or Less. McGraw-Hill. p. 3. ISBN 0-07-034223-7. 
  8. Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. Addison-Wesley. p. 27. ISBN 978-0-13-111155-4. 
  9. "1.2.2: Agile Manifesto - Module 2: Foundations of Software Product Management | Coursera". Coursera (en inglés). Consultado o 2018-02-09. 
  10. "Manifesto polo Desenvolvemento Áxil de Software". agilemanifesto.org. Consultado o 2018-02-09. 
  11. "Principios do Manifesto Áxil". agilemanifesto.org. Consultado o 2018-02-09. 
  12. Anderson, David (2005). "Declaration of Interdependence". Arquivado dende o orixinal o 27 de xaneiro de 2018. Consultado o 02 de setembro de 2018.  Arquivado 27 de xaneiro de 2018 en Wayback Machine.
  13. McDonald, Kent (1 de novembro de 2016). "How You Can Help Agile Alliance Help You". Agile Alliance Blog. Consultado o July 4, 2017. 

Véxase tamén[editar | editar a fonte]

Ligazóns externas[editar | editar a fonte]