Un Framework para Evaluación de Metodologías Ágiles

Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
 5
 
  Un Framework para Evaluación de Metodologías Ágiles
Share
Transcript
  Un Framework para Evaluación de Metodologías Ágiles Karla MendesCalo (1) , Elsa Estevez (1,2) , Pablo Fillottrani (1)   (1) Laboratorio de I&D en Ingeniería de Software y Sistemas de Información (LISSI) Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur, Avenida Alem 1253, (8000) Bahía Blanca, Argentina (2)  United Nations University – International Institute for Software Technology Macao SAR, China {kmca, ece, prf}@cs.uns.edu.ar Resumen.  Las metodologías de desarrollo ágil se basan fundamentalmente en la colaboración con los usuarios de software durante todo el proceso de desarrollo, la facilidad para adaptar el producto a cambios en requerimientos y en la entrega incremental del producto. Basadas en el Manifiesto Ágil, han sido aceptadas y son utilizadas con éxito en proyectos donde los requerimientos detallados son inicialmente desconocidos y se van construyendo durante el proceso de desarrollo a partir de interacciones con los usuarios y de la retro-alimentación obtenida a partir de las mismas. En este trabajo se propone un framework de evaluación para las metodologías ágiles de desarrollo, y se aplica a dos de ellas – Scrum y eXtreme Programming (XP). La definición de este framework cuantitavio es novedosa, especialmente porque permite evaluar en cuánto las metodologías ágiles satisfacen los principios básicos definidos por el Manifiesto Ágil. Su utilización es recomendada al momento de decidir una metodología a adoptar. Keywords: Manifiesto Ágil, Metodologías Ágiles, SCRUM, XP 1 Introducción Tradicionalmente, los procesos de desarrollo de software llevan asociado un marcado acento en el control del proceso. Definen actividades, artefactos y documentación a producir, herramientas y notaciones a ser utilizadas, orden de ejecución de las actividades, entre otras definiciones. Si bien existen varios procesos de desarrollo – Proceso Unificado [1], Proceso V [2], etc. , la mayoría de estos procesos se derivan del Modelo de Cascada propuesto por Boehm [3]. Estos procesos, denominados tradicionales, han demostrado ser efectivos en proyectos de gran tamaño, particularmente en lo que respecta a la administración de recursos a utilizar y a la planificación de los tiempos de desarrollo. Sin embargo, el enfoque propuesto por estos métodos no resulta el más adecuado para el desarrollo de proyectos donde los requerimientos del sistema son muy cambiantes, se pide reducir drásticamente los tiempos de desarrollo y al mismo tiempo producir un producto de alta calidad.  Como alternativa a los métodos tradicionales de desarrollo, surgen las Metodologías Ágiles. Manteniendo prácticas esenciales de las metodologías tradicionales, las metodologías ágiles se centran en otras dimensiones del proyecto, como por ejemplo: la colaboración con los usuarios durante todas las etapas del proceso de desarrollo, y el desarrollo incremental del software con iteraciones muy cortas que entregan una solución a medida. Las prácticas ágiles están especialmente indicadas para productos cuya definición detallada es difícil de obtener desde el comienzo, o que si se definiera, tendría menor valor que si el producto se construye con una retro-alimentación continua durante el proceso de desarrollo. El objetivo de este trabajo es presentar un marco de evaluación de metodologías ágiles que permite evaluar en qué medida las metodologías cumplen con los valores declarados por el Manifiesto Ágil. El marco de evaluación permite tomar una decisión más informada al momento de seleccionar una de estas metodologías. A modo de ejemplo, el marco se aplica para las metodologías SCRUM y XP. El resto de este trabajo se estructura de la siguiente manera. La Sección 2 presenta el Manifiesto Ágil y algunas de las metodologías ágiles comúnmente utilizadas. La Sección 3 explica en detalle dos metodologías – SCRUM y XP. A continuación, la Sección 4 presenta y explica el framework de evaluación, mientras que la Sección 5 muestra su aplicación a las metodologías SCRUM y XP. Finalmente, la Sección 6 presenta comparación con trabajos relacionados, conclusiones y trabajo futuro. 2 Manifiesto Ágil y Metodologías Ágiles de Desarrollo En febrero de 2001, académicos y expertos de la industria del software se reunieron en Utha, Estados Unidos, a fin de discutir los valores y principios que facilitarían desarrollar software más rápidamente y respondiendo a los cambios que surjan a lo largo del proyecto. La idea era ofrecer una alternativa a los procesos de desarrollo tradicionales. Como resultado de esta reunión, se creó The Agile Alliance [4], una organización, sin fines de lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones a adoptar dichos conceptos. El resultado de esta reunión fue un documento conocido como el Manifiesto Ágil [5]. El Manifiesto Ágil incluye cuatro postulados y una serie de principios asociados. Sus postulados son: 1)   Valorar al individuo y a las interacciones del equipo de desarrollo por encima del proceso y las herramientas . Tres premisas sustentan este principio: a) los integrantes del equipo son el factor principal de éxito de un proyecto; b) es más importante construir el equipo de trabajo que construir el entorno; y c) es mejor crear el equipo y que éste configure el entorno en base a sus propias necesidades. 2)   Valorar el desarrollo de software que funcione por sobre una documentación exhaustiva . El principio se basa en la premisa que los documentos no pueden sustituir ni ofrecer el valor agregado que se logra con la comunicación directa entre las personas a través de la interacción con los prototipos. Se debe reducir al mínimo indispensable el uso de documentación que genera trabajo y que no aporta un valor directo al producto.  3)   Valorar la colaboración con el cliente por sobre la negociación contractual . En el desarrollo ágil el cliente se integra y colabora con el equipo de trabajo como un integrante más. El contrato en sí no aporta valor al producto, es sólo un formalismo que establece líneas de responsabilidad entre las partes. 4)   Valorar la respuesta al cambio por sobre el seguimiento de un plan . La evolución rápida y continua deben ser factores inherentes al proceso de desarrollo. Se debe valorar la capacidad de respuesta ante los cambios por sobre la capacidad de seguimiento y aseguramiento de planes pre-establecidos. El ciclo de desarrollo que aplican las Metodologías Ágiles es iterativo e incremental. Este modelo permite entregar el software en partes pequeñas y utilizables, conocidas como incrementos . Cada iteración se puede considerar como un mini-proyecto en el que las actividades de análisis de requerimiento, diseño, implementación y testing son llevadas a cabo con el fin de producir un subconjunto del sistema final. El proceso se repite varias veces produciendo un nuevo incremento en cada ciclo hasta que se elabora el producto completo. Si bien todas las metodologías ágiles adoptan este ciclo, cada una presenta sus propias características.. Las metodologías ágiles más comúnmente usadas se describen a continuación. Scrum  [6] – Indicada para proyectos con alto ratio de cambio de requerimientos, su principal característica es la definición de sprints  – cada una de las iteraciones del proceso con una duración máxima de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. Otra característica importante son las reuniones diarias que se llevan a cabo a lo largo del proyecto. Dichas reuniones no requieren más de 15 minutos del equipo de desarrollo y su objetivo son la coordinación e integración del producto a entregar. Cristal Methodologies  [7] – Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por la valoración a las personas que componen el equipo de trabajo y la reducción al máximo del número de artefactos producidos. Enfatiza en esfuerzos para mejorar las habilidades de los integrantes del equipo y para definir políticas de trabajo en equipo. Las políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear corresponde a equipos con 3 a 8 integrantes y Crystal Orange en equipos con 25 a 50 integrantes. Dynamic Systems Development Method (DSDM) [8] – Cumple con las características generales de definir un proceso iterativo e incremental. Propone cinco etapas de desarrollo: Estudio de Viabilidad, Estudio del Negocio, Modelado Funcional, Diseño y Construcción, e Implementación. La iteración se produce en las tres últimas etapas, sin embargo prevé retro-alimentación en todas. Adaptive Software Development (ASD) [9] –   Es un proceso iterativo, tolerante a cambios y orientado a los componentes de software. Define tres etapas para el ciclo de vida: a) Especulación – se inicia el proyecto y se planifican las características del software; b) Colaboración – se desarrolla el producto; y c) Aprendizaje – se revisa la calidad del producto y se entrega al cliente. La revisión tiene como objetivo aprender de los errores cometidos y volver a iniciar el ciclo de desarrollo. Feature-Driven Development (FDD) [10] – Define un proceso iterativo, con iteraciones cortas de dos semanas como máximo. El ciclo de vida consta de cinco pasos: a) Desarrollo de un modelo global, b) Construcción de una lista de funcionalidades, c) Planeación por funcionalidad, d) Diseño por funcionalidad y e) Construcción por funcionalidad.  Programación Extrema (XP) [11] – Define un proceso iterativo e incremental con pruebas unitarias continuas y entregas frecuentes. El cliente o un representante del cliente son integrados al equipo de desarrollo. Recomienda que el desarrollo de las funciones del producto sea realizado por dos personas en el mismo puesto – programación por pares. Antes de incorporar nueva funcionalidad, se deben corregir todos los defectos encontrados. Constantemente, se llevan a cabo pruebas de regresión a fin de detectar los posibles errores. 3 Scrum y XP – Principios, Actividades, Roles y Prácticas Las próximas dos secciones presentan en detalle los principios, actividades, roles a cubrir en los equipos de trabajo y prácticas recomendadas de Scrum y XP. 3.1 Scrum La metodología respeta el ciclo de vida evolutivo y la entrega incremental. Al comienzo del proyecto, se identifican los requerimientos funcionales y no funcionales y se conforma una lista de los mismos llamada  product backlog . El product backlog constituye el artefacto base para medir el avance del proyecto. Las iteraciones, denominadas sprints  entregan partes del producto llamadas builds , que si bien no incluyen toda la funcionalidad del sistema, constituyen ejecutables operativos. Cada iteración comienza con una planificación adaptativa guiada por el cliente y culmina con una demostración del build al cliente. Cada sprint puede durar como máximo 30 días. En cada sprint, el equipo de desarrollo selecciona del product backlog un conjunto de ítems de mayor prioridad que se convierte en el objetivo a desarrollar. La metodología propone las siguientes tres fases: 1)   Fase de Planeamiento  – es subdividida en: a) Planeación  – se define el equipo del proyecto, herramientas, el sistema de desarrollo y se crea el product backlog con la lista de requerimientos conocidos hasta ese momento, se definen prioridades para los requerimientos y se estima el esfuerzo necesario para llevar a cabo la implementación de los mismos; y b)  Diseño Arquitectónico  – se define la arquitectura del producto que permita implementar los requerimientos definidos. 2)   Fase de Desarrollo - es la parte ágil, donde el sistema se desarrolla en sprints. Cada sprint incluye las fases tradicionales del desarrollo de software – relevamiento de requerimientos, análisis, diseño, implementación y entrega. 3)   Fase de Finalización – incluye integración, testing y documentación . Indica la implementación de todos los requerimientos, quedando el product backlog vacío y el sistema listo para entrar en producción. La metodología propone la creación de equipos de trabajo auto-dirigidos y auto-organizados, aconsejando equipos pequeños que maximizan la comunicación entre sus integrantes. Dentro del equipo de trabajo, se identifican roles com o el S crum  Master   – responsable de asegurar que el proyecto se ejecute en base a las prácticas, valores y reglas de Scrum-; el  Dueño del Producto  – responsable del proyecto, administra, controla y mantiene y publica el product backlog-; los  Miembros del  Equipo  – tienen la autoridad para decidir acerca de las acciones a realizar y  organizarlas de tal manera de alcanzar los objetivos de cada sprint; y el Cliente  – participa de las tareas relacionadas con la lista de requerimientos del producto a desarrollar, aporta ideas, sugerencias y nuevas necesidades-. Scrum prevee las siguientes prácticas: o    Reunión de Planeamiento del Sprint    –   organizada por el Scrum Master, se divide en dos etapas. En la primera etapa se reúnen los clientes, el dueño del producto y los miembros del equipo para decidir sobre los objetivos y funcionalidad del nuevo sprint. La segunda etapa de la reunión se realiza entre el Scrum Master y el equipo de trabajo y se concentra en cómo el incremento del producto será implementado durante el proceso. o   Sprint    – es una lista de requerimientos seleccionados para ser implementados en la próxima iteración. Los requerimientos son seleccionados por el equipo de trabajo, en conjunto con el Scrum Master y el propietario del producto en la reunión de planeamiento del sprint. Cuando todos los ítems del sprint se completan, se entrega una nueva iteración del sistema. o    Reuniones Diarias   – son dirigidas por el Scrum Master. Se organizan básicamente para mantener una revisión constante del avance del proyecto. Los integrantes responden a tres preguntas: 1) ¿Qué se ha logrado completar desde la última reunión?, 2) ¿Qué obstáculos o problemas se han detectado ?, y 3) ¿Qué funciones del backlog planea completar para la próxima reunión? o    Revisión del Sprint - el equipo de trabajo y el Scrum Master presentan los resultados del sprint al cliente. o    Retrospectiva del Sprint   – s e realiza al finalizar un product backlog y la revisión del sprint. El equipo de trabajo revisa el cumplimiento de los objetivos marcados al inicio del sprint. Se analizarán y se aplicarán los ajustes y cambios necesarios cuando corresponda, se destacarán los aspectos positivos y se tratará de cambiar aquellos aspectos negativos, para no repetirlos en el siguiente sprint. 3.2 eXtreme Programing (XP) XP, formulada por Kent Beck, se diferencia del resto de las metodologías por su énfasis en la adaptabilidad. La metodología está diseñada para ofrecer el software que el usuario necesita, en el momento en que lo necesite. El éxito de la metodología se basa en potenciar las relaciones interpersonales, promoviendo el trabajo en equipo, el aprendizaje de los desarrolladores, y un ambiente de trabajo cordial. Los cinco principios básicos de XP incluyen: 1) Simplicidad   – simplificar el diseño para agilizar el desarrollo y facilitar el mantenimiento mediante la refactorización del código; 2) Comunicación  – fomenta la comunicación: escrita – como código autodocumentado y pruebas unitarias, recomendando documentar el objetivo de clases y la funcionalidad de métodos; y oral - entre programadores y con el cliente, recomendando que ambas sean constantes y fluidas; 3)  Retro-alimentación  – promueve la retro-alimentación constante del cliente a través de ciclos de entrega cortos y demostraciones de la funcionalidad entregada; 4) Coraje  – para mantener la simplicidad permitiendo diferir decisiones de diseño, para comunicarse con los demás aún cuando esto permita exponer la propia falta de conocimiento y para recibir la retro-alimentación durante el
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x