Introduccin

SCRUM es una estrategia de gestin donde se aplican de manera regular un conjunto de prcticas para mejorar el trabajo colaborativo y obtener el mejor resultado posible en la gestin de un proyecto software Una metodologa gil es una metodologa efectiva par a modelar y documentar un proyecto de software, es una coleccin de valores principios y prcticas para modelar software que puede ser aplicado de manera simple y ligera. La metodologa gil tiene varios principios que la diferencian sobre las metodologas tradicionales reflejados en un Manifiesto que enuncia cuatro valores que son: 1. Los individuos y sus relaciones sobre las personas y los procesos .- con este principio se hace manifiesto el nfasis de esta metodologa sobre las personas , ya que ellas son de las que depende el xito o el fracaso de un proyecto, es a las que se les debe motivar 2. Un Software funcional, que trabaje sobre la documentacin ms completa .con este principio se trata de decir que lo ms importante es que el software trabaje , cumpla con las necesidades de negocio, no hacer de la documentacin un fin en s mismo, ya que esta es solo para dar soporte , no es el objetivo primario del desarrollo, existen situaciones en donde incluso la documentacin podra ser innecesaria, por ejemplo una pequea aplicacin emergente, que una vez pasada la emergencia , esta aplicacin desaparece, el cargar de documentacin de requerimientos, arquitectura , testeo etc. Podra considerarse de sobra, sin embargo eso no quiere decir que no es necesaria la documentacin, esta debe existir pero solo la suficiente 3. Colaboracin el cliente sobre el contrato de negocio .- Se trata de colaborar con el cliente el mayor tiempo no de luchar con el sobre un contracto minucioso , esto puede ser difcil ya que los clientes no estn acostumbrados, ellos estn acostumbrados a trabajar sobre un contrato con el que puedan defenderse si las cosas van mal 4. Ser capaz de responder a los cambios y no obsesionarse sobre el seguimiento de un plan .-Es tener la capacidad de adaptacin, no decir NO A LOS CAMBIOS, aceptar las sugerencias de los usuarios, sin por eso hacer un lado la planificacin

Contenido
Introduccin........................................................................................................ 1 Contenido............................................................................................................ 2 Metodologa Tradicional...................................................................................... 3 Rational Unified Process (RUP).........................................................................4 Fases: Las cuatro fases del ciclo de vida son:..........................................................5 Microsoft Solution Framework (MSF)................................................................5 Descripcin:.................................................................................................. 5 Todo proyecto es separado en cinco principales fases: ..............................6 Modelo de roles................................................................................................ 7 Ejemplo de metodologa MSF aplicada.........................................................8 Modelado gil.................................................................................................... 11 Objetivos: ...................................................................................................... 11 Criterios para un meldado gil.......................................................................12 Ejemplos de metodologas consideradas gil son.......................................12 El Scrum:........................................................................................................ 13 Proceso de trabajo del Scrum.....................................................................14 Aspectos de las Metodologas Agiles..............................................................14 Caractersticas:........................................................................................... 15 Criterios de referencia:............................................................................... 15 Fortalezas de SCRUM.................................................................................. 16 Requisitos para poder utilizar Scrum..........................................................16 Herramientas documentales - Historias de Usuario....................................17 Roles del Scrum.......................................................................................... 18 Implementacin de Scrum............................................................................. 19

Ventajas del Scrum........................................................................................ 21 Historias de Usuario....................................................................................... 21 Historias Tcnicas.......................................................................................... 22 Elaboracin del sprint (carrera corta)............................................................22 Sprint 0 y el DSDM......................................................................................... 22 Principios del DSDM.................................................................................... 23 Procesos del ciclo de desarrollo DSDM.......................................................23 Elaboracin de la pila de productos (back log)..............................................25 Conclusiones..................................................................................................... 26 Bibliografa........................................................................................................ 27

Metodologa Tradicional

Al inicio el desarrollo de software era artesanal en su totalidad, la fuerte necesidad de mejorar el proceso y llevar los proyectos a la meta deseada, tuvieron que importarse la concepcin y fundamentos de metodologas existentes en otras reas y adaptarlas al desarrollo de software. Esta nueva etapa de adaptacin contena el desarrollo dividido en etapas de manera secuencial que de algo mejoraba la necesidad latente en el campo del software. Entre las principales metodologas tradicionales tenemos los ya tan conocidos RUP y MSF entre otros, que centran su atencin en llevar una documentacin exhaustiva de todo el proyecto y centran su atencin en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto. Otra de las caractersticas importantes dentro de este enfoque tenemos los altos costos al implementar un cambio y al no ofrecer una buena solucin para proyectos donde el entorno es voltil. Las metodologas tradicionales (formales) se focalizan en documentacin, planificacin y procesos. (Plantillas, tcnicas de administracin, revisiones, etc.), a continuacin se detalla RUP uno de los mtodos ms usados dentro de los mtodos tradicionales

Rational Unified Process (RUP)

