1 SCRUM 1. INTRODUCCIN Scrum significa mel. Mel es un tipo de jugada del deporte Rugby.

Todos los jugadores de ambos equipo se agrupan en una formacin en la cual lucharn por obtener el baln que se introduce por el centro. La complejidad de una mel hace que: Si un miembro del equipo se viene abajo, se cae toda le mel En consecuencia, los jugadores deben estar bien coordinados, apoyndose en sus compaeros para empujar al mismo tiempo y con ello, avanzar a la misma velocidad. Scrum es una metodologa de desarrollo muy simple, que requiere trabajo duro, porque no se basa en el seguimiento de un plan, sino en la adaptacin continua a las circunstancias de la evolucin del proyecto, realizado por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80 y restructurado por Jeff Sutterland. 2. CARACTERSTICAS Scrum es un marco de trabajo gil que se basa en la iteracin y entrega de incrementales de desarrollo de un producto o servicio. Posee las siguientes caractersticas: Su prioridad es la satisfaccin del cliente; que se da con la continua interaccin entre ste y el equipo de desarrolladores. Se aceptan requisitos cambiantes. Enfocado a conseguir pequeos incrementos de software completamente funcionales Es un modo de desarrollo adaptable, antes que predictivo. Orientado a las personas, ms que a los procesos. Emplea el modelo de construccin incremental basado en iteraciones y revisiones. Alta flexibilidad 3. ROLES Y RESPONSABILIDADES El product Owner (dueo del producto): Caractersticas El Dueo de Producto es la nica persona autorizada para decidir sobre cules funcionalidades y caractersticas funcionales tendr el producto. Es quien representa al cliente, usuarios del software y todas aquellas partes interesadas en el producto, cuidando los intereses de cada uno de ellos.

2 Funciones y responsabilidades: Crear la pila de producto. Para esto puede contar con la colaboracin del resto del equipo, pero es importante recordar que el responsable de este documento es l. Encaminar las necesidades del negocio, sabiendo "escuchar" a las partes interesadas en el producto y transmitirlas en "objetivos de valor para el producto", al equipo de trabajo. Maximizar el valor para el negocio con respecto al Retorno de Inversin (ROI), abogando por los intereses del negocio. Estima el financiamiento inicial y el requerido en el curso del proyecto mediante la creacin de los requisitos totales e iniciales del proyecto, preocupndose de retornar los objetivos de inversin (ROI), y los planes de revisin. Revisar el producto e ir adaptndole sus funcionalidades, analizando las mejoras que stas puedan otorgar un mayor valor para el negocio. Aptitudes que debe tener un Dueo de Producto: Excelente facilidad de comunicacin en las relaciones interpersonales. Excelente conocimiento del negocio. Facilidad para anlisis de relaciones costo/beneficio. Visin de negocios. El Equipo (Scrum Team): Caractersticas Est integrado por programadores, diseadores, arquitectos, testers y dems, que en forma auto-organizada, ser los encargados de desarrollar el producto. Se auto-gestiona y auto-organiza, y dispone de atribuciones suficientes en la organizacin para tomar decisiones sobre cmo realizar su trabajo. Funciones y responsabilidades: Tienen la responsabilidad, en cada iteracin, de transformar el Product Backlog en un incremento en la funcionabilidad del producto y planificar su propio trabajo para lograrlo. Los miembros del equipo son responsables en conjunto del xito de cada iteracin y del proyecto en su totalidad. Aptitudes que deben tener los integrantes de un Equipo.

Ser profesionales expertos o avanzados en su disciplina. Tener vocacin para trabajar en equipo. Capacidad de auto-gestin.

El Scrum Master:

3 Caractersticas: El Scrum Master es el alma mater de Scrum, es un un autntico servidor neutral, que ser el encargado de fomentar e instruir sobre los principios giles de Scrum, gracias a sus excelentes conocimientos de esta metodologa. Protege al equipo de distracciones y de otros elementos externos. Elimina obstculos que alejen al grupo de la consecucin de objetivos del sprint. No es el lder del grupo, ya que el grupo se autogestiona. El Scrum Master es responsable del proceso Scrum, debe ensear la metodologa Scrum a cada integrante implicado en el proyecto, preocupndose de poner la metodologa en prctica de modo que se encuentre dentro de la cultura de la organizacin y as entregue las ventajas previstas, asegurndose de que cada uno siga las Reglas y prcticas de Scrum. Funciones y responsabilidades:

