SCRUM. ¿QUÉ ES SCRUM? Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo,

Presentación del tema: "SCRUM. ¿QUÉ ES SCRUM? Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo,"— Transcripción de la presentación:

1 SCRUM

2 ¿QUÉ ES SCRUM? Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

3 ¿CUÁNDO SE UTILIZA? Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento realinear el software con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración sin ningún problema. Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar sus capacidades. En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales. Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.

4 EL PROCESO En Scrum un proyecto se ejecuta en ciclos temporales cortos y de duración fija (iteraciones que normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas, límite máximo de feedback y reflexión). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite. El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste (que el equipo estima considerando la Definición de Hecho) y quedan repartidos en iteraciones y entregas.

5 EL PROCESO Las actividades que se llevan a cabo en Scrum son las siguientes: Planificación de la iteración El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene dos partes: Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de la iteraciónnecesarias para desarrollar los requisitos a que se ha comprometido. La estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se autoasignan las tareas. Ejecución de la iteración Cada día el equipo realiza una reunión de sincronización (15 minutos máximo), normalmente delante de untablero físico o pizarra (Scrum Taskboard). Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunión cada miembro del equipo responde a tres preguntas: ¿Qué he hecho desde la última reunión de sincronización? ¿Qué voy a hacer a partir de este momento? ¿Qué impedimentos tengo o voy a tener?

6 EL PROCESO Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad. Elimina los obstáculos que el equipo no puede resolver por sí mismo. Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad. Durante la iteración, el cliente junto con el equipo refinan la lista de requisitos (para prepararlos para las siguientes iteraciones) y, si es necesario, cambian o replanifican los objetivos del proyecto para maximizar la utilidad de lo que se desarrolla y el retorno de inversión. Inspección y adaptación El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos partes: Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo. En función de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteración, replanificando el proyecto. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos identificados.

7 EL PROCESO El desarrollo se realiza de forma iterativa e incremental. Cada iteración, denominada Sprint, tiene una duración preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versión del software con nuevas prestaciones listas para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya construida y se añaden nuevas prestaciones priorizándose siempre aquellas que aporten mayor valor de negocio. Product Backlog: Conjunto de requisitos demoninados historias descritos en un lenguaje no técnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversión considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares. Sprint Planning: Reunión durante la cual el Product Owner presenta las historias del backlog por orden de prioridad. El equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint, para en una segunda parte de la reunión, decidir y organizar cómo lo va a conseguir. Sprint: Iteración de duración prefijada durante la cual el equipo trabaja para convertir las historias del Product Backlog a las que se ha comprometido, en una nueva versión del software totalmente operativo. Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint. Daily sprint meeting: Reunión diaria de cómo máximo 15 min. en la que el equipo se sincroniza para trabajar de forma coordinada. Cada miembro comenta que hizo el día anterior, que hará hoy y si hay impedimentos. Demo y retrospectiva: Reunión que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una demonstración del producto. Posteriormente, en la retrospectiva, el equipo analiza qué se hizo bien, qué procesos serían mejorables y discute acerca de cómo perfeccionarlos.

8

9 BENEFICIOS Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le aporta cada requisito / historia del proyecto, el equipo los estima y con esta información el Product Owner establece su prioridad. De manera regular, en las demos de Sprint el Product Owner comprueba que efectivamente los requisitos se han cumplido y transmite se feedback al equipo. Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado. La metodología está diseñada para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos. Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más importantes del proyecto antes de que esté finalizado por completo. Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión funcional después de cada iteración, ayuda a la obtención de un software de calidad superior. Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos para organizarse. Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de inversión. Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el Backlog. Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada.

10 ROLES Roles principales: Product Owner: el propietario del proyecto representa la voz de un cliente. Él es responsable de comprender los requisitos del cliente y articular el mismo para el equipo de scrum. También es responsable de entregar el máximo valor comercial al cliente. Él define los criterios de aceptación para los entregables. Scrum Master - es responsable de eliminar los impedimentos que enfrentan los miembros del equipo de scrum y facilitar al equipo el desarrollo de los entregables. También se asegura de que el equipo trabaje en armonía y trabaje para alcanzar los objetivos definidos. Team: el equipo de Scrum o el equipo de desarrollo es responsable de la producción de bienes y servicios que cumplan con los criterios de aceptación. El equipo de scrum es responsable del éxito o fracaso del proyecto ya que está directamente involucrado en la producción. Funciones no esenciales: Grupos de interés : clientes, usuarios y patrocinadores son los interesados ​​ en el proyecto de scrum que tienen interés en el resultado del proyecto pero que no están directamente involucrados en los sprints de producción. Vendedores : los proveedores o los proveedores son quienes entregan los productos semiacabados que entran en la producción final del entregable por parte del equipo de scrum. Cuerpo de orientación de Scrum : como se define en la Guía de SBOK, el cuerpo de orientación de escoria es un grupo de personas con un conjunto de documentos que definen los criterios de calidad, las normas y regulaciones gubernamentales, etc. que afectan el desempeño del equipo de scrum.

