Informática Manifiesto Ágil

0 Comments

En febrero 2001 hubo una reunión de expertos en la industria del software: nace el término “ágil” aplicado al desarrollo del software.

Objetivos:

  • Esbozar valores y principios que permitan a los desarrolladores desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.
  • Ser alternativa a procesos de desarrollo tradicionales.

Se creó “The Agile Alliance”: organización sin ánimo de lucro dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos.

Principios del Manifiesto Ágil

  1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.
  2. Dar la bienvenida a los cambios. se capturan los cambios para que el cliente tenga una ventaja competitiva. 3.
  3. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.
  4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
  5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.
  6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.
  7. El software que funciona es la medida principal de progreso.
  8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
  9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
  10. La simplicidad es esencial.
  11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos.
  12. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según ésto ajusta su comportamiento.

Según el Manifiesto se valora:

  • Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de éxito de un proyecto software. Es más importante construir un buen equipo que construir el entorno. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades.
  • Desarrollar software que funciona más que conseguir una buena documentación. La regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisión importante”. Estos documentos deben ser cortos y centrarse en lo fundamental.
  • Responder a los cambios más que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a lo largo del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc) determina también éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.

Desarrollo tradicional vs Desarrollo ágil

Desarrollo tradicional:

  • Inspirados en las ingenierías clásicas
  • Predictivos y optimizables
  • Orientados a:
    • La planificación
    • La documentación del proceso y el producto
  • Todas las fases tienen elementos de proceso definidos
  • Los equipos de desarrollo se comportan según las actividades del proceso

Desarrollo ágil:

  • Procesos adaptativos
    • Pensados para contextos cambiantes (requisitos inestables, cambios tecnológicos, etc)
    • Basados en reglas generativas
    • Minimizar la documentación
  • Asumen que:
    • Los requisitos cambian
    • Los planes cambian
    • El diseño es una actividad creativa
    • La construcción de sw (programación) es una actividad poco costosa
  • Al ser orientados a personas:
  • Es necesaria una alta participación y compromiso
    • Las personas participan en el proceso de decisión
    • Ciclos de vida iterativo o incremental iterativo
DESARROLLO TRADICIONAL DESARROLLO ÁGIL
Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo Basadas en heurísticas provenientes de buenas prácticas de producción de código
Resistencia a los cambios: Invertir esfuerzo al principio del proyecto para reducir la probabilidad de tener que realizar cambios durante el proyecto Especialmente preparados para cambios durante el proyecto (Los requisitos cambian frecuentemente)
Impuestas externamente Impuestas internamente (equipo)
Proceso mucho más controlado, con numerosas políticas/normas Proceso menos controlado, con pocos principios
Existe un contrato prefijado No existe un contrato tradicional o al menos es bastante flexible
El cliente interactúa con el equipo de desarrollo mediante reuniones El cliente es parte del equipo de desarrollo
Grupos grandes y posiblemente distribuídos Grupos pequeños (<10) y trabajando en el mismo sitio
Más artefactos Pocos artefactos
Más roles Pocos roles
La arquitectura del software es esencial y se expresa mediante modelos Menos énfasis en la arquitectura del software
Documentar y especificar para que los desarrolladores implementen la solución El centro de desarrollo de software es el desarrollador. Los usuarios aprenden durante el desarrollo
Planificar el proyecto para asegurar el desempeño del proyecto (alcance, tiempo, coste, calidad) Dos niveles de planificación y seguimiento: planificación global y planificaciones por iteraciones a bajo nivel.
Poder repetir el proceso La tecnología evoluciona rápidamente. El software es maleable e intangible

Tags: , , , , , , ,

Comments are closed.