LICENCIATURA EN SISTEMAS Y COMPUTACIÓN

Transcripción

1 FACULTAD SAN FRANCISCO UNIVERSIDAD CATÓLICA ARGENTINA LICENCIATURA EN SISTEMAS Y COMPUTACIÓN METODOLOGÍAS ÁGILES CENTRADAS EN LA AUTOMATIZACIÓN DE PRUEBAS ALUMNO DIRECTORA DE TESINA Prof. a Cargo Prof. Adjunto FRANK MARTHY ESCOBAR ARTEAGA Ing. María Antonella Manna Mg. Jorge Mariotti Mg. Alejandro Vázquez Presentada ante la Secretaría Académica de la Facultad San Francisco U.C.A. como requisito parcial para optar al título de LICENCIADO EN SISTEMAS Y COMPUTACIÓN Mayo 29 de 2012

2 TÍTULO DE LA TESINA METODOLOGÍAS ÁGILES CENTRADAS EN LA AUTOMATIZACIÓN DE PRUEBAS Tesina presentada por: Alumno: ESCOBAR ARTEAGA, FRANK MARTHY Aprobada en contenido por: Aprobada en estilo por: Nombre del profesor, miembro del tribunal Nombre del profesor, miembro del tribunal Nombre del Director de Carrera ii

3 AGRADECIMIENTOS A mis excelentes profesores: Gustavo Sabio, Diego Garay, Julieta Suárez, Carlos Troglia, Rolando Conde, Italo Ortiz, Jorge Hidalgo, Jorge Cadoni, Alejandro Vázquez y Jorge Mariotti quienes me transmitieron a través de sus enseñanzas, la voluntad para seguir creciendo y valorarme como profesional. A mis compañeros de trabajo: Jonathan Ortiz, Antonella Manna y Mariano Giardina quienes a través de su experiencia me ayudaron a desarrollar mis cualidades y habilidades en el área de calidad. A mi madre Ana Cecilia Arteaga, quien inspiró en mí, ser una persona constante y nunca darme por vencido a pesar de las adversidades. A mi hermana Annie Escobar y a mi novia Rita Loloy quienes me motivaron y alentaron en cada momento. A mis amigos y compañeros de facultad Diego Arena y Armando Rosario con quienes aprendí y compartí grandes momentos durante el cursado de la carrera. iii

4 RESUMEN TÍTULO DE LA TESINA METODOLOGÍAS ÁGILES CENTRADAS EN LA AUTOMATIZACIÓN DE PRUEBAS FECHA DE LA DEFENSA: 29 de Mayo del 2012 NOMBRE DEL ESTUDIANTE: ESCOBAR ARTEAGA, FRANK MARTHY LICENCIATURA EN SISTEMAS Y COMPUTACIÓN FACULTAD SAN FRANCISCO U.C.A. Dirigida por la Ing. María Antonella Manna. Existen diversos problemas por los que actualmente atraviesan los proyectos de desarrollo de software que realizan una transición hacia las metodologías ágiles. Los líderes y otros miembros que forman parte del proyecto tienden a darle poca importancia a la calidad del software ya que esta no resulta visible a los ojos del cliente, preocupándose solo por entregar la mayor cantidad de funcionalidad posible sin importarle su buen funcionamiento. Esto implica arduas horas de trabajo para todo el equipo ya que generalmente no se llega con lo pactado cuando se está cerca al plazo de entrega, lo que genera tanto la insatisfacción por parte del equipo de desarrollo por haber realizado esfuerzos extra, como la del cliente por no obtener una calidad considerablemente aceptable. Con el tiempo, estas malas prácticas se han ido propagando, opacando las funciones y responsabilidades de los profesionales en el área de calidad. Lo que a su vez, ha logrado impactar en las concepciones de los miembros del equipo, promoviendo la idea de que los profesionales del área de calidad no brindan valor agregado al negocio. Es aquí donde interviene la automatización de pruebas generando un fuerte impacto, ya que a través de esta actividad podemos obtener grandes beneficios como: la reducción de tiempo durante la ejecución de pruebas, disminución de costos, retroalimentación continua, refactorización de código, documentación de las funcionalidades del sistema de forma ágil, cobertura de pruebas, etc. Esta actividad requiere de mayor formación y capacitación técnica por parte de los miembros del equipo de control de calidad, como así también de mayor participación y comunicación con el equipo de programadores, que da como resultado todo un equipo trabajando en conjunto por la calidad del software. Además de destacar los beneficios de la automatización de pruebas, de este seminario se obtienen propuestas de estrategias de automatización, según el tipo de software que se esté desarrollando. Además se incluyen flujos de trabajo que involucran a todos los miembros del equipo; y por último se expone el proceso ideal de automatización de pruebas junto a sus métricas necesarias para la toma de decisiones en el ámbito gerencial, resaltando el rol fundamental del profesional en el área de calidad y el uso de las herramientas de prueba. iv

5 ÍNDICE DE CONTENIDO Contenido: Agradecimientos...iii Resumen... iv Índice de Tablas... vii Índice de Ilustraciones o figuras...viii Introducción... 1 Capítulo 1. Metodologías ágiles centradas en la automatización de pruebas ) Presentación del Problema ) Objetivos ) Alcance ) Metas... 3 Capítulo 2. Metodologías Tradicionales ) Historia ) Modelo en cascada ) Principales roles del modelo en cascada ) Ventajas y desventajas... 7 Capítulo 3. Metodologías Ágiles ) Historia ) Principios ágiles ) Scrum ) Roles en Scrum ) Ventajas y desventajas Capítulo 4. Transición hacia las metodologías ágiles ) Cultura Organizacional ) Problemas que surgen de la aplicación de las metodologías ágiles v

6 Capítulo 5. Automatización de pruebas ) Conceptos erróneos sobre la automatización de pruebas ) Tipos de sistemas ) Estrategias de prueba ) Estrategias de automatización de pruebas ) Metodologías ágiles centradas en la automatización de pruebas ) Impedimentos para llevar a cabo la automatización de pruebas ) Automatización de pruebas aplicadas en las metodologías ágiles ) Selección de casos de prueba a automatizar ) Selección de herramientas de automatización ) Integración Continua ) Métricas Capítulo 6. Profesional del área de calidad ) Aseguramiento y Control de la calidad ) Conocimientos y habilidades técnicas ) Cualidades humanas, grado de influencia y participación Conclusión Glosario Anexo: Curriculum Vitae Bibliografía vi