Garantizar la correcta aplicacin de Scrum. Esto incluye, desde la correcta trasmisin de sus principios a las altas gerencias, hasta la prevencin de la inversin roles (es decir, guardar especial cuidado en que el dueo de producto no acte en nombre del equipo y viceversa, o que la audiencia se inmiscuya en tareas que no le son propicias). Resolver los conflictos que entorpezcan el progreso del proyecto. Incentivar y motivar al Equipo de trabajo, creando un clima de trabajo colaborativo, fomentar la auto-gestin del equipo e impedir la intervencin de terceros en la gestin del equipo. Aptitudes que debe tener un Scrum Master

Amplia vocacin de servicio. Predisposicin generosa. Amplia capacidad para la resolucin de problemas. Analtico y observador. Saber incentivar y motivar. Capacidad docente e instructiva. Buen carisma para las negociaciones.

4. ARTEFACTOS O ELEMENTOS DE SCRUM Scrum, aplicado al software, emplea dos formatos para registrar los requisitos: Pila del producto (Product Backlog) Pila del sprint (Sprint Backlog)

4 La pila del producto se sita en el rea de necesidades de negocio desde el punto de vista del cliente. Es el rea que en la ingeniera del software tradicional, cubren los requisitos del sistema o ConOps (Concept of Operations). La pila del sprint cubre la especificacin de los requisitos de software necesarios para dar respuesta a las funcionalidades esperadas por el cliente. Estas listas no tienen que cumplir con un determinado formato scrum-estndar; pueden, y deben adoptar la forma ms adecuada al sistema equipo-proyecto. Algunos equipos giles emplean pilas de requisitos, otras historias de usuario, WBS,entre otras. Lo relevante no es tanto la forma, sino qu. Pila del producto: los requisitos del cliente La pila del producto es el inventario de funcionalidades, mejoras, tecnologa y correccin de errores que deben incorporarse al producto a travs de las sucesivas iteraciones de desarrollo. Representa todo aquello que esperan los clientes, usuarios, y en general los interesados. Todo lo que suponga un trabajo que debe realizar. Para dar comienzo al desarrollo se necesita una visin de los objetivos de negocio que se quieren conseguir con el proyecto, comprendida y conocida por todo el equipo, y elementos suficientes Formato de la pila del producto : El desarrollo gil prefiere la comunicacin directa, a la comunicacin con documentos. La pila del producto no es un documento de requisitos, sino una herramienta de referencia para el equipo. Si se emplea formato de lista, es recomendable que al menos incluya la siguiente informacin en cada lnea: Identificador nico de la funcionalidad o trabajo. Descripcin de la funcionalidad. Campo o sistema de priorizacin. Estimacin

Dependiendo del tipo de proyecto, funcionamiento del equipo y la organizacin, pueden resultar aconsejables otros campos como observaciones, criterio de validacin, persona asignada, nmero de Sprint en el que se realiza, mdulo del sistema al que pertenece, entre otros. Ejemplo:

Pila del Sprint La pila del sprint, (sprint backlog) es la lista que descompone las funcionalidades de la pila del producto en las tareas necesarias para construir un incremento: una parte completa y operativa del producto. La realiza el equipo durante la reunin de planificacin del sprint, en donde se estima cada tarea para luego ser asignada entre sus miembros; adems, se indica en la misma lista cunto tiempo falta an para que la termine. Las duraciones estimadas de las tareas no son ni inferiores, ni superiores a los lmites definidos en el equipo Es til porque descompone el proyecto en unidades de tamao adecuado para determinar el avance a diario, e identificar riesgos y problemas sin necesidad de procesos complejos de gestin. Es tambin una herramienta de soporte para la comunicacin directa del equipo. Condiciones Realizada de forma conjunta por todos los miembros del equipo. Cubre todas las tareas identificadas por el equipo para conseguir el objetivo del sprint. Slo el equipo lo puede modificar durante el sprint. Es visible para todo el equipo. Idealmente en una pizarra o pared en el mismo espacio fsico donde trabaja el equipo. Formato y soporte Hoja de clculo. Pizarra fsica o pared. Herramienta colaborativa o de gestin de proyectos. Y sobre la que mejor se adecua a las caractersticas del proyecto, oficina y equipo, lo apropiado es disear el formato ms cmodo para todos, teniendo en cuenta los siguientes criterios:

6 Incluye la informacin: lista de tareas, persona responsable de cada una, estado en el que se encuentra y tiempo de trabajo que queda para completarla. Slo incluye la informacin estrictamente necesaria. El medio y modelo elegido es la opcin posible que ms facilita la consulta y comunicacin diaria y directa del equipo. Sirve de soporte para registrar en cada reunin diaria del sprint, el tiempo que le queda a cada tarea.

El Incremento El incremento es la parte de producto producida en un sprint, y tiene como caractersticas que est completamente terminada, probada y operativa, en condiciones de ser entregada al cliente final. No se trata por tanto de mdulos o partes a falta de pruebas, o documentacin. Idealmente en el desarrollo gil:

7 Cada funcionalidad de la pila del producto se refiere a funcionalidades entregables, no a trabajos internos del tipo diseo de la base de datos Se produce un incremento en cada iteracin. Sin embargo suele ser una excepcin habitual el primer sprint. En el que objetivos del tipo contrastar la plataforma y el diseo pueden ser normales, e implican trabajos de diseo o desarrollo de prototipos para probar la solvencia de la plataforma que se va a emplear, entre otros. Si el proyecto o el sistema requiere documentacin, o procesos de validacin y verificacin documentados, o con niveles de independencia que implican procesos con terceros, stos tambin tienen que estar realizados para considerar que el producto est terminado. 5. LAS REUNIONES Scrum realiza el seguimiento y la gestin del proyecto a travs de las tres reuniones que forman parte del modelo y la retrospectiva que nos ayuda a reconocer los problemas y a plantear mejoras: Planificacin del sprint Seguimiento del sprint Revisin del sprint Retrospectiva

Planificacin del sprint En esta reunin se toman como base las prioridades y necesidades de negocio del cliente, y se determina cules y cmo van a ser las funcionalidades que incorporar el producto tras el siguiente sprint. Las caractersticas de la planificacin del sprint son: Pre-condiciones La organizacin tiene determinados los recursos disponibles para llevar a cabo el sprint.

8 El Product Owner tiene preparada la pila del producto, con su criterio de prioridad para el negocio, y un nmero suficiente de elementos para desarrollar en el sprint. Siempre que sea posible, Product Owner debe haber trabajado antes con el equipo. De esta forma su estimacin previa del trabajo que se puede realizar en el sprint ser bastante ajustada. El equipo tiene un conocimiento de las tecnologas empleadas, y del negocio del producto suficiente para realizar estimaciones basadas en "juicio de expertos, y para comprender los conceptos del negocio que expone el propietario del producto. Entradas El backlog del producto El producto desarrollado hasta la fecha a travs de los sucesivos incrementos (excepto si se trata del primer sprint) Circunstancias de las condiciones de negocio del cliente y del escenario tecnolgico empleado. Resultados Los elementos de la backlog del producto que se van a ejecutar. El objetivo del sprint. Backlog del sprint con todas las tareas estimadas y asignadas. La duracin del sprint y la fecha de la reunin de revisin. Formato de la reunin Duracin mxima: un da. Deben asistir: el Product Owner, el equipo y el Scrum Master (o responsable de este rol) Pueden asistir: es una reunin abierta a todos los que puedan aportar informacin til. Consta de dos partes separadas por una pausa, segn la duracin. Primera parte: Duracin de 1 a 4 horas. Propietario del producto: El Scrum Master acta de moderador de la reunin. Presenta las funcionalidades de la pila del producto que tienen mayor prioridad y que estima se pueden realizar en el sprint. La presentacin se hace con un nivel de detalle suficiente para transmitir al equipo toda la informacin necesaria para construir el incremento. El equipo: Realiza las preguntas y solicita las aclaraciones necesarias.

9 Propone sugerencias, modificaciones y soluciones alternativas. Las aportaciones del equipo pueden suponer modificaciones en la pila.

Tras reordenar y replantear las funcionalidades de la pila del producto, el equipo define el objetivo del sprint o frase que sintetiza cul es el valor que se le va a entregar al cliente. Exceptuando sprints dedicados exclusivamente a refactorizacin o a colecciones de tareas desordenadas (que deberan ser los menos), la elaboracin de este lema de forma conjunta en la reunin es una garanta de que todo el equipo comprende y comparte la finalidad del trabajo; y durante el sprint sirve de criterio de referencia en las decisiones que auto gestiona el equipo. Segunda parte: Su duracin es hasta el final de la jornada. El equipo desglosa cada funcionalidad en tareas, y estima el tiempo para cada una de ellas, determinando de esta forma las tareas de la pila del sprint, el equipo debe tener en cuenta los elementos de diseo y arquitectura que deber incorporar el sistema. Los miembros del equipo se auto-asignan las diferentes tareas tomando como criterios sus conocimientos, intereses y distribucin homognea del trabajo. El objetivo del Product Owner es atender a dudas y comprobar que el equipo comprende y comparte su objetivo. Seguimiento del sprint Reunin diaria breve, de no ms de 15 minutos, en la que cada miembro del equipo dice las tareas en las que est trabajando, si se ha encontrado o prev encontrarse con algn impedimento, y actualiza sobre la pila del sprint las ya terminadas, o los tiempos de trabajo que les quedan. Pre-condiciones Disponibilidad de un lugar fsico en la organizacin para realizar diariamente la reunin. Sprint backlog actualizado en el soporte que emplee el equipo (dibujado en pizarra, con post-its, sobre hoja de clculo) Asiste todo el equipo. Asiste un responsable con rol de Scrum Master de la organizacin. Un miembro del equipo (team leader) conduce y garantiza el protocolo, formato y tiempos de la reunin.

