Introducción“SCRUM es una estrategia de gestión donde se aplican de manera regular un conjunto de prácticas para mejorar el trabajo colaborativo y obtener el mejor resultado posible en la gestión de un proyecto software”

Una metodología Ágil es una metodología efectiva par a modelar y documentar un proyecto de software, es una colección de valores principios y prácticas para modelar software que puede ser aplicado de manera simple y ligera.

La metodología Ágil tiene varios principios que la diferencian sobre las metodologías 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 metodología 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 documentación más completa .- con este principio se trata de decir que lo más importante es que el software trabaje , cumpla con las necesidades de negocio, no hacer de la documentación 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 documentación podría ser innecesaria, por ejemplo una pequeña aplicación emergente, que una vez pasada la emergencia , esta aplicación desaparece, el cargar de documentación de requerimientos, arquitectura , testeo etc. Podría considerarse de sobra, sin embargo eso no quiere decir que no es necesaria la documentación, esta debe existir pero solo la suficiente

3. Colaboración 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 difícil ya que los clientes no están acostumbrados, ellos están 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 adaptación, no decir NO A LOS CAMBIOS, aceptar las sugerencias de los usuarios, sin por eso hacer un lado la planificación

ContenidoIntroducción.......................................................................................................................................1

Metodología Tradicional....................................................................................................................5

Rational Unified Process (RUP).......................................................................................................5

Fases: Las cuatro fases del ciclo de vida son:......................................................................6

Microsoft Solution Framework (MSF)............................................................................................7

Descripción:................................................................................................................................7

Todo proyecto es separado en cinco principales fases:..............................................................7

Modelo de roles.............................................................................................................................8

Ejemplo de metodología MSF aplicada......................................................................................9

Modelado Ágil..................................................................................................................................13

Objetivos:.....................................................................................................................................13

Criterios para un meldado Ágil.....................................................................................................13

Ejemplos de metodologías consideradas Ágil son....................................................................14

El Scrum:......................................................................................................................................14

Proceso de trabajo del Scrum...................................................................................................15

Aspectos de las Metodologías Agiles............................................................................................16

Características:.........................................................................................................................16

Criterios de referencia:.............................................................................................................16

Fortalezas de SCRUM...............................................................................................................17

Requisitos para poder utilizar Scrum........................................................................................17

Herramientas documentales - Historias de Usuario.................................................................18

Roles del Scrum........................................................................................................................19

Implementación de Scrum...........................................................................................................20

1. Comenzar el proceso de Scrum........................................................................................20

2. Nombrar al Scrum Máster................................................................................................20

3. Identificar el acumulado..................................................................................................21

4. Establecer y conducir la reunión diaria del Scrum............................................................21

Ventajas del Scrum.......................................................................................................................22

Historias de Usuario.....................................................................................................................22

Historias Técnicas.........................................................................................................................22

Elaboración del sprint (carrera corta)...........................................................................................23

Sprint 0 y el DSDM........................................................................................................................23

Principios del DSDM.................................................................................................................23

Procesos del ciclo de desarrollo DSDM....................................................................................24

Elaboración de la pila de productos (back log).............................................................................25

Conclusiones....................................................................................................................................27

Bibliografía.......................................................................................................................................27

Metodología 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 concepción y fundamentos de metodologías existentes en otras áreas y adaptarlas al desarrollo de software. Esta nueva etapa de adaptación contenía el desarrollo dividido en etapas de manera secuencial que de algo mejoraba la necesidad latente en el campo del software.

Entre las principales metodologías tradicionales tenemos los ya tan conocidos RUP y MSF entre otros, que centran su atención en llevar una documentación exhaustiva de todo el proyecto y centran su atención en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto.

Otra de las características importantes dentro de este enfoque tenemos los altos costos al implementar un cambio y al no ofrecer una buena solución para proyectos donde el entorno es volátil.

Las metodologías tradicionales (formales) se focalizan en documentación, planificación y procesos. (Plantillas, técnicas de administración, revisiones, etc.), a continuación se detalla RUP uno de los métodos más usados dentro de los métodos tradicionales