7 ÍNDICE DE TABLAS Tabla 1: Ejemplo ROI de Esfuerzo Tabla 2: Cuadro comparativo de métricas de tres proyectos diferentes vii

8 ÍNDICE DE ILUSTRACIONES O FIGURAS Fig. 1: Modelo en Cascada... 5 Fig. 2: Roles del Modelo en Cascada... 7 Fig. 3: Reuniones de Scrum Fig. 4: Historia de Usuario con criterios de aceptación y dividida en tareas Fig. 5: Actividades del dueño del producto Fig. 6: Actividades del equipo de Scrum Fig. 7: Scrum diario Fig. 8: Demostración de Sprint Fig. 9: Retrospectiva de Sprint Fig. 10: Sprint Release Fig. 11: Equipo del cliente y desarrollo trabajando como un solo equipo Fig. 12: Escasa o nula participación del cliente Fig. 13: Problemas que surgen de la aplicación de las metodologías ágiles Fig. 14: Software que no aplica automatización de pruebas Fig. 15: Software que aplica automatización de pruebas inadecuadamente Fig. 16: Arquetipo de una aplicación de cliente enriquecida Fig. 17: Arquetipo de una aplicación de Internet enriquecida Fig. 18: Arquetipo de una aplicación de servicios Fig. 19: Arquetipo de una aplicación web Fig. 20: Arquetipo de una aplicación móvil Fig. 21: Cuadrantes de las Pruebas Ágiles Fig. 22: Diagrama de flujo de TDD Fig. 23: Creando prueba unitaria Fig. 24: Refactorizando código para que la prueba sea exitosa Fig. 25: Historia de usuario junto al prototipo de pantalla Fig. 26: Caso de prueba verificado por el cliente (UAT) Fig. 27: Gráfica de tiempo de respuesta y nº de hilos activos de un sistema Fig. 28: Pruebas de bajo nivel aplicadas en la capa de negocio Fig. 29: Pruebas de nivel intermedio aplicadas en la capa de negocio y/o servicios Fig. 30: Pruebas de nivel superior aplicadas en la capa de presentación Fig. 31: Metodologías ágiles centradas en la automatización de pruebas Fig. 32: Impedimentos para llevar a cabo la automatización de pruebas Fig. 33: Desarrollo de software sin automatización de pruebas Fig. 34: Desarrollo de software sin criterios de automatización de pruebas Fig. 35: Desarrollo de software con criterios de automatización de pruebas Fig. 36: Diagrama de flujo de ATDD Fig. 37: Integración Continua Fig. 38: Ecuación de porcentaje de pruebas automatizables Fig. 39: Ecuación de porcentaje de progreso de automatización Fig. 40: Ecuación de porcentaje de cobertura de pruebas automatizadas Fig. 41: Ecuación de eficiencia de eliminación de errores y/o defectos Fig. 42: Representación de un miembro del equipo frustrado y exitoso viii

9 INTRODUCCIÓN Las primeras metodologías tradicionales del desarrollo del software presentaban conceptos muy estructurados, burocráticos, lentos y estrictos como es el caso del Modelo en Cascada. En los años 90 las metodologías ágiles aparecían con un proceso de desarrollo formado por las características de los modelos anteriores, basándose en la experiencia y en un conjunto de principios y valores que tenían como objetivo último la satisfacción del cliente. En los primeros años del nuevo milenio, estudios realizados revelaron que se generaban altos costos en la búsqueda por alcanzar una mejor calidad en los softwares, ya que más del 80% del costo de desarrollo se ocupaba detectando y corrigiendo errores y defectos. Esto sumado, a que existía la necesidad de lograr una mejor calidad con menos recursos disponibles; y que cada vez se incrementaba la utilización de sistemas tercerizados, los cuales no brindaban seguridad, integridad y confidencialidad; y el advenimiento de nuevos estándares de calidad, dio como origen a la automatización de pruebas. Por lo general, si bien la automatización de pruebas ha sido adoptada por una cantidad considerable de proyectos de software, no ha sido implementada de forma adecuada. Es por ello que este seminario intenta generar o recuperar la confianza en la automatización de pruebas, que a través de sus beneficios y la participación de las personas que hacen todo esto posible, dan como resultado una calidad de software progresivamente mejorable. 1

10 CAPÍTULO I: METODOLOGÍAS ÁGILES CENTRADAS EN LA AUTOMATIZACIÓN DE PRUEBAS 1.1) Presentación del problema: Los proyectos de desarrollo de software que intentan realizar una transición entre el uso de una metodología tradicional hacia una metodología ágil, que buscan satisfacer las necesidades y expectativas del cliente, tienden a fracasar debido a que los conceptos y prácticas de las metodologías anteriores están fuertemente arraigados y los nuevos conceptos, que son fundamentales para el éxito del proyecto, no son muy bien aceptados y si son aceptados son mal implementados, impactando de esta forma negativamente en la calidad de los software y por ende provocando la pérdida de confianza en las actividades de calidad tanto en el equipo de desarrollo como en el cliente. 1.2) Objetivos: o Demostrar que la automatización de pruebas es uno de los factores claves para alcanzar el éxito de todo proyecto de desarrollo de software que aplique metodologías ágiles. o Destacar la importancia del papel que desempeña un profesional del área de calidad de software tanto en cualidades humanas, habilidades técnicas como el grado de influencia y participación durante el proceso, que brindan un valor agregado al negocio, teniendo como resultado productos de calidad y equipos de trabajo con un alto grado de motivación. 1.3) Alcance: Si bien existen diversos problemas que surgen de la transición de las metodologías tradicionales hacia las ágiles, se intentará resolver los problemas con respecto al gerente y al equipo de desarrollo, específicamente los relacionados con la dificultad para medir el progreso del proyecto, escasez de tiempo durante el desarrollo de software y los conceptos erróneos que se tienen sobre los profesionales de control de calidad. A través de la exposición se demostrará los beneficios, estrategias, procesos, flujos de trabajo y métricas de la automatización de pruebas, que se requiere de mayor formación, capacitación técnica, comunicación y participación de parte del profesional de control de calidad para lograr una mejor calidad de software trabajando en equipo. 2