Entradas

10 Sprint backlog y grfico de avance (burn-down) actualizados con la informacin de la reunin anterior. Informacin de las tareas realizadas por cada componente del equipo Resultados Sprint backlog y grfico de avance (burn-down) actualizados. Identificacin de necesidades e impedimentos. Formato de la reunin Se recomienda realizarla de pie y emplear un formato de pila de tareas en una pizarra, junto con el grfico de avance del sprint, para que todo el equipo pueda ver y anotar. Cada miembro del equipo expone estas tres cuestiones: 1.- Tarea en la que trabaj ayer. 2.- Tarea o tareas en las que trabajar hoy. 3.- Si va a necesitar alguna cosa especial o prev algn impedimento para realizar su trabajo. Y actualiza sobre el sprint backlog el tiempo de trabajo que queda pendiente en las tareas que tiene asignadas, o marca como finalizadas las ya completadas. Al final de la reunin: Con las estimaciones actualizadas, el equipo refresca el grfico de avance del sprint. El Scrum Master comienza la gestin de necesidades e impedimentos identificados. REVISIN DEL SPRINT Reunin realizada al final del sprint en la que, con una duracin mxima de 4 horas, el equipo presenta al Product Owner, clientes, usuarios, gestores el incremento construido en el sprint. Objetivos El Product Owner obtiene informacin objetiva del progreso del sistema. Esta reunin marca a intervalos regulares, el ritmo de construccin del sistema y la trayectoria que va tomando la visin del producto. Al ver y probar el incremento, el Product Owner, y el equipo en general obtienen feedback clave para evolucionar y dar ms valor a la pila del producto. El Scrum Master obtiene retroinformacin sobre buenas prcticas y problemas durante el sprint, necesaria para las prcticas de ingeniera de procesos y mejora continua de la implementacin Scrum Master.

11 Pre-condiciones Se ha concluido el sprint. Asiste todo el equipo de desarrollo, el Product Owner, el responsable de procesos de la empresa y todas las personas implicadas en el proyecto que lo deseen. Entradas Incremento terminado. Resultados Feedback para el Product Owner: hito de seguimiento de la construccin del sistema, e informacin para mejorar el valor de la visin del producto. Feedback para el Scrum Master: buenas prcticas y problemas durante el sprint. Convocatoria de la reunin del siguiente sprint. Formato de la reunin Es una reunin informativa e informal. El objetivo es ver el incremento. El equipo no debe invertir ms de una hora en preparar la reunin, y lo que se muestra es el resultado final: terminado, probado y operando en el entorno del cliente (incremento), adems puede incluir tambin documentacin de usuario, o tcnica. Un protocolo recomendado: 1.- El team leader expone el objetivo del sprint, la lista de funcionalidades que se incluan y las que se han desarrollado. 2.- El equipo hace una introduccin general del sprint y demuestra el funcionamiento de las partes construidas. 3.- Se abre un turno de preguntas y sugerencias sobre lo visto. 4.- El responsable del proceso (Scrum Master), de acuerdo con las agendas del Product Owner y el equipo cierra la fecha para la reunin de preparacin del siguiente sprint. RETROSPECTIVA Conviene sealar que una reunin retrospectiva no es lo mismo que la reunin de revisin del sprint. Al igual que los modelos de procesos incorporan prcticas de ingeniera de procesos para conseguir una mejora continua de su capacidad, en agilidad tambin van surgiendo prcticas para lo que sera el equivalente de mejora continua de la agilidad de la organizacin; y en esta lnea, las reuniones retrospectivas son un una meta-practica gil.

12 Una reunin retrospectiva se centra en CMO lo estamos construyendo: CMO estamos trabajando, con el objetivo de analizar problemas y aspectos mejorables. Se plantean los inconvenientes tenidos durante el desarrollo del Sprint, as como las mejoras posibles para trabajos futuros. 6. MEDICION Para que medir?: Dentro de la metodologa SCRUM es necesario medir para verificar el cumplimiento de los objetivos planteados en un tiempo transcurrido, estas nos proporcionan criterios objetivos de gestin y seguimiento. Se considera tres fondos de escala, o de zoom con los que se puede medir el trabajo: Desarrollo y gestin de la solucin tcnica. Gestin de proyecto. Gestin de la organizacin. En el desarrollo del proyecto podemos medir en los campos de: Organizacin (rendimiento, satisfaccin clientes, eficiencia, desempeo, etc), proyecto (esfuerzo, coste, tamao, etc) y desarrollo (densidad de fallos, complejidad de diseo, disponibilidad, etc). Antes de incorporar un procedimiento de medicin, se debe cuestionar su conveniencia, y la forma en la que se aplicar. Criterios para el diseo y aplicacin de mtricas Por qu se va a usar? El uso de las mtricas es tanto para uso del equipo de trabajo como para el cliente. Dentro del equipo de trabajo permite saber si estn cumpliendo con su trabajo y as poder tomar medidas de correccin, etc. Para el cliente, porque puede ver el progreso y desarrollo del software si est satisfactoriamente y se encuentra dentro del coste y as poder tomar decisiones de continuar con el desarrollo del mismo y poder invertir en l. Para tomar una mtrica debemos tomar en cuenta un indicador. El indicador es apropiado para el fin que se debe conseguir?