RUP es un proceso formal: Provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro de una organizacin de desarrollo. Su objetivo

es asegurar la produccin de software de alta calidad que satisfaga los requerimientos de los usuarios finales (respetando cronograma y presupuesto). Fue desarrollado por Rational Software, y est integrado con toda la suite Rational de herramientas. Puede ser adaptado y extendido para satisfacer las necesidades de la organizacin que lo adopte. (Customizacin). Es guiado por casos de uso y centrado en la arquitectura, y utiliza UML como lenguaje de notacin.

Fases:
Las cuatro fases del ciclo de vida son:
Concepcin Elaboracin Construccin Transicin

Ventajas Evaluacin en cada fase que permite cambios de objetivos Funciona bien en proyectos de innovacin. Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software. Seguimiento detallado en cada una de las fases.

Desventajas La evaluacin de riesgos es compleja Excesiva flexibilidad para algunos proyectos Estamos poniendo a nuestro cliente en una situacin que puede ser muy incmoda para l. Nuestro cliente deber ser capaz de describir y entender a un gran nivel de detalle para poder acordar un alcance del proyecto con l.

Microsoft Solution Framework (MSF)

Descripcin:
MSF es un compendio de las mejores prcticas en cuanto a administracin de proyectos se refiere. Ms que una metodologa rgida de administracin de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnologa de informacin.

Todo proyecto es separado en cinco principales fases:

Visin y Alcances:
La fase de visin y alcances trata uno de los requisitos ms fundamentales para el xito del proyecto, la unificacin del equipo detrs de una visin comn. El equipo debe tener una visin clara de lo que quisiera lograr para el cliente y ser capaz de indicarlo en trminos que motivarn a todo el equipo y al cliente. Se definen los lderes y responsables del proyecto, adicionalmente se identifican las metas y objetivos a alcanzar; estas ltimas se deben respetar durante la ejecucin del proyecto en su totalidad, y se realiza la evaluacin inicial de riesgos del proyecto.

Planificacin:
Es en esta fase es cuando la mayor parte de la planeacin para el proyecto es terminada. El equipo prepara las especificaciones funcionales, realiza el proceso de diseo de la solucin, y prepara los planes de trabajo, estimaciones de costos y cronogramas de los diferentes entregables del proyecto.

 Desarrollo:
Durante esta fase el equipo realice la mayor parte de la construccin de los componentes (tanto documentacin como cdigo), sin embargo, se puede realizar algn trabajo de desarrollo durante la etapa de estabilizacin en respuesta a los resultados de las pruebas. La infraestructura tambin es desarrollada durante esta fase.

Estabilizacin:
En esta fase se conducen pruebas sobre la solucin, las pruebas de esta etapa enfatizan el uso y operacin bajo condiciones realistas. El equipo se enfoca en priorizar y resolver errores y preparar la solucin para el lanzamiento.

Implantacin:
Durante esta fase el equipo implanta la tecnologa base y los componentes relacionados, estabiliza la instalacin, traspasa el proyecto al personal soporte y operaciones, y obtiene la aprobacin final del cliente.

Modelo de roles
El modelo de equipos de MSF (MSF team model) fue desarrollado para compensar algunas de las desventajas impuestas por las estructuras jerrquicas de los equipos en los proyectos tradicionales. Los equipos organizados bajo este modelo son pequeos y multidisciplinarios, en los cuales los miembros comparten responsabilidades y balancean las destrezas del equipo para mantenerse enfocados en el proyecto que estn desarrollando. Comparten una visin comn del proyecto y se enfocan en implementar la solucin, con altos estndares de calidad y deseos de aprender. El modelo de equipos de MSF tiene seis roles que corresponden a las metas principales de un proyecto y son responsables por las mismas. Cada rol puede estar compuestos por una o ms personas, la estructura circular del modelo, con valos del mismo tamao para todos los roles, muestra que no es un modelo jerrquico y que cada todos los roles son igualmente importantes en su aporte al proyecto. Aunque los roles pueden tener diferentes niveles de actividad durante las diversas etapas del proyecto, ninguno puede ser omitido.

La comunicacin se pone en el centro del crculo para mostrar que est integrada en la estructura y fluye en todas direcciones. El modelo apoya la comunicacin efectiva y es esencial para el funcionamiento del mismo

Ejemplo de metodologa MSF aplicada

Como ejemplo de una aplicacin de metodologa MSF a un proyecto, a continuacin se describe el contenido de cada una de las fases y, en la medida de lo posible, un detalle de acciones concretas y estimacin de carga de trabajo en trminos de jornadas, nmero de personas implicadas y perfil de las mismas. El proyecto ejemplo se trata de una implantacin de infraestructuras, en concreto, migracin a Windows 2000 de una red de servidores.

Fase 1 - Estrategia y alcance