11 1.4) Metas: o Exponer las diferencias que existen entre metodologías tradicionales y ágiles. o Explicar el por qué la automatización de pruebas produce beneficios a mediano y a largo plazo. o Proponer estrategias de automatización de pruebas según el tipo de software. o Sugerir un proceso de automatización de pruebas que mejor se adapte a un proceso en el que se implementen las metodologías ágiles. o Demostrar cómo la automatización de pruebas contribuye a optimizar las pruebas de regresión, realizadas manualmente en las metodologías tradicionales. o Demostrar que las métricas provenientes de la automatización de pruebas son fundamentales para la toma de decisiones en el ámbito gerencial. o Demostrar que se requiere de profesionales del área de calidad con perfiles especializados para llevar a cabo una mejor adaptación en las metodologías ágiles. 3

12 CAPÍTULO II: METODOLOGÍAS TRADICIONALES 2.1) Historia: A partir de los años 70, surgieron diversos modelos que seguían los principios de las metodologías tradicionales. Estas metodologías imponían una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Por lo que ponían énfasis en la planificación total de todo el trabajo a realizar y una vez que estaba todo detallado, comenzaban con el ciclo de desarrollo del producto software. Se centraban especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas, notaciones para el modelado y documentación detallada. Entre ellos podemos citar: o MSF (Microsoft Solution Framework) o Win Win Spiral Model o Iconix o RUP (Rational Unified Procces). Pero el más representativo de todos los modelos en las metodologías tradicionales fue el Modelo en Cascada. Se cree que este modelo fue el que se introdujo primero y ampliamente en la ingeniería de software. En la década del 70 no había conciencia de la división de desarrollo de software en diferentes fases. Los requisitos eran pocos y los programas eran muy pequeños, por lo que no existía la necesidad de llevar a cabo una adecuada organización. Como los programas se hicieron cada vez más grandes y complejos, resultó mucho más costoso para los programadores poder capturar los requisitos del producto, así como también diseñarlos, implementarlos y probarlos. Fue así como surgió la necesidad de una metodología de desarrollo de software. Las diferentes fases de ingeniería de software fueron identificadas y en 1970, Royce propuso lo que actualmente se conoce como el Modelo en Cascada, este fue uno de los primeros modelos de ciclo de vida del desarrollo de software. El modelo describe un orden secuencial en la ejecución de los procesos asociados. El modelo de cascada supone, de manera general, que los requisitos del cliente no cambian radicalmente durante el transcurso de desarrollo del sistema. 2.2) Modelo en cascada: Como se dijo anteriormente el modelo de cascada se estructura en varias fases, especialmente para ayudar a las empresas de desarrollo de software a construir un sistema de forma organizada y alivianando así a todo el proceso. En este modelo se avanza a la etapa siguiente, una vez que la anterior haya sido completada. De esta manera uno se va acercando gradualmente a la etapa final y una vez que se alcanza ese punto, no se puede dar marcha atrás. Las fases son las siguientes: o Captura de Requisitos: es el proceso donde se averigua qué es lo que debería hacer el producto que vamos desarrollar. El sistema tiene que proporcionar valor al negocio para quien lo utiliza y para sus clientes. Esto se logra mediante una 4

13 descripción de los requisitos del sistema para llegar a un acuerdo entre el cliente y los desarrolladores sobre qué debe y qué no debe hacer el sistema. o Análisis: en esta etapa se refinan y estructuran los requisitos capturados, para tener una comprensión más precisa. Además se describen los mismos, para que nos ayuden a mantener y estructurar el sistema entero, incluyendo su arquitectura. o Diseño: en el diseño modelamos el sistema y encontramos su forma, para que soporte todos los requisitos. El propósito, es adquirir una comprensión en profundidad de los aspectos relacionados con los requisitos no funcionales y restricciones relacionadas con: los lenguajes de programación, componentes reutilizables, sistemas operativos, etc. o Implementación: construimos el sistema en términos de componentes, es decir, ficheros código de fuente, scripts, ficheros de código binario, ejecutables y similares. o Pruebas: en esta fase verificamos el resultado de la implementación ejecutando cada construcción, incluyendo tanto construcciones internas como intermedias, así como las versiones finales del sistema a ser entregadas a terceros. o Mantenimiento: es el proceso de optimización del software después de su entrega al usuario final, es decir, la revisión del programa. Así como también la corrección y prevención de los defectos. Fig. 1: Modelo en Cascada. 5

14 2.3) Principales roles del modelo en cascada: Existen distintos roles que se distribuyen a los largo de las fases del modelo en cascada. Entre los principales roles que pueden existir en un proyecto de desarrollo se encuentran los siguientes: Cliente: o Conocer las distintas etapas y roles en la construcción del software. o Definir los objetivos del proyecto. o Definir y expresar los requisitos necesarios para desarrollar el sistema. o Revisar y aprobar los documentos en forma responsable. o Entregar los recursos necesarios para la realización del proyecto. Arquitecto: o Definir las vistas de la arquitectura de una aplicación (conjunto de vistas de alto nivel). o Dar soporte técnico-tecnológico a desarrolladores, clientes y expertos en negocios. o Conceptualizar y experimentar con distintos enfoques arquitectónicos. o Crear documentos de modelos, componentes y especificaciones de interfaces. o Validar la arquitectura de forma de que cumpla con los requisitos. o Garantizar la integridad del modelo de análisis, diseño, implementación y despliegue de manera de generar modelos correctos, consistentes y legibles en su totalidad. Analista de Sistemas: o Analizar y comprender que el estado actual del proceso asegure que el contexto y las implicaciones de los cambios sean comprendidos por el cliente y los miembros del equipo. o Desarrollar un plan de gestión de requisitos y difundir el plan hacia todos los interesados. o Describir y documentar los requisitos manifestados por el cliente. o Trabajar con el cliente para priorizar los requisitos. o Delimitar el sistema, encontrando los usuarios que interactúan con el sistema y asegurándose que los requisitos estén completos y consistentes. Programador/Ing. de Componentes: o Definir y mantener las responsabilidades, atributos, relaciones de uno o varios componentes, asegurándose de que cada componente implementa la funcionalidad correcta. o Definir y mantener las operaciones, métodos, atributos, relaciones y requisitos de implementación del código fuente. o Crear códigos de pruebas para verificar las funcionalidades. o Mantener la integridad de uno o varios subsistemas de implementación. Tester/Ingeniero de Pruebas: o Mantener la integridad del modelo de pruebas, asegurando que el modelo cumple con su propósito. o Planificar las pruebas, definiendo objetivos de prueba apropiados. o Seleccionar y describir los casos de prueba y los procedimientos de prueba correspondientes que se necesitan. o Realizar y evaluar las pruebas de integración y de sistema cuando éstas se ejecuten. o Documentar los defectos en los resultados de las pruebas de integración. 6

