Inicio » PrimerParcialIngSW1 » Algo sobre el desarrollo Ágil

Algo sobre el desarrollo Ágil

En 2001, Kent Beck y otros 16 notables desarrolladores, escritores y consultores IBEC011 (conocidos como la “Alianza Ágil”) firmaron el “Manifiesto para el desarrollo ágil de software“, el cual establecía:

Hemos descubierto mejores formas de desarrollar software al construirlo por nuestra cuenta y ayudar a otros a hacerlo. Por medio de este trabajo hemos llegado a valoran:

– A los individuos y sus interacciones sobre los procesos y las herramientas.
– Al software en funcionamiento sobre la documentación extensa.
– A la colaboración del cliente sobre la negociación del contrato.
– A la respuesta al cambio sobre el seguimiento de un plan.
Esto es, aunque los términos a la derecha tienen valor, nosotros valoramos más los aspectos, de la izquierda.

¿Qué es la agilidad en el contexto del trabajo de la ingeniería del software? Ivar jacobson proporciona una definición útil:

Agilidad se ha convertido actualmente en la palabra de moda en cuanto se describe un moderno proceso de software. Cualquiera es ágil. Un equipo ágil es un equipo rápido que responde de manera apropiada a los cambios. Éstos son, en gran parte, la materia del desarrollo de software. Cambios en el software que se va a construir, cambios entre los miembros del equipo, cambios debidos a las nuevas tecnologías, Cambios de todo tipo que pueden incidir en el producto que se construye o en el proyecto que crea el producto. En cualquier actividad de software se debe incluir un soporte para los cambios, esto es algo que adoptamos porque es el alma y el corazón del software. Un equipo ágil reconoce que el software lo desarrollan individuos que trabajan en equipo y que las aptitudes de esta gente, y su capacidad para colaborar, son esenciales para el éxito del proyecto.


La Alianza Ágil define 12 principios para quienes quieren alcanzar la agilidad:

  1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso.
  2. Bienvenidos los requisitos cambiantes, incluso en fases tardías del desarrollo. La estructura de los procesos ágiles cambia para la ventaja competitiva del cliente.
  3. Entregar con frecuencia software en funcionamiento, desde un par de semanas hasta un par de meses, con una preferencia por la escala de tiempo más corta.
  4. La gente de negocios y los desarrolladores deben trabajar juntos a diario a lo largo del proyecto.
  5. Construir proyectos alrededor de individuos motivados. Darles el ambiente y el soporte que necesitan, y confiar en ellos para obtener el trabajo realizado.
  6. El método más eficiente y efectivo de transmitir información hacia y dentro de un equipo de desarrollo es la conversación cara a cara.
  7. El software en funcionamiento es la medida primaria de progreso.
  8. Los procesos ágiles promueven el desarrollo sustentable. Los patrocinadores, desarrolladores y usuarios deben ser capaces de mantener un paso constante de manera indefinida.
  9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad
  10. La simplicidad —el arte de maximizar la cantidad de trabajo no realizado— es esencial.
  11. Las mejores arquitecturas, los mejores requisitos y los mejores diseños emergen de equipos autoorganizados.
  12. A intervalos regulares el equipo refleja la forma en que se puede volver más efectivo: entonces su comportamiento se ajusta y adecua en concordancia.

¿Qué es un proceso Ágil?

Cualquier proceso ágil de software se caracteriza de una manera que refiere tres suposiciones clave acerca de la mayoría de los proyectos de software:

  1. Resulta difícil predecir cuáles requisitos del software persistirán y cuáles cambiarán. De igual forma, es difícil presagiar cómo cambiarán las prioridades del cliente mientras se ejecuta un proyecto.
  2. Para muchos tipos de software, el diseño y la construcción están intercalados. Esto es, ambas actividades se deben realizar de manera conjunta, de modo que los modelos de diseño sean probados conforme se crean. Resulta difícil predecir cuánto diseño se necesita antes de que la construcción se utilice para probar el diseño.
  3. El análisis, el diseño y la construcción no son predecibles (desde el punto de vista de la planeación), lo que sería deseable.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Calificaciones UTRNG

Links de Descargas

cdlibre.org
- Página de Software Libre
PixaBay
- Imágenes libres de alta calidad
DistroWatch
- Todas las ditribuciones de Linux
Python
IDLE de Python
LinuxMint
- Ditribución de Linux altamente recomendable
YUMI
- Creador de USB Booting
Code Blocks
- Para programar con C/C++
-

Links Interesantes

Pilar Baselga
- Blog "No morir idiota". Investigaciones de interés general
-