En esta fase deberan tener lugar los siguientes trabajos: Elaboracin y aprobacin del Documento de Alcance y Estrategia definitivo: debe ser un documento de consenso con la participacin del mayor nmero de agentes implicados en el proyecto. En este documento quedarn definitivamente reflejadas las funcionalidades y servicios que, ineludiblemente, debe ofrecer la solucin a implantar. Formacin del Equipo de Trabajo y distribucin de competencias y responsabilidades: generalmente se definen como reas principales la de Diseo de Arquitectura, Pruebas de Laboratorio, Documentacin, Logstica y Coordinacin. Elaboracin del Plan de Trabajo: deben marcarse fechas y contenidos para esta fase y las siguientes. Los mecanismos y protocolos de intercambio de informacin y coordinacin deben quedar suficientemente bien establecidos y consensuados. Elaboracin de la matriz de Riesgos y Plan de Contingencia: los principales riesgos detectados deben tener un plan de mitigacin y actuacin y revisarse con periodicidad.

Para un proyecto de migracin a Windows 2000 podra estimarse que los trabajos indicados pueden requerir en torno a 20 jornadas de trabajo y la intervencin de un Consultor de Microsoft junto con el equipo de trabajo que formen El cliente y el Partner.

Fase 2 - Planificacin y Prueba de Concepto

Deben alcanzarse los siguientes objetivos e hitos: Documento de Planificacin y Diseo de Arquitectura: es el documento principal, donde se describen en detalle los aspectos funcionales y operativos de la nueva plataforma. La aprobacin de este documento es el

hito principal de esta fase, y supone la directriz ltima de todos los trabajos tcnicos, que, a partir de ese momento, deben ser consistentes con esta Gua. Si en el curso de las fases sucesivas fuera necesario revisar estos contenidos, se deber hacer por acuerdo y conocimiento de todo el equipo de trabajo y se llevar un registro de versiones que permita hacer un seguimiento adecuado de estas revisiones. Documento de Plan de Laboratorio - Prueba de Concepto: la descripcin del contenido del laboratorio de prueba de concepto, los diversos escenarios a simular, los criterios de validez, el control de incidencias y las mtricas de calidad son objetivos a cubrir en este documento. Es un documento dinmico, en el que se recoge la idea y la experiencia prctica al llevarla a cabo en entorno controlado y aislado. La etapa de prueba de laboratorio concluye cuando la maqueta ofrece todos los servicios y funciones descritos en el Documento de Alcance y Estrategia, y su grado de estabilidad y rendimiento es considerado como "suficiente".

Habitualmente, en las propuestas de preventa no se pueden indicar con precisin parmetros como el esfuerzo tcnico, tiempo o coste definitivo que puede suponer esta fase. De otras experiencias anteriores se puede obtener una relacin de trabajos slo a ttulo orientativo, y que debe ser revisado y acordado por todas las partes: El cmputo de jornadas para la relacin de actividades descritas (que como se observa slo recogen las relativas a la Planificacin y Diseo, y deja aparte las necesarias para elaborar el plan de Migracin), ofrecera este resultado: Jornadas totales: 80 (aprox. 4 meses) Jornadas / tcnico del PARTNER: 150 jornadas (2 personas) Jornadas / tcnico del CLIENTE: 110 jornadas (Max. 2 personas)

Fase 3 Estabilizacin
La solucin implantada en la maqueta se pasa a un entorno real de explotacin, restringido en nmero de usuarios y en condiciones tales que se pueda llevar un control efectivo de la situacin. Los hitos y objetivos fundamentales de esta fase son: Seleccin del entorno de prueba piloto: se acordar la composicin y ubicacin del conjunto de mquinas y usuarios que entrarn en la prueba. Esta seleccin se recomienda que se haga atendiendo a la mayor variedad posible de casos, de manera que puedan aflorar el mximo de incidentes potenciales en el menor tiempo posible. La dimensin de la muestra tiene

tambin que calcularse, sin perder de vista que la prueba piloto no es el despliegue propiamente, sino una fase de observacin en la que es absolutamente crtico establecer unos cauces efectivos de tratamiento de los errores. Gestin de Incidencias: aunque esta labor se habr iniciado en la fase anterior, el xito de la prueba piloto depender de que se forme un sistema de recogida de incidentes (helpdesk o similar), de atencin al usuario (formacin, consultas) y de resolucin de problemas y documentacin de los mismos (versionado de la plataforma). Revisin de la documentacin final de Arquitectura: el documento de Planificacin y Diseo de Arquitectura se puede ver alterado parcialmente como resultado de esta fase. El documento final, aprobado por consenso, supone el principal documento del Proyecto y la culminacin de los trabajos de diseo, al menos en sus lneas principales. Este documento se considerar definitivo cuando la solucin puesta en marcha se muestre estable y el nmero de incidencias graves (de intervencin o de resolucin) sea nulo y la cantidad de las consideradas leves quede por debajo de un lmite establecido en las Mtricas de Calidad. Elaboracin de la documentacin de Formacin y Operaciones: con vistas al soporte post proyecto y los programas de formacin a usuarios y administradores, en esta fase deben elaborarse las Guas de Usuario, de Administracin, las "paso-a-paso", y otros cuyos contenidos deben acordarse previamente. Elaboracin del Plan de Despliegue: se debe consensuar la fecha de finalizacin de la fase Piloto, y las condiciones de calidad que debe cumplir la solucin final para iniciar el despliegue. En el Plan deben identificarse las fases, estrategia de implantacin, fechas, tareas a realizar, procedimientos de validacin y mtodo de control de incidencias. Elaboracin del Plan de Formacin: con anterioridad al despliegue definitivo, debe haberse aprobado el Plan de Formacin orientado a usuarios finales y administradores, y debe hacerse compatible con los ritmos acordados en el Plan de Despliegue. El tiempo necesario para abordar esta fase es variable y depende en parte de factores ajenos a la complejidad de la propia solucin, como es la adecuada seleccin del entorno de prueba y el momento del ao en que tenga lugar (evitando que coincida con periodos de vacaciones o puntas de trabajo crticas como Fin de Ao). En proyectos de similar envergadura se ha llegado al momento "Error Free Versin" en 30 jornadas de trabajo (aproximadamente mes y medio) con una muestra de 50 usuarios.