15 Diseñador de Interfaz de Usuario: dan forma visual a las interfaces de usuario en base a su experiencia en usabilidad. CAPTURA DE REQUISITOS Cliente Arquitecto Analista de Sistemas Diseñador de IU ANÁLISIS Arquitecto Analista de Sistemas Programador DISEÑO Arquitecto Analista de Sistemas Programador IMPLEMENTACIÓN Arquitecto Programador PRUEBAS Tester Programador MANTENIMIENTO Fig. 2: Roles del Modelo en Cascada. Programador 2.4) Ventajas y desventajas: Ventajas: o Es útil para sistemas en los cuales los requisitos nunca cambian. o Es un modelo sencillo y disciplinado. o Es fácil aprender a utilizarlo y comprender su funcionamiento. o Está dirigido por los tipos de documentos y resultados que deben obtenerse al final de cada etapa. o Es muy usado y, por lo tanto, está ampliamente contrastado. o Ayuda a minimizar los gastos de planificación, pues se realiza sin problemas. Desventajas: o Es poco probable que los proyectos sigan un proceso lineal tal como se definía originalmente el ciclo de vida. o Es difícil que el cliente exponga explícitamente todos los requisitos al principio. o Es necesario que el cliente tenga paciencia, ya que obtendrá el producto al final del ciclo de vida. o Contribuye a que el equipo trabaje individualmente, preocupándose solo por cumplir con sus funciones y responsabilidades, y no por el resultado total del producto, que surge del trabajo en equipo. o Genera poca comunicación entre los miembros de todo el equipo, ya que solo intervienen en sus respectivas fases. 7

16 o Impulsa a que las actividades de control de calidad se realicen en las últimas fases, lo que acumula errores y defectos que pueden ser críticos. o Es complicado regresar a fases anteriores para realizar correcciones. o Es muy probable que el producto final obtenido no refleje todos los requisitos del usuario. 8

17 CAPÍTULO III: METODOLOGÍAS ÁGILES 3.1) Historia: En los primeros años de desarrollo de software, la mayoría de las necesidades de los usuarios eran bastante estables, y los planes de desarrollo a seguir no sufrían grandes cambios. Sin embargo, como el desarrollo de software era más importante y crítico en los proyectos industriales, nuevas dificultades surgieron de acuerdo con el crecimiento de las empresas, las cuales son: o La evolución de los requisitos: los requisitos de los clientes estaban cambiando, debido a las necesidades empresariales en evolución o asuntos legislativos. La mayoría de los clientes, no tenían una visión clara acerca de las especificaciones de sus necesidades durante las primeras fases. Algunos clientes se daban cuenta de cuáles eran sus necesidades reales, sólo cuando utilizaban la aplicación, que no satisfacía sus necesidades. o La participación de los clientes: la falta de participación del cliente durante el desarrollo del software, conducía al proyecto a mayores posibilidades de fracaso. Muchas empresas, por lo general, no promovían la participación de los clientes. o Plazos y presupuestos: las compañías solían ofrecer presupuestos bajos con plazos ajustados, debido a la competencia en los mercados. Lo que resultaba costoso a la hora de llevar a cabo la implementación del sistema, para cumplir con lo pactado con el cliente. o Falta de comunicación: una de las causas de la falta de comprensión de los requisitos, era la falta de comunicación entre los desarrolladores y clientes. Por ejemplo, cada parte utilizaba su propio vocabulario, y esto conducía a la incomprensión de las necesidades del cliente. Debido a esto un equipo de profesionales de TI comenzó a trabajar de forma individual sobre los nuevos enfoques para el desarrollo de software. Los resultados de sus investigaciones fueron un conjunto de nuevas metodologías que tienen muchas características comunes. Cuando se conocieron en 2001, se creó el llamado: Manifiesto Ágil. Fue así como surgieron numerosas metodologías ágiles como: o Scrum o XP (Extreme Programming) o Crystal Clear o DSDM (Dynamic Systems Developmemt Method) o FDD (Feature Driven Development) o ASD (Adaptive Software Development) o XBreed o Extreme Modelin 9

18 3.2) Principios ágiles: Como se explicó en el capítulo anterior, las metodologías ágiles se formaron de acuerdo al manifiesto ágil, el cual expone los siguientes principios: a. Proveer retroalimentación continua: La mayor prioridad es satisfacer al cliente mediante entregas tempranas e iterativas del software. Una de las más importantes contribuciones es ayudar al cliente a especificar los requisitos y las pruebas, luego el equipo logra convertir los requisitos en ejecutables de prueba, que a menudo son guiados por una retroalimentación significativa. Cuando el equipo se encuentra con obstáculos, la retroalimentación es una de las maneras para eliminarlos, ya sea mediante los prototipos de interfaces de usuario presentados al cliente, así como también, a través del estado y la cobertura de las pruebas, o de la estabilidad del sistema. b. Dar valor agregado al cliente: El desarrollo ágil genera valor agregado en pequeñas iteraciones que proveen los requisitos definidos y priorizados por el cliente. El cliente participa en las reuniones de planificación realizadas antes de cada iteración, donde se discuten detalles de los requisitos y de como probarlos. Una inocente pregunta puede incrementar la complejidad del requisito. El equipo de desarrollo debe entregar la mayoría de las funcionalidades críticas en la iteración actual, si se le da importancia a las funcionalidades que no son críticas o a las nuevas funcionalidades, se corre el riesgo de no llegar con la entrega a tiempo, y por lo tanto no se cumplirá con añadirle valor agregado al negocio. c. Conversación cara a cara: Se sabe que los equipos no pueden trabajar bien, si no hay una buena comunicación; más si aún no todos se encuentran geográficamente en el mismo lugar. Se debe visualizar cada requisito desde el punto de vista del cliente, pero además se deben tener en cuenta los aspectos y limitaciones a la hora de implementar esos requisitos. La comunicación no tiene reemplazo, el desarrollo ágil depende de la constante colaboración. d. Tener Coraje: Se necesita coraje para cometer errores y aprender de ellos, se necesita decisión para investigar y aplicar tecnologías jamás utilizadas, se necesita valentía para pedir ayuda, sobre todo si esta persona que va a proporcionar esa ayuda se ve cansada o estresada. Hacer una pregunta o señalar un defecto requiere coraje. Los equipos ágiles son abiertos y en general aceptan nuevas ideas. e. Mantener la simpleza: No tiene ningún sentido construir complicadas estructuras que dificulten la comprensión y utilización. Es preferible acudir a cosas sencillas y simples que, a primera vista, reflejen lo que se quiere expresar. Las metodologías ágiles, apuestan a la 10