13 El medir es una parte difcil, debemos tomar un indicador que nos ayude a medir lo necesario, ya que si no lo es solo supondrn un coste de gestin evitable; muchas veces empeorarn lo que se intentaba mejorar. Medicin de la eficiencia en la empresa La organizacin plantea indicadores para medir el grado de eficiencia de los departamentos, combinndola con otra que es la de tiempo de respuesta. Si la implantacin del indicador ha dado buenos resultados: el departamento ha comenzado a ser ms eficiente y conseguir mayor satisfaccin de su cliente: 1.- Va reduciendo los costes que suponen la incorporacin de nuevas personas a la empresa. 2.- Va reduciendo los tiempos de respuesta a los departamentos que solicitan nuevo personal. Medicin del avance del proyecto La organizacin ha diseado un cuadro de informacin para mostrar el grado de avance de cada proyecto. Los indicadores de progreso de los proyectos, y de las tareas en las que se descomponen; se elaboran con el sistema clsico de la gestin de proyectos predictiva: 1.- Se realiza la estimacin del tiempo de trabajo necesario para cada tarea. 2.- Diariamente se actualizan los tiempos de trabajo invertidos. 3.- La diferencia muestra el porcentaje ejecutado de las tareas, y por tanto, el de cada proyecto. Medicin de la eficiencia de los trabajos de programacin Para esto se ha adoptado mtricas estndar de eficiencia de Ingeniera del Software: LOC/Hour: Nmero total de lneas de cdigo nuevas o modificadas en cada hora. Al vincular los resultados de esta mtrica a la retribucin por desempeo de los programadores. Esta aumenta el resultado de las lneas de cdigo en el programa. El resultado ha sido producir ms lneas de cdigo sin incrementar la plantilla. Para evitar que se trate de un incremento hueco de lneas de cdigo, o que conlleve un aumento de los errores por programar ms deprisa, se ha dotado de mayor rigor al sistema de mtrica, incorporando al poco tiempo otras mtricas para complementar y mejorar el sistema de calidad.

14 Las Unidades Velocidad, trabajo y tiempo son las tres magnitudes que mide la gestin de proyectos gil, y componen la frmula de la velocidad, definindola como: cantidad de trabajo realizada por unidad de tiempo. Velocidad = Trabajo / Tiempo Tiempo El desarrollo gil emplea la tcnica timeboxing6 para gestin de tiempo. En el caso de Scrum, la unidad de tiempo para cada incremento de producto es el Sprint. Podemos diferenciar dos tipos de tiempo: Tiempo real, es el efectivo de trabajo. Es equivalente a la jornada laboral. Tiempo ideal se refiere al tiempo de trabajo necesario, en condiciones ideales, esto es, sin ninguna interrupcin, pausa, distraccin o atencin a tareas ajenas a la tarea del sprint que se tiene asignada. Trabajo Medir el trabajo puede ser necesario por dos razones: para registrar lo ya hecho, o para estimar anticipadamente, el que hay que realizar. En ambos casos se necesita una unidad, y un criterio objetivo de cmo se cuantifica. Velocidad=trabajo/tiempo tiempo=sprint

Trabajo ya realizado: no es de gran dificultad, se puede hacer con unidades relativas al producto (p. ej. lneas de cdigo) o a los recursos empleados (coste, tiempo de trabajo). La gestin gil no determina el grado de avance del proyecto por el trabajo ya realizado, sino por el pendiente de realizar. Trabajo pendiente de realizar : Scrum mide el trabajo pendiente para: Estimar el esfuerzo y la duracin prevista para completar el trabajo (tareas, historias de usuario). Determinar el avance del proyecto, y en especial en cada sprint. Las unidades para medir el trabajo pueden estar relacionadas directamente con el producto, como los tradicionales puntos de funcin de COCOMO; o indirectamente, a travs del tiempo necesario para realizarlo. Velocidad = Trabajo / Tiempo

