MARCOS DE TRABAJO AGILES, Diapositivas de Ingeniería

¡Descarga MARCOS DE TRABAJO AGILES y más Diapositivas en PDF de Ingeniería solo en Docsity! Marcos de trabajo agiles Los marcos de trabajo ágiles o metodologías ágiles para el desarrollo de software nacen como otra opción para abordar proyectos donde no es posible tener un detalle completo de los requerimientos y sus estimaciones en la primera fase del proyecto o donde es necesario hacer procesos de adaptabilidad a lo largo del proceso de desarrollo de software. Las metodologías ágiles proveen un conjunto de pautas y principios que buscan facilitar y priorizar la entrega de producto sobre procesos de documentación exhaustiva, haciéndolos más simples, donde interactúa el cliente final desde las primeras etapas del proyecto. El inicio de las metodologías ágiles nació en el año 2001 a partir del manifiesto ágil de software donde se establecen cuatro valores fundamentales (Manifiesto Ágil, 2001):  Individuos e interacciones sobre procesos y herramientas.  Software funcionando sobre documentación extensiva.  Colaboración con el cliente sobre negociación contractual.  Respuesta ante el cambio sobre seguir un plan. Adicionalmente a los valores ágiles anteriormente listados, el manifiesto ágil establece 12 principios ágiles para materializar los valores definidos (Manifiesto Ágil, 2001): 1. 1 “Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor. 2. 2 Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente. 3. 3 Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los períodos breves. 4. 4 Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto. 5. 5 Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea. 6. 6 La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara. 7. 7 El software que funciona es la principal medida del progreso. 8. 8 Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida. 9. 9 La atención continua a la excelencia técnica enaltece la agilidad. 10. 10 La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial. 11. 11 Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto organizan. 12. 12 En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia”. A continuación, se invita a profundizar en el tema revisando la sección de material complementario donde encontrará un video que le permitirá ampliar el conocimiento, por otro lado, en los numerales siguientes podrá identificar otra serie de factores importantes que debe tener en cuenta. 3.1 Programación Extrema - XP XP es la abreviación comúnmente utilizada para referirse a Extreme Programming, que es un marco de desarrollo de software ágil que busca producir software de alta calidad en contextos con requisitos altamente cambiantes, riesgos que involucran tiempos fijo con tecnologías nuevas y equipos de trabajo pequeños ubicados en un mismo sitio. En XP se definen cinco valores según Beck y Andrés (2004): Comunicación: el desarrollo de software requiere de trabajo en equipo por lo cual es importante la transferencia de conocimientos y utilizar medios de comunicación apropiados, se propone la discusión cara a cara con herramientas que permitan dibujar o escribir, como, por ejemplo: un tablero. Simplicidad: esto se refiere a hacer solo las cosas que sean absolutamente necesarias evitando el desperdicio, elaborar las cosas de forma que sea fácil entender por otros y abordar solo requisitos conocidos. El coach es una figura encargada de brindar asesoría a los miembros del equipo y son los que definen el rumbo del proyecto. El manager se encarga de la coordinación de actividades, del aseguramiento de los recursos requeridos para el proyecto y quien tiene la responsabilidad de la comunicación externa. 3.2 Desarrollo rápido de aplicaciones - RAD RAD (Desarrollo Rápido de Aplicaciones) es otra metodología de desarrollo de software ágil que se centra en el desarrollo rápido de aplicaciones mediante la realización de iteraciones frecuentes y realimentación constante y fue inventado por James Martin en 1991. Algunas características fundamentales de RAD son:  Mayor flexibilidad y adaptabilidad a cualquier ajuste que deba realizarse durante el proceso de desarrollo.  Iteraciones rápidas que reducen el tiempo de desarrollo y mantienen un ritmo de entrega acelerado.  Se fomenta la reutilización de código.  Mejor gestión del riesgo, ya que las partes interesadas discuten y abordan cualquier vulnerabilidad mientras se construyen los productos. A continuación, se describen las fases propuestas en RAD. Nota. Tomada de Blog Capterra (2019). La primera fase definida corresponde a la definición y finalización de los requisitos del proyecto. En esta fase las partes interesadas se reúnen para definir los requisitos del proyecto definiendo entre otros casos:  Los objetivos.  Las expectativas.  Los plazos.  Presupuesto del proyecto. La segunda fase aborda la construcción de prototipos los cuales son construidos, validados y mejorados a partir de la validación con los usuarios y una vez son aprobados pasan a la tercera fase donde estos prototipos son transformados en modelos funcionales. En la cuarta fase se enfoca en la realización de pruebas exhaustivas para garantizar que todos los elementos construidos funcionan bien individualmente y también de forma colectiva. Finalmente, en la última fase se realizan todas las actividades de lanzamiento del producto lo que involucra el cargue inicial de datos y entrenamiento a los usuarios. Según HKSAR (2009) los roles más importantes de la metodología RAD son: facilitador, escriba, equipo Swat, administrador del modelo, administrador de bases de datos, equipo de planificación de Workshop, equipo de diseño de usuario, equipo de soporte de construcción y equipo de transición, a continuación se mencionan las características más importantes de cada rol. Facilitador: se encarga del aseguramiento de los objetivos, es responsable de los Workshops de captura de requerimientos, se asegura del alistamiento de materiales, es un mediador en procesos de resolución de conflictos. Equipo Swat: equipo encargado del diseño y construcción del sistema. Administrador de bases de datos: responsables del rendimiento, integridad y seguridad de los datos de la organización Equipo de diseño de usuario: proveen información detallada describiendo las funciones del negocio y procesos que serán afectados por el sistema propuesto. Equipo de transición: desarrolla las tareas necesarias para preparar y llevar el sistema a entornos de producción. Escriba: es responsable de la documentación de todas las salidas producto de los Workshops de captura de requerimientos y registra información de todo el proceso. Administrador del modelo: encargado de coordinar el desarrollo y mantenimiento de las arquitecturas modelos resultantes del proyecto. Equipo de planificación de los Workshops: asisten en la definición de requerimientos y el alcance propuesto para el sistema propuesto. Equipo de soporte de construcción: equipo que se asegura que las necesidades del usuario final sean alcanzadas en el sistema completo mediante la entrega de conocimiento detallado de actividades de negocio y realimentación en la usabilidad del sistema al equipo Swat. 3.3 Scrum requerimiento terminado y presentación de avances a los clientes. Generalmente es un equipo autoorganizado y autogestionado. Además de los roles, Scrum define un conjunto de eventos con participantes y objetivos claros que se desarrollan en momentos particulares del flujo general de Scrum, a continuación, se detalla cada uno de estos: 1 2 3 4 5 Sprint: es el corazón de Scrum y se refiere a una iteración que está acotada generalmente por un lapso entre 2 y 4 semanas donde se realiza un ciclo completo de actividades de análisis, diseño, construcción y pruebas para desarrollar una versión del producto potencialmente entregable al cliente. Planeación del Sprint: reunión realizada justo antes del inicio de un Sprint donde se definen el subconjunto de requerimientos (Sprint Backlog) a ser desarrollados en los siguientes y cómo será el proceso requerido para hacer la entrega, lo cual incluye detallar los requerimientos en tareas concretas, estimación de tiempos/esfuerzo y distribución inicial de responsabilidades. Dependiendo de la duración del Sprint este tiempo de planificación puede variar, pero la métrica establecida para un Sprint de 4 semanas corresponde a una planeación de Sprint de 8 horas. Reunión diaria (Daily Meeting): reunión realizada generalmente al inicio de cada día donde el equipo de trabajo informa en que ha venido trabajando, qué cosas realizará en el día y qué problemas se le han presentado. Esta es corta, se realiza de pie y debe tener una duración alrededor de los 15 minutos, por lo que, se alinea con los pilares de transparencia e inspección. Revisión del Sprint: reunión realizada al finalizar el sprint donde el equipo de desarrollo muestra los resultados. Para un Sprint de 4 semanas se usan reuniones de revisiones 4 horas. Reunión de retrospectiva: esta es la última, se realiza luego de la revisión del Sprint y tiene como objetivo la autoevaluación personal y del grupo sobre el desempeño del Sprint que acaba de finalizar. En esta se identifican y documentan los aprendizajes por medio de diferentes técnicas en las que generalmente se busca dar respuesta a las siguientes preguntas: ¿Qué funcionó bien y se debe seguir haciendo? ¿Qué no funcionó bien y se debe dejar de realizar? ¿Qué debemos empezar a mejorar? Para un Sprint de 4 semanas se utilizan 3 horas para esta reunión. Finalmente, el marco de trabajo Scrum define un conjunto de artefactos que permiten registrar y gestionar información clave para asegurar los tres pilares fundamentales y proveen información valiosa durante todo el proceso de desarrollo de software. Entre los artefactos representativos de este se encuentran los siguientes: Pila de producto (Product Backlog): lista priorizada de requerimientos generalmente descritos en formato de historias de usuarios que representa todas las características del sistema a construir. Pila del Sprint (Sprint Backlog): lista de requerimientos seleccionados desde el Product backlog por el equipo de trabajo para ser desarrollados durante un Sprint particular. Este es uno de los artefactos generados en la reunión de planeación del Sprint. Burndown Chart: es un gráfico visual de dos ejes que muestra a los equipos la cantidad de trabajo pendiente por completar (eje Y) y el tiempo disponible para hacerlo (eje X). Este generalmente se realiza por cada Sprint ubicando la cantidad de trabajo a realizar del Sprint Backlog (usualmente medido por puntos de historia u de horas de trabajo) en un tiempo 0 y por cada día finalizado se resta la cantidad de puntos de historia u horas de cada tarea completada. Por otro lado, también es posible usar este mismo gráfico para representar el avance general del proyecto ubicando en el eje Y la cantidad total de horas o esfuerzo del Product Backlog y en el eje X la cantidad de Sprint proyectados. Cada uno de estos puntos se une por medio de una línea y es posible determinar visualmente si el flujo de trabajo está en una situación óptima o no respecto al tiempo restante para completar el Sprint. Figura 7 Burndown Chart Tablero de Scrum (Scrumboard): es un elemento visual donde se integra la mayor parte de los elementos del marco de trabajo Scrum, en él se indica la carga de trabajo, el estado actual de cada una de las actividades y sus respectivos responsables. Este es un elemento que se sincroniza de manera permanente y facilita la implementación de los pilares de transparencia, inspección y adaptabilidad. Si bien se aconseja el uso de un tablero, existen diferentes tipos de herramientas digitales que permiten la implementación de un tablero de Scrum. Nota. Tomada de intl-blog.imgix.net (2019). Figura 8 Tablero de Scrum Adicionalmente es de vital importancia mencionar que entre los principales beneficios del marco de trabajo Scrum se encuentran los siguientes elementos:  Es posible gestionar las expectativas del cliente de manera regular, ya que, este puede y debe participar en las reuniones de revisión, por lo que, está enterado todo el tiempo del estado actual del proyecto.  El cliente puede obtener resultados importantes y utilizables desde las primeras iteraciones, ya que, la lista de producto está priorizada para ofrecer mayor valor en el menor tiempo posible y porque cada finalización de Sprint debe tener como resultado una versión totalmente funcional.  El proyecto puede iniciar con requerimientos de muy alto nivel y es fácil administrar los cambios.  La participación constante del cliente permite mitigar riesgos del proyecto desde sus primeras etapas.  Los procesos de retrospectiva permiten establecer actividades permanentes de mejora continua en función de las experiencias del equipo. Un elemento clave en su formación es la planeación de proyectos de software que aunado con los contenidos ya vistos le permite tener un panorama amplio sobre el tema. Para profundizar le invito a revisar la sección de material complementario donde encontrará un video sobre el tema. Metodologías de desarrollo de software ágiles