Fase 4 Despliegue
Se llevarn a cabo en esta fase los planes diseados en la anterior, principalmente el de despliegue y el de formacin. Los principales trabajos e hitos a conseguir son, en este caso, adems de los obvios (implantacin de la plataforma, puesta en

servicio de todas las funciones, formacin a los usuarios y administradores), los siguientes: Continuacin con las labores de recepcin de incidencias, clasificacin, tratamiento, resolucin y distribucin de faxes o intervencin on-site. Registro de mejoras y sugerencias, funcionalidades no cubiertas y novedades a incorporar en sucesivas versiones de la plataforma, incluyendo mejoras aportadas por los fabricantes de software (nuevas versiones o Service Packs, por ejemplo) Revisin de las Guas y manuales de usuario, rectificacin de errores y obtencin de los documentos de formacin definitivos. Entrega de los documentos definitivos acordados como "deliverables" en la fase de Vision Scope. Revisin (si procede) de la matriz de riesgos, las mtricas de calidad y establecimiento de los estndares de calidad y SLA definitivos. Finalmente, entrega del Proyecto y cierre del mismo, con o sin apertura de nuevo proyecto en base a la informacin y experiencia obtenidas. La duracin fase de despliegue, puesto que debe planificarse, no puede establecerse a priori. Depende de numerosos factores externos al propio proyecto (incluyendo factores de oportunidad poltica o de negocio) que pueden retardar o acelerar la conclusin. La experiencia demuestra que no hay una relacin directa entre nmero de mquinas y tiempo necesario para el despliegue. Los factores ms relevantes en el clculo suelen ser la dispersin o concentracin geogrfica, la complejidad del proceso de migracin, el grado de automatizacin alcanzado, la experiencia y nivel de los tcnicos que realizan la operacin y condicionantes de calendario, a menudo con restricciones no tcnicas, sino de otros tipos (las fechas-objetivo suelen marcarse por criterios de oportunidad de negocio).

Modelado gil
En el modelado gil se trata de hallar el equilibrio ente exceso de modelado y carencia de este, se intenta que el modelado no se convierta en una carga, que sea suficiente para documentar el sistema, se pueden aprovechar el modelado de un proyecto RUP , esto es la documentacin UML, se intenta promover procesos ligeros.

Objetivos:

Promover y definir un grupo de valores, prcticas y principios que ayudan a producir los modelos adecuados Orientacin de cmo aplicar el modelado de proyectos agiles Orientacin de cmo aplicar el modelado gil a otro tipo de procesos o metodologas (por ejemplo RUP)

Criterios para un meldado gil

Un modelado gil debe seguir estos criterios: Deben dar valor positivo, deben servir realmente de ayuda para dar un software funcional Deben solo cumplir su propsito y no ms , esto es dar a entenderse solo con los suficiente, no usar herramientas pesadas, por ejemplo las ofrecidas por Rational Rose, no ser tan estricto Debe ser comprensible para su audiencia, no para todos, el nivel de detalle debe ser comprensible de acuerdo a la audiencia a la que se le presente Deben ser lo suficientemente precisos Deben ser lo suficientemente consistentes, modelos ms detallados que otros pueden causar confusin a las audiencias a las que van dirigidos. Deben ser lo suficientemente detallados, muchos detalles pueden ser irrelevante de acuerdo a quien se dirige el modelo. Tan simples como sea posible.

La documentacin de las metodologas agiles debe ser tan simple como sea posible y de acuerdo a la audiencia a la que vaya dirigida, no es un modelado tan prescriptivo, no da recetas de diseo, no crea documentacin innecesaria, se puede usar cualquier tipo de diseo o documentacin que nos ayude, puede haber procesos que sea difcil capturarlos con los diagramas conocidos, pero si otros, una metodologa gil podra asociarlos.

Ejemplos de metodologas consideradas gil son