19 sencillez, en su máxima expresión. Sencillez en el diseño, en el código, en los procesos, en las pruebas, etc. La sencillez es esencial para que todos puedan entender el código, y se trata de mejorar mediante refactorizaciones continuas. f. Mejora continua: Es tarea de todo el equipo buscar la mejor manera de hacer un trabajo. Todos los miembros del equipo participan en las reuniones retrospectivas donde se evalúa y analiza que es lo que está haciendo bien y qué es lo que se debería agregar o modificar. El equipo está en la continua búsqueda de herramientas, habilidades o prácticas que pueden agregar valor al negocio, y las iteraciones cortas permiten que sea más fácil probar algo nuevo para unas pocas iteraciones y si vale la pena, se podrá adoptar a largo plazo. g. Responder al cambio: La pesadilla de todos los desarrolladores de software, es la continua evolución de las necesidades, debido a la falta de estabilidad que sufre el sistema al aplicar los cambios. Es un asunto complicado, que podría resultar en la pérdida de tiempo si los requisitos se han re priorizado o si han cambiado mucho. Sin embargo se acepta que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. h. Auto - Organizarse: Cuando un equipo se enfrenta a algún problema, es problema de todos, por lo que los miembros de todo el equipo deben discutir el asunto de inmediato y decidir cómo y quién lo resolverá. El equipo tiene la autonomía para organizarse para desarrollar en la mejor forma sus resultados. Para que la auto-organización funcione, un equipo debe tener autonomía, no deben ser molestados y se debe confiar en ellos. La confianza es difícil cuando los requisitos son vagos, y la autogestión es imposible cuando el equipo experimenta continuas interferencias con respecto a las tecnologías, herramientas y prácticas que se utilizan. i. Centrado en las personas: Los miembros del equipo deben sentirse seguros y no tener que preocuparse de ser culpados por los errores o de perder sus puestos de trabajo. Se deben respetar mutuamente y reconocer los logros individuales. Todos en un equipo ágil deben tener oportunidades para crecer y desarrollar sus habilidades. j. Disfrutar de lo que se hace: Un equipo donde todo el mundo colabora, donde todos están involucrados desde principio hasta fin, donde los clientes trabajen juntos con los desarrolladores, donde todo el equipo asume la responsabilidad de calidad; son elementos que encaminan a que el trabajo pueda realizarse con mayor satisfacción. 11

20 3.3) Scrum: De las metodologías ágiles anteriormente nombradas en el capítulo 3, se seleccionó Scrum porque es una de las metodologías predominantemente utilizadas en el desarrollo de software debido a las prácticas y actividades que impulsa. Scrum es un marco de trabajo que consiste en entregar parte de un producto en pequeñas iteraciones que pueden ser entre 2, 4 ó 6 semanas, estas iteraciones son denominadas Sprint. Esta metodología reconoce tres grandes roles: Dueño del Producto, Scrum Master y Equipo de Scrum, quienes participan en un conjunto de reuniones que se realizan en cada Sprint, llamadas: Planificación de Sprint, Scrum Diario, Demostración de Sprint y Retrospectivas de Sprint. a. Planificación de Sprint: Fig. 3: Reuniones de Scrum. El dueño del producto define mediante historias de usuario, un conjunto de requisitos listos para ser propuestos al equipo de Scrum para que lleven a cabo su desarrollo. A este conjunto de requisitos se los denomina Pila del Producto. Fig. 4: Historia de Usuario con criterios de aceptación y dividida en tareas. Esta reunión se realiza al principio del Sprint, en donde el dueño del producto comenta la meta del Sprint y prioriza las historias de usuario de la Pila de Producto para que formen parte de la Pila del Sprint. El propósito de esta reunión, es darle al equipo la suficiente información, para que puedan trabajar sin ninguna interrupción. El equipo 12

21 decide cuántas historias se incluirán en el Sprint de acuerdo al tiempo estimado en base a su experiencia o a estimaciones anteriores. Para realizar una estimación más realista, el dueño del producto define criterios de aceptación para cada historia de usuario, y el equipo de Scrum divide cada historia de usuario en tareas. Fig. 5: Actividades del dueño del producto. Historia de Usuario 008 -CA001 -CA002 -CA003 -T001 -T002 -T003 Historia de Usuario 001 -CA001 -CA002 -CA003 -T001 -T002 -T003 Pila del Sprint Historia de Usuario CA001 - CA002 - CA003 - T001 - T002 - T003 Historia de Usuario CA001 - CA002 - CA003 - T001 - T002 - T003 Historia de Usuario 011 -CA001 -CA002 -CA003 -T001 -T002 -T003 Historia de Usuario 012 -CA001 -CA002 -CA003 -T001 -T002 - T003 Divide en tareas Planificación Pila del Sprint de Sprint 32 hrs. 20 hrs. 11 hrs. Equipo de Scrum Estima Historia de Usuario 008 -CA001 -CA002 -CA003 -T001 -T002 -T003 Historia de Usuario 001 -CA001 -CA002 -CA003 -T001 -T002 -T003 Historia de Usuario 003 -CA001 -CA002 -CA003 - T001 - T002 - T003 Historia de Usuario 009 -CA001 -CA002 -CA003 - T001 - T002 - T003 Historia de Usuario CA001 - CA002 - CA003 - T001 - T002 - T hrs. 6 hrs. 5 hrs. Historia de Usuario CA001 - CA002 - CA003 - T001 - T002 - T003 Fig. 6: Actividades del equipo de Scrum. El equipo puede rechazar o no las historias de usuario que formen parte del Sprint, todo dependerá de la negociación que se genere entre ambos, en donde si al dueño del producto no le agrada que algunas historias queden fuera del Sprint, tendrá que repriorizar las historias de usuario, subdividirlas o reducir el alcance de las mismas. Como conclusión de la planificación del sprint, el dueño del producto define el alcance e importancia, mientras que el equipo de Scrum realiza la estimación. b. Scrum Diario: El Scrum Diario es una reunión de 15 minutos máximo, que se realiza todos los días y participan todos los miembros del equipo de Scrum durante el desarrollo de un Sprint. Durante esta reunión el equipo sincroniza su trabajo, progreso e informa cualquier impedimento que tenga o prevea al Scrum Master. Cada miembro del equipo debe responder a estas preguntas: 13

