DESARROLLO AGIL ING. MA. MARGARITA LABASTIDA ROLDÁN

Transcripción

1 DESARROLLO AGIL ING. MA. MARGARITA LABASTIDA ROLDÁN

2 CONTENIDO Qué es un proceso agil Proceso Ágil Otros modelos ágiles de proceso Programación extrema Desarrollo adaptativo de software Método de desarrollo de sistemas dinámicos Cristal Desarrollo impulsado por las características Desarrollo esbelto de software Modelado ágil El proceso unificado ágil

3 Desarrollo Ágil Los métodos ágiles se desarrollaron en un intento por superar las debilidades advertidas y reales en la ingeniería del software convencional. El desarrollo ágil proporciona beneficios importantes, pero es imposible aplicarlo en todos los proyectos, productos, personas y situaciones.

4 Qué es? La ingeniería de software ágil combina una filosofía y un conjunto de directrices de desarrollo. La filosofía busca la satisfacción del cliente y la entrega temprana de software incremental; equipos de proyectos pequeños y con alta motivación. Las directrices de desarrollo resaltan la entrega sobre el análisis y el diseño y la comunicación activa y continua entre los desarrolladores y los clientes.

5 Agilidad La agilidad se ha convertido en la palabra idónea para describir un proceso de software moderno. Un equipo ágil es un equipo rápido que responde de manera apropiada a los cambios. Cambios propios del software, Cambios entre miembros del equipo Cambios de nuevas tecnologías Cambios que inciden en el producto o proyecto Un equipo ágil reconoce que el software lo desarrollan individuos que trabajan en equipo y que las aptitudes y su capacidad de colaboración, son esenciales para el éxito del proyecto. La agilidad es dinámica, con contenido específico, ajustable al cambio de manera dinámica y orientada al crecimiento Steven Goldman et al..

6 Agilidad Es mas que una respuesta efectiva al cambio. Estimula las estructuras y actitudes de los equipos para que la comunicación sea más fácil. Resalta la entrega rápida de software y le resta importancia a los productos de trabajo intermedio. Adopta al cliente como una parte del equipo de desarrollo y trabaja para eliminar la actitud del tipo nosotros y ustedes. Reconoce que la planeación tiene sus límites en un mundo incierto y que el plan de proyecto debe ser flexible.

7 Agilidad La alianza Ágil define 12 principios para alcanzar la agilidad: 1. Satisfacer al cliente mediante la entrega temprana y continua de software valioso. 2. La estructura de los procesos ágiles cambia para la ventaja competitiva del cliente. 3. Entrega 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.

8 Agilidad 5. Construir proyectos alrededor de individuos motivados. 6. Conversación cara a cara para transmitir información 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 definida. 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.

9 Agilidad 11. Los mejores arquitectos, los mejores requisitos y los mejores diseños emergen de equipos auto organizados. 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.

10 Agilidad La agilidad se puede aplicar en cualquier proceso de software, pero el equipo debe ser capaz de adaptar y coordinar las tareas con fluidez de un enfoque de desarrollo ágil, y enfatizar en una estrategia de entrega incremental que proporcione software en funcionamiento al cliente tan rápido como sea factible para el tipo de producto y el ambiente operativo.

11 Proceso Ágil Cualquier proceso ágil de software se caracteriza de una manera que refiere tres suposiciones clave de los proyectos de software: Es difícil predecir los requisitos de software que persistirán y cuales cambiarán. Es difícil presagiar como cambiarán las prioridades del cliente mientras se ejecuta un proyecto. El diseño y la construcción se deben realizar de manera conjunta. El análisis, el diseño y la construcción no son predecibles (desde el punto de vista de la planeación) Un proceso ágil debe ser adaptable.

12 Proceso Ágil Un proceso ágil de software debe adaptarse en forma incremental. Un equipo ágil requiere de la retroalimentación con el cliente para que sea factible realizar la adaptaciones apropiadas. Para una efectiva retroalimentación se manejan prototipos operacionales o una porción de un sistema operacional. Por lo anterior debe instituirse una estrategia incremental de desarrollo.

13 Proceso Ágil Los incrementos de software deben entregarse en cortos periodos para que la adaptación mantenga un buen ritmo con el cambio (imprevisibilidad). Permitiendo con lo anterior que el cliente evalúe el incremento del software de manera regular, proporcionando retroalimentación necesaria al equipo de software.

14 Proceso Ágil Se debe destacar la importancia de los factores de las personas en un desarrollo ágil exitoso. Cockburn y Highsmith: 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. Los miembros de un equipo de software deben adquirir ciertas características clave entre la gente del equipo ágil y el equipo mismo.

15 Proceso Ágil: Rasgos Clave Competencia: Abarca un talento innato, habilidades específicas relacionadas con el software, y un conocimiento del proceso que el equipo haya elegido aplicar. Enfoque común: Todos deben enfocarse en una meta: entregar al cliente un incremento de trabajo de software dentro del tiempo establecido. El equipo se debe centrar en adaptaciones continuas. Colaboración: Incluye evaluar, analizar y usar información que se comunica al equipo de software, así como crear información que ayudará al cliente y a otros a entender el trabajo del equipo y construir información que ofrezca un valor comercial para el cliente.