Rational Unified Process (RUP)

RUP es un proceso formal: Provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es asegurar la producción 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 organización que lo adopte. (Customización). Es guiado por casos de uso y centrado en la arquitectura, y utiliza UML como lenguaje de notación.

Fases:Las cuatro fases del ciclo de vida son:

Concepción Elaboración Construcción Transición

Ventajas

Evaluación en cada fase que permite cambios de objetivos Funciona bien en proyectos de innovación. 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 evaluación de riesgos es compleja Excesiva flexibilidad para algunos proyectos Estamos poniendo a nuestro cliente en una situación que puede ser muy

incómoda 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)

Descripción:MSF es un compendio de las mejores prácticas en cuanto a administración de proyectos se refiere. Más que una metodología rígida de administración de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnología de información.

Todo proyecto es separado en cinco principales fases:

Visión y Alcances:

La fase de visión y alcances trata uno de los requisitos más fundamentales para el éxito del proyecto, la unificación del equipo detrás de una visión común. El equipo debe tener una visión clara de lo que quisiera lograr para el cliente y ser capaz de indicarlo en términos que motivarán a todo el equipo y al cliente. Se definen los líderes y responsables del proyecto, adicionalmente se identifican las metas y objetivos a alcanzar; estas últimas se deben respetar durante la ejecución del proyecto en su totalidad, y se realiza la evaluación inicial de riesgos del proyecto.

Planificación:

Es en esta fase es cuando la mayor parte de la planeación para el proyecto es terminada. El equipo prepara las especificaciones funcionales, realiza el proceso de diseño de la solución, 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 construcción de los componentes (tanto documentación como código), sin embargo, se puede realizar algún trabajo de desarrollo durante la etapa de estabilización en respuesta a los resultados de las pruebas. La infraestructura también es desarrollada durante esta fase.

Estabilización:

En esta fase se conducen pruebas sobre la solución, las pruebas de esta etapa enfatizan el uso y operación bajo condiciones realistas. El equipo se enfoca en priorizar y resolver errores y preparar la solución para el lanzamiento.

Implantación:

Durante esta fase el equipo implanta la tecnología base y los componentes relacionados, estabiliza la instalación, traspasa el proyecto al personal soporte y operaciones, y obtiene la aprobación 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 jerárquicas de los equipos en los proyectos tradicionales.

Los equipos organizados bajo este modelo son pequeños y multidisciplinarios, en los cuales los miembros comparten responsabilidades y balancean las destrezas del equipo para mantenerse enfocados en el proyecto que están desarrollando. Comparten una visión común del proyecto y se enfocan en implementar la solución, con altos estándares 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 más personas, la estructura circular del modelo, con óvalos del mismo tamaño para todos los roles, muestra que no es un modelo jerárquico 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 comunicación se pone en el centro del círculo para mostrar que está integrada en la estructura y fluye en todas direcciones. El modelo apoya la comunicación efectiva y es esencial para el funcionamiento del mismo

Ejemplo de metodología MSF aplicadaComo ejemplo de una aplicación de metodología MSF a un proyecto, a continuación se describe el contenido de cada una de las fases y, en la medida de

lo posible, un detalle de acciones concretas y estimación de carga de trabajo en términos de jornadas, número de personas implicadas y perfil de las mismas. El proyecto ejemplo se trata de una implantación de infraestructuras, en concreto, migración a Windows 2000 de una red de servidores.

Fase 1 - Estrategia y alcance

En esta fase deberían tener lugar los siguientes trabajos:

Elaboración y aprobación del Documento de Alcance y Estrategia definitivo: debe ser un documento de consenso con la participación del mayor número de agentes implicados en el proyecto. En este documento quedarán definitivamente reflejadas las funcionalidades y servicios que, ineludiblemente, debe ofrecer la solución a implantar.

Formación del Equipo de Trabajo y distribución de competencias y responsabilidades: generalmente se definen como áreas principales la de Diseño de Arquitectura, Pruebas de Laboratorio, Documentación, Logística y Coordinación.