22 o Qué hiciste desde el último Scrum Diario? o Qué harás desde ahora y hasta el próximo Scrum diario? o Qué te está impidiendo hacer tu trabajo lo mejor posible? Fig. 7: Scrum diario. Esta reunión es de suma utilidad y tiene los siguientes beneficios: o Se identifican los impedimentos prontamente, para poder mantener el ritmo de desarrollo. o Se disminuye la duplicación de esfuerzo. o Se comparten objetivos y una dirección clara en el equipo. o Se construye confianza y motivación durante el Sprint. o Se conoce sobre qué actividades está trabajando cada miembro del equipo. o Mejora la comunicación del equipo y sus relaciones. c. Demostración de Sprint: El objetivo de la demo, es tener las funcionalidades terminadas, probadas, demostrables, y entregables. Esta reunión se hace al final del Sprint y sirve para: o Obtener el reconocimiento del equipo por sus logros. o Informar a terceros sobre las actividades que realiza el equipo. o Conseguir la retroalimentación vital de los interesados. o Forzar al equipo a terminar realmente las cosas y entregarlas. o Incrementar significativamente las posibilidades de que haya algo útil que demostrar. Fig. 8: Demostración de Sprint. 14

23 d. Retrospectiva de Sprint: Con el objetivo de mejorar de manera continua la productividad y la calidad del producto que se está desarrollando, el equipo analiza cómo ha sido su manera de trabajar durante la iteración, para determinar si está alcanzando o no los objetivos a los cuales se comprometió al inicio del Sprint. Esta reunión que se realiza después de la demo de Sprint sirve para saber: o Qué cosas han funcionado bien? o Qué cosas hay que mejorar? o Qué acciones hay que llevar a cabo para mejorar el trabajo? Fig. 9: Retrospectiva de Sprint. Este ciclo iterativo se repite hasta que un conjunto de funcionalidades generen un producto utilizable para sus usuarios, a esto se le llama Sprint Release. Un Sprint Release, no debería ser más largo que un Sprint normal. Es una buena práctica que asegura, que el sistema esté en un estado tal que un sólo Sprint, alcance para ponerlo en producción. Si la respuesta es negativa, entonces el equipo debería mejorar la calidad del código existente y verificar que su concepto de "terminado" es lo suficientemente completo. SPRINT 1 SPRINT 2 DÍA 1 DÍA 21 DÍA 3 DÍA 4 DÍA 5 DÍA 6 DÍA 7 DÍA 1 DÍA 21 DÍA 3 DÍA 4 DÍA 5 DÍA 6 DÍA 7 Planificación de Sprint Scrum Diario Scrum Diario Scrum Diario Scrum Diario Scrum Diario Scrum Diario Planificación de Sprint Scrum Diario Scrum Diario Scrum Diario Scrum Diario Scrum Diario Scrum Diario DÍA 8 DÍA 91 DÍA 10 DÍA 11 DÍA 12 DÍA 13 DÍA 14 DÍA 8 DÍA 91 DÍA 10 DÍA 11 DÍA 12 DÍA 13 DÍA 14 Scrum Diario Scrum Diario Scrum Diario Scrum Diario Scrum Diario Scrum Diario Demostración de Sprint Retrospectiva del Sprint Scrum Diario Scrum Diario Scrum Diario Scrum Diario Scrum Diario Scrum Diario Demostración de Sprint Retrospectiva del Sprint SPRINT RELEASE Fig. 10: Sprint Release. 15

24 3.4) Roles en Scrum: Como mencionamos anteriormente existen tres grandes roles en Scrum, los cuales tienen las siguientes funciones y responsabilidades: Dueño de Producto: o Decidir sobre cuáles funcionalidades y características funcionales tendrá el producto. o Representar al cliente, usuarios del software y todas aquellas partes interesadas en el producto. o Canalizar las necesidades del negocio, sabiendo "escuchar" a las partes interesadas en el producto y transmitirlas en "objetivos de valor para el producto", al equipo de Scrum. o Maximizar el valor para el negocio con respecto al Retorno de Inversión (ROI), resguardando los intereses del negocio. o Revisar el producto e ir adaptándole sus requisitos, analizando las mejoras que éstas puedan otorgar un mayor valor para el negocio. Scrum Master: o Fomentar e instruir sobre los principios ágiles de Scrum. o Garantizar la correcta aplicación de Scrum. o Resolver los conflictos que entorpezcan el progreso del proyecto. o Incentivar y motivar al equipo de Scrum, creando un clima de trabajo colaborativo. o Fomentar la auto-gestión del equipo. o Impedir la intervención de terceros en la gestión del equipo. Equipo de Scrum: o Analizar, evaluar, aceptar o rechazar los requisitos propuestos por el dueño del producto. o Estimar en tiempo las historias de usuario correspondientes al Sprint. o Entregar el producto a través de desarrollos potencialmente funcionales y operativos. o Contar con capacidades profesionales de nivel experto o avanzado en su disciplina. o Tener vocación para trabajar en equipo. o Poseer capacidad de auto-gestión. o Conocer la metodología Scrum. El equipo de Scrum es un equipo de desarrolladores multidisciplinario, integrado por programadores, diseñadores, arquitectos, administradores de base de datos, encargados del control de calidad y demás, que en forma auto-organizada, serán los encargados de desarrollar el producto. Si bien las funciones y responsabilidades que realiza cada miembro del equipo de desarrollo son similares a las que existen en un modelo en cascada, la gran diferencia es que cada miembro tiene como objetivo principal obtener un software con la máxima calidad posible en sus distintas etapas, y no sólo en la etapa de pruebas, ya que esta etapa, es un componente central del desarrollo ágil de software y debe estar presente en todo momento. En las metodologías ágiles todos tienen que colaborar con la calidad del software. 16