Programacin Extrema Scrum MSF 4.0 Microsoft RAD * Cristal

RUP Agil Otras ..

En este documento hablaremos de las primeras cuatro metodologas, estas metodologas pueden combinarse, por ejemplo Programacin Extrema y Scrum, RAD puede integrarse con otras etc.

El Scrum:
Naturalmente Scrum se enfoca en la construccin de proyectos exitosos en la organizacin, sin mayores cambios dentro de los 30 das de cada carrera (ciclo) construyendo una funcionalidad completa y demostrada del producto al final de cada carrera, Scrum puede implementarse al principio o a la mitad de un proyecto de desarrollo Scrum es un conjunto de prcticas interrelacionadas y reglas que optimizan el entorno de desarrollo, reducen la sobrecarga organizativa, y sincronizan los requisitos del mercado con los prototipos de cada iteracin. Basado en una teora de control de procesos moderna, Scrum nos da el mejor software posible teniendo en cuenta los recursos disponibles, una calidad aceptable, con las fechas requeridas de liberacin. Una funcionalidad del producto til es dada cada treinta das como requisito, la arquitectura, y el diseo aparecen, incluso cuando la tecnologa es inestable aun Scrum como lo muestra la ilustracin se basa en el equipo, en reuniones diarias presididas por el Scrum mster para establecer el estado del proyecto, y en la salida cada 30 das de caractersticas del proyecto finalizadas y listas para trabajar, el corazn del Scrum es la iteracin, que en cada iteracin presenta una mejora del funcionamiento del producto final, en cada iteracin se evala la tecnologa y capacidades requeridas, diariamente se pueden modificar el enfoque si se encuentran nuevas dificultades y tratar de remediarlas, el corazn del Scrum es la productividad

Proceso de trabajo del Scrum