11 VENTAJAS Entregables en tiempo y forma, puedes ir enviando entregables al cliente mientras vas atacando los objetivos mas sencillos, eso te hace ganar tiempo para atacar los objetivos mas complejos. el ScrumMaster tiene el conocimiento necesario para lograr el objetivo primario y secundario por lo cual puede ir controlando el proyecto y delegando roles. Cada persona sabe que es lo que tiene que hacer y no es necesario estar reorganizando una y otra vez los Tracks de cada persona. Se involucra desde un principio y se da un rol a todos los stakeholders (personas que van a participar en el proyecto incluyendo cliente final, QA, Testers, etc.) DESVENTAJAS Algunos miembros de tu equipo pueden saltar pasos importantes en el camino rápido para llegar al “sprint” final. El cliente siempre va a esperar los informes con la fecha exacta, y muchas veces los va a pedir antes, cuando capaz no pudiste avanzar en nada. Demasiadas Reuniones para poco avance, a veces es muy cansador y estresante reunirse demasiadas veces por el mismo tema, algunos van perdiendo el interés en el proyecto. Si una persona renuncia o hay algún cambio es complicado remplazar ese rol ya que es la persona que se lleva el conocimiento especifico y afecta a todo el proyecto. No es aplicable a grandes escalas o cuando el sector IT es variado.

12 PROGRAMACION EXTREMA XP

13 PROGRAMACIÓN EXTREMA XP Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico. Metodología liviana de desarrollo de software Conjunto de prácticas y reglas empleadas para desarrollar software Basada en diferentes ideas acerca de cómo enfrentar ambientes muy cambiantes Originada en el proyecto C3 para Chrysler En vez de planificar, analizar y diseñar para el futuro distante, hacer todo esto un poco cada vez, a través de todo el proceso de desarrollo

14

15 OBJETIVOS. Establecer las mejores prácticas de Ingeniería de Software en los desarrollo de proyectos. Mejorar la productividad de los proyectos. Garantizar la Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente. CONTEXTO XP Cliente bien definido Los requisitos pueden (y van a) cambiar Grupo pequeño y muy integrado (máximo 12 personas Equipo con formación elevada y capacidad de aprender

16 CARACTERÍSTICAS XP Metodología basada en prueba y error Fundamentada en Valores y Prácticas Expresada en forma de 12 Prácticas–Conjunto completo–Se soportan unas a otras– Son conocidas desde hace tiempo. La novedad es juntarlas VALORES XP Simplicidad: XP propone el principio de hacer la cosa más simple que pueda funcionar, en relación al proceso y la codificación. Es mejor hacer hoy algo simple, que hacerlo complicado y probablemente nunca usarlo mañana. Comunicación: Algunos problemas en los proyectos tienen origen en que alguien no dijo algo importante en algún momento. XP hace casi imposible la falta de comunicación. Realimentación: Retroalimentación concreta y frecuente del cliente, del equipo y de los usuarios finales da una mayor oportunidad de dirigir el esfuerzo eficientemente. Coraje: El coraje (valor) existe en el contexto de los otros 3 valores.(si funciona…mejóralo)

17 EL ESTILO XP Está orientada hacia quien produce y usa el software Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema. Combina las que han demostrado ser las mejores practicas para desarrollar software, y las lleva al extremo. PRÁCTICAS BÁSICAS DE LA PROGRAMACIÓN EXTREMA Para que todo esto funcione, la programación extrema se basa en doce "prácticas básicas" que deben seguirse al pie de la letra. Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto. Planificación: Se hacen las historias de usuario y se planifica en qué orden se van a hacer y las mini-versiones. La planificación se revisa continuamente. Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones.

18 PRÁCTICAS BÁSICAS DE LA PROGRAMACIÓN EXTREMA Para que todo esto funcione, la programación extrema se basa en doce "prácticas básicas" que deben seguirse al pie de la letra. Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto. Planificación: Se hacen las historias de usuario y se planifica en qué orden se van a hacer y las mini- versiones. La planificación se revisa continuamente. Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones. Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo útil al usuario final y no trozos de código que no pueda ver funcionando. Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla posible. Mantener siempre sencillo el código. Pareja de programadores: Los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario). Desarrollo guiado por las pruebas automáticas: Se deben realizar programas de prueba automática y deben ejecutarse con mucha frecuencia. Cuantas más pruebas se hagan, mejor.

19 Integración continua: Deben tenerse siempre un ejecutable del proyecto que funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe recompilarse y probarse. Es un error mantener una versión congelada dos meses mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando falle algo, no se sabe qué es lo que falla de todo lo que hemos metido. El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del código. Para eso se hacen las pruebas automáticas. Normas de codificación: Debe haber un estilo común de codificación (no importa cual), de forma que parezca que ha sido realizado por una única persona. Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las distintas partes del programa, de forma que sólo con los nombres se pueda uno hacer una idea de qué es lo que hace cada parte del programa. Un ejemplo claro es el "recolector de basura" de java. Ayuda a que todos los programadores (y el cliente) sepan de qué estamos hablando y que no haya mal entendidos. Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente. Esto quiere decir que no debe haber días muertos en que no se sabe qué hacer y que no se deben hacer un exceso de horas otros días. Al tener claro semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir el objetivo cercano de terminar una historia de usuario o mini-versión. PRÁCTICAS BÁSICAS DE LA PROGRAMACIÓN EXTREMA

20 VENTAJAS Y DESVENTAJAS DE EXTREME PROGRAMMING. Ventajas: Programación organizada. Menor taza de errores. Satisfacción del programador. Desventajas: Es recomendable emplearlo solo en proyectos a corto plazo. Altas comisiones en caso de fallar.