Unidad 1.2 B Metodos Agiles 1

Taller de SoftwareTaller de SoftwareMétodos Ágiles Métodos Ágiles

Sergio Sánchez Rios

Ingeniero en Informática

IntroducciónIntroducción

En el año 2001, Kent Beck y otros 16 desarrolladores destacados firmaron el manifiesto para el desarrollo ágil. Gracias a este manifiesto dichos actores postulan que valoran más lo siguiente:

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.

En esencia este movimiento ágil nace como un intento por superar las debilidades advertidas y reales en la ingeniería de software convencional.

¿Qué es la Agilidad?¿Qué es la Agilidad?

Según un diccionario de lengua española:

“Habilidad de cambiar rápida y efectivamente la dirección de un movimiento ejecutado a velocidad”.

De acuerdo a Jacobson: “La insistencia en el cambio es el conductor primordial hacia la agilidad”.

Un equipo ágil es un equipo rápido que responde de manera apropiada a los cambios.

Cambios en el software que se va a construir, cambios entre los miembros del equipo, cambios debido a las nuevas tecnologías, cambios de todo tipo que puedan influir el producto o en el proyecto que crea el producto.


Se podría pensar entonces que la Agilidad es solo saber adaptarse a los cambios, PERO ESTO NO ES ASI YA QUE SE DEBE TENER EN CUENTA LO MENCIONADO EN EL MANIFIESTO AGIL.

La alianza ágil definió 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.

3.- Entregar con frecuencia software en funcionamiento, desde un par de semanas hasta un par de meses, con preferencia en las escalas de tiempo más cortas.


4.- La gente de negocio 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 primaría 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.

Proceso ÁgilProceso Ágil

La agilidad puede ser aplicada a cualquier proceso de software. Sin embargo, para lograrlo es necesario considerar los siguiente:

El proceso debe diseñarse de una forma que permita al equipo del proyecto adaptar y coordinar las tareas.

Se debe poder conducir la planeación en una forma que se entienda la agilidad.

Eliminar todo pero no los productos de trabajo esenciales y mantenerlos controlados.

Se debe enfatizar en una estrategia de entrega incremental que proporciones software en funcionamiento.


Martin Fowler señala que los procesos ágiles de software se caracterizan de una manera que refieren tres suposiciones claves:

Resulta difícil predecir cuales requisitos de software persistirán o cambiaran. De igual forma, es difícil presagiar cómo cambiarán las prioridades del cliente mientras se ejecuta un proyecto.

Para muchos tipos de software, el diseño y la construcción están intercalados. Esto quiere decir, que ambos se deben realizar de forma conjunta, de modo que los modelos de diseño se prueben conforme como se crean.

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.


El gran punto según lo mencionado anteriormente tiene que ver con lo impredecible, y la pregunta que nace es, ¿Cómo se maneja esto en un proceso?.

La respuesta es generar procesos ágiles adaptables.

Pero la adaptabilidad sin progreso logra muy poco. Por lo que es importante que un proceso ágil realice una adaptación incremental. Estos incrementos deben entregarse en cortos periodos para que la adaptación mantenga un buen ritmo con el cambio.

Proceso ÁgilDichos Interesantes de Analizar

Proceso ÁgilDichos Interesantes de Analizar

Jim Highsmith

“Los metodólogos tradicionales son un conjunto de tipos que se arrastran en el lodo y que prefieren producir documentación que no fluye, en vez de un sistema de trabajo que cubra las necesidades del negocio”.

“Los metodólogos ligeros son un conjunto de intrusos informáticos que van a estar hay para dar una maldita sorpresa cuando intenten elevar sus juguetes al nivel de software de la empresa”.

Proceso ÁgilFactores Humanos


Los factores humanos son uno de los puntos importantes para llevar acabo algún proceso de desarrollo ágil. Cockburn y Highmith señalan:

“El desarrollo ágil se centra en los talentos y las habilidades de los individuos , puesto que el proceso se ajusta a personas y equipos específicos”.

Lo importante ES QUE EL PROCESO SE AJUSTA A LAS NECESIDADES DE LAS PERSONAS Y DEL EQUIPO, Y NO AL REVES.



Rasgos que deben poseer las personas que participen de un desarrollo ágil y el equipo mismo:

Competencia: abarca un talento innato, habilidades especificas relacionadas con el software y un conocimiento general del proceso que el equipo a decidido aplicar.

Enfoque Común: Todos los miembros del equipo deben enfocarse en una meta: entregar al cliente un incremento de trabajo de software dentro del tiempo establecido.

Colaboración: La ingeniería de software incluye evaluar, analizar y usar información que se comunica al equipo de software; crear información que ayudara al equipo de desarrollo y al cliente a entender el trabajo, etc. Sin que exista colaboración esto es imposible.