Elaboración del Plan de Trabajo: deben marcarse fechas y contenidos para esta fase y las siguientes. Los mecanismos y protocolos de intercambio de información y coordinación deben quedar suficientemente bien establecidos y consensuados.

Elaboración de la matriz de Riesgos y Plan de Contingencia: los principales riesgos detectados deben tener un plan de mitigación y actuación y revisarse con periodicidad.

Para un proyecto de migración a Windows 2000 podría estimarse que los trabajos indicados pueden requerir en torno a 20 jornadas de trabajo y la intervención de un Consultor de Microsoft junto con el equipo de trabajo que formen El cliente y el Partner.

Fase 2 - Planificación y Prueba de Concepto

Deben alcanzarse los siguientes objetivos e hitos:

Documento de Planificación y Diseño de Arquitectura: es el documento principal, donde se describen en detalle los aspectos funcionales y operativos de la nueva plataforma. La aprobación de este documento es el hito principal de esta fase, y supone la directriz última de todos los trabajos técnicos, que, a partir de ese momento, deben ser consistentes con esta Guía. 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 descripción del contenido del laboratorio de prueba de concepto, los diversos escenarios a simular, los criterios de validez, el control de

incidencias y las métricas de calidad son objetivos a cubrir en este documento. Es un documento dinámico, en el que se recoge la idea y la experiencia práctica 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 precisión parámetros como el esfuerzo técnico, tiempo o coste definitivo que puede suponer esta fase. De otras experiencias anteriores se puede obtener una relación de trabajos sólo a título orientativo, y que debe ser revisado y acordado por todas las partes:

El cómputo de jornadas para la relación de actividades descritas (que como se observa sólo recogen las relativas a la Planificación y Diseño, y deja aparte las necesarias para elaborar el plan de Migración), ofrecería este resultado: Jornadas totales: 80 (aprox. 4 meses) Jornadas / técnico del PARTNER: 150 jornadas (2 personas) Jornadas / técnico del CLIENTE: 110 jornadas (Max. 2 personas)

Fase 3 – Estabilización

La solución implantada en la maqueta se pasa a un entorno real de explotación, restringido en número de usuarios y en condiciones tales que se pueda llevar un control efectivo de la situación. Los hitos y objetivos fundamentales de esta fase son:

Selección del entorno de prueba piloto: se acordará la composición y ubicación del conjunto de máquinas y usuarios que entrarán en la prueba. Esta selección se recomienda que se haga atendiendo a la mayor variedad posible de casos, de manera que puedan aflorar el máximo de incidentes potenciales en el menor tiempo posible. La dimensión de la muestra tiene también que calcularse, sin perder de vista que la prueba piloto no es el despliegue propiamente, sino una fase de observación en la que es absolutamente crítico establecer unos cauces efectivos de tratamiento de los errores.

Gestión 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 atención al usuario (formación, consultas) y de resolución de problemas y documentación de los mismos (versionado de la plataforma).

Revisión de la documentación final de Arquitectura: el documento de Planificación y Diseño 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 culminación de los trabajos de diseño, al menos en sus líneas principales. Este documento se considerará definitivo cuando la solución puesta en marcha se muestre estable y el número de incidencias graves (de intervención o de resolución) sea nulo y la cantidad de las consideradas leves quede por debajo de un límite establecido en las Métricas de Calidad.

Elaboración de la documentación de Formación y Operaciones: con vistas al soporte post proyecto y los programas de formación a usuarios y administradores, en esta fase deben elaborarse las Guías de Usuario, de Administración, las "paso-a-paso", y otros cuyos contenidos deben acordarse previamente.

Elaboración del Plan de Despliegue: se debe consensuar la fecha de finalización de la fase Piloto, y las condiciones de calidad que debe cumplir la solución final para iniciar el despliegue. En el Plan deben identificarse las fases, estrategia de implantación, fechas, tareas a realizar, procedimientos de validación y método de control de incidencias.