16 Proceso Ágil: Rasgos Clave Habilidad para la toma de decisiones: Debe permitirse la libertad de controlar su propio destino, con autonomía, en cuanto a cuestiones técnicas y del proyecto. Capacidad de resolución de problemas confusos: El equipo se enfrentará a ambigüedades de forma continua debido al cambio, sin embargo las lecciones aprendidas en cualquier actividad benefician al equipo en fases posteriores al proyecto. Confianza y respeto mutuo: Debe ser un equipo unido donde muestre confianza y respeto necesarios de forma que el todo sea mayor que la suma de las partes.

17 Proceso Ágil: Rasgos Clave Organización propia: implica tres factores El equipo ágil se organiza a sí 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 del incremento del software. El equipo sirve como su propia gestoría: El equipo selecciona la cantidad de trabajo que cree que es capaz de hacer dentro de la iteración y el equipo se compromete con el trabajo

18 Modelos Ágiles de Proceso Programación Externa Desarrollo adaptativo de software (DAS) Método de desarrollo de sistemas dinámicos (MDSD) Melé Cristal Desarrollo conducido por características (DCC) Modelo Ágil (MA)

19 Programación Externa (PE) La PE utiliza un enfoque orientado a objetos como su paradigma de desarrollo preferido. La PE abarca un conjunto de reglas y prácticas que ocurren en el contexto de cuatro actividades del marco de trabajo: Planeación Diseño Codificación Pruebas

20 Programación Externa (PE)

21 Programación Externa (PE) Planeación: La actividad de planeación comienza creando una serie de historias que describen las características y la funcionalidad requeridas para el software. Cada historia la escribe el cliente, de igual forma le asigna un valor. Los miembros del equipo evalúan cada historia y le asignan un costo, medido en semanas de desarrollo. Los clientes y el equipo trabajan juntos para decidir como agrupar las historias para que el equipo de la PE las desarrolle.

22 Programación Externa (PE) El equipo ordena las historias que se desarrollarán de tres maneras: 1) todas las historias se implementaran de forma inmediata; 2) las historias con mayor valor se cambiaran al principio; 3) las historias mas riesgosas se moverán dentro del programa. Una vez establecidas las historias se calcula la velocidad del proyecto que se utiliza para: 1) estimar fechas de entrega y el programa para lanzamientos subsecuentes y 2) determinar si se hizo un compromiso excesivo en alguna historia, de ser así el contenido de los lanzamientos se modifica, al igual que las fechas de entrega.

23 Programación Externa (PE) Diseño: sigue el principio MS (mantenimiento simple). El diseño ofrece una guía de implementación para una historia, se utilizan tarjetas CRC (colaborador responsabilidad clase) que identifican y organizan las clases orientadas a objetos relevantes para el incremento del software. Si se encuentra un problema como parte del diseño de la historia, la PE recomienda la creación de un prototipo operacional, llamado solución pico, el propósito es reducir el riesgo cuando comiencen la implementación

24 Programación Externa (PE) Además la PE apoya la refabricación, cuyo propósito es controlar modificaciones al sugerir pequeños cambios del diseño que pueden mejorar de manera radical el diseño. La refabricación ocurre de manera continua a medida que se construye el sistema; proporcionando un guía sobre como mejorar el diseño.

25 Programación Externa (PE) Codificación: la PE recomienda antes de la codificación desarrollar una serie de pruebas de unidad que ejerciten cada una de las historias que se van a incluir en el lanzamiento actual. Una vez creada la prueba de unidad, el desarrollador se centra en la implementación para pasar la prueba de unidad y al concluir proporcionar una retroalimentación instantánea. Un concepto clave es la programación en pareja, que recomienda que dos personas trabajen en una estación de trabajo para crear el código de una historia.

26 Programación Externa (PE) Permitiendo por ejemplo que una persona piense en los detalles de codificación de una parte del diseño, mientras que la otra se asegura de que sigan los estándares de codificación y que el código que se genera coincida con el diseño más amplio de la historia. Cuando los programadores completan su trabajo el código que desarrollaron se integra con el trabajo de otros; en otros casos la pareja es la responsable de la integración. Esta integración continua ayuda a evitar problemas de compatibilidad e interfaz y proporciona un ambiente de prueba de humo.

27 Programación Externa (PE) Pruebas: las pruebas de unidad que se crean deben implementarse con un marco de trabajo que permita automatizarlas (pueden ejecutarse de manera fácil y repetida). Cuando las unidades individuales se organizan en un conjunto universal de pruebas. Las pruebas de integración y validación del sistema se realizan diario, indicando un progreso continuo. Las pruebas de aceptación de la PE, también llamadas pruebas del cliente, las especifica el cliente y se enfocan en las características generales y la funcionalidad del sistema, elementos visibles y revisables por el cliente.