Habilidad para la toma de decisiones: todo equipo de software debe tener la habilidad de controlar su propio destino. Autonomía y Autoridad.

Capacidad de resolución de problemas confusos: Los gestores deben reconocer que el equipo de desarrollo enfrentará ambigüedades y sufrirá golpes de manera continua gracias a los cambios. Un problema que este resolviendo hoy no será el mismo que estaré resolviendo mañana.

Confianza y Respeto mutuo: el equipo “debe unirse con tanta fuerza, que el todo sea mayor que la suma de las partes”.




Organización Propia: esto implica tres factores:

El equipo ágil se organiza a si mismo para el trabajo que debe hacerse.

El equipo organiza el proceso que mejor se ajusta a su ambiente local.

El equipo organiza el programa de trabajo con el que se alcance de mejor manera la entrega incremental.

Esto mejora la COLABORACION Y MORAL DEL EQUIPO.

Proceso ÁgilModelo de Procesos

Proceso ÁgilModelo de Procesos

Es bueno señalar que todos los modelos ágiles se ajustan en mayor medida al Manifiesto Ágil y a los 12 principios señalados anteriormente.

Algunos de los modelos ágiles más connotados son:

Programación Extrema (PE) – Extreme Programming (XP)

Desarrollo Adaptativo de Software (DAS)

Método de desarrollo de sistemas dinámicos (MDSD)

Scrum

Cristal

Desarrollo conducido por características (DCC)

Modelos ÁgilesProgramación Extrema (PE)


Los primeros trabajos sobre las ideas y los métodos asociados a Programación Extrema se realizaron en la década de los 80, el trabajo fundamental fue publicado en el año 1999 por Kent Beck.

La PE utiliza como enfoque preferido la orientación a objetos.



Son importante destacar los siguientes aspectos de está metodología:

Valores

Comunicación

Retroalimentación

Simplicidad

Coraje

Principios

Retroalimentación Rápida

Cambio Incremental

Trabajo de Calidad

Simplicidad.



Características particularidades del proceso:

Fase inicial de captura de requerimientos es eliminada.

El ciclo de desarrollo de PE se divide en liberaciones, cada una de las cuales es medida en historias de usuarios

Historia de Usuarios: unidad funcional en un proyecto PE, debe ser entendible tanto para el cliente como para los desarrolladores, verificable y pequeña.

La PE logra todas las cosas mencionadas anteriormente en el contexto de cuatro actividades claves: Planeación, Diseño, Codificación y Prueba.



Planeación

Planeación DiseñoDiseño

PruebaPrueba Codificación

Codificación

-Historias del Usuario

Valores

Criterios de las pruebas de iteración

-plan de iteración

-Diseño simple cartas CRC

-Soluciones prototipos

-Programación en Parejas

-Integración Continua

-Refactoring

-Prueba de Unidad

-Pruebas de Aceptación

Lanzamiento



Otra forma de verlo



Planeación

Comienza creando una serie de historias que describen las características y la funcionalidad requeridas para el software que se construirá. Cada historia las escribe el cliente y se coloca en una carta índice.

El cliente le asigna un valor a la historia basándose en los valores generales del negocio.

Los miembros del equipo PE evalúan las historias y le asignan un costo, el cuál se mide en semanas de desarrollo. Si la historia requiere mas de tres semanas se solicita una reformulación.

Los clientes y el equipo PE trabajan juntos para decidir cómo agrupar las historias hacia el próximo lanzamiento. Se debe generar un compromiso básico de las historias que se desarrollaran en un incremento.



Planeación

Una vez establecido el compromiso básico, el equipo PE ordena las historias que se desarrollaran de una de las siguientes tres maneras:

1. Todas las historias serán implementadas de un modo inmediato (dentro de pocas semanas).

2. Las historias con valor mas alto se moverán en el programa y se implementaran al principio.

3. Las historias más riesgosas se moverán dentro del programa y se implementarán al principio.

Después de que se realiza el primer lanzamiento el equipo de PE calcula la velocidad del proyecto (La velocidad del proyecto es el número de historias implementadas en un lanzamiento).



Planeación

La velocidad del proyecto puede utilizarse para:

1. Estimar fechas de entrega y lanzamientos subsecuentes.

2. Determinar si se ha hecho un compromiso excesivo en algunas de las historias de todo el proyecto de desarrollo.

Es importante tener claro que, el cliente puede agregar historias, cambiar el valor de la historia existente, dividir historias o eliminarlas. Por lo que el equipo modifica los lanzamientos restantes y sus planes.



Planeación - Prácticas

Algunas buenas prácticas utilizadas en esta etapa son:

El juego de la Planificación (Planning Game): Se trata de realizar la planificación mediante un “juego” en el que deben participar desarrolladores, clientes y gestores. Se pretende involucrar al cliente, con el fin de evitar y hacer desaparecer nebulosas, cabos sueltos, requisitos sin definir etc..

Pequeñas Liberaciones (Small Releases): El software se desarrolla en lapsos cortos de tiempo, con objetivos que son actualizados frecuentemente (típicamente, cada 2 semanas).



Diseño

Esta actividad sigue de manera rigurosa el principio de mantener las cosas simples. Se prefiere simplicidad a complejidad.

El diseñó es una guía de implementación para una historia como esta escrita, ni más ni menos.

La PE apoya el uso de las tarjetas CRC como un mecanismo efectivo para pensar en el software en un contexto orientado a objetos. Estas tarjetas son el único producto del diseño.

Este modelo de clases Responsabilidad-Colaborador (CRC) proporciona un medio simple para identificar y organizar las clases relevantes para los requisitos del sistema o producto.



Diseño

Ejemplo CRC:



Diseño

Si el diseño de una historia se encuentra difícil, la PE recomienda la creación inmediata de un prototipo operacional de esa porción del diseño.

La PE apoya la refabricación (refactoring), una técnica de construcción que también es de diseño. Esto ya que el diseño se considera una fase que puede y debe modificarse de manera continua a medida que prosigue la construcción.



Diseño - Prácticas


Metáfora: Todos deben entender lo mismo, para lo cual se utilizaran “metáforas”. Al final se termina creando una “jerga” del proyecto que entiende todo el mundo.

Diseño Simple: El diseño debe ser todo lo simple que sea posible y sin lógicas duplicadas. Que sirva para alcanzar los resultados comunicados por el cliente en esa etapa del proceso (desde el punto de vista del desarrollador, debería pasar los tests y punto) .



Codificación

La PE recomienda que después de diseñar las historias y realizar el trabajo de diseño preliminar el equipo no debe moverse hacia la codificación, sino que debe desarrollar una serie de pruebas de unidad.

Una vez desarrollada las pruebas el desarrollador puede centrarse en implementar lo necesario para cumplirlas.

Uno de los aspectos importantes de la codificación es la PROGRAMACION EN PAREJAS. PE recomienda que dos personas trabajen juntas en una estación de trabajo creando una historia (se sigue el concepto dos cabezas piensan mejor que una).

También existe una integración continua, ya que cada vez que se termina de codificar una historia se debe integrar esta parte con las realizadas por los demás.



Codificación - Prácticas


Programación por Pares (Pair Programming): El código debe ser desarrollado por parejas que trabajen sobre la misma máquina. Esto que, a simple vista parece un gasto de recursos, consigue por un lado que el código desarrollado normalmente sea de mayor calidad (2 pares de ojos ven mejor que uno) y, por otro, que los desarrolladores trabajen todo el tiempo.

Refactoring: Una vez que pase los test un método se revisa para ver si se puede mejorar. Se refactoriza en todas las etapas del desarrollo, no solo al final.





Propiedad colectiva del código (Collective Ownership): Todo es responsabilidad de todos. Ninguna línea de código es conocida solo por un desarrollador.

Estándares de Codificación: Se siguen una serie de estándares a la hora de realizar el código de tal forma que cualquiera lea lo mismo en el mismo fragmento. Esto ayuda a que cualquier desarrollador pueda seguir el trabajo de otro cuando se rotan las parejas y a la transferencia de conocimiento dentro del equipo de desarrollo.





Integración Continua: El código debe ser probado e integrado cada poco tiempo con lo que los errores de codificación y de integración se detectan y se corrigen mucho antes.



Pruebas

Las pruebas de unidad que se crean deben implementarse con un marco de trabajo que permita automatizarlas. Esto apoya una estrategia de regresión de prueba.

Se recomienda que las pruebas de integración y de sistemas se vayan realizando a medida que se realizan un conjunto pequeño de pruebas de unidades. Esto se refrenda con la siguiente frase:

“Arreglar problemas pequeños cada pocas horas toma menos tiempo que arreglar problemas enormes justo antes de la

fecha limite.”

Las pruebas de aceptación o cliente, las especifica el cliente. Se realizan en base a las historias de usuario.



Pruebas – Prácticas


Pruebas Automatizadas (testing): Programación orientada por pruebas. El cliente realiza test funcionales y el desarrollador realiza tests por cada característica nueva.



Prácticas que involucran a todo el desarrollo.

Cuarenta horas semanales: Semanas de 40 horas de trabajo al 100% para todo el mundo del equipo. El trabajo del día a día está dirigido a maximizar la productividad, con lo que 40 horas semanales se ve más que suficiente.