Elaboración del Plan de Formación: con anterioridad al despliegue definitivo, debe haberse aprobado el Plan de Formación 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 solución, como es la adecuada selección del entorno de prueba y el momento del año en que tenga lugar (evitando que coincida con periodos de vacaciones o puntas de trabajo críticas como Fin de Año). En proyectos de similar envergadura se ha llegado al momento "Error Free Versión" en 30 jornadas de trabajo (aproximadamente mes y medio) con una muestra de 50 usuarios.

Fase 4 – Despliegue

Se llevarán a cabo en esta fase los planes diseñados en la anterior, principalmente el de despliegue y el de formación. Los principales trabajos e hitos a conseguir son, en este caso, además de los obvios (implantación de la plataforma, puesta en servicio de todas las funciones, formación a los usuarios y administradores), los siguientes:

Continuación con las labores de recepción de incidencias, clasificación, tratamiento, resolución y distribución de faxes o intervención 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)

Revisión de las Guías y manuales de usuario, rectificación de errores y obtención de los documentos de formación definitivos.

Entrega de los documentos definitivos acordados como "deliverables" en la fase de Vision Scope.

Revisión (si procede) de la matriz de riesgos, las métricas de calidad y establecimiento de los estándares de calidad y SLA definitivos.

Finalmente, entrega del Proyecto y cierre del mismo, con o sin apertura de nuevo proyecto en base a la información y experiencia obtenidas.

La duración fase de despliegue, puesto que debe planificarse, no puede establecerse a priori. Depende de numerosos factores externos al propio proyecto (incluyendo factores de oportunidad política o de negocio) que pueden retardar o acelerar la conclusión.

La experiencia demuestra que no hay una relación directa entre número de máquinas y tiempo necesario para el despliegue. Los factores más relevantes en el cálculo suelen ser la dispersión o concentración geográfica, la complejidad del proceso de migración, el grado de automatización alcanzado, la experiencia y nivel de los técnicos que realizan la operación y condicionantes de calendario, a menudo con restricciones no técnicas, 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 documentación UML, se intenta promover procesos ligeros.

Objetivos:

Promover y definir un grupo de valores, prácticas y principios que ayudan a producir los modelos adecuados

Orientación de cómo aplicar el modelado de proyectos agiles

