Está en la página 1de 7

METODOLOGA SCRUM

Qu es? Scrum es una metodologa gil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversin para su empresa (ROI). Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspeccin continua, adaptacin, auto-gestin e innovacin.

Cundo se utiliza? Con la metodologa Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteracin a iteracin. 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 iteracin sin ningn problema. Esta metdica de trabajo promueve la innovacin, motivacin y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un mbito propicio para desarrollar sus capacidades.

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 informacin el Product Ownerestablece 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 reaccin ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado. La metodologa est diseada para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos. REDUCCIN DEL TIME TO MARKET: El cliente puede empezar a utilizar las funcionalidades ms importantes del proyecto antes de que est finalizado por completo. MAYOR CALIDAD DEL SOFTWARE: La metdica de trabajo y la necesidad de obtener una versin funcional despus de cada iteracin, ayuda a la obtencin de un software de calidad superior. MAYOR PRODUCTIVIDAD: Se consigue entre otras razones, gracias a la eliminacin de la burocracia y a la motivacin del equipo que proporciona el hecho de que sean autnomos para organizarse. MAXIMIZA EL RETORNO DE LA INVERSIN (ROI): Produccin de software nicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorizacin por retorno de inversin. PREDICCIONES DE TIEMPOS: Mediante esta metodologa se conoce la velocidad media del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar fcilmente para cuando se dispondr de una determinada funcionalidad que todava est en el Backlog. REDUCCIN DE RIESGOS: El hecho de llevar a cabo las funcionalidades de ms valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada.

PROCESO Y ROLES DE SCRUM EL PROCESO El desarrollo se realiza de forma iterativa e incremental. Cada iteracin, denominada Sprint, tiene una duracin preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versin del software con nuevas prestaciones listas para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya construida y se aaden nuevas prestaciones priorizndose siempre aquellas que aporten mayor valor de negocio. PRODUCT BACKLOG: Conjunto de requisitos demoninados historias descritos en un lenguaje no tcnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversin considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares. SPRINT PLANNING: Reunin 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 reunin, decidir y organizar cmo lo va a conseguir.

SPRINT: Iteracin de duracin prefijada durante la cual el equipo trabaja para convertir las historias del Product Backlog a las que se ha comprometido, en una nueva versin del software totalmente operativo. SPRINT BACKLOG: Lista de las tareas necesarias para llevar a cabo las historias del sprint. DAILY SPRINT MEETING: Reunin diaria de cmo mximo 15 min. en la que el equipo se sincroniza para trabajar de forma coordinada. Cada miembro comenta que hizo el da anterior, que har hoy y si hay impedimentos. DEMO Y RETROSPECTIVA: Reunin que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una demonstracin del producto. Posteriormente, en la retrospectiva, el equipo analiza qu se hizo bien, qu procesos seran mejorables y discute acerca de cmo perfeccionarlos. ROLES En Scrum, el equipo se focaliza en construir software de calidad. La gestin de un proyecto Scrum se centra en definir cules son las caractersticas que debe tener el producto a construir (qu construir, qu no y en qu orden) y en vencer cualquier obstculo que pudiera entorpecer la tarea del equipo de desarrollo. El equipo Scrum est formado por los siguientes roles: Scrum master: Persona que lidera al equipo guindolo para que cumpla las reglas y procesos de la metodologa. Gestiona la reduccin de impedimentos del proyecto y trabaja con el Product Owner para maximizar el ROI. Product owner (PO): Representante de lso accionistas y clientes que usan el software. Se focaliza en la parte de negocio y el es responsable del ROI del proyecto (entregar un valor superior al dinero invertido). Traslada la visin del proyecto al equipo, formaliza las prestaciones en historias a incorporar en el Product Backlog y las reprioriza de forma regular. Team: Grupo de profesionales con los conocimientos tcnicos necesarios y que desarrollan el proyecto de manera conjunta llevando a cabo las historias a las que se comprometen al inicio de cada sprint.

