Metodologías Ágiles de Desarrollo de Software: Características y Principios, Esquemas y mapas conceptuales de Psicomotricidad

¡Descarga Metodologías Ágiles de Desarrollo de Software: Características y Principios y más Esquemas y mapas conceptuales en PDF de Psicomotricidad solo en Docsity! POLITÉCNICO S INGENIERÍA, DISEÑO (POLI CRaNeoLoMotaro sen Unidad 2 / Escenario 3 RA ll Metodologías agiles 1 Metodologías de desarrollo de software 2 Metodologías tradicionales versus Metodologías ágiles Palabras clave: Softwore, procesos, modelos, desarrollo de softwore, ingeniería del software, procesos del software, cascada, espiral 1. Metodologías de desarrollo de software Antes de hablar de las metodologías ágiles de desarrollo de software, se verá cuáles son las características de las metodologías de desarrollo de software y en qué difieren de los modelos de procesos de software. Como se ha visto, un modelo de procesos de software define las actividades que se van a desarrollar para construir un software, las metodologías por su parte brindan métodos y herramientas específicas para desarrollar esas actividades cuidando el proceso. Dicho de otra manera, el modelo de procesos se enfoca en definir qué actividades desarrollar y en qué orden, mientras que las metodologías ofrecen herramientas que orientan el cómo desarrollar y gestionar estas actividades. Para cumplir con su propósito una metodología de desarrollo de software debe cumplir con unas características fundamentales: + Debe ajustarse a los objetivos y contexto del proyecto a realizar. + Debe cubrir todas las fases del ciclo del proceso de desarrollo de software. Como hemos visto hasta ahora cada etapa tiene un objetivo específico que se debe satisfacer para garantizar que el producto de software obtenido es un producto de calidad. + Debe además facilitar la integración de las distintas fases del ciclo de desarrollo permitiendo. + Rastreabilidad: es decir que es posible moverse no solo hacia adelante en el ciclo de vida, sino hacia atrás de forma que se pueda comprobar el trabajo realizado y se puedan efectuar correcciones. + — Fácil interacción entre etapas del ciclo de desarrollo: es necesaria una validación formal de cada fase antes de pasar a la siguiente. La información que se pierde en una fase determinada queda perdida para siempre, con un impacto en el sistema resultante. + Debe facilitar el entendimiento del problema a desarrollar por parte de todos los interesados, de manera que la metodología de alguna manera es también una herramienta que facilita la comunicación entre todos los involucrados. Esto significa que las herramientas de especificación y análisis debe ser amigables y sencillas. + La metodología debe ser la base de una comunicación efectiva, no solo entre el analista y el usuario sino en todos los implicados en el proyecto, es decir, no sólo en la determinación de los requisitos sino en la comunicación de los avances y decisiones tomadas en la ejecución del proyecto. MAA INTA O INTO) + La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. + 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. + 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. + Elsoftware que funciona es la medida principal de progreso. + Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante. + La atención continua a la calidad técnica y al buen diseño mejora la agilidad. + La simplicidad es esencial. + Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos. + En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento. La intención de los defensores del desarrollo de software ágil es que “el desarrollo ágil se centre en los talentos y habilidades de los individuos, y adapta el proceso a personas y equipos específicos.” Es decir, que el proceso se adapta a las necesidades de las personas y del equipo, no al revés. Por esta razón, los miembros de un equipo de software deben compartir las siguientes características clave: + Competencia: en un contexto de desarrollo ágil (así como en la ingeniería de software), la “competencia” incluye el talento innato, las habilidades específicas relacionadas con el software y el conocimiento general del proceso que el equipo haya elegido aplicar. La habilidad y el conocimiento del proceso pueden y deben considerarse para todas las personas que sean miembros ágiles del equipo. + Enfoque común: aunque los miembros del equipo ágil realicen diferentes tareas y aporten habilidades distintas al proyecto, todos deben centrarse en una meta: entregar al cliente en la fecha prometida un incremento de software que funcione. Para lograrlo, el equipo también se centrará en adaptaciones continuas (pequeñas y grandes) que hagan que el proceso se ajuste a las necesidades del equipo. MAA INTA O INTO) + Colaboración. La ingeniería de software (sin importar el proceso) trata de evaluar, analizar y usar la información que se comunica al equipo de software; crear información que ayudará a todos los participantes a entender el trabajo del equipo; y generar información (software de cómputo y bases de datos relevantes) que aporten al cliente valor del negocio. Para efectuar estas tareas, los miembros del equipo deben colaborar, entre sí y con todos los participantes. + Habilidad para tomar decisiones. Cualquier equipo bueno de software (incluso los equipos ágiles) debe tener libertad para controlar su destino. Esto implica que se de autonomía al equipo (autoridad para tomar decisiones sobre asuntos tanto técnicos como del proyecto). + Capacidad para resolver problemas difusos. Los gerentes de software deben reconocer que el equipo ágil tendrá que tratar en forma continua con la ambigúedad y que será sacudido de manera permanente por el cambio. En ciertos casos, el equipo debe aceptar el hecho de que el problema que resuelven ahora tal vez no sea el que se necesite resolver mañana. Sin embargo, las lecciones aprendidas de cualquier actividad relacionada con la solución de problemas (incluso aquellas que resuelven el problema equivocado) serán benéficas para el equipo en una etapa posterior del proyecto. + Confianza y respeto mutuos. El equipo ágil debe tener tanta y confianza para lograr “un tejido tan fuerte que el todo sea más que la suma de sus partes” + Organización propia. En el contexto del desarrollo ágil, la organización propia implica tres cosas: 1) el equipo ágil se organiza a sí mismo para hacer el trabajo, 2) el equipo organiza el proceso que se adapte mejor a su ambiente local, 3) el equipo organiza la programación del trabajo a fin de que se logre del mejor modo posible la entrega del incremento A continuación, verá las características de las principales metodologías ágiles según (Orjuela, 2008, pp. 159-171) 2.2. Programación Extrema (Extreme Programming, XP) Se basa en: + Retroalimentación continua entre el cliente y el equipo de desarrollo, + Comunicación fluida entre todos los participantes, om [INTA ON TO) + Simplicidad en las soluciones implementadas y agilidad para enfrentar los cambios. + XP se define como especialmente adecuada para proyectos con requisitos imprecisos y cambiantes, y donde existe un alto riesgo técnico. 2.3. Crystal Methodologies Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo, Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros). 2.4. Dynamic Systems Development Method (DSDM) Es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: 1. Estudio de viabilidad: se elabora un informe en el que se evalúa la conveniencia de desarrollar el proyecto. 2. Estudio del negocio: en esta fase se identifican las características esenciales del negocio y de la tecnología listando y priorizando los requerimientos del negocio. 3. Modelado funcional: se determinan las principales funcionalidades a través de un prototipo que debe ser aprobado para continuar con la siguiente fase. 4. Diseño y construcción: el prototipo funcional de la fase anterior se transforma en un prototipo de diseño más detallado que se debe implementar o construir. 5. Implantación: se verifica que el sistema cumple con lo deseado y se hace el entrenamiento de los usuarios. om [INTA ON TO) En la siguiente tabla se presentan las características fundamentales de los diferentes roles de acuerdo con Monte (2016). Rol Product owner (PO) El product owner es el enlace entre el cliente y el equipo de desarrollo. Debe conocer el negocio; ha de saber de qué se habla en el ámbito funcional; por qué una historia del product backlog es más importante que otra; y por qué la historia dice lo que dice. Scrum master (SM) Generalmente se relaciona con el rol del project manager, pero no es su equivalente, puede ser cualquier miembro del development team. El SM y el PO no pueden ser la misma persona. Tabla 2. Roles de SCRUM Funciones Definir la estrategia Definir los objetivos Mantener el product backlog Negociar el alcance con el cliente Definir, junto con el Serum master, los criterios de aceptación del proyecto y de cada sprint Mantener el presupuesto Participar en los sprint reviews Ayudar al SM y al DT a resolver cualquier cuestión en lo referente al proyecto, la funcionalidad y los productos. Es un mentor para los componentes del development team (DT). Es quien proporciona suporte al DT y ayuda a resolver los problemas. Es el enlace entre el DT yelPO. Es quien reporta, archiva y lleva registro. SEE Evaluación del curso del proyecto + De la gestión, junto con el DT, del curso del sprint, mediante el Scrum board. + De la evaluación del grado de avance y éxito del sprint, mediante el gráfico sprint burn-down. om [INTA ON TO) 10 Es quien propone, promueve y potencia mejoras sobre el proceso y sobre el Scrum team. De la gestión, junto con el DT, del alcance del sprint actual, mediante el sprint backlog. De la gestión de los problemas del sprint y del equipo, y de buscar soluciones mediante el incidence backlog y el impediments backlog. De la promoción de la mejora continua, mediante la reunión de Scrum retrospective. Development team (DT) El development team se caracteriza por ser flexible, autoorganizado y multidisciplinario. Se recomienda que este conformado entre tres y nueve Integrantes. De la estimación del esfuerzo, tanto de la funcionalidad descrita al product backlog como de cada tarea del sprint. De la gestión del sprint backlog. De la determinación del detalle de cada funcionalidad descrita en el product backlog y la subdivisión en tareas. De la entrega del producto acabado y convenientemente depurado, siguiendo los criterios de aceptación marcados. De la ejecución diaria del daily meeting y de cumplir las normas de esta actividad. om [INTA ON TO) 1 Stakeholder + De definir los criterios Los stakeholder son los de aceptación de cada funcionalidad del product receptores del producto backlog y de proporcionar acabado y, por lo tanto, son - resolver las dudas que le quienes hacen la aceptación. Y a presente el PO, que puede Para hacer esto, están obligados . . acudir tanto por cuenta a asistir a los sprint reviews. propia como por encargos del DT. Fuente: elaboración propia En la siguiente tabla se presentan las características fundamentales de los artefactos de acuerdo con Monte (016). Tabla 3. Artefactos de SCRUM Artefacto DESTA Product backlog (PB) El product backlog es la lista de Funcionalidades, productos o acciones que conforman el producto que se ha de construir. El product backlog se escribe en «el idioma» del cliente y se compone de user stories (historias de usuario) Cada historia se va completando y detallando a medida que se necesita o debe información. Ha de tener suficiente información para permitir que el equipo pueda hacer una estimación de lo que costaría hacerla realidad. El PO es responsable de mantener la lista, y de encargarse de que los usuarios proporcionan suficiente información útil y de priorizarla. Sprint backlog . ] (SB) El sprint backlog es la lista de funcionalidades extraídas del product backlog que se incorporan al sprint en curso. Como cada funcionalidad está tasada en un valor de story points, el PO, en función de la velocidad del equipo (team velocity) puede asignar las funcionalidades más prioritarias que cubran la capacidad de trabajo del DT en el sprint. om [INTA ON TO) 12 Referencias Doce Principios del manifiesto ágil. (2001) Recuperado de: http://agilemanifesto.org/iso/es/principles. html Jacobson, |., Booch,G., y Rumbaugh, J. (000). El proceso unificado de desarrollo de software. Madrid, España: Adisson Wesley. Manifesto for Agile Software Development. (2001) Recuperado de: http://agilemanifesto.org Martínez, A., Martinez, Raul. (2000). Guía a Rational Unified Process. Monte, J.L. (2016). Implantar SCRUM con éxito. Barcelona, España: Editorial UOC. Orjuela Duarte, A., 8 Rojas C., M. (2008). Las Metodologías de Desarrollo Ágil como una Oportunidad para la Ingeniería del Software Educativo. Revista Avances en Sistemas e Informática, 5 (2), 159-171. IAS Ne) 15 INFORMACIÓN TÉCNICA FACULTAD DE (S INGENIERÍA, DISEÑO E INNOVACIÓN Módulo: Ingeniería del Software | Unidad 2: Metodologías de desarrollo de software Escenario 3: Metodologías ágiles Autor: Diana Angélica Cruz Ortega Asesor Pedagógico: Luisa Esperanza Rincón Jiménez Diseñador Gráfico: Cristian Navarro Asistente: Ginna Quiroga or 7 Ao el Ne) 16