Ir al contenido

Diferencia entre revisiones de «Desarrollo ágil de software»

De Wikipedia, la enciclopedia libre
Explorar historial interactivamente
← Ir a diferencia anteriorIr a siguiente diferencia →
Contenido eliminado Contenido añadido
VisualWikitexto
mSin resumen de edición
Creación del bloque "El Manifiesto por el Desarrollo Ágil de Software"
Línea 17: Línea 17:


En 2011, la Agile Alliance creó la ''Guía de Prácticas Ágiles'' (rebautizada como ''Glosario Agile'' en 2016),<ref>{{Cita web|url=https://www.agilealliance.org/how-you-can-help-the-agile-alliance-help-you/|título=How You Can Help Agile Alliance Help You {{!}} Agile Alliance|fechaacceso=2024-04-02|fecha=2016-10-31|sitioweb=www.agilealliance.org|idioma=en-US}}</ref> un compendio de [[código abierto]] en evolución de las definiciones funcionales de las prácticas, términos y elementos ágiles, junto con interpretaciones y directrices sobre experiencias de la comunidad mundial de profesionales de Agile.
En 2011, la Agile Alliance creó la ''Guía de Prácticas Ágiles'' (rebautizada como ''Glosario Agile'' en 2016),<ref>{{Cita web|url=https://www.agilealliance.org/how-you-can-help-the-agile-alliance-help-you/|título=How You Can Help Agile Alliance Help You {{!}} Agile Alliance|fechaacceso=2024-04-02|fecha=2016-10-31|sitioweb=www.agilealliance.org|idioma=en-US}}</ref> un compendio de [[código abierto]] en evolución de las definiciones funcionales de las prácticas, términos y elementos ágiles, junto con interpretaciones y directrices sobre experiencias de la comunidad mundial de profesionales de Agile.

== El ''Manifiesto por el Desarrollo Ágil de Software'' ==

=== Valores del desarrollo ágil de software ===
Basándose en su experiencia común desarrollando software y ayudando a otros a hacerlo, los autores del manifiesto declararon que valoraban:<ref name=":0" />

* '''''Personas e interacciones''' por encima de procesos y herramientas''
* '''''Software operativo''' por encima de una documentación exhaustiva''
* '''''Colaboración del cliente''' por encima de la negociación del contrato''
* '''''Responder a los cambios''' en lugar de seguir un plan''

Es decir, aunque ambos lados tienen valor y los elementos de la derecha deberían tenerse en cuenta, los autores consideraron que los de la izquierda deberían tener más influencia en la forma en que las personas enfocan su trabajo.

Como explicó [[:en:Scott_Ambler|Scott Ambler]]:<ref>{{Cita web|url=https://ambysoft.com/essays/agilemanifesto.html|título=Examining the Agile Manifesto: Think Outside the Agile Box|fechaacceso=2024-04-09|fecha=2023-03-03|idioma=en-US}}</ref>

* Las herramientas y los procesos son importantes, pero lo es más contar con personas competentes que trabajen juntas con eficacia.
* Una buena documentación es útil para ayudar a la gente a entender cómo se ha construido el software y cómo utilizarlo, pero el objetivo principal del desarrollo es crear software, no la documentación.
* Un contrato es importante, pero no sustituye a una estrecha colaboración con los clientes para descubrir lo que necesitan.
* Un plan de proyecto es importante, pero no debe ser demasiado rígido para poder adaptarse a los cambios tecnológicos o del entorno, a las prioridades de las partes interesadas y a la forma en que la gente entiende el problema y su solución.

Algunos de los autores formaron la Agile Alliance, una organización sin ánimo de lucro que promueve el desarrollo de software según los valores y principios del manifiesto. Presentando el manifiesto en nombre de la Agile Alliance, [[Jim Highsmith]] dijo,<ref>{{Cita web|url=https://agilemanifesto.org/history.html|título=History: The Agile Manifesto|fechaacceso=2024-04-09|sitioweb=agilemanifesto.org}}</ref>
{{Cita|El movimiento Agile no es antimetodológico, de hecho muchos de nosotros queremos devolver la credibilidad a la palabra metodología. Queremos restablecer un equilibrio. Aceptamos el modelado, pero no para archivar un diagrama en un polvoriento repositorio corporativo. Aceptamos la documentación, pero no cientos de páginas de tomos nunca mantenidos y raramente utilizados. Planificamos, pero reconocemos los límites de la planificación en un entorno turbulento. Los que tachan de "hackers" a los defensores de XP, SCRUM o cualquier otra metodología ágil desconocen tanto las metodologías como la definición original del término hacker.|Jim Highsmith, History: The Agile Manifesto}}


== Referencias ==
== Referencias ==

Revisión del 11:39 9 abr 2024

En el desarrollo de software, las prácticas ágiles (a veces denominadas "Agile")[1]​ consisten en la mejora de requisitos, investigación y soluciones mediante el esfuerzo colaborativo de equipos autoorganizados y multifuncionales junto con sus clientes/usuarios finales.[2]​ Popularizados en el Manifiesto por el Desarrollo Ágil de Software de 2001,[3]​ estos valores y principios se derivaron de, y sustentan, una amplia gama de modelos de desarrollo de software, incluidos Scrum y Kanban.

Aunque hay muchas evidencias anecdóticas de que la adopción de prácticas y valores ágiles mejora la eficacia de los profesionales del software, así como de los equipos y las organizaciones, las pruebas empíricas son dispares y difíciles de encontrar.[4]​[5]​[6]​

Historia

Los métodos de desarrollo iterativo e incremental de software se remontan a 1957, mientras que la gestión evolutiva de proyectos[7]​ y el desarrollo adaptativo de software surgieron a principios de los setenta.[8]​

Durante la década de 1990, surgieron una serie de métodos ligeros de desarrollo de software como reacción a los métodos pesados predominantes (a menudo denominados en conjunto cascada) que los críticos describían como excesivamente regulados, planificados y microgestionados.[9]​ Entre estos métodos ligeros se encuentran: el desarrollo rápido de aplicaciones (RAD), de 1991;[10]​ el proceso unificado (UP) y el método de desarrollo de sistemas dinámicos (DSDM), ambos de 1994; Scrum, de 1995; Crystal Clear y la programación extrema (XP), ambos de 1996; y el desarrollo basado en funcionalidades (FDD), de 1997. Aunque todos ellos se originaron antes de la publicación del Manifiesto Agile, ahora se denominan colectivamente métodos ágiles de desarrollo de software.

Ya desde 1991 se habían producido cambios similares en el planteamiento de la fabricación y la gestión derivados de la lean manufacturing.[11]​

En 2001, diecisiete desarrolladores de software se reunieron en un complejo turístico de Snowbird (Utah) para debatir métodos de desarrollo ligero. Eran: Kent Beck (Extreme Programming), Ward Cunningham (Extreme Programming), Dave Thomas (PragProg, Ruby), Jeff Sutherland (Scrum), Ken Schwaber (Scrum), Jim Highsmith (Adaptive Software Development), Alistair Cockburn (Crystal), Robert C. Martin (SOLID), Mike Beedle (Scrum), Arie van Bennekum, Martin Fowler (OOAD y UML), James Grenning, Andrew Hunt (PragProg, Ruby), Ron Jeffries (Extreme Programming), Jon Kern, Brian Marick (Ruby, TDD) y Steve Mellor (OOA). Juntos publicaron el Manifiesto por el Desarrollo Ágil de Software.[3]​

En 2005, un grupo encabezado por Cockburn y Highsmith redactó un apéndice de principios de gestión de proyectos, la Declaración de Interdependencia del PM, para orientar la gestión de proyectos de software según los métodos ágiles de desarrollo de software.[12]​

En 2009, un grupo que trabajaba con Martin redactó una ampliación de los principios de desarrollo de software, el Manifiesto de la Artesanía del Software, para guiar el desarrollo ágil de software de acuerdo con la conducta y el dominio profesionales.

En 2011, la Agile Alliance creó la Guía de Prácticas Ágiles (rebautizada como Glosario Agile en 2016),[13]​ un compendio de código abierto en evolución de las definiciones funcionales de las prácticas, términos y elementos ágiles, junto con interpretaciones y directrices sobre experiencias de la comunidad mundial de profesionales de Agile.

El Manifiesto por el Desarrollo Ágil de Software

Valores del desarrollo ágil de software

Basándose en su experiencia común desarrollando software y ayudando a otros a hacerlo, los autores del manifiesto declararon que valoraban:[3]​

  • Personas e interacciones por encima de procesos y herramientas
  • Software operativo por encima de una documentación exhaustiva
  • Colaboración del cliente por encima de la negociación del contrato
  • Responder a los cambios en lugar de seguir un plan

Es decir, aunque ambos lados tienen valor y los elementos de la derecha deberían tenerse en cuenta, los autores consideraron que los de la izquierda deberían tener más influencia en la forma en que las personas enfocan su trabajo.

Como explicó Scott Ambler:[14]​

  • Las herramientas y los procesos son importantes, pero lo es más contar con personas competentes que trabajen juntas con eficacia.
  • Una buena documentación es útil para ayudar a la gente a entender cómo se ha construido el software y cómo utilizarlo, pero el objetivo principal del desarrollo es crear software, no la documentación.
  • Un contrato es importante, pero no sustituye a una estrecha colaboración con los clientes para descubrir lo que necesitan.
  • Un plan de proyecto es importante, pero no debe ser demasiado rígido para poder adaptarse a los cambios tecnológicos o del entorno, a las prioridades de las partes interesadas y a la forma en que la gente entiende el problema y su solución.

Algunos de los autores formaron la Agile Alliance, una organización sin ánimo de lucro que promueve el desarrollo de software según los valores y principios del manifiesto. Presentando el manifiesto en nombre de la Agile Alliance, Jim Highsmith dijo,[15]​

El movimiento Agile no es antimetodológico, de hecho muchos de nosotros queremos devolver la credibilidad a la palabra metodología. Queremos restablecer un equilibrio. Aceptamos el modelado, pero no para archivar un diagrama en un polvoriento repositorio corporativo. Aceptamos la documentación, pero no cientos de páginas de tomos nunca mantenidos y raramente utilizados. Planificamos, pero reconocemos los límites de la planificación en un entorno turbulento. Los que tachan de "hackers" a los defensores de XP, SCRUM o cualquier otra metodología ágil desconocen tanto las metodologías como la definición original del término hacker.
Jim Highsmith, History: The Agile Manifesto

Referencias

  1. ↑ «Agile With a Capital “A” Vs. agile With a Lowercase “a”. | Rally Software Blog». web.archive.org. 5 de enero de 2016. Consultado el 2 de abril de 2024. 
  2. ↑ «What is Agile? | Agile 101 | Agile Alliance». www.agilealliance.org (en inglés estadounidense). 29 de junio de 2015. Consultado el 2 de abril de 2024. 
  3. ↑ a b c «Manifiesto por el Desarrollo Ágil de Software». agilemanifesto.org. Consultado el 2 de abril de 2024. 
  4. ↑ Dybå, Tore; Dingsøyr, Torgeir (2008-08). «Empirical studies of agile software development: A systematic review». Information and Software Technology 50 (9-10): 833-859. ISSN 0950-5849. doi:10.1016/j.infsof.2008.01.006. Consultado el 2 de abril de 2024. 
  5. ↑ Lee, Gwanhoo; Xia, Weidong (2010). «Toward Agile: An Integrated Analysis of Quantitative and Qualitative Field Data on Software Development Agility». MIS Quarterly 34 (1): 87-114. ISSN 0276-7783. doi:10.2307/20721416. Consultado el 2 de abril de 2024. 
  6. ↑ Kroll, Josiane; Richardson, Ita; Prikladnicki, Rafael; Audy, Jorge L.N. (2018-01). «Empirical evidence in follow the Sun software development: A systematic mapping study». Information and Software Technology 93: 30-44. ISSN 0950-5849. doi:10.1016/j.infsof.2017.08.011. Consultado el 2 de abril de 2024. 
  7. ↑ «Tom Gilb & Kai Gilb - Helping you deliver Value to your Stakeholders | EvolutionaryProjectManagement». web.archive.org. 27 de marzo de 2016. Consultado el 2 de abril de 2024. 
  8. ↑ Gilb, Tom (1 de abril de 1981). «Evolutionary development». ACM SIGSOFT Software Engineering Notes 6 (2): 17. ISSN 0163-5948. doi:10.1145/1010865.1010868. Consultado el 2 de abril de 2024. 
  9. ↑ Swamidass, P. M., ed. (2000). Heavyweight project organizationHEAVYWEIGHT PROJECT ORGANIZATION (en inglés). Springer US. pp. 261-262. ISBN 978-1-4020-0612-8. doi:10.1007/1-4020-0612-8_400. Consultado el 2 de abril de 2024. 
  10. ↑ Internet Archive, James (1991). Rapid application development. New York : Macmillan Pub. Co. ; Toronto : Collier Macmillan Canada ; New York : Maxwell Macmillan International. ISBN 978-0-02-376775-3. Consultado el 2 de abril de 2024. 
  11. ↑ Sanchez, Luis M.; Nagi, Rakesh (2001-01). «A review of agile manufacturing systems». International Journal of Production Research (en inglés) 39 (16): 3561-3600. ISSN 0020-7543. doi:10.1080/00207540110068790. Consultado el 2 de abril de 2024. 
  12. ↑ «Declaration of Interdependence». web.archive.org. 27 de enero de 2018. Consultado el 2 de abril de 2024. 
  13. ↑ «How You Can Help Agile Alliance Help You | Agile Alliance». www.agilealliance.org (en inglés estadounidense). 31 de octubre de 2016. Consultado el 2 de abril de 2024. 
  14. ↑ «Examining the Agile Manifesto: Think Outside the Agile Box» (en inglés estadounidense). 3 de marzo de 2023. Consultado el 9 de abril de 2024. 
  15. ↑ «History: The Agile Manifesto». agilemanifesto.org. Consultado el 9 de abril de 2024. 

Bibliografía

Enlaces externos

Obtenido de «https://es.wikipedia.org/eswiki/w/index.php?title=Desarrollo_ágil_de_software&oldid=159318265»