Entendiendo el maniesto para el desarrollo ágil

1

¿Entiendes realmente el manifiesto para el desarrollo ágil? Creo que la mayoría de gente pasa por encima de él y no se plantea por qué ese grupo de personas que iniciaron la revolución del desarrollo ágil escogieron esas frases.

Con el objetivo de entenderlo mejor, me he dedicado a analizar cada frase del manifiesto, escribiendo un artículo entero para cada una de ellas. Aquí os dejo una copia del manifiesto con links a todos esos artículos. Espero que os guste el trabajo.


Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.

Seguimos estos principios:

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

El software funcionando es la medida principal de progreso.

Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Sobre el autor

Jose M. Huerta

Jose es Gestor de IT en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de desarrollo de software, usando metodologías clásicas, o desarrollo ágil, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable de desarrollo en Palma y Londres.

1 comment

  1. Gonzalo 24 abril, 2020 at 16:16 Responder

    Excelente post Jose… a mi lo que me enojaba mucho cuando desarrollaba eran 2 cosas principalmente con los cambios tardios, entiendo y respeto los cambios porque el cliente volantea pero no cuando por falta de analisis se encara todo para otro lado, y me paso la otra con sm que son talibanes donde nos enfocabamos en el sprint sin poder ver o saber que venia despues como que lo que desarrollemos este alineado con lo que viene y no que tenes que refactorizar todo el tiempo no se si se entiende bien….

Post a new comment