Las ms de cincuenta organizaciones que han usado el Scrum en miles de proyectos han tenido siempre mejoras en la productividad, las practicas existentes son envueltas y mejoradas necesariamente y as dar al usuario o al mercado los incrementos del producto Scrum ha sido usado producir productos financieros, productos de Internet. En cada ejemplo, la organizacin era incapaz producir productos utilizables en un perodo de tiempo largo, as que ingenieros, direccin, e inversionistas estaban profundamente preocupados. Scrum saco del atolladero y empez una entrega de producto incremental, a menudo con un primer producto de utilizable en el primer trimestre Scrum aplicado para el desarrollo de productos tuvo su primer referencia en El nuevo, nuevo producto para el desarrollo de juegos (Harvard Business Review 86116:137-146, 1986) y posteriormente aclarada "The Knowledge Creating Company" ambos por Ikujiro Nonaka y Hirotaka Takeuchi (Oxford University Press, 1995. Basados en estas ideas y en la investigacin de teora de procesos y en colaboracin con DuPont Advanced Research Facility, Scrum fue formulado por primera vez y presentado al OMG ( Object Management Group) en 1995.

Aspectos de las Metodologas Agiles

Caractersticas:
Metodologa de trabajo gil Diseada para acortar el ciclo de desarrollo Conseguir una mejor aproximacin entre las funcionalidades del software y los requerimientos del cliente Evitar la burocracia innecesaria Mayor versatilidad frente a los cambios Comenzar el trabajo lo ms rpidamente posible Manejo ms eficiente de los requerimientos cambiantes en un proyecto Mejorar la comunicacin entre el cliente y el equipo desarrollador

Criterios de referencia:
Aumento de la productividad y de la comunicacin directa entre el cliente y el equipo desarrollador. Recomendado para equipos de trabajo pequeos (mx. 8 personas) Desarrollo incremental e iterativo produccin frecuente de prototipos para evaluacin del cliente Manejo ms eficiente de los requerimientos cambiantes en un proyecto mejorando la versatilidad frente a los cambios. SCRUM no dice Qu hacer sino Cmo hay que hacer las cosas

Fortalezas de SCRUM
Gestin regular de las expectativas del cliente Resultados market) anticipados (time to Flexibilidad y adaptacin Retorno de inversin (ROI) Mitigacin de riesgos Productividad de calidad Alineamiento entre cliente y equipo Equipo motivado Priorizacin de requisitos Demostracin del proyecto en cada Sprint Priorizacin de requisitos por valor/coste Re planificacin en el inicio de cada iteracin Priorizacin de requisitos Desarrollo iterativo e incremental Mejora continua Comunicacin diaria del equipo TimeBoxing Equipo multidisciplinar Estimacin de esfuerzo conjunta Compromiso del equipo Demostracin de resultados

Reuniones en cada itinerario (Sprint) Equipo autosugestionado Reuniones diarias y en cada Sprint

Requisitos para poder utilizar Scrum

Los siguientes puntos son de especial importancia para la implantacin de una gestin gil de proyectos como Scrum:

Cultura de empresa

basada en trabajo en equipo, delegacin, creatividad y

mejora continua. .- Scrum exige del cliente una alta implicacin y una dedicacin regular:.
Compromiso del cliente

de la organizacin para resolver problemas cambios organizativos, formando equipos autogestionados y multidisciplinares y fomentando una cultura de gestin basada en la colaboracin y en la facilitacin.
Compromiso de la Direccin

endmicos

realizar

Compromiso conjunto y colaboracin de los miembros del equipo.

.- las dos partes asumen que habr cambios para que el cliente obtenga lo que realmente necesita, no lo que est escrito en un documento
Relacin entre proveedor y cliente

en el proyecto. Para poder utilizar Scrum se debe poder ir incorporando requisitos de manera incremental en el producto del proyecto
Facilidad para realizar cambios

entre 5 y 9 personas (con tcnicas de colaboracin entre equipos que trabajan en el mismo proyecto).
Tamao de cada equipo

Equipo trabajando en un mismo espacio comn para maximizar la comunicacin. Dedicacin del equipo a tiempo completo.
Estabilidad de los miembros del equipo

Herramientas documentales - Historias de Usuario

En la programacin XP, suele utilizarse algo similar a lo utilizado en la Metodologa RUP, esto es los casos de uso, pero en esta Metodologa, el concepto cambia, ya no es un formato preciso, es ms anecdtico, se trata de referir la manera en que los usuarios pueden usar el sistema, las historias de usuario son escritas para los usuarios no para el equipo de desarrollo Las historias de Usuario no son requerimientos detallados, pueden obtenerse durante las iteraciones, como una experiencia de uso del sistema resultado de una iteracin, deben usar la terminologa del usuario , un lenguaje de negocios , no la de un desarrollador, deben ser cortas un ejemplo ser algo tan simple como esto que refleja esta Story Card (que es donde se pueden apuntar aspectos de historias de usuario) y dice : Un usuario puede mandar su resumen a travs de una pgina Web

Ms importante que una Story Card, que es la parte visible de la historia, son las conversaciones entre clientes y desarrolladores Una Historia de Usuario describe una funcionalidad, un propsito de un sistema o software, son tradicionalmente escritas a mano y se componen de tres aspectos 1. Uno que describa la historia y como planeacin y recordatorio 2. Conversaciones que puedan servir para reflejar detalles de la historia 3. Test que puedan documentar cuando una historia ha sido completada Puede tenerse un proyecto inicial de historias pero pueden surgir otras durante todo el proyecto, pueden apilarse historias cortas durante una iteracin para su atencin, pueden priorizarse en pilas para su desarrollo en cada iteracin

Roles del Scrum

Scrum implementa sus procesos a travs de tres roles considerados fundamentales, todas las responsabilidades de direccin son divididas en estos roles

El propietario del producto

Este rol, representa a la persona interesada en el estado del proyecto y el sistema resultante, este es el que se enfoca en que se retorne la inversin (ROI), el back log provedo a este rol representa una herramienta poderosa al proyecto, este lo usa para dar a los requerimientos la ms alta prioridad, estos mismos son el ms alto valor del negocio, este rol conoce cuales son las funcionalidades requeridas para resolver la problemtica del negocio Los clientes pueden estables los requerimientos que optimizan el ROI al inicio del proyecto pero ellos no pueden establecer con sus estimados de manera precisa los esfuerzos implicados durante el desarrollo del proyecto, la persona en este Rol es la que ajusta el ROI ms frecuentemente y por eso debe diferencirsele a la persona cliente

El Scrum mster
Es el responsable de los procesos del Scrum, de que finalic exitosamente, el que ensea el Scrum a todos los involucrados, el encargado de organizar e introducir la cultura del Scrum, descubrir los beneficios esperados y el que se

asegura de que se sigan las reglas y prcticas del Scrum. Tambin puede ayudar al equipo a decidir cules de los elementos (backlog) deben desarrollarse en cada iteracin (sprint)

El equipo
Es el responsable del desarrollo, deben ser auto-dirigidos, autoorganizados, son los que sacan las caractersticas deseadas (el back log) en cada iteracin, y son los responsables de estos mismos. Es el equipo el que decide que parte de la funcionalidad (back log) debe sacarse en cada incremento

Implementacin de Scrum
1.

Comenzar el proceso de Scrum

Debemos seleccionar al equipo, existe una fbula que ejemplifica el significado del proceso del Scrum: Un cerdo y una gallina se encuentran en la calle. La gallina le dice al cerdo: por qu no abrimos un restaurante?" El cerdo le dice: "Buena idea, cmo se llamara el restaurante?" La gallina contesta: "Por qu no lo llamamos "Huevos con jamn?" "Lo siento pero no", dice el cerdo, "Yo estara comprometido pero t solamente estaras involucrada Segn esta fbula el equipo consiste de cerdos (gente a la que se le asigna el trabajo) y los pollos (las personas interesadas pero que no trabajan directamente en el), identificando los cerdos nosotros podemos componer el equipo de trabajo Recomendaciones No ms de 6 9 miembros por equipo Si hay ms miembros , romperlos en grupos Cada grupo enfocado en una sola rea de trabajo Todo el staff trabajara en esta rea

2.

Nombrar al Scrum Mster

El Scrum mster es la persona que conduce las reuniones diarias, mide empricamente los progresos, toma decisiones y resuelve los problemas de lentitud o trabajo parado, un ingeniero o un director de marketing puede estar en esta rea, es la persona que hace las preguntas referidas en el diagrama de proceso del Scrum, que se hizo desde la reunin pasada, que problemas ha habido y que espera para la prxima reunin

3.

Identificar el acumulado
Acumulado (Back log) es todo el trabajo pendiente para un rea del producto, bien definido en sus trminos Listar todo el trabajo a ser realizado Agrupar todo el trabajo que puede hacerse en los 30 das En reas no bien definidas o cambiantes establecer un incremento de horizonte conocido Listar todo el trabajo a ser hecho Solo una persona encargada de realizar la priorizacin de trabajos El equipo elige el acumulado para el sprint - periodo de 30 das Periodo o sprint es el lapso que se da el Scrum para realizar un incremento este debe ser de 30 das Este acumulado se firma por los miembros del equipo Solo este acumulado se trabaja durante el periodo

4.

Establecer y conducir la reunin diaria del Scrum

Diariamente se hace una reunin para checar el status del trabajo, donde el equipo informa de las actualizaciones, la reunin se enfoca en el trabajo que se est realizando Recomendaciones Mismo tiempo y lugar

Evitar siempre buscar un lugar diario Evitar que los miembros del equipo se pregunten siempre donde y cuando son Todos los pollos deben saber dnde y cundo son No debe durar ms de treinta minutos El Scrum mster debe preguntar las 3 cuestiones bsicas ya dichas Scrum mster es el responsable de tomar decisiones y resolver los problemas de trabajo Todas las discusiones a las tres cuestiones postergar a posteriores reuniones

Ventajas del Scrum

Se enfoca en equipos de trabajo Hay una comunicacin diaria Ofrece una direccin basada en experiencia y de bajo nivel Hace los obstculos visibles Se toman decisiones y se resuelven problemas en tiempo real

Historias de Usuario
Bsicamente es la misma referencia que en los proyectos XP, esto es deben ser breves y describir una funcionalidad del negocio que tenga valor, es una manera de describir un requerimiento funcional en la metodologa gil al igual que los casos de uso en las metodologas tradicionales

Se pueden obtener de entrevistas, de reuniones de lluvia de ideas etc., regularmente se anotan en una simple tarjeta de papel, y se colocan en un tablero (pizarrn) A estas historias se les da una priorizacin de acuerdo a la importancia, , y al alcance proporcionados por el dueo del producto, a la estimacin en tiempo , horas de trabajo por persona esta cantidad es dada por equipo de trabajo.

Historias Tcnicas
Las historia tcnicas se refieren a aquellas historias que no describen una caracterstica del negocio o que aparentemente no dan valor al negocio, a estas actividades, como instalar un servidor, documentar el diseo general, optimizacin y limpieza del cdigo, etc. Estas historias se intentan evitar, una manera es tratando de convertirlas en historias normales con valor de negocio medible, no siempre es posible, el intentar priorizarlas junto con el resto de las historias es difcil porque el dueo del producto no las reconoce, lo que se puede hacer es mantener una lista aparte, el dueo del producto puede verla pero no modificarla, las actividades para estas historias se acomodan segn convenga en la agenda del sprint Se puede o no mantener informado al dueo del producto, aunque lo mejor es siempre mantenerlo informado

Elaboracin del sprint (carrera corta)

En base a las historias de usuario, las actividades de ingeniera (historias tcnicas) se definen las actividades a realizar para cada una La elaboracin del sprint consiste en seleccionar en base a la importancia de negocio y a la estimacin de esfuerzo de ingeniera, las ms adecuadas y comprometerse a solo elaborar esas durante el sprint

Sprint 0 y el DSDM
Se sugiere hacer un sprint 0, que es donde se hacen los anlisis y diseos previos, es un sprint para trazar la ruta del proyecto. Esto se hace para poder ir de acuerdo al modelo de procesos DSDM dado por el DSDM Consortium

DSDM es el acrnimo que da nombre a un modelo de procesos para el desarrollo de sistemas de software, desarrollado y concebido por el denominado DSDM Consortium, que se fund en Inglaterra en 1994, y que actualmente tiene presencia en Inglaterra, EE.UU. Benelux, Dinamarca, Francia y Suiza, Es un modelo que estuvo representado en la firma del Manifiesto gil. En 2001, ao del Manifiesto gil, DSDM public la versin 4.1 de su modelo, y se consider una metodologa gil; y aunque mantuvo las siglas, cambi la denominacin original (Dynamis Systems Development Method) por Framework for Business Centred Development

Principios del DSDM

En su versin actual (4.2) el marco de procesos DSDM se basa en 9 principios. La implicacin activa de los usuarios es imprescindible. Los miembros de los equipos de desarrollo DSDM deben tener la autonoma y potestad necesarias para tomar decisiones. Entrega frecuente de incrementos operativos del producto. El principal criterio de prioridad, desarrollo y validacin de las entregas incrementales es el objetivo y la salud del negocio. El desarrollo iterativo o incremental hace posible obtener la solucin ms adecuada a las necesidades del negocio. Todos los cambios realizados en el desarrollo son reversibles. Los requisitos se establecen a un nivel general Las pruebas forman parte del ciclo de desarrollo Es imprescindible trabajar con espritu de colaboracin con todos los agentes implicados en el sistema que se desarrolla.

Procesos del ciclo de desarrollo DSDM

El ciclo de desarrollo de DSDM est compuesto de 5 fases, precedidas de un preproyecto y un post-proyecto. 1. Pre-proyecto

2. Estudio de viabilidad 3. Estudio de negocio 4. Iteracin de modelado funcional 5. Iteracin de diseo y desarrollo 6. Implementacin 7. Post-desarrollo

Observando el diseo del modelo de gestin gil DSDM ( ) vemos que se incluye antes de comenzar con las iteraciones (funcional - Diseo - e implementacin), un punto de inicio representado por un tringulo de su diagrama, en este tringulo vemos actividades que son: Pre-proyecto Estudio de viabilidad Estudio de negocio

En ellos se debe realizar: Anlisis gil de viabilidad sobre las cuestiones: El sistema propuesto es tcnicamente posible? Impacto en el proceso de negocio Es DSDM el mejor ciclo de desarrollo para la solucin del cliente? Anlisis previo de los riesgos del proyecto

Y en el "estudio de negocio" : comprobar que el cliente dispone de una visin vlida de lo que desea. Definir y validar la definicin de alto nivel de la arquitectura del sistema. y generar un plan de desarrollo con las lneas de actividades en las iteraciones del modelo, del diseo y de la implementacin. Este concepto de "validacin inicial del proyecto" sera el equivalente al que la ingeniera del software ortodoxa cubre con el proceso de Adquisicin, y que tiene como finalidad comprobar que todas las luces estn verdes, antes de comenzar, aunque la metodologa gil pura no contiene estas fases el sprint 0 es usado para no romper la filosofa de la metodologa

Elaboracin de la pila de productos (back log)

El back log de productos es el corazn del scrum, es una lista priorizada de requisitos funcionales que pueden ser historias de usuario, cosas que el cliente quiere con su terminologa, esta lista puede contener varios campos para cada tem o producto, estos seran ID el cual es el identificador nico del producto, su nombre, la importancia que le da el dueo del producto, la estimacin en horas, como se puede probar que la funcionalidad est cubierta y nota, se pueden agregar ms campos, categora de actividad (anlisis, diseo etc.), usuario de la actividad etc., regularmente con los primeros seis est bien

En base a las historias reunidas se seleccionan conforme a varios criterios (alcance, estimacin, importancia) las que van a ir en el sprint, en base a estas se definen las actividades que daran cumplimiento a esas historias, se descomponen en sub-actividades etc.

Se pueden elaborar tarjetas de producto en papel, comnmente se ordenan en un tablero y se van marcando las que se van cumpliendo El tablero nos indica que tareas estn en el sprint, cuales se estn realizando y cuales ya estn hechas.

Ejemplo de tablero de Sprint

Conclusiones

El retrasar las decisiones en un proyecto de software permite potenciar el valor del producto tanto para el cliente como al equipo o empresa que desarrolla Para que un grupo de desarrollo adopte una metodologa gil debe poseer experiencia trabajando con metodologas tradicionales, ya que la experiencia es la que predomina en los mementos cruciales del proyecto, adems debe tener la capacidad de ser equipos auto-gestionados, altamente motivados y con gran innovacin Las metodologas giles permiten disminuir costos y brindar flexibilidad a los proyectos de software donde la incertidumbre est presente El uso de metodologas tradicionales es esencial al inicio en un equipo de desarrollo de software Las metodologas giles se deberan aplicar en proyectos donde exista mucha incertidumbre donde el entorno es voltil, donde los requisitos no se conocen con exactitud, mientras que las metodologas tradicionales obligan al cliente a tomar las decisiones al inicio del proyecto.

Bibliografa
Metodologas giles: La ventaja competitiva de estar preparado para tomar decisiones lo ms tarde posible y cambiarlas en cualquier momento. (En lnea), Disponible en: www.spinec.org/wp-content/metodologiasagiles_01.pdf Metodologas giles (En lnea) ,Disponible en: http://www.agile-spain.com ICONIX (En lnea), Disponible en: www.spinec.org/wp-content/ICONIX.pdf Extreme Programming Refactored: The Case Against Stephens and DOUG Rosenberg, Disponible en Formato chm Introduccin a Iconix (En lnea),
http://www.informit.com/articles/article.asp?p=167902&rl=1

XP,

MATT en:

Disponible