Orientación de cómo aplicar el modelado Ágil a otro tipo de procesos o metodologías (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 propósito y no más , 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 más detallados que otros pueden causar confusión 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 documentación de las metodologías 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 diseño, no crea documentación innecesaria, se puede usar cualquier tipo de diseño o documentación que nos ayude, puede haber procesos que sea difícil capturarlos con los diagramas conocidos, pero si otros, una metodología Ágil podría asociarlos.

Ejemplos de metodologías consideradas Ágil son Programación Extrema Scrum MSF 4.0 Microsoft RAD * Cristal RUP Agil Otras ..

En este documento hablaremos de las primeras cuatro metodologías, estas metodologías pueden combinarse, por ejemplo Programación Extrema y Scrum, RAD puede integrarse con otras etc.

El Scrum:

Naturalmente Scrum se enfoca en la construcción de proyectos exitosos en la organización, sin mayores cambios dentro de los 30 días 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 prácticas interrelacionadas y reglas que optimizan el entorno de desarrollo, reducen la sobrecarga organizativa, y sincronizan los requisitos del mercado con los prototipos de cada iteración. Basado en una teoría 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 liberación. Una funcionalidad del producto útil es dada cada treinta días como requisito, la arquitectura, y el diseño aparecen, incluso cuando la tecnología es inestable aun

Scrum como lo muestra la ilustración se basa en el equipo, en reuniones diarias presididas por el Scrum máster para establecer el estado del proyecto, y en la salida cada 30 días de características del proyecto finalizadas y listas para trabajar, el corazón del Scrum es la iteración, que en cada iteración presenta una mejora del funcionamiento del producto final, en cada iteración se evalúa la tecnología y capacidades requeridas, diariamente se pueden modificar el enfoque si se encuentran nuevas dificultades y tratar de remediarlas, el corazón del Scrum es la productividad

Proceso de trabajo del Scrum

Las más 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 organización era incapaz producir productos utilizables en un período de tiempo largo, así que ingenieros, dirección, 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 investigación de teoría de procesos y en colaboración con DuPont Advanced Research Facility, Scrum fue formulado por primera vez y presentado al OMG ( Object Management Group) en 1995.

Aspectos de las Metodologías Agiles

Características:

• Metodología de trabajo ágil

• Diseñada para acortar el ciclo de desarrollo

• Conseguir una mejor aproximación entre las funcionalidades del software y los requerimientos del cliente

• Evitar la burocracia innecesaria

• Mayor versatilidad frente a los cambios

• Comenzar el trabajo lo más rápidamente posible

• Manejo más eficiente de los requerimientos cambiantes en un proyecto

• Mejorar la comunicación entre el cliente y el equipo desarrollador

Criterios de referencia:

• Aumento de la productividad y de la comunicación directa entre el cliente y el equipo desarrollador. Recomendado para equipos de trabajo pequeños (máx. 8 personas)

• Desarrollo incremental e iterativo producción frecuente de prototipos para evaluación del cliente

• Manejo más eficiente de los requerimientos cambiantes en un proyecto mejorando la versatilidad frente a los cambios.

• SCRUM no dice Qué hacer sino Cómo hay que hacer las cosas

Fortalezas de SCRUM

Gestión regular de las expectativas del cliente

Priorización de requisitos

Resultados anticipados (“time to market”)

• Demostración del proyecto en cada Sprint

• Priorización de requisitos por valor/coste

Flexibilidad y adaptación Re planificación en el inicio de cada iteración

Retorno de inversión (ROI) • Priorización de requisitos

Mitigación de riesgos • Desarrollo iterativo e incremental

Productividad de calidad • Mejora continua

• Comunicación diaria del equipo

• TimeBoxing

• Equipo multidisciplinar

• Estimación de esfuerzo conjunta

• Compromiso del equipo

• Demostración de resultados

Alineamiento entre cliente y equipo Reuniones en cada itinerario (Sprint)

Equipo motivado • Equipo autosugestionado

• Reuniones diarias y en cada Sprint

Requisitos para poder utilizar Scrum

Los siguientes puntos son de especial importancia para la implantación de una gestión ágil de proyectos como Scrum:

Cultura de empresa basada en trabajo en equipo, delegación, creatividad y mejora continua.

Compromiso del cliente .- Scrum exige del cliente una alta implicación y una dedicación regular:.

Compromiso de la Dirección de la organización para resolver problemas endémicos y realizar cambios organizativos, formando equipos autogestionados y multidisciplinares y fomentando una cultura de gestión basada en la colaboración y en la facilitación.

Compromiso conjunto y colaboración de los miembros del equipo.

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

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

Tamaño de cada equipo entre 5 y 9 personas (con técnicas de colaboración entre equipos que trabajan en el mismo proyecto).

Equipo trabajando en un mismo espacio común para maximizar la comunicación.

Dedicación del equipo a tiempo completo.

Estabilidad de los miembros del equipo

Herramientas documentales - Historias de UsuarioEn la programación XP, suele utilizarse algo similar a lo utilizado en la

Metodología RUP, esto es los casos de uso, pero en esta Metodología, el concepto cambia, ya no es un formato preciso, es más anecdótico, 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 iteración, deben usar la terminología 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 través de una página Web

Más 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 propósito de un sistema o software, son tradicionalmente escritas a mano y se componen de tres aspectos

1. Uno que describa la historia y como planeación 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 iteración para su atención, pueden priorizarse en pilas para su desarrollo en cada iteración

Roles del ScrumScrum implementa sus procesos a través de tres roles considerados fundamentales, todas las responsabilidades de dirección 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 inversión (ROI), el back log proveído a este rol representa una herramienta poderosa al proyecto, este lo usa para dar a los requerimientos la más alta prioridad, estos mismos son el más alto valor del negocio, este rol conoce cuales son las funcionalidades requeridas para resolver la problemática 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 más frecuentemente y por eso debe diferenciársele a la persona cliente

El Scrum máster

Es el responsable de los procesos del Scrum, de que finalicé exitosamente, el que enseña 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 prácticas del Scrum. También puede

ayudar al equipo a decidir cuáles de los elementos (backlog) deben desarrollarse en cada iteración (sprint)

El equipo

Es el responsable del desarrollo, deben ser auto-dirigidos, auto-organizados, son los que sacan las características deseadas (el back log) en cada iteración, 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

Implementación de Scrum

1. Comenzar el proceso de Scrum

Debemos seleccionar al equipo, existe una fábula 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, ¿cómo se llamaría el restaurante?" La gallina contesta: "¿Por qué no lo llamamos "Huevos con jamón?" "Lo siento pero no", dice el cerdo, "Yo estaría comprometido pero tú solamente estarías involucrada”

Según esta fábula 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 más de 6 – 9 miembros por equipo Si hay más miembros , romperlos en grupos Cada grupo enfocado en una sola área de trabajo Todo el staff trabajara en esta área

2. Nombrar al Scrum Máster

El Scrum máster es la persona que conduce las reuniones diarias, mide empíricamente 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 reunión pasada, que problemas ha habido y que espera para la próxima reunión

3. Identificar el acumulado

Acumulado (Back log) es todo el trabajo pendiente para un área del producto, bien definido en sus términos

Listar todo el trabajo a ser realizado Agrupar todo el trabajo que puede hacerse en los 30 días 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 priorización de trabajos El equipo elige el acumulado para el sprint - periodo de 30 días Periodo o sprint es el lapso que se da el Scrum para realizar un

incremento este debe ser de 30 días Este acumulado se firma por los miembros del equipo Solo este acumulado se trabaja durante el periodo

4. Establecer y conducir la reunión diaria del Scrum

Diariamente se hace una reunión para checar el status del trabajo, donde el equipo informa de las actualizaciones, la reunión 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 dónde y cuándo son No debe durar más de treinta minutos El Scrum máster debe preguntar las 3 cuestiones básicas ya dichas Scrum máster 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 comunicación diaria Ofrece una dirección basada en experiencia y de bajo nivel Hace los obstáculos visibles Se toman decisiones y se resuelven problemas en tiempo real

Historias de Usuario

Básicamente 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 metodología ágil al igual que los casos de uso en las metodologías 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 (pizarrón)

A estas historias se les da una priorización de acuerdo a la importancia, , y al alcance proporcionados por el dueño del producto, a la estimación en tiempo , horas de trabajo por persona esta cantidad es dada por equipo de trabajo.

Historias Técnicas

Las historia técnicas se refieren a aquellas historias que no describen una característica del negocio o que aparentemente no dan valor al negocio, a estas actividades, como instalar un servidor, documentar el diseño general, optimización y limpieza del código, 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 difícil porque el dueño del producto no las reconoce, lo que se puede hacer es mantener una lista aparte, el

dueño del producto puede verla pero no modificarla, las actividades para estas historias se acomodan según convenga en la agenda del sprint

Se puede o no mantener informado al dueño del producto, aunque lo mejor es siempre mantenerlo informado

Elaboración del sprint (carrera corta)

En base a las historias de usuario, las actividades de ingeniería (historias técnicas) se definen las actividades a realizar para cada una

La elaboración del sprint consiste en seleccionar en base a la importancia de negocio y a la estimación de esfuerzo de ingeniería, las más 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 análisis y diseños 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 acrónimo 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, año del Manifiesto Ágil, DSDM publicó la versión 4.1 de su modelo, y se consideró una metodología ágil; y aunque mantuvo las siglas, cambió la denominación original (Dynamis Systems Development Method) por Framework for Business Centred Development

Principios del DSDMEn su versión actual (4.2) el marco de procesos DSDM se basa en 9 principios.

La implicación activa de los usuarios es imprescindible. Los miembros de los equipos de desarrollo DSDM deben tener la

autonomía y potestad necesarias para tomar decisiones. Entrega frecuente de incrementos operativos del producto. El principal criterio de prioridad, desarrollo y validación de las entregas

incrementales es el objetivo y la salud del negocio.

El desarrollo iterativo o incremental hace posible obtener la solución más 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 espíritu de colaboración con todos los

agentes implicados en el sistema que se desarrolla.

Procesos del ciclo de desarrollo DSDMEl ciclo de desarrollo de DSDM está compuesto de 5 fases, precedidas de un pre-proyecto y un post-proyecto.

1. Pre-proyecto 2. Estudio de viabilidad 3. Estudio de negocio 4. Iteración de modelado funcional 5. Iteración de diseño y desarrollo 6. Implementación 7. Post-desarrollo

Observando el diseño del modelo de gestión ágil DSDM ( ) vemos que se incluye antes de comenzar con las iteraciones (funcional - Diseño - e implementación), un punto de inicio representado por un triángulo de su diagrama, en este triángulo vemos actividades que son:

Pre-proyecto Estudio de viabilidad Estudio de negocio

En ellos se debe realizar: Análisis ágil de viabilidad sobre las cuestiones: ¿El sistema propuesto es técnicamente posible? Impacto en el proceso de negocio ¿Es DSDM el mejor ciclo de desarrollo para la solución del cliente? Análisis previo de los riesgos del proyecto

Y en el "estudio de negocio" : comprobar que el cliente dispone de una visión válida de lo que desea. Definir y validar la definición de alto nivel de la arquitectura del sistema. y generar un plan de desarrollo con las líneas de actividades en las

iteraciones del modelo, del diseño y de la implementación.

Este concepto de "validación inicial del proyecto" sería el equivalente al que la ingeniería del software ortodoxa cubre con el proceso de Adquisición, y que tiene como finalidad comprobar que todas las luces están verdes, antes de comenzar, aunque la metodología ágil pura no contiene estas fases el sprint 0 es usado para no romper la filosofía de la metodología

Elaboración de la pila de productos (back log)

El back log de productos es el corazón del scrum, es una lista priorizada de requisitos funcionales que pueden ser historias de usuario, cosas que el cliente quiere con su terminología, esta lista puede contener varios campos para cada ítem o producto, estos serían ID el cual es el identificador único del producto, su nombre, la importancia que le da el dueño del producto, la estimación en horas, como se puede probar que la funcionalidad está cubierta y nota, se pueden agregar más campos, categoría de actividad (análisis, diseño 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, estimación, importancia) las que van a ir en el sprint, en base a estas se definen las actividades que darían cumplimiento a esas historias, se descomponen en sub-actividades etc.

Se pueden elaborar tarjetas de producto en papel, comúnmente se ordenan en un tablero y se van marcando las que se van cumpliendo

El tablero nos indica que tareas están en el sprint, cuales se están realizando y cuales ya están 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 metodología ágil debe poseer experiencia trabajando con metodologías tradicionales, ya que la experiencia es la que predomina en los mementos cruciales del proyecto, además debe tener la capacidad de ser equipos auto-gestionados, altamente motivados y con gran innovación

Las metodologías ágiles permiten disminuir costos y brindar flexibilidad a los proyectos de software donde la incertidumbre está presente

El uso de metodologías tradicionales es esencial al inicio en un equipo de desarrollo de software

Las metodologías ágiles se deberían aplicar en proyectos donde exista mucha incertidumbre donde el entorno es volátil, donde los requisitos no se conocen con exactitud, mientras que las metodologías tradicionales obligan al cliente a tomar las decisiones al inicio del proyecto.

Bibliografía

Metodologías Ágiles: La ventaja competitiva de estar preparado para tomar decisiones lo más tarde posible y cambiarlas en cualquier momento. (En línea), Disponible en: www.spinec.org/wp-content/metodologiasagiles_01.pdf

Metodologías ágiles (En línea) ,Disponible en: http://www.agile-spain.com

ICONIX (En línea), Disponible en: www.spinec.org/wp-content/ICONIX.pdf

Extreme Programming Refactored: The Case Against XP, MATT Stephens and DOUG Rosenberg, Disponible en Formato chm

Introducción a Iconix (En línea), Disponible en: http://www.informit.com/articles/article.asp?p=167902&rl=1