METODOLOGIA RAD

Qu es? La metodologa de desarrollo conocida como diseo rpido de aplicaciones RAD (por sus siglas en ingls) ha tomado gran auge debido a la necesidad que tienen las instituciones de crear aplicaciones funcionales en un plazo de tiempo corto. RAD es un ciclo de desarrollo diseado para crear aplicaciones de computadoras de alta calidad de las que acontecen en corporaciones grandes.

FASES DEL RAD


MODELADO DE GESTIN: el flujo de informacin entre las funciones de gestin se modela de forma que responda a las siguientes preguntas: Qu informacin conduce el proceso de gestin? Qu informacin se genera? Quin la genera? A dnde va la informacin? Quin la proceso? MODELADO DE DATOS: el flujo de informacin definido como parte de la fase de modelado de gestin se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las caractersticas (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos. MODELADO DE PROCESO: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de informacin necesario para implementar una funcin de gestin. Las descripciones del proceso se crean para aadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicacin entre los objetos. GENERACIN DE APLICACIONES: El DRA asume la utilizacin de tcnicas de cuarta generacin. En lugar de crear software con lenguajes de programacin de tercera generacin, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automticas para facilitar la construccin del software. PRUEBAS DE ENTREGA: Como el proceso DRA enfatiza la reutilizacin, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

PORQU USAR RAD? MALAS RAZONES Prevenir presupuestos rebasados (RAD necesita un equipo disciplinado en manejo de costos). Prevenir incumplimiento de fechas (RAD necesita un equipo disciplinado en manejo de tiempo). BUENAS RAZONES Convergir tempranamente en un diseo aceptable para el cliente y posible para los desarrolladores. Limitar la exposicin del proyecto a las fuerzas de cambio. Ahorrar tiempo de desarrollo, posiblemente a expensas de dinero o de calidad del producto.

CARACTERSTICAS DE RAD Equipos Hbridos Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo del sistema as como aquellas personas involucradas con los requisitos. Los desarrolladores de RAD deben ser "renacentistas": analistas, diseadores y programadores en uno.

HERRAMIENTAS ESPECIALIZADAS Desarrollo "visual" Creacin de prototipos falsos (simulacin pura) Creacin de prototipos funcionales Mltiples lenguajes Calendario grupal Herramientas colaborativas y de trabajo en equipo Componentes reusables Interfaces estndares (API)

"TIMEBOXING" Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario.

PROTOTIPOS ITERATIVOS Y EVOLUCIONARIOS. Reunion JAD (Joint Application Development): Se renen los usuarios finales y los desarrolladores. Lluvia de ideas para obtener un borrador inicial de los requisitos. ITERAR HASTA ACABAR: Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales. Los diseadores revisan el prototipo. Los clientes prueban el prototipo, depuran los requisitos. Los clientes y desarrolladores se renen para revisar juntos el producto, refinar los requisitos y generar solicitudes de cambios. Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es necesario para cumplir el calendario. VENTAJAS 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Comprar puede ahorrar dinero en comparacin con construir. Los entregables pueden ser fcilmente trasladados a otra plataforma. El desarrollo se realiza a un nivel de abstraccin mayor. Visibilidad temprana. Mayor flexibilidad. Menor codificacin manual. Mayor involucramiento de los usuarios. Posiblemente menos fallas. Posiblemente menor costo. Ciclos de desarrollo ms pequeos. Interfaz grfica estndar.

DESVENTAJAS 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Comprar puede ser ms caro que construir. Costo de herramientas integradas y equipo necesario. Progreso ms difcil de medir. Menos eficiente. Menor precisin cientfica. Riesgo de revertirse a las prcticas sin control de antao. Ms fallas (por sndrome de codificar a lo bestia). Prototipos pueden no escalar, un problema maysculo. Funciones reducidas (por timeboxing). Dependencia en componentes de terceros: funcionalidad de ms o de menos, problemas legales.