25 Por esta razón el papel del encargado del control de calidad, es clave para el éxito de todo proyecto, ya que no sólo es el que ejecuta las pruebas sino que también está al tanto de los demás aspectos del software que contribuyen hacia una mejor calidad como: o Reunir, compartir información y trabajar con el dueño del producto con el fin de ayudarle a expresar sus necesidades de manera adecuada para que pueda obtener las características que necesita, y para proporcionar información sobre los avances del proyecto a todos los miembros del equipo. o Colaborar con las personas del negocio y profesionales técnicos que comprenden los conceptos de pruebas para documentar requisitos y guiar el desarrollo. o Saber colaborar con el resto del equipo para tener una visión más detallada del problema que se piensa solucionar con el software. o Planificar y ejecutar los distintos tipos de pruebas. Además del equipo de desarrollo, también existe el equipo del cliente, este equipo se comunica y colabora con el equipo de desarrollo, respondiendo preguntas, graficando ejemplos y revisando historias de usuarios. Entre los miembros del equipo del cliente pueden estar: los dueños del producto, expertos del negocio, expertos del dominio, analistas de negocio, administradores del producto, etc. Ambos equipos trabajan juntos todo el tiempo. Ellos son sólo un equipo con un objetivo en común, este objetivo es darle valor agregado al negocio. El equipo del cliente con el aporte de los desarrolladores priorizará las historias de usuario a desarrollar, y el equipo de desarrollo determinará cuál será el esfuerzo que les demandará. Scrum Master Valor agregado al Negocio Equipo del Cliente Equipo de Desarollo Fig. 11: Equipo del cliente y desarrollo trabajando como un solo equipo. 17

26 3.5) Ventajas y desventajas: Ventajas: o Es más rápido, ya que se obtiene un producto funcional al finalizar cada Sprint que cumple con los requisitos planificados. o Es flexible, ya que nos permite ajustar las funcionalidades en base a la necesidad del negocio del cliente. o Permite producir software de una forma consistente, sostenida y competitiva. o Provee visualización del proyecto día a día. o Contribuye a que el equipo trabaje de forma integrada y comprometida. o Mantiene la efectividad del equipo habilitando y protegiendo un entorno libre de interrupciones e interferencias. o Evita el estancamiento, ya que las reuniones se dedican a inconvenientes recientes. Desventajas: o Genera poca evidencia o documentación, a comparación de otras metodologías. o Expone ciertas prácticas que no pueden ser aplicadas por todos los proyectos de desarrollo de software. o Requiere delegar responsabilidades al equipo, incluso permite fallar si es necesario. o Causa cierta resistencia en su aplicación para algunas personas. 18

27 CAPÍTULO IV: TRANSICIÓN HACIA LAS METODOLOGÍAS ÁGILES 4.1) Cultura Organizacional: Como se vió en el capítulo anterior la razón de la existencia de las metodologías ágiles, se debe a que son metodologías que se adaptan al cambio de los requisitos, ya que al ser iterativas, se puede obtener una mejor retroalimentación con el cliente, y a su vez lograr una mejor calidad en el software. A pesar de que las nuevas metodologías solucionaron problemas que las metodologías tradicionales no tuvieron en cuenta. Apareció una gran causante de nuevos problemas a la hora de aplicar una metodología ágil, la resistencia al cambio. Es por ello, que la cultura organizacional es un factor clave, ya que puede afectar el éxito de un equipo ágil. o Resistencia al cambio: Las organizaciones, al igual que los individuos, tienden a resistirse al cambio, negándose a adaptar a las diferentes transformaciones que suceden en su medio por ser este difícil o costoso. El cambio significa para éstos moverse desde una situación actual y estable, hacia otra situación que genera incertidumbre, debido a que se piensa que este cambio traerá consecuencias negativas. Cuanto más grande sea el cambio, mayor será la resistencia. 4.2) Problemas que surgen de la aplicación de las metodologías ágiles: Existen diversos problemas que derivan de la resistencia al cambio y la mediocridad; pero los principales y más comunes son: 4.2.1) Con respecto al cliente: a. Escasa o nula participación y comunicación durante el desarrollo del software: El cliente por lo general tiene un comportamiento muy distinto a lo que sugieren los principios ágiles, con respecto a su participación. Si bien éste puede participar en las reuniones de planificación, demostración y retrospectiva de Sprint, suele tener muy poca interacción con los miembros del equipo, ya que casi nunca se encuentra disponible durante el transcurso del desarrollo del software. Esto afecta gravemente a un equipo ágil, ya que las preguntas, dudas o sugerencias realizadas por el equipo no pueden ser respondidas. Este inconveniente resulta ser un impedimento común en todo equipo, que si no se soluciona rápidamente, reduce la productividad del equipo de desarrollo. Lo que se suele hacer para solucionar esto, es hacer uso de distintos medios de comunicación como correos electrónicos, chats, etc. De no mejorar la comunicación por éstos medios, lo que se hace comúnmente, es suponer cuál será la respuesta del cliente, y es aquí donde surgen diversas suposiciones por parte del equipo de desarrollo, lo que perjudica directamente la calidad del software, produciendo así, la disconformidad del cliente. 19