15 La gestin gil suele llamar a las unidades que emplea para medir el trabajo puntos, puntos de funcionalidad puntos de historia Cada organizacin, segn sus circunstancias y su criterio institucionaliza su mtrica de trabajo definiendo el nombre y las unidades. Lo importante es que la mtrica empleada, su significado y la forma de aplicacin sea consistente en todas las mediciones, en todos los proyectos de la organizacin y conocida por todas las personas. Velocidad Velocidad es la magnitud que viene determinada por la cantidad de trabajo realizada en un periodo de tiempo. Los equipos que miden el trabajo con tiempo ideal, hablan de Velocidad. Si en el sprint siguiente consiguen una velocidad mayor, querr decir que han logrado programar ms story points en el mismo tiempo, o lo que es lo mismo que han conseguido aumentar el porcentaje de tiempo ideal en la jornada de trabajo: han reducido los tiempos de interrupciones, distracciones o dedicados a otras tareas. Se le puede llamar velocidad o eficiencia, cuando un equipo en un siguiente sprint logra programar ms story points. Velocidad y eficiencia son trminos similares. Se suele preferir velocidad cuando las mediciones se basan en tiempo tericos, y eficiencia cuando lo hacen en tiempo real. 7. HERRAMIENTAS DE SCRUM Historias de usuario Cada historia de usuario contiene lo que el cliente quiere, con total claridad y ninguna ambigedad. Deben ser breves, concretas y algo estimables. Son el resultado de escuchar al cliente y ayudarle a resumir el requisito en una sola frase. Algo muy importante es que estn escritas con el vocabulario del negocio del cliente, no con vocabulario tcnico. Ejemplo:

16 Cada historia provoca una serie de preguntas acerca de los mltiples contextos en que se puede dar. Son las que naturalmente hacen los desarrolladores a los analistas de negocio o al cliente. Ejemplo: Qu hace el sistema si el libro que se quiere aadir al carrito ya est dentro de l? Qu sucede si se ha agotado el libro en el almacn? Se le indica al usuario que el libro ha sido aadido al carrito de la compra? Las respuestas a estas preguntas son afirmaciones, ejemplos, los cuales se deben transformar en test de aceptacin. Por tanto, cada historia de usuario tiene asociados uno o varios test de aceptacin (ejemplos):

Las preguntas surgidas de una historia de usuario pueden incluso dar lugar a otras historias que pasan a engrosar el backlog o lista de requisitos: Si el libro no est en stock, se enviar un email al usuario cuando llegue. Grfico de producto o burn-up: Es una herramienta de planificacin y seguimiento del propietario del producto, que muestra de un vistazo, en un grfico muy simple el plan general de desarrollo del producto, y la traza de su evolucin. Se confecciona con: La estimacin del esfuerzo prevista en la pila del producto. La velocidad del equipo. Se lo representa con un diagrama cartesiano que en el eje de ordenadas muestra el trabajo estimado para desarrollar el producto, y en el de abcisas las fechas, medidas segn las duraciones previstas para los sprints. Adems, se traza en el grfico la lnea de velocidad prevista. Tambin puede resultar til esbozar una estimacin optimista y otra pesimista para tener la visin de fechas aceptables. La lnea de velocidad proyecta sobre el eje X la fecha o sprint en el que previsiblemente se completarn las versiones representadas en el eje Y.

17 Ejemplo: Representacin del plan del producto, a partir de los temas previstos en la pila de producto (product backlog). Las convenciones empleadas por el equipo son: Unidad para medicin de trabajo: tiempo ideal Tiene previsto realizar sprints de duracin fija mensual. El equipo est formado por 4 personas, y viene desarrollando una velocidad de 300 puntos por sprint.

Grfico de avance-burndown: monitorizacin del sprint Es el grfico que actualiza el equipo en las reuniones de seguimiento del sprint, para comprobar el ritmo de avance, y detectar desde el primer momento si es el previsto, o se puede ver comprometida la entrega prevista al final del sprint. La estrategia gil para el seguimiento de los proyectos se basa en medir el esfuerzo que falta, no el realizado y el seguimiento muy cercano (diario de ser posible), en este grfico toman forma los dos principios: En el eje Y se registra el trabajo que an falta por realizar. Se actualiza a diario. El equipo dispone en la pila del Sprint, de la lista de tareas que va a realizar y en cada uno figura el esfuerzo pendiente. El primer da, en la pila de tareas figura para cada tarea el esfuerzo que se ha estimado, puesto que an no se ha trabajado en ninguna de ellas.

18 Da a da, cada miembro del equipo actualiza en la pila del sprint el tiempo que le queda a las tareas que va desarrollando, hasta que se terminan y van quedando en 0 los tiempos pendientes. Con esta informacin de la pila del sprint se actualiza el grfico poniendo cada da el esfuerzo pendiente total de todas las tareas que an no se han terminado. Ejemplo:

El avance ideal de un sprint estara representado por la diagonal que reduce el esfuerzo en forma de pendiente de forma continua y gradual hasta terminarlo en el ltimo da del Sprint. Las grficas de diagonal perfecta no son lo habitual, y la curva puede estar por encima o bajo ella lo que significa que se debe quitar o agregar elementos del Sprint backlog.

Estimacin de pquer Es una prctica gil, til para conducir las reuniones en las que se estima el esfuerzo y la duracin de tareas. Para evitar en estos casos las discusiones dilatadas que no terminan de dar conclusiones concretas, James Grening ide este juego de planificacin como ayuda para conducir la reunin.

19

El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la estimacin de cada tarea, todos vuelven boca arriba la combinacin que suma el esfuerzo estimado. Cuando se considera que ste es mayor al tamao mximo considerado por el equipo para una tarea, se levanta la carta &. Cada equipo u organizacin puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamao mximo de tarea que se va a estimar. Sin embargo hay que respetar los siguientes principios: No definir tareas demasiado grandes, porque entorpece la precisin de las estimaciones y la identificacin de riesgos. No definir tareas cuya duracin (en puntos o tiempo) resulte inferior a medio da ideal de trabajo. Utilizar la misma unidad de medida (storypoints, das, horas, entre otras) en todos los grficos y pilas. 8. PROCESO

Prejuego: Planificacin: definicin de una nueva entrega basndose en un Product Backlog conocido junto a un costo y cronograma estimados. Si un nuevo sistema empieza a desarrollarse, esta fase consiste en conceptualizacin y anlisis.

20 Pasos:

Desarrollo de un backlog completo. Determinacin de la fecha de entrega y la funcionalidad de una o ms versiones. Seleccin de la versin ms adecuada para desarrollo inmediato. Trazado de los paquetes del producto (objetos) sobre los elementos del backlog de la versin elegida. Seleccin del equipo o equipos para desarrollar la nueva versin. Evaluacin y control adecuado de los riesgos. Estimacin del coste de la versin, incluyendo desarrollo, material, marketing, formacin y despliegue. Conformidad de la direccin y financiacin del proyecto.

Arquitectura: Disea cmo los artculos del Backlog son implementados. Incluye la creacin o modificacin de la arquitectura del sistema y el diseo de alto nivel. Pasos: Revisin de los elementos del backlog incluidos en la versin. Identificacin de los cambios necesarios para implementar el backlog. Anlisis del dominio para incluir los requisitos que incluye el desarrollo mejorado y actualizacin. Acotar la arquitectura del sistema para apoyar el nuevo contexto y necesidades. Identificar problemas del desarrollo o modificaciones. Reunin de revisin de diseo. Cada equipo presenta los cambios para implementar los elementos del backlog, e identificar posibles reasignaciones.

Juego: Desarrollo de los Sprints: desarrollo de una nueva funcionalidad en constante mira a las variables tiempo, requerimientos calidad, costo y competencia. La interaccin con estas variables define el final de esta fase. Son mltiples los Sprints o ciclos usados para desarrollar el sistema. Dentro del Sprint la retroalimentacin se obtiene con las reuniones diarias (ScrumMeetings) y el control de la curva de progreso burnup. La fase de desarrollo es un ciclo de trabajo repetitivo. Macro-procesos:

Reunin con los equipos para revisar los planes de lanzamiento de versin. Distribucin, revisin y ajuste de los estndares de conformidad para el producto. Sprints iterativos hasta que el producto se considera listo para su distribucin.

21 Postjuego: Clausura: preparacin para la entrega, incluyendo la documentacin final, prueba y entrega. Tareas: integracin, pruebas del sistema, documentacin de usuario, preparacin del material de formacin y marketing. 9. EJEMPLO DE SCRUM

Un cliente se pone en contacto con una empresa que fabrica robots. El cliente les realiza el pedido

El Cliente se reune con el Dueo de producto, que toma nota de lo que tiene en su cabeza.

22 El Duelo de Producto divide el proyecto en historias que son las que componen la pila de producto.

El Dueo de Producto le entrega al Scrum Master la pila de producto para que estimen el coste de creacin del producto.

El equipo se reune para estimar el coste de cada historia de la pila de producto. En este caso utilizan Planning Poker.

El cliente, una vez aprobado el presupuesto, reordena la pila de producto para que el equipo vaya trabajando segn la prioridad del cliente.

El equipo comienza su trabajo desglosando la primera historia de la pila de producto, la cual subdividen en tareas menores para crear la pila de sprint.

23