Cliente siempre disponible: Es necesario que el usuario del sistema esté presente para resolver dudas y definir propiedades a más baja escala.

Modelos ÁgilesScrum


El nombre SCRUM (MELE en español) se deriva de una jugada de rugby. Este es un modelo ágil de proceso que desarrollaron Jeff Sutherland y su equipo a principios de la década de los 90.

Este proceso de desarrollo fue presentado a la OMG en el año 1995, y se han realizado algunos cambios, específicamente en el año 2001 por Schwaber y Beedle.

La jugada de rugby a la cuál hace mención el nombre SCRUM se refiere al proceso de volver a poner la pelota en juego, esto lo realiza un conjunto de jugadores.



Aplicado al desarrollo de software, la definición se refiere a la técnica de organización y gestión usada para llevar acabo exitosamente proyectos de desarrollo de software en un ambiente caótico.

Modelos ÁgilesScrum – Como se Diferencia


Los modelos de desarrollo de software tradicionales (tales como cascada) usan un método bien definido:

Se especifican los requerimientos.

Se tiene una descomposición lógica del trabajo.

Se estima y planifica.

Se comienza el desarrollo mientras se trata de limitar/controlar los cambios que amenazarán el plan.



SCRUM asume que los baselines cambiarán significativamente durante el proyecto.

En ambientes impredecibles, se debe usar métodos empíricos para monitorear el progreso y el cambio, en vez de métodos definitivos que intentan predecir el progreso y detener el cambio.

SCRUM espera el cambio.

El resultado final será un producto más cercano a las necesidades del usuario en el final del desarrollo.

SCRUM tiene también estructura y mecanismos de control.

Modelos ÁgilesScrum – PrincipiosModelos ÁgilesScrum – Principios

Estos principios son consistentes con lo que señala el manifiesto ágil:

Los equipos de trabajo pequeños están organizados para “maximizar la comunicación, minimizar los gastos generales y maximizar el hecho de compartir conocimientos tácitos e informales”.

El proceso de adaptarse a los cambios técnicos y de negocios “para asegurar que se produzca el mejor producto posible”.

El proceso produce incrementos frecuentes de software “los cuales se pueden inspeccionar, ajustar, probar, documentar y construir”.

El trabajo de desarrollo y la gente que lo realiza están divididos en “particiones o paquetes de bajo acoplamiento”.

Conforme se construye el producto se realizan pruebas y documentación constante.

Modelos ÁgilesScrum – PrincipiosModelos ÁgilesScrum – Principios

Estos principios son consistentes con lo que señala el manifiesto ágil:

Los procesos de scrum proporcionan la “capacidad de declarar un producto como ‘realizado’ siempre que esto se requiere”.

Bajo estos principios se guían las actividades dentro un proceso que incorpora las siguientes actividades del marco de trabajo: requisitos, análisis, diseño, evolución y entrega.

Modelos ÁgilesScrum – Proceso




Features (Características): son una lista que considera la prioridad de los requisitos o características de proyecto que proporcionan un valor comercial para el cliente. En cualquier minuto se pueden agregar requerimientos a las características.

Sprint: consiste en unidades de trabajo que se requieren para satisfacer un requisito definido en las características en un periodo definido (lapso usual 30 días). Durante el sprint no se pueden introducir cambios a las características.

Reuniones de Scrum: son reuniones cortas (por lo general de 15 minutos) y las realiza a diario el equipo de scrum.



Reuniones de Scrum: En estas reuniones se deben responder las siguientes preguntas:

• ¿Qué hiciste desde la última reunión?.

• ¿Cuáles obstáculos encontraste?.

• ¿Qué esperas lograr para la siguiente reunión del equipo?.

Un líder de equipo, llamado “maestro de scrum”, preside la reunión y evalúa las respuestas de cada persona.

Demostración: se entrega el incremento de software al cliente de forma que éste demuestre y evalué la funcionalidad implementada.



Como SCRUM no es realmente una metodología de desarrollo de software, sino de gestión de proyectos de desarrollo, no determina prácticas de desarrollo de software. Por tanto, la mayoría de los métodos de desarrollo de software pueden ser gestionados usando SCRUM sin mayores conflictos.

¿Cuándo USARLO?

No es apropiado para todas las situaciones, especialmente:

• Grandes equipo.

• Estructuras organizacionales complejas de equipos.

• Equipos distribuidos geográficamente.

• Aplicaciones Críticas.

BibliografíaBibliografía

“Apuntes Ingeniería de Software MTI”, Marcello Viscontti & Hernán Astudillo.

“Ingeniería de Software: Un enfoque práctico”, Roger S. Pressman, Sexta Edición, 2005.

http://www.extremeprogramming.org/

http://www.extremeprogramming.org/

Unidad 1.2 B Metodos Agiles 1

Documents