28 Fig. 12: Escasa o nula participación del cliente ) Con respecto al equipo de desarrollo: a. Escasez de tiempo de desarrollo del software: Parece poco creíble que la escasez de tiempo sea un problema fundamental en el uso de las metodologías ágiles, ya que las iteraciones son cortas y es notorio rápidamente si el progreso del desarrollo van encaminado o no. La escasez de tiempo es un gran desencadenante de problemas que suelen afectar al equipo, al cliente como también a la calidad del producto y entre estos subproblemas se encuentran: o Horas de trabajo extra: A menudo surgen situaciones en las cuales los miembros del equipo como los líderes, comprometen a todo el equipo a cumplir con el desarrollo de todos los requisitos propuestos por el cliente, sin importarles las opiniones del resto del equipo de desarrollo, que son los que tienen que estimar y aceptar, rechazar, acotar o extender el conjunto de requisitos propuestos a ser desarrollados durante la iteración. Esta actitud es conocida con la frase Nosotros podemos hacerlo, logrando como resultado el fracaso de la iteración, ya que siempre se hace el compromiso, la negociación beneficiando al cliente y no de forma equitativa. Cercana a la fecha final de cada iteración se puede ver claramente los esfuerzos extra que realiza cada miembro del equipo por intentar cumplir con lo pactado. o Escasa o nula calidad del software: No hay tiempo suficiente para programar los requisitos del cliente, mucho menos para probar el funcionamiento de los mismos. Los programadores solo se ocupan de probar los casos de prueba positivos que nacen de su creatividad y entienden como críticos para dar por terminada la funcionalidad, restándoles importancia a los casos de pruebas negativos y/o alternativos que pueden surgir de la misma. Cercana a la fecha final de cada iteración, el equipo de programadores entrega la versión del software desarrollada al equipo de control de calidad, los cuales tienen tiempo solo para llevar a cabo algunas pruebas funcionales, que se creen que son suficientes, para obtener una calidad de software aceptable; dejando de lado otros tipos de prueba, como las pruebas automatizadas, pruebas de exploración, pruebas de usabilidad, pruebas de aceptación de usuario y mucho menos hablar de pruebas de carga, performance y seguridad. 20

29 Al final las pocas pruebas funcionales que se le aplican al software, realizadas por el equipo de desarrollo terminan siendo insuficientes, provocando una acumulación de errores y defectos que probablemente serán arreglados, durante alguna iteración futura. o Acumulación de la deuda técnica: La misma desesperación por dar como concluida una funcionalidad determinada, incita al programador a buscar soluciones temporales, que les ayudan a reducir las presiones que están padeciendo. Poco a poco, durante cada iteración se va perdiendo las buenas prácticas de programación, como la utilización de convenciones de nombres, comentarios en el código, manejo de errores, uso de variables, etc.; así como también se va perdiendo la arquitectura del software, debido a que los patrones de diseño inicialmente planteados no se están respetando. La integración del código resulta todavía más costosa, más aún cuando trabajan varios sub-equipos juntos. Cuando se intenta hacer funcionar el código en conjunto, es común encontrar que el código se rompa fácilmente, ya que este no es seguro ni fiable. Aquí saltan a la luz un conjunto de problemas técnicos acumulados por cada sub-equipo y durante cada iteración. Permaneciendo así, la deuda técnica en la memoria y conciencia de cada uno de los miembros del equipo de desarrollo, ya que reducir esa deuda, es muy costosa, pues no solo porque implica mucho esfuerzo, sino también porque implica tiempo y dinero. o Nula documentación del sistema: Si bien las metodologías ágiles enfatizan la comunicación cara a cara, por encima de la documentación exhaustiva. El manifiesto ágil, no afirma que la documentación no sea necesaria. Este concepto, es casi siempre mal interpretado por el equipo de desarrollo, ya que entienden por equipo ágil, producir rápida y desordenadamente. Evitando así la documentación básica del sistema. La documentación permite la transferencia del conocimiento, registra la información histórica, y en muchas cuestiones legales o normativas son obligatorias. Un sistema sin documentación básica y necesaria, es imposible de entender tanto para los usuarios, los clientes, como para los futuros miembros del equipo de desarrollo. Si un nuevo miembro del equipo de desarrollo hace su ingreso cómo entenderá el funcionamiento del sistema?, será suficiente con hablar con el especialista de cada módulo del sistema? o No se disfruta de lo que se hace: Durante cada iteración el equipo de desarrollo ha intentado dar lo mejor de sí, han invertido esfuerzos extras como dedicación y tiempo; pero estos esfuerzos resultan en vano ya que los resultados no son favorables. A quién le gusta trabajar presionado por los tiempos?, a quién le gusta trabajar en un proyecto que no presenta avances?, a quién le gusta trabajar lleno de incertidumbre?, a quién no le gusta ser reconocido por los logros obtenidos? Todas 21

30 estas razones producen en los miembros del equipo, que cada vez se trabaje con menos motivación y con menos deseos de seguir siendo parte del equipo. b. Conceptos erróneos sobre los profesionales de control de calidad: Debido a que durante el desarrollo de software, se le presta mayor atención a las actividades de programación, resulta obvio que mayor importancia se les dará a los programadores, ya que a éstos se les procura y exige mayor participación, comunicación, formación y capacitación en las cuestiones del equipo en un amplio sentido. Restándole importancia a los demás miembros del equipo, como es el caso de los profesionales de control de calidad. De este punto también se generan un conjunto de subproblemas: o Se piensa que el rol del profesional de control de calidad, es el rol de un usuario del sistema: Muchas empresas, cometen el error de creer que el profesional de control de calidad, tiene sólo como objetivo verificar si las interfaces de usuario del sistema, realizan las funcionalidades adecuadas. Con esta mentalidad las empresas, buscan y contratan personas para este tipo de rol, sin importarles su formación y capacitación; contratando incluso, de esta manera, a personas con estudios que no están relacionados a las ciencias informáticas. La ventaja que tienen, es que no les es costoso conseguir a una persona que ocupe este rol. Lo que no tienen en cuenta, es el riesgo que corren al realizar este tipo de acciones. o El equipo de control de calidad es excluido de las reuniones técnicas y de negocios: Contar con profesionales de control de calidad, que no tienen una buena formación profesional, es una gran desventaja. Por esta desventaja, que se presenta la mayor parte de las veces, comúnmente se suele excluir al equipo de control de calidad de las reuniones técnicas y de negocios, ya que se considera, que éstos no poseen los conocimientos suficientes para aportar con alguna idea, que le de valor al equipo y al negocio; y que de participar éstos, sería una pérdida de tiempo. Se piensa erróneamente que los profesionales de control de calidad solo deben estar enfocados en actividades de pruebas y que solo deben tener contacto con el sistema, una vez que las funcionalidades desarrolladas estén terminadas. o Se genera rivalidad entre el equipo de control de calidad y el equipo de programación: Como el equipo de control de calidad, se centra a las actividades de prueba, la única forma de demostrar su progreso, es encontrando la mayor cantidad de defectos y errores en el sistema. Erróneamente, se suele premiar a la persona que lleva a cabo este objetivo con mucha satisfacción. 22