La pila de sprint tiene como utilidad fraccionar el trabajo de un periodo de 15 das en tareas ms pequeas, que tarden mximo dos das.

Estas tareas se colocan en una pila, la cual prioriza el Dueo de Producto, que ha consultado con el cliente, antes de comenzar el sprint.

24 El equipo comienza el sprint tomando las tareas priorizadas. Una vez concluida una se toma la siguiente de la lista. Se convoca todos los das una reunin del equipo donde se cuenta las tareas realizadas el da anterior y cuales se van a realizar ese da.

Una vez finalizado el sprint, el Dueo de Producto le muestra al cliente el resultado del trabajo realizado. El cliente ya tiene el primer contacto con su encargo y adems puede volver a priorizar la pila de producto antes de que comience otro sprint.

El equipo de trabajo celebra su buen hacer con una reunin de retrospectiva, donde se analiza lo ocurrido durante el sprint. Esta reunin se celebra fueras de la oficina, normalmente con comida y bebidas de por medio.

10. VENTAJAS Y DESVENTAJAS Ventajas:

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. 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.

25

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 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. Visualizacin del proyecto da a da Equipos integrados y comprometidos con el proyecto, toda vez que ellos definieron el alcance y se auto-administran.

Desventajas No genera toda la evidencia o documentacin de otras metodologas Tal vez sea necesario complementarlo con otros procesos Si no existe una fecha definitiva de finalizacin del proyecto es posible que se siga solicitando, y aadiendo, nueva funcionalidad. Si una tarea no est bien definida, los costes de tiempo y dinero estimados del proyecto no sern demasiado exactos. En ese caso, la tarea se puede extender sobre varios sprints. Esta metodologa necesita solo miembros de equipo experimentados. Si el equipo consiste en gente que son junior, el proyecto no puede ser completado a tiempo. Adems de los recursos sin suficiente experiencia, la falta de direccin firme pueden llevar a los proyectos a no completarse o incluso fallar. La metodologa Scrum funciona bien cuando el scrum master confa en el equipo que lleva. Si se practican controles muy estrictos sobre los miembros del equipo, puede ser extremadamente frustrante para ellos, llevando a la desmoralizacin y el fallo del proyecto. Si algunos de los miembros del equipo se marcha durante el desarrollo puede tener un efecto negativo enorme en el desarrollo del proyecto. 11. QUIN USA SCRUM?

Microsoft Electronic Arts Nokia Capital One Telefnica

Yahoo Philips Ericsson BBC BMC Software

Google Siemens IBM F-Secure

26 12. PARA QU SE USA SCRUM? Software comercial. Proyectos internos. Proyecto de precio fijo. Aplicaciones financieras. Sistemas empotrados. Desarrollo de video juegos. Software de control de satlites. Sitios web. Software para dispositivos mviles. Network switching applications. 13. BIBLIOGRAFA: PALACIO JUAN, Flexibilidad con Scrum, [Octubre 2008], [20/03/2012], http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf ANTOL LEO, GUTIERREZ JUAN, YAGE AGUSTN; Introduccin a Scrum, [19/03/2012], http://www.adictosaltrabajo.com/material_charlas/20090507/scrum.pdf PALACIO JUAN, RUATA CLAUDIA, Scrum Manager Gestin de Proyectos, [Enero de 2011], [19/03/2012], http://www.scrummanager.net/files/sm_proyecto.pdf DUARTE ROMNY, Roles que se aplican en Scrum, [06/04/2008 17:46], [20/03/2012] http://geeks.ms/blogs/rduarte/archive/2008/04/06/roles-que-se-aplican-en-scrum.aspx Los roles de Scrum, [20/03/2012], http://sites.google.com/site/oeguzman/losrolesdescrum BAHIT EUGENIA, Los roles en Scrum, [14 de September de 2011], [20/03/2012], http://www.desarrolloweb.com/articulos/roles-scrum.html KNIBERG HENRIK, Scrum y Xp desde las trincheras, [Octubre-2008], [2012], http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-lastrincheras.pdf MOUSQUS GASTN, Metodologa SCRUM, [2003], [20/03/12], http://www.ort.edu.uy/fi/ingenieria/SubSitios/ingsoft/investigacion/ayudantias/SCRUM. pdf ITZCOALT ALVAREZ M, Desarrollo gil con SCRUM, [20/03/2012], http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:sg07.p02.scrum.pdf ORJUELA DUARTE AILIN, ROJAS C. MAURICIO, Las Metodologas de Desarrollo gil como una Oportunidad para la Ingeniera del Software Educativo, [2/06/2008],[20/03/2012], http://www.revista.unal.edu.co/index.php/avances/article/viewFile/10037/10567 FLOWERSINSPACE, Breve introduccin a Scrum, [28/03/2012], http://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-prctico1516220.