Metodologias Agiless, Guías, Proyectos, Investigaciones de Ingeniería del Software

¡Descarga Metodologias Agiless y más Guías, Proyectos, Investigaciones en PDF de Ingeniería del Software solo en Docsity! 30 Revisión de metodologías ágiles para el desarrollo de software Revisión de metodologías ágiles para el desarrollo de software A review of agile methodologies for software development Andrés Navarro Cadavid1, Juan Daniel Fernández Martínez2, Jonathan Morales Vélez3 1Doctor Ingeniero en Telecomunicaciones, Grupo de investigación i2T, Universidad Icesi Email: anavarro@icesi.edu.co 2Ingeniero de Sistemas e Ingeniero Telemático, Grupo de investigación i2T, Universidad Icesi 3Ingeniero de Sistemas, Grupo de investigación i2T, Universidad Icesi Recibido 04/06/13, Aceptado 20/09/2013 RESUMEN En los años noventa surgieron metodologías de desarrollo de software ligeras –luego llamadas ágiles– dirigidas a reducir la probabilidad de fracaso por subestimación de costos, tiempos y funcionalidades en los proyectos de de- sarrollo de software. Se gestaron como alternativa a las metodologías tradicionales, específicamente para reducir la carga burocrática propia ellas, en proyectos de pequeña y mediana escala. A diferencia de las tradicionales, las metodologías ágiles son adaptativas –no predictivas–, y están orientadas a las personas –no a los procesos–. Este documento hace una revisión de publicaciones sobre las metodologías ágiles, sus principios y fundamentos; esta- blece criterios para definir la relevancia de las metodologías ágiles; define y explica con detalle las más relevantes (i.e., Scrum y XP); y presenta las características de otras cuatro destacadas (i.e., DSDM, Crystal, ASD y FDD). Palabras clave: Scrum, XP, Método de desarrollo de sistemas dinámicos, Crystal, Desarrollo adaptativo de soft- ware, Desarrollo orientado a funcionalidades, Metodologías ágiles. ABSTRACT In the nineties appeared lightweight software development methodologies – then called agile - that aimed to reduce the probability of failure due to underestimation of cost, time and functionality in software development projects. Agile methodologies were developed as an alternative to traditional methodologies specifically to reduce the bureaucratic burden in projects of small and medium scale. Unlike traditional methodologies, agile methodologies are adaptive and oriented to people. This document describes the agile methodologies, its principles and fundamentals, establishes a criteria for defining the relevance of the agile methodologies, defines and explains in detail the most relevant (i.e., Scrum and XP) and presents other prominent ones(i.e., DSDM, Crystal, ASD and FDD). Keywords: Scrum, XP, Dynamic system development method, Crystal, Adaptative software development, Feature-Driven Development, Agile methodologies. 1. INTRODUCCIÓN En la década de los noventa surgieron metodologías de desarrollo de software ligeras, más adelante nombradas como metodologías ágiles, que buscaban reducir la pro- babilidad de fracaso por subestimación de costos, tiem- pos y funcionalidades en los proyectos de desarrollo de software. Estas metodologías nacieron como reacción a las metodologías existentes con el propósito de disminuir la burocracia que implica la aplicación de las metodologías tradicionales en los proyectos de pequeña y mediana es- cala. Las metodologías tradicionales buscan imponer discipli- na al proceso de desarrollo de software y de esa forma volverlo predecible y eficiente. Para conseguirlo se sopor- tan en un proceso detallado con énfasis en planeación [1] propio de otras ingenierías. El principal problema de este enfoque es que hay muchas actividades que hacer para se- guir la metodología y esto retrasa la etapa de desarrollo. Las metodologías ágiles tienen dos diferencias fundamen- tales con las metodologías tradicionales; la primera es que los métodos ágiles son adaptativos –no predictivos-. La se- gunda diferencia es que las metodologías ágiles son orien- tadas a las personas –no orientadas a los procesos- [1]. 31 Prospect. Vol. 11, No. 2, Julio - Diciembre de 2013, págs. 30-39 Las metodologías ágiles son adaptativas. Este hecho es de gran importancia ya que contrasta con la predictibilidad buscada por las metodologías tradicionales. Con el enfo- que de las metodologías ágiles los cambios son eventos esperados que generan valor para el cliente [2]. Este artículo está motivado por la necesidad de encontrar una metodología que se adapte al proceso de desarrollo de sistemas de radio software (SDR) empleando plataformas (hardware) y software abierto, lo que llevó a una revisión de la literatura sobre metodologías ágiles y su respectiva comparación para decidir la más adecuada a este tipo de proyectos. El resto del documento está organizado de la siguiente forma: en la sección 2 se presenta una descripción de las metodologías ágiles, cuáles son sus principios y funda- mentos. En la sección 3 se describen una serie de criterios para definir la relevancia de las metodologías ágiles y se muestran las más relevantes. La sección 4 explica en deta- lle las metodologías seleccionadas como más relevantes y hace una breve descripción de otras metodologías ágiles destacadas. En la sección 5 se muestran las conclusiones. 2. METODOLOGÍAS ÁGILES Hablar de metodologías agiles implica hacer referencia a las metodologías de desarrollo de software tradicionales ya que las primeras surgieron como una reacción a las se- gundas; sus características principales son antagónicas y su uso ideal aplica en contextos diferentes. 2.1 Metodologías tradicionales Las metodologías tradicionales de desarrollo de software son orientadas por planeación. Inician el desarrollo de un proyecto con un riguroso proceso de elicitación de reque- rimientos, previo a etapas de análisis y diseño. Con esto tratan de asegurar resultados con alta calidad circunscri- tos a un calendario. En las metodologías tradicionales se concibe un solo pro- yecto, de grandes dimensiones y estructura definida; se sigue un proceso secuencial en una sola dirección y sin marcha atrás; el proceso es rígido y no cambia; los requeri- mientos son acordados de una vez y para todo el proyecto, demandando grandes plazos de planeación previa y poca comunicación con el cliente una vez ha terminado ésta [3]. 2.2 Metodologías Ágiles Las metodologías ágiles son flexibles, pueden ser modifi- cadas para que se ajusten a la realidad de cada equipo y proyecto. Los proyectos ágiles se subdividen en proyectos más pe- queños mediante una lista ordenada de características. Cada proyecto es tratado de manera independiente y desarrolla un subconjunto de características durante un periodo de tiempo corto, de entre dos y seis semanas. La comunicación con el cliente es constante al punto de re- querir un representante de él durante el desarrollo. Los proyectos son altamente colaborativos y se adaptan mejor a los cambios; de hecho, el cambio en los requerimientos es una característica esperada y deseada, al igual que las entregas constantes al cliente y la retroalimentación por parte de él. Tanto el producto como el proceso son mejora- dos frecuentemente [4]. 2.3 Comparación entre metodologías La tabla 1 muestra aspectos relevantes de las metodolo- gías de desarrollo tradicional contrastándolas con los as- pectos relevantes de las metodologías de desarrollo ágil. Tabla 1. Metodologías tradiciones vs metodologías Ágiles Table 1. Traditional methodologies vs Agile methodologies Metodologías tradicionales Metodologías ágiles Predictivos Adaptativos Orientados a procesos Orientados a personas Proceso rígido Proceso flexible Se concibe como un proyecto Un proyecto es subdividido en varios proyectos más pequeños Poca comunicación con el cliente Comunicación constante con el cliente Entrega de software al finalizar el desarrollo Entregas constantes de software Documentación extensa Poca documentación 2.4 Manifiesto por el desarrollo Ágil Las metodologías ágiles son flexibles, sus proyectos son subdivididos en proyectos más pequeños, incluyen co- municación constante con el cliente, son altamente cola- borativos y se adaptan mejor a los cambios. De hecho, el cambio en los requerimientos es una característica espe- rada al igual que las entregas constantes al cliente y la re- troalimentación por parte de él. Tanto el producto como el proceso son mejorados frecuentemente [4]. En 2001 se crea el Manifiesto por el desarrollo ágil de software, documento en el que se acuerdan cuatro principios básicos para el desarrollo de software, que establece prioridades y marca diferencias de fondo frente a los sistemas tradi- cionales: individuos e interacciones, por encima de pro- cesos y herramientas; software funcionando, por encima 34 Revisión de metodologías ágiles para el desarrollo de software La Retrospectiva del Sprint es una reunión de tres horas del equipo Scrum en la que se analiza cómo fue la comunica- ción, el proceso y las herramientas; qué estuvo bien, qué no, y se crea un plan de mejoras para el siguiente Sprint. El tiempo, tal como en los casos anteriores, se debe ajustar proporcionalmente en el caso de proyectos de duración menor a un mes. Existen también Artefactos de Scrum. Estos son subproduc- tos de las actividades del marco de trabajo que le brindan dirección y transparencia al equipo [28]. Los artefactos de Scrum son: Product Backlog, Sprint Backlog, Monitoreo de Progreso e Incremento. El Product Backlog es una lista −ordenada por valor, riesgo, prioridad y necesidad− de los requerimientos que el due- ño del producto define, actualiza y ordena. La lista tiene como característica particular que nunca está terminada, pues evoluciona durante el desarrollo del proyecto. El Sprint Backlog es un subconjunto de ítems del Product Backlog y el plan para realizar en el Incremento del pro- ducto. Debido a que el Product backlog está organizado por prioridad, el Sprint backlog es construido con los re- querimientos más prioritarios del Product backlog y con aquellos que quedaron por resolver en el Sprint anterior. Una vez construido, el Sprint backlog debe ser aceptado por el equipo de desarrollo, pertenece a éste y solo puede ser modificado por él. Requerimientos adicionales deben ser incluidos en el Product backlog y desarrollados en el siguiente Sprint, si su prioridad así lo indica. El Monitoreo de Progreso consiste en la suma del trabajo que falta por realizar en el Sprint. Tiene como característica que se puede dar en cualquier momento, lo que le permite al dueño del producto evaluar el progreso del desarrollo. Para que esto sea posible, los integrantes del equipo ac- tualizan constantemente el estado de los requerimientos que tienen asignados indicando cuánto consideran que les falta por terminar. El Incremento es la suma de todos los ítems terminados en el Sprint backlog. Si hay ítems incompletos deben ser devueltos al Product backlog con una prioridad alta para que sean incluidos en el siguiente Sprint. Se considera que un ítem está terminado si es funcional. La suma de ítems terminados es el producto a entregar. El ciclo de vida de este marco de trabajo está compuesto de cuatro fases: planeación, puesta en escena, desarrollo y en- trega [29]. En la planeación se establece la visión, se fijan las expectativas y se asegura el financiamiento. En la puesta en escena se identifican más requerimientos y se priorizan para la primera iteración. En la implementación se desarrolla el sistema, y en la entrega se hace el despliegue operativo. 4.2 Extreme Programming [XP] XP es la metodología ágil más conocida [30, 31]. Fue desa- rrollada por Kent Beck buscando guiar equipos de desa- rrollo de software pequeños o medianos, entre dos y diez desarrolladores, en ambientes de requerimientos impre- cisos o cambiantes [32]. XP tiene como base cinco valores: Simplicidad, Comunicación, Retroalimentación, Respeto y Coraje [33]. Estos valores, a su vez, son la base para la definición de sus principios. De ellos, los fundamentales son: la retroalimen- tación rápida, asumir simplicidad, el cambio incremental, la aceptación del cambio y el trabajo de calidad [32]. Las prácticas de esta metodología se derivan de sus va- lores y principios y están enfocadas en darle solución a las actividades básicas de un proceso de desarrollo, esto es: escribir código, realizar pruebas, escuchar (planear) y diseñar [32, 8]. Las prácticas de XP incluyen: planning game, pequeñas en- tregas, diseño simple, programación en pareja, pruebas, refactoring, integración continua, propiedad común del código, paso sostenible, cliente en sitio, metáfora y están- dares de código. Planning Game define el alcance y la fecha de cumplimien- to de una entrega funcional completa −es decir, la fecha de entrega de un release que pueda ser puesto en funciona- miento [32]− y divide las responsabilidades entre el cliente y los desarrolladores. El cliente define, utilizando Historias de Usuario, una versión simplificada de los tradicionales Casos de Uso, los requerimientos de manera general, y pre- cisa su importancia; Con base en ellas, los desarrolladores estiman el costo de implementarlas y se definen las carac- terísticas de una entrega y el número de iteraciones que se necesitarán para terminarla. Para cada iteración el cliente define cuáles de las historias de usuario que componen la entrega funcional desea que se desarrollen. Se pueden crear o modificar historias de usuario en cualquier mo- mento excepto cuando forman parte de una iteración en curso [21]. Entregas Pequeñas se refiere al uso de ciclos cortos de desa- rrollo (iteraciones) que le muestran software terminado al cliente y obtienen retroalimentación de él. La definición de terminado está relacionada con la pruebas de aceptación. Diseño Simple indica que el sistema debe ser tan simple como sea posible, en un momento determinado, lo cual implica que los desarrolladores deben preocuparse úni- camente por las historias de usuario planeadas para la iteración actual, sin importar cuanto pueden cambiar por funciones futuras [21, 32]. 35 Prospect. Vol. 11, No. 2, Julio - Diciembre de 2013, págs. 30-39 Programación en pareja indica que todo el código debe ser desarrollado por dos programadores. Las parejas deben cambiar con cierta frecuencia para que el conocimiento de todo el sistema quede en todo el equipo, una práctica que fortalece los principios de diseño simple, calidad y propie- dad colectiva del código [34]. Las Pruebas son la guía del desarrollo del producto ya que los detalles de las historias de usuario (i.e., requerimientos específicos) se obtienen en el desarrollo de la prueba de aceptación. Las pruebas son lo primero que se desarrolla; con base en ellas, se desarrolla el código que las satisfaga. A este concepto se le denomina Desarrollo orientado a las pruebas [21]. Refactoring consiste en realizar cambios que mejoren la es- tructura del sistema sin afectar su funcionamiento. Para garantizar la no afectación, después de cada cambio se corre la prueba unitaria, con el fin de corroborar sus be- neficios. Esta práctica ayuda a mantener el código simple. Integración continua, establece que cada tarea que se com- pleta se integra al sistema, un proceso que puede darse, incluso, varias veces al día [21]. Con cada tarea que se in- tegra al sistema se corren las pruebas unitarias, las cuales validan si lo que ha sido agregado no perjudica las fun- cionalidades existentes. En ocasiones las pruebas unitarias fallan y es responsabilidad del desarrollador –o de la pa- reja que integró el código– arreglarlo. Es común encontrar una regla en los proyectos XP que evita que un desarrolla- dor o pareja se enfoque en otra cosa distinta a arreglar los errores que surgieron de la integración de su código con el del sistema. Esta regla va acompañada de otra que evita que otras partes de código sean integradas en el sistema mientras no hayan superado exitosamente las pruebas. Esto pone un poco más de presión en aquellos desarro- lladores cuyo código fue incapaz de superar las pruebas. Propiedad común del código implica que no hay una persona propietaria del código que se está desarrollando o de una porción del mismo, por lo que cualquier desarrollador que esté participando en una iteración puede hacer cambios en el código, siempre que le agregue valor al sistema. Paso sostenible hace referencia al ritmo de trabajo del equi- po. Indica que debe ser adecuado para que sea factible ter- minar la iteración o la entrega sin trabajar horas extras. La metodología establece además que nunca se debe trabajar horas extras dos semanas consecutivas [32]. Cliente en sitio se refiere a la necesidad de incluir un re- presentante del cliente trabajando a tiempo completo con el equipo de desarrollo. Su función es resolver oportu- namente dudas en la implementación de las historias de usuario. Metáfora establece que todos los implicados en el proyec- to deben tener la misma visión del sistema. Para lograrlo deben hacer abstracciones que establezcan un lenguaje co- mún entre el cliente y los desarrolladores. La metáfora es la guía global del desarrollo [32]. Estándares de código son las reglas que definen como se va a escribir la aplicación. La metodología establece que estos estándares deben estar definidos de tal forma que el códi- go en si mismo sirva como un documento [35]. Este tema es de altísima relevancia porque tanto la programación en pareja, como la propiedad común del código, son imposi- bles sin estos estándares [32]. El ciclo de vida de esta metodología, por su parte, está compuesto por Exploración, Planeación, Iteraciones hacia la primera entrega, Productionizing y Mantenimiento [29, 32]. En la fase de Exploración se hace una estimación con base en las historias de usuario requeridas para la primera en- trega; en la de Planeación, el cliente y los programadores definen las historias de usuario que se van a implementar y sus fechas; Iteraciones hacia la Primera Entrega, por su par- te, se transforma en el calendario acordado con el cliente, expresado en iteraciones, donde cada una de ellas repre- senta historias de usuario implementadas y probadas; en Productionizing se afina el funcionamiento del programa y se despliega; y en Mantenimiento se continúan realizando mejoras y arreglos, e implementando nuevas funcionali- dades. En 2004 se publicó una versión revisada de XP [36] en la que se modifican los principios y las prácticas. Los nuevos principios hacen más directa la asociación de los valores con las prácticas. Las nuevas prácticas se subdividen en dos categorías: primarias, las de mayor impacto y por lo tanto las primeras que deberían ser implementadas; y co- ralarias, las más difíciles de implementar y por ello las que deberían adoptarse después de haber adoptado las prima- rias. Esta versión, sin embargo, no ha tenido gran acogida y la mayoría de los autores siguen tomando como referen- cia la versión original. 4.3 Otras metodologías Como se mencionó al inicio de la sección II, las metodo- logías ágiles no están limitadas a Scrum y XP, sino que incluyen varias más. A continuación se presenta una breve descripción de las más relevantes. 4.3.1 Crystal La familia de metodologías Crystal se basa en los concep- tos de Rational Unified Process [RUP] y está compuesta por 36 Revisión de metodologías ágiles para el desarrollo de software Crystal Clear, Crystal Yellow, Crystal Orange y Crystal Red [37]; el nivel de opacidad del color en el nombre in- dica un mayor número de personas implicadas en el de- sarrollo, un mayor tamaño del proyecto y, por lo tanto, la necesidad de mayor control en el proceso [7, 38]. La filosofía de Crystal define el desarrollo como un juego cooperativo de invención y comunicación cuya meta prin- cipal es entregar software útil, que funcione, y su objetivo secundario, preparar el próximo juego [38]. Los valores compartidos por los miembros de la familia Crystal están centrados en las personas y en la comunica- ción. Sus principios indican que: el equipo puede reducir trabajo intermedio en la medida que produce código con mayor frecuencia y utiliza mejores canales de comunica- ción entre las personas; los proyectos evolucionan distinto con el tiempo por lo que las convenciones que el equipo adopta tienen que adecuarse y evolucionar; los cambios en el cuello de botella del sistema determinan el uso de tra- bajo repetido; y el afinamiento se realiza sobre la marcha. Existen dos reglas que aplican para toda la familia Crystal. La primera indica que los ciclos donde se crean los incre- mentos no deben exceder cuatro meses; la segunda, que es necesario realizar un taller de reflexión después de cada entrega para afinar la metodología. 4.3.2 Método de desarrollo de sistemas dinámicos (Dynamic Systems Development Method - DSDM) DSDM es un marco de trabajo creado para entregar la so- lución correcta en el momento correcto. Utiliza un ciclo de vida iterativo, fragmenta el proyecto en periodos cor- tos de tiempo y define entregables para cada uno de estos periodos. Tiene roles claramente definidos y especifica su trabajo dentro de periodos de tiempo [39]. El Consorcio DSDM es el responsable del mantenimien- to de esta metodología. Su versión actual es DSDM Atern. Los principios de DSDM son: la necesidad del negocio como eje central; las entregas a tiempo; la colaboración; nunca comprometer la calidad; construir de modo incre- mental sobre una base sólida; el desarrollo iterativo; la co- municación clara y continua; y la demostración de control [39]. 4.3.3 Desarrollo adaptativo de software (Adaptative Software Development - ASD) ASD tiene como fundamento la teoría de sistemas adapta- tivos complejos. Por ello, interpreta los proyectos de soft- ware como sistemas adaptativos complejos compuestos por agentes −los interesados−, entornos −organizacional, tecnológico− y salidas −el producto desarrollado−. El ciclo de vida de ASD está orientado al cambio y se com- pone de las fases: especulación, colaboración y aprendiza- je [40, 41]. Estas fases se caracterizan por estar enfocadas en la misión, estar basadas en características, ser iterativas, tener marcos de tiempo especificados, ser orientadas por los riesgos y ser tolerantes a los cambios. 4.3.4 Desarrollo orientado a funcionalidades (Feature-Driven Development - FDD) FDD tiene como rasgo característico la planeación y el di- seño por adelantado. En consecuencia, el modelo de ob- jetos, la lista de características y la planeación se hacen al inicio del proyecto. Las iteraciones son incrementos con características identificadas [42]. Las prácticas que FDD pregona son: el modelado de objetos de dominio (domain object modeling), el desarrollo por carac- terísticas, Class (code) ownership, los equipos de característi- cas o Feature Teams, las inspecciones, la construcción regular de planificación (Regular Build Schedule), la gestión de confi- guración y los reportes y visibilidad de los resultados [43]. Su ciclo de vida está compuesto por cinco etapas: el desa- rrollo de un modelo general, la construcción de la lista de características, la planeación por característica, el diseño por característica y la construcción por característica [44]. FDD se enfoca en las fases de diseño –diseño por caracte- rística– y desarrollo –construcción por característica– sien- do estas las etapas del proceso que se iteran [45]. 5. CONCLUSIONES Las metodologías ágiles funcionan bien dentro de un con- texto específico caracterizado por equipos pequeños de desarrollo, ubicados en el mismo sitio, con clientes que pueden tomar decisiones acerca de los requerimientos y su evolución, con requerimientos que cambian con fre- cuencia (semanal, mensual), con alcance del proyecto o presupuesto variable, con pocas restricciones legales y con pocas restricciones en el proceso de desarrollo [16]. Por fuera de este ambiente, es común que se presenten incon- venientes derivados de la falta de participación del cliente, los contratos con precio fijo, los proyectos con arquitectura o diseño intensivo o con documentación intensiva, la tasa de cambios lenta y los equipos distribuidos [16]. El papel del cliente es más notorio en el proceso de desa- rrollo de las metodologías ágiles; uno de los principios del Manifiesto dice que los responsables de negocio y los de- sarrolladores trabajan juntos de manera cotidiana durante todo el proyecto [6]. Esta condición no es fácil de satisfa- cer. Los clientes pueden estar separados geográficamente o puede ser muy costoso para ellos mantener un represen-