Scrum I Tabla de contenido

Scrum Manager I Introduccin: La agilidad El manifiesto gil Origen de scrum Adopciones de scrum: tcnica y pragmtica Introduccin al modelo Marco de scrum tcnico Artefactos Eventos Roles Introduccin a las mtricas giles Velocidad, trabajo y tiempo Grfico de producto Grfico de avance Estimacin de pquer

Introduccin: La agilidadEl entorno de trabajo de las empresas del conocimiento se parece muy poco al que origin la gestin de proyectos predictiva. Ahora se necesitan estrategias para el lanzamiento de productos orientadas a la entrega temprana de resultados tangibles, y a la respuesta gil y flexible, necesaria para trabajar en mercados de evolucin rpida.Ahora se construye el producto mientras se modifican y aparecen nuevos requisitos. El cliente parte de una visin medianamente clara, pero el nivel de innovacin que requiere, y la velocidad a la que se mueve su sector de negocio, no le permiten predecir con detalle cmo ser el resultado final. Quiz ya no hay productos finales, sino productos en continua evolucin y mejora.

La gestin de proyectos gil no se formula sobre la necesidad de anticipacin, sino sobre la de adaptacin continua.

La gestin de proyectos predictiva es la nica posible? Los criterios para determinar el xito son siempre el cumplimiento de fechas y costos? Puede haber proyectos cuya gestin no busque realizar un trabajo previamente planificado, con un presupuesto y en un tiempo previamente calculado? Hoy hay directores de producto que no necesitan conocer cules van a ser las 200 funcionalidades que tendr el producto final, ni si este estar terminado en 12 o en 16 meses.

Hay clientes que necesitan disponer de una primera versin con funcionalidades bsicas en cuestin de semanas, y no un producto completo dentro de uno o dos aos. Clientes cuyo inters es poner en el mercado rpidamente un concepto nuevo, y desarrollar de forma continua su valor.

Hay proyectos que no necesitan gestionar el seguimiento de un plan, y que fracasan por haber empleado un modelo de gestin inapropiado.

La mayora de los fiascos se producen por aplicar ingeniera secuencial y gestin predictiva tanto en el proceso de adquisicin (requisitos, contratacin, seguimiento y entrega) como en la gestin del proyecto, en productos que no necesitan tanto garantas de previsibilidad en la ejecucin, como respuesta rpida y flexibilidad para funcionar en entornos de negocio que cambian y evolucionan rpidamente.

El manifiesto gil

En marzo de 2001, 17 crticos de los modelos de produccin basados en procesos, convocados por Kent Beck, que haba publicado un par de aos antes el libro en el que explicaba la nueva metodologa Extreme ProgrammingBeck) se reunieron en Salt Lake City para discutir sobre el desarrollo de software. En la reunin se acu el trmino Mtodos giles para definir a aquellos que estaban surgiendo como alternativa a las metodologas formales:CMM-SW, precursor delCMMI,PMI, SPICE (proyecto inicial deISO 15504), a las que consideraban excesivamente pesadas y rgidas por su carcter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo. Los integrantes de la reunin resumieron en cuatro postulados lo que ha quedado denominado como Manifiesto gil, que son los valores sobre los que se asientan estos mtodos. Hasta 2005, entre los defensores de los modelos de procesos y los de modelos giles fueron frecuentes las posturas radicales, ms ocupadas en descalificar al otro, que en estudiar sus mtodos y conocerlos para mejorar los propios.Manifiesto gilValoramos ms a los individuos y su interaccin que a los procesos y las herramientas.Este es el valor ms importante del manifiesto.

Por supuesto que los procesos ayudan al trabajo. Son una gua de operacin. Las herramientas mejoran la eficiencia, pero hay tareas que requieren talento y necesitan personas que lo aporten y trabajen con una actitud adecuada.

La produccin basada en procesos persigue que la calidad del resultado sea consecuencia del know-how explicitado en los procesos, ms que en el conocimiento aportado por las personas que los ejecutan.

Sin embargo en desarrollo gil los procesos son una ayuda. Un soporte para guiar el trabajo. La defensa a ultranza de los procesos lleva a afirmar que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio no es cierto cuando se necesita creatividad e innovacin.

Valoramos ms el software que funciona que la documentacin exhaustiva.Poder anticipar cmo ser el funcionamiento del producto final, observando prototipos previos, o partes ya elaboradas ofrece un "feedback" estimulante y enriquecedor, que genera ideas imposibles de concebir en un primer momento, y difcilmente se podran incluir al redactar un documento de requisitos detallado en el comienzo del proyecto.

El manifiesto gil no da por intil la documentacin, slo la de la documentacin innecesaria. Los documentos son soporte de hechos, permiten la transferencia del conocimiento, registran informacin histrica, y en muchas cuestiones legales o normativas son obligatorios, pero su relevancia debe ser mucho menor que el producto final.

La comunicacin a travs de documentos no ofrece la riqueza y generacin de valor que logra la comunicacin directa entre las personas, y a travs de la interaccin con prototipos del producto. Por eso, siempre que sea posible debe preferirse reducir al mnimo indispensable el uso de documentacin, que requiere trabajo sin aportar un valor directo al producto. Si la organizacin y los equipos se comunican a travs de documentos, adems de ocultar la riqueza de la interaccin con el producto, forman barreras de burocracia entre departamentos o entre personas.

Valoramos ms la colaboracin con el cliente que la negociacin contractual.Las prcticas giles estn indicadas para productos cuyo detalle resulta difcil prever al principio del proyecto; y si se detallara al comenzar, el resultado final tendra menos valor que si se mejoran y precisan con retroinformacin continua durante el.

Tambin son apropiadas cuando se prevn requisitos inestables por la velocidad de cambio en el entorno de negocio del cliente. El objetivo de un proyecto gil no es controlar la ejecucin conforme a procesos y cumplimiento de planes, sino proporcionar el mayor valor posible al producto.

Resulta por tanto ms adecuada una relacin de implicacin y colaboracin continua con el cliente, ms que una contractual de delimitacin de responsabilidades.

Valoramos ms la respuesta al cambio que el seguimiento de un planPara desarrollar productos de requisitos inestables, que tienen como factor inherente el cambio y la evolucin rpida y continua, resulta mucho ms valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes. Los principales valores de la gestin gil son la anticipacin y la adaptacin, diferentes a los de la gestin de proyectos ortodoxa: planificacin y control que evite desviaciones del plan.

Los 12 principios del manifiesto gilEl manifiesto gil, tras los postulados de estos cuatro valores en los que se fundamenta, establece estos 12 principios:1. Nuestra principal prioridad es satisfacer al cliente a travs de la entrega temprana y continua de software de valor.2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos giles se doblegan al cambio como ventaja competitiva para el cliente.3. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a travs del proyecto.5. Construccin de proyectos en torno a individuos motivados, dndoles la oportunidad y el respaldo que necesitan y procurndoles confianza para que realicen la tarea.6. La forma ms eficiente y efectiva de comunicar informacin de ida y vuelta dentro de un equipo de desarrollo es mediante la conversacin cara a cara.7. El software que funciona es la principal medida del progreso.8. Los procesos giles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.9. La atencin continua a la excelencia tcnica enaltece la agilidad.10. La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial.11. Las mejores arquitecturas, requisitos y diseos emergen de equipos que se autoorganizan.12. En intervalos regulares, el equipo reflexiona sobre la forma de ser ms efectivo y ajusta su conducta en consecuencia.

Origen de scrumScrum es un modelo de desarrollo gil caracterizado por: Adoptar una estrategia de desarrollo incremental, en lugar de la planificacin y ejecucin completa del producto. Basar la calidad del resultado ms en el conocimiento tcito de las personas en equipos auto organizados, que en la calidad de los procesos empleados. Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o de cascada.

Este modelo fue identificado y definido porIkujiro Nonaka e Hirotaka Takeuchia principios de los 80, al analizar cmo desarrollaban los nuevos productos las principales empresas de manufactura tecnolgica: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986)

En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con el avance en formacin de scrum de los jugadores de Rugby, a raz de lo cual qued acuado el trmino scrum para referirse a ella.

Aunque esta forma de trabajo surgi en empresas de productos tecnolgicos, es apropiada para proyectos con requisitos inestables y para los que requieren rapidez y flexibilidad, situaciones frecuentes en el desarrollo de determinados sistemas de software.

En 1995 Ken Schwaber present Scrum Development Process en OOPSLA 95 (Object-Oriented Programming Systems & Applications conference)(SCRUM Development Process), un marco de reglas para desarrollo de software, basado en los principios de scrum, y que l haba empleado en el desarrollo de Delphi, y Jeff Sutherland en su empresa Easel Corporation (compaa que en los macrojuegos de compras y fusiones, se integrara en VMARK, y luego en Informix y finalmente en Ascential Software Corporation).

Adopciones de scrum: tcnica y pragmticaScrum se puede adoptar de forma tcnica, aplicando reglas definidas, o pragmtica, adoptando los valores originales scrum con reglas personalizadas. El contenido del temario "Scrum Manager I" ensea scrum tcnico, basado en la aplicacin de reglas concretas en un marco deroles,eventosyartefactosdefinidos. El aprendizaje de scrum tcnico es el primer paso aconsejable para familiarizarse con la agilidad. Una vez iniciados en agilidad, y con el conocimiento que el propio equipo acumula a travs de las retrospectivas, se pueden ir rompiendo las reglas y adoptar scrum pragmtico, personalizado y ms adecuado a las propias circunstancias del propio equipo y proyecto.

Introduccin al modelo

El marco tcnico de scrum, por su sencillez, resulta apropiado para equipos y organizaciones que quieren comenzar a avanzar en scrum

Est formado por un conjunto de prcticas y reglas que resultan vlidos para dar respuesta a los siguientes principios de desarrollo gil: Gestin evolutiva del avance, en lugar de la tradicional o predictiva. Trabajar basando la calidad del resultado en el conocimiento tcito de las personas, ms que en el explcito de los procesos y la tecnologa empleada. Estrategia de desarrollo incremental a travs de iteraciones (sprints) y revisiones. Seguir los pasos del desarrollo gil: desde el concepto o visin general de la necesidad del cliente, construccin sel producto de forma incremental a travs de iteraciones breves que comprenden fases de especulacin exploracin y revisin. Estas iteraciones (en scrum llamadas sprints) se repiten de forma continua hasta que el cliente da por cerrada la evolucin del producto.

Se comienza con la visin general de lo que se desea obtener, y a partir de ella se especifica y da detalle a las partes de mayor prioridad, y que se desean tener cuanto antes.

Cada ciclo de desarrollo o iteracin (sprint) finaliza con la entrega de una parte operativa del producto (incremento). La duracin de cada sprint puede ser desde una, hasta seis semanas, aunque se recomienda que no excedan de un mes.

En scrum, el equipo monitoriza la evolucin de cada sprint en reuniones breves diarias donde se revisa en conjunto el trabajo realizado por cada miembro el da anterior, y el previsto para el da en curso. Esta reunin diaria es de tiempo prefijado de 5 a 15 minutos mximo, se realiza de pie junto a un tablero o pizarra con informacin de las tareas del sprint, y el trabajo pendiente en cada una. Esta reunin se denomina reunion de pie o scrum diario y si se emplea la terminologa inglesa: stand-up meeting

Gestin de la evolucin del proyectoScrum maneja de forma emprica la evolucin del proyecto con las siguientes tcticas:Revisin de las IteracionesAl finalizar cada sprint se revisa funcionalmente el resultado, con todos los implicados en el proyecto. Es por tanto la duracin del sprint, el perodo de tiempo mximo para descubrir planteamientos errneos, mejorables o malinterpretaciones en las funcionalidades del productoDesarrollo incrementalNo se trabaja con diseos o abstracciones durante toda la construccin del producto. El desarrollo incremental ofrece al final de cada iteracin una parte de producto operativa, que se puede usar, inspeccionar y evaluar. Scrum resulta adecuado en proyectos con requisitos inciertos y, o inestables. Por qu predecir la versin definitiva de algo que va a estar evolucionando de forma continua? scrum considera a la inestabilidad como una premisa, y adopta tcnicas de trabajo para facilitar la evolucin sin degradar la calidad de la arquitectura y permitir que tambin evolucione durante el desarrollo. Durante la construccin se depura el diseo y la arquitectura, y no se cierran en una primera fase del proyecto. Las distintas fases que el desarrollo en cascada realiza de forma secuencial, en scrum se solapan y realizan de forma continua y simultnea.AutoorganizacinSon muchos los factores impredecibles en un proyecto. La gestin predictiva asigna al rol de gestor del proyecto la responsabilidad de su gestin y resolucin. En scrum los equipos son autoorganizados, con un margen de maniobra suficiente para tomar las decisiones que consideren oportunas.ColaboracinEs un componente importante y necesario para que a travs de la autoorganizacin se pueda gestionar con solvencia la labor que de otra forma realizara un gestor de proyectos. Todos los miembros del equipo colaboran de forma abierta con los dems, segn sus capacidades y no segn su rol o su puesto.

Marco de scrum tcnicoEl marco de scrum tcnico est formado por: Roles: El equipo scrum. El dueo del producto. El Scrum Master. Artefactos: Pila del producto. Pila del sprint. incremento. Sprint. Eventos Reunin de planificacin del sprint. Scrum diario. Revisin del sprint. Retrospectiva del sprint.Y la pieza clave es elsprint. Se denomina sprint a cada ciclo o iteracin de trabajo que produce una parte del producto terminada y funcionalmente operativa (incremento)Scrum tcnico utilizaincremento iterativobasado en pulsos de tiempo prefijado (sprints) para mantener el avance continuo de proyecto.En implementaciones pragmticas de scrum tambin se empleaincremento continuocuando resulta ms aconsejable.

Los artefactos del marco de scrum tcnico son:Pila del producto: (product backlog) lista de requisitos de usuario, que a partir de la visin inicial del producto crece y evoluciona durante el desarrollo.

Pila del sprint: (sprint backlog) lista de los trabajos que debe realizar el equipo durante el sprint para generar el incremento previsto.

Sprint: nombre que recibe cada iteracin de desarrollo. Es el ncleo central que genera el pulso de avance por tiempos prefijados (time boxing).

Incremento: resultado de cada sprint.

Otro artefacto de scrum tcnico es elgrfico de avanceo grfico burn down que el equipo actualiza a diario para comprobar el avance.

Pila del productoEn ingls product backlog Lista gil de los requisitos del cliente o requisitos del sistema: Simples: Expresados de forma breve, con una sentencia para cada uno, habitualmente con formato de historia de usuario o similar. Estimados: Est estimado el esfuerzo de construccin de cada requisito. Priorizados: Ordenados segn la importancia para el cliente o responsable de la lista.

La ingeniera del software clsica diferencia dos mbitos de requisitos: Requisitos del sistema Requisitos del softwareLos requisitos del sistema forman parte del proceso de adquisicin, y por tanto es responsabilidad del cliente la definicin del problema y de las funcionalidades que debe aportar la solucin.No importa si se trata de gestin tradicional o gil. La pila del producto es responsabilidad del cliente, aunque se aborda de forma diferente en cada caso.

La pila del producto es el inventario de funcionalidades, mejoras, tecnologa y correccin de errores que deben incorporarse al producto a travs de los sucesivossprints.

Representa todo aquello que esperan el cliente, los usuarios, y en general los interesados. Todo lo que suponga un trabajo que debe realizar elequipodebe estar reflejado en esta pila.La pila de requisitos del producto nunca se da por completada; est en continuo crecimiento y evolucin. Al comenzar el proyecto incluye los requisitos inicialmente conocidos y mejor entendidos, y conforme avanza el desarrollo, y evoluciona el entorno en el que ser usado, se va desarrollando.

En definitiva su continuo dinamismo refleja aquello que el producto necesita incorporar para ser el ms adecuado a las circunstancias, en todo momento.

Para comenzar el desarrollo se necesita la visin del objetivo de negocio que se quieren conseguir con el proyecto, comprendida y conocida por todo el equipo, y elementos suficientes en la pila para llevar a cabo el primer sprint. Habitualmente se comienza a elaborar la pila con el resultado de una reunin de tormenta de ideas, o "fertilizacin cruzada", o un proceso de Exploracin (eXtreme Programming) donde colabora todo el equipo partiendo de la visin del propietario del producto.

El formato de la visin no es relevante. Segn los casos, puede ser una presentacin informal del responsable del producto, un informe de requisitos del departamento de marketing, u otros. Sin embargo, s es importante disponer de una visin real, comprendida y compartida por todo el equipo. Elpropietario del productomantiene la pila ordenada por la prioridad de los elementos, siendo los ms prioritarios los que confieren mayor valor al producto, o por alguna razn resultan ms necesarios, y determinan las actividades de desarrollo inmediatas.

El detalle de los requisitos en la pila del producto debe ser proporcional a la prioridad: Los elementos de mayor prioridad deben tener mayor nivel de comprensin y detalle que los del resto. De esta forma el equipo de desarrollo puede descomponer un elemento de prioridad alta en tareas con la precisin suficiente para ser hecho en un sprint. Los elementos de la pila del producto que pueden ser incorporados a un sprint se denominan preparados o accionables y son los que pueden seleccionarse en la reunin de planificacin del sprint.

Preparacin de la pila del productoSe denomina preparacin (grooming) de la pila del producto a las actividades de priorizacin, detalle y estimacin de los elementos que la componen. Es un proceso que realizan de forma puntual, en cualquier momento, continua y colaborativa el propietario del producto y el equipo de desarrollo. No debe consumir ms del 10% de la capacidad de trabajo del equipo. La responsabilidad de estimar el esfuerzo previsible para cada elemento, es de las personas del equipo que previsiblemente harn el trabajo.

Formato de la pila del productoScrum prefiere la comunicacin verbal o de visualizacin directa, a la escrita. 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 para cada elemento: Identificador nico de la funcionalidad o trabajo. Descripcin de la funcionalidad/requisito, denominado historia de usuario. Campo o sistema de priorizacin. Estimacin del esfuerzo necesario.

Dependiendo del tipo de proyecto, funcionamiento del equipo y la organizacin, pueden ser aconsejables otros campos: Observaciones. Criterio de validacin. Persona asignada. N de Sprint en el que se realiza. Mdulo del sistema al que pertenece.Entre otros.Es preferible no adoptar formatos rgidos. Los resultados de scrum no dependen de las formas, sino de la institucionalizacin de sus principios y la implementacin adecuada a las caractersticas de la empresa y del proyecto. He aqu un sencillo ejemplo de pila de producto:

Pila del sprintLista de tareas que va a realizar el equipo en una iteracin, para construir un incremento. Para cada una registra la informacin: Descripcin breve. Persona que la tiene asignada. Esfuerzo pendiente para terminarla.InformacinEs 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 la puede modificar durante el sprint. Las tareas demasiado grandes deben descomponerse en otras ms pquelas. Se deben considerar grandes .las tareas que necesitan ms de un da para realizarse. Es visible para todo el equipo. Idealmente en un tablero o pared en el mismo espacio fsico donde trabaja el equipo.

Formato y soporteSon soportes habituales: Tablero fsico o pared. Hoja de clculo. Herramienta colaborativa o de gestin de proyectos.Y sobre el ms adecuado a las caractersticas del proyecto, oficina y equipo, lo apropiado es disear el formato ms cmodo para todos, teniendo en cuenta los siguientes criterios: Incluir la siguiente informacin: Pila del sprint, persona responsable de cada tarea, estado en el que se encuentra y tiempo detrabajo que queda para completarla. Incluir slo la informacin estrictamente necesaria. Debe servir de medio para registrar en cada reunin diaria del sprint, el tiempo que le queda a cada tarea. Facilitar la consulta y la comunicacin diaria y directa del equipo.

Durante elsprint, el equipo actualiza a diario en ella los tiempos pendientes de cada tarea. Al mismo tiempo, con estos datos traza el grfico de avance o trabajo consumido (burn-down), que se describe ms adelante, en el captulo de mtricas giles.

SprintCiclo de tiempo en el que se desarrolla cada incremento iterativo del producto.En funcin de las caractersticas del proyecto y el criterio del equipo, lo habitual es realizar sprints de duracin no inferior a una semana ni mayor de un mes (1).Cada sprint produce unincremento.

(1) Las primeras descripciones del ciclo de Scrum (Schwaber & Beedle) establecan una duracin mnima de dos semanas y mxima de dos meses. Tanto entonces como ahora, los ciclos de desarrollo con iteraciones de ms de dos meses no se consideran giles.

IncrementoEl incremento es la parte de producto producida en un sprint, y tiene como caracterstica el estar completamente terminada y operativa, en condiciones de ser entregada al cliente.

No se deben considerar como Incremento a prototipos, mdulos o sub-mdulos, ni partes pendientes de pruebas o integracin.

Idealmente en scrum: Cada elemento 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 es una excepcin frecuente el primer sprint. En el que objetivos del tipo contrastar la plataforma y el diseo pueden resultar necesarios, e implican trabajos de diseo o desarrollo de prototipos para contrastar las expectativas de la plataforma o tecnologa que se va a emplear. Teniendo en cuenta esta excepcin habitual:Incremento es la parte de producto realizada en un sprint potencialmente entregable: terminada y probada.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 incremento est hecho

Grfico de avanceEl grfico de avance o burndown es el grfico que actualiza el equipo en las reuniones de seguimiento del sprint, para monitorizar el ritmo de avance, y detectar de forma temprana posibles desviaciones sobre la previsin que pudieran comprometer la entrega al final de sprint.La estrategia gil para el seguimiento de los proyectos se basa en: Medir el esfuerzo que falta, no el realizado. Realizar un seguimiento muy cercano (diario de ser posible).Este grfico debe ser actualizado diariamente, y se registra: En el eje Y se registra el trabajo que an falta por realizar. En el eje X se registran los das del sprint.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. Esto es: 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.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.El avance ideal de un sprint estara representado por la diagonal que reduce el esfuerzo pendiente de forma continua y gradual hasta terminarlo en el ltimo da del sprint:

La superficie marcada muestra el esfuerzo pendienteLas grficas de diagonal perfecta no son lo habitual, y la siguiente imagen es un ejemplo de un patrn de avance ms normal.

El siguiente sera el aspecto de la grfica en un sprint subestimado

La estimacin que realiz el equipo en la reunin de inicio del sprint es inferior al esfuerzo real que estn requiriendo las tareas. Y el siguiente sera el patrn de grfica de un sprint sobrestimado.

Eventos

Los eventos o reuniones del marco de scrum tcnico son:Reunin dePlanificacin del sprint: reunin de trabajo previa al inicio de cada sprint en la que se determina cul va a ser el objetivo del sprint y las tareas necesarias para conseguirlo.

Scrum diario: breve reunin diaria del equipo.

Revisin del sprint: anlisis e inspeccin del incremento generado, y adaptacin de la pila del producto si resulta necesario. Una cuarta reunin se incorpor al marco estndar de scrum en la primera dcada de 2.000:

Retrospectivadel sprint: revisin de lo sucedido durante el Sprint. Reunin en la que el equipo analiza aspectos operativos de la forma de trabajo y crea un plan de mejoras para aplicar en el prximo sprint.

Planificacin del sprint

La reunin de planificacin del sprint es uno de loseventosde scrum tcnico.DescripcinEn esta reunin se toman como base las prioridades y necesidades de negocio del cliente, y se determinan cules y cmo van a ser las funcionalidades que se incorporarn al producto en el siguiente sprint.

Se trata de una reunin conducida por el responsable del funcionamiento del marco scrum (Scrum Master en scrum tcnico, o un miembro del equipo, en scrum pragmtico) a la que deben asistir el propietario del producto y el equipo completo, y a la que tambin pueden asistir otros implicados en el proyecto.

La reunin puede durar una jornada de trabajo completa, cuando se trata de planificar un sprint largo (de un mes de duracin) o un tiempo proporcional para planificar un sprint ms breve. Esta reunin debe dar respuesta a dos cuestiones: Qu se entregar al terminar el sprint. Cul es el trabajo necesario para realizar el incremento previsto, y cmo lo llevar a cabo el equipo.

La reunin se articula en dos partes de igual duracin, para dar respuesta a una de estas cuestiones, en cada una.Precondiciones La organizacin tiene determinados los recursos disponibles para llevar a cabo el sprint. Ya estn preparados los elementos prioritarios de la pila del producto, de forma que ya tienen un nivel de detalle suficiente y una estimacin previa del trabajo que requieren.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 La pila del producto. El producto desarrollado hasta la fecha en los incrementos anteriores (excepto si se trata del primer sprint). Dato de la velocidad o rendimiento del equipo en el ltimo sprint, que se emplea como criterio para estimar la cantidad de trabajo que es razonable suponer para el prximo sprint. Circunstancias de las condiciones de negocio del cliente y del escenario tecnolgico empleado.Resultados Pila del sprint. Duracin del sprint y fecha de la reunin de revisin. Objetivo del sprint.Formato de la reuninEsta reunin marca el inicio de cada sprint. Duracin mxima: un da. Asistentes: Propietario del producto, equipo de desarrollo y Scrum Master. Pueden asistir: todos aquellos que aporten informacin til, ya que es una reunin abierta. Consta de dos partes separadas por una pausa de caf o comida, segn la duracin.Primera parte: Qu se entregar al terminar el sprint.El propietario del producto presenta la pila de producto, exponiendo los requisitos de mayor prioridad que necesita y que prev que se podrn desarrollar en el siguiente sprint. Si la pila del producto ha tenido cambios significativos desde la anterior reunin, explica las causas que los han ocasionado. El objetivo es que todo el equipo conozca las razones y los detalles con el nivel suficiente para comprender el trabajo del sprint.

Propietario del producto: 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. Propone sugerencias, modificaciones y soluciones alternativas.

Los aportes del equipo pueden suponer modificaciones en la pila. Esta reunin es un punto caliente de scrum para favorecer la fertilizacin cruzada de ideas en equipo y aadir valor a la visin del producto.

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 autogestiona el equipo.Segunda parte: Cmo se conseguir hacer el incremento.El equipo desglosa cada funcionalidad en tareas, y estima el tiempo para cada una de ellas, componiendo as las tareas que forman la pila del sprint. En este desglose, el equipo tiene en cuenta los elementos de diseo y arquitectura que deber incorporar el sistema.

Los miembros del equipo establecen cules van a ser las tareas para los primeros das del sprint, y se las autoasignan tomando como criterios sus conocimientos, intereses y una distribucin homognea del trabajo. Esta segunda parte debe considerarse como una reunin del equipo, en la que deben estar todos sus miembros, y ser ellos quienes descompongan estimen y asignen el trabajo.

El papel del propietario del producto es atender a dudas y comprobar que el equipo comprende y comparte su objetivo. El Scrum Master acta de moderador de la reunin.

Funciones del Scrum MasterEl Scrum Master, o el moderador de la reunin es responsable y garante de:1. Realizar esta reunin antes de cada sprint.2. Asegurar que se cuenta con una pila de producto adecuadamente preparada por el propietario del producto.3. Ayudar a mantener el dilogo entre el propietario del producto y el equipo.4. Asegurar que se llegue a un acuerdo entre el propietario del producto y el equipo respecto de lo que incluir el incremento.5. Ayudar al equipo a comprender la visin y necesidades de negocio del cliente.6. Asegurar que el equipo ha realizado una descomposicin y estimacin del trabajo realistas, y ha considerado las posibles tareas necesarias de anlisis, investigacin o apoyo.7. Asegurar que al final de la reunin estn objetivamente determinados: Los elementos de la pila del producto que se van a ejecutar. El objetivo del sprint. La pila del sprint con todas las tareas estimadas. La duracin del sprint y la fecha de la reunin de revisin.

El Scrum Master modera la reunin para que no dure ms de un da. Debe evitar que el equipo comience a profundizar en trabajos de anlisis o arquitectura que son propios del trabajo del sprint.

Scrum diario

La reunin de scrum diario es uno de loseventosde scrum tcnico.DescripcinReunin diaria breve, de no ms de 15 minutos, en la que el equipo sincroniza el trabajo y establece el plan para las 24 horas siguientes.Entradas Pila del sprint y grfico de avance (burn-down) actualizados con la informacin de la reunin anterior. Informacin del avance de cada miembro del equipo.Resultados Pila del sprint y grfico de avance (burn-down) actualizados. Identificacin de posibles necesidades e impedimentos.Formato de la reuninSe recomienda realizarla de pie junto a un tablero con la pila del sprint y el grfico de avance del sprint, para que todos puedan compartir la informacin y anotar. En la reunin est presente todo el equipo, y pueden asistir tambin otras personas relacionadas con el proyecto o la organizacin, aunque stas no pueden intervenir.En esta reunin cada miembro del equipo de desarrollo explica: Lo que ha logrado desde el anterior scrum diario. Lo que va ha hacer hasta el prximo scrum diario. Si estn teniendo algn problema, o si prev que puede encontrar algn impedimento.Y actualiza sobre la pila del sprint el esfurezo que estima pendiente en las tareas que tiene asignadas, o marca como finalizadas las ya completadas. Al final de la reunin: El equipo refresca el grfico de avance del sprint, con las estimaciones actualizadas, El Scrum Master realiza las gestiones adecuadas para resolver las necesidades o impedimentos identificados.El equipo es el responsable de esta reunin, no el Scrum Master; y no se trata de una reunin de inspeccin o control sino de comunicacin entre el equipo para compartir el estado del trabajo, chequear el ritmo de avance y colaborar en posibles dificultades o impedimentos.Revisin del sprint

La reunin de revisin del sprint es uno de loseventosde scrum tcnico.DescripcinReunin realizada al final del sprint para comprobar el incremento. . No debe durar ms de 4 horas, en el caso de revisar sprints largos. Para sprints de una o dos semanas, con una o dos horas de duracin debera ser suficiente. Objetivos: El propietario del producto comprueba el progreso del sistema. Esta reunin marca, a intervalos regulares, el ritmo de construccin, y la trayectoria que va tomando la visin del producto. El propietario del producto identifica las funcionalidades que se pueden considerar hechas y las que no. Al ver y probar el incremento, el propietario del producto, y el equipo en general obtienen feedback relevante para revisar la pila del producto. Otros ingenieros y programadores de la empresa tambin pueden asistir para conocer cmo trabaja la tecnologa empleada.Precondiciones Se ha concluido el sprint. Asiste todo el equipo de desarrollo, el propietario del producto, el Scrum Master y todas las personas implicadas en el proyecto que lo deseen.Entradas Incremento terminado.Resultados Feedback para el propietario del producto: hito de seguimiento de la construccin del sistema, e informacin para mejorar el valor de la visin del producto. Convocatoria de la reunin del siguiente sprint.Formato de la reuninEs una reunin informal. El objetivo es ver el incremento realizado. Estn prohibidas las presentaciones grficas y powerpoints. El equipo no debe invertir ms de una hora en desarrollar la reunin, y lo que se muestra es el resultado final: terminado, probado y operando en el entorno del cliente (incremento). Segn las caractersticas del proyecto puede incluir tambin documentacin de usuario, o tcnica. Es una reunin informativa. Su misin no es la toma de decisiones ni la crtica del incremento. Con la informacin obtenida, posteriormente el propietario del producto tratarn las posibles modificaciones sobre la visin del producto. Protocolo recomendado:1. El equipo 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. Esta parte genera informacin valiosa para que el propietario del producto y el equipo en general, puedan mejorar la visin del producto.4. El Scrum Master, de acuerdo con las agendas del propietario del producto y el equipo, cierra la fecha para la reunin de preparacin del siguiente sprint.

RetrospectivaNombre de la reunin en la que el equipo analiza la forma de trabajo para su mejora continua. Las reuniones retrospectivas son por tanto un una meta-prctica gil.Aunque es frecuente realizarlas al final de cadasprint, no deben confundirse con las reuniones derevisin del sprint.El objetivo de la revisin del sprint es analizar QU se est construyendo, mientras que una reunin retrospectiva se centra en CMO lo estamos construyendo: CMO estamos trabajando, con el objetivo de analizar problemas y aspectos mejorables.Algunas tcnicas: Estrella de mar Barco Seis sombreros para mejorar

Estrella de mar

Tcnica o protocolo para usar enreuniones retrospectivas. Proporciona retroinformacin del equipo para mejorar la eficiencia. El facilitador anima a los participantes a escribir en etiquetas adhesivas qu qu cosas indicaran en cada una de las siguientes categoras para mejorar la eficiencia de la forma forma de trabajo y la calidad del resultado:1. Empezar a hacer2. Dejar de hacer3. Hacer menos4. Seguir haciendo5. Hacer msPara grupos grandes (ms de 7 - 9 personas) en retrospectivas que analizan el trabajo de periodos de trabajo largos se recomienda dividir en subgrupos para focalizar en cada uno un rea diferente de anlisis: requisitos, pruebas, gestin con cliente etc.Tras la exposicin y comentario se deciden las actividades que se van a empezar a aplicar (hacer ms, menos, suprimir) a partir del siguiente ciclo.

Barco

Tcnica o protocolo para usar enreuniones retrospectivas. Proporciona retroinformacin del equipo para mejorar la eficiencia. El facilitador anima a los participantes a escribir en etiquetas adhesivas qu qu cosas consideran que impulsan la eficiencia y cules implican un rozamiento o freno en el funcionamiento.En una pizarra se dibuja un barco, con motor, velas o remos y un ancla o anclas.

Sobre la parte de las velas (o motor o marineros segn el tipo de barco) se sitan las etiquetas con tcnicas, herramientas, y en general todo aquello que se ha apuntado como "impulsores". Sobre el ancla o las anclas se colocan las cosas que frenan o entorpecen el avance.Tras la exposicin y comentario se deciden las acciones que se van a tomar en el siguiente ciclo.

Seis sombreros para mejorar

Protocolo para usar enreuniones retrospectivas, desarrollado sobre el mtodo para discusiones y toma de decisiones en grupo conocido como "mtodo de los seis sombreros para pensar" o "mtodo de los seis sombreros" (Infomacin del mtodo en Wikipedia).Con la ayuda de este protocolo el equipo analiza las prcticas y modos de trabajo desde la ltima reunin retrospecitva para determinar acciones de mejora. El moderador de la reunin registra las aportaciones de cada sombrero en una pizarra o rotafolios. Las realizadas en ltimo lugar con el sombrero rojo son las acciones de mejora.

Se recomienda realizar la reunin sentados en crculo, pero sin una mesa en en medio, y mantenindose el moderador y la pizarra de registro fuera de l. El moderador comienza la reunin explicando brevemente el mtodo de discusin en equipo de los seis sombreros, y que la reunin consiste en hacer 6 iteraciones de anlisis y discusin sobre las tcnicas y mtodos de trabajo. Cada iteracin se har con la perspectiva de un color.Si durante la reunin algn miembro opina de forma no adecuada para el color con el que se est trabajando en ese momento, el moderador se lo debe hacer saber de forma inmediata y reconducir el enfoque.La discusin se realiza en el orden definido por este mtodo:1. Azul (5 minutos): para discutir los objetivos de la reunin y apuntarlos en la pizarra.2. Blanco (10 minutos): el equipo seala todo aquello que desde la ltima retrospectiva pueda servir como informacin y hechos objetivos.3. Amarillo (10 minutos): aspectos positivos ocurridos desde la ltima reunin.4. Negro (10 minutos): aspectos negativos ocurridos desde la ltima reunin.5. Verde (10 minutos): propuestas para solucionar problemas, aadir valor al producto o ayudar en cualquier aspecto.6. Rojo (5 minutos): Cada participante puede escribir un par de ideas, acciones o propuestas.

Terminados los 6 colores, se dedica un tiempo breve para el cierre de la reunin, en donde se determinan cules van a ser las acciones de mejora que se van a tomar. No se recomienda que sean ms de dos, y deben ser concretas y realizables.

RolesLos roles en un marco de scrum tcnico son: Propietario del producto Equipo de desarrollo Scrum Master

Todas las personas que intervienen, o tienen relacin directa o indirecta con el proyecto, se clasifican en dos grupos: comprometidos e implicados. En crculos de Scrum es frecuente llamar a los primeros (sin la menor connotacin peyorativa) cerdos y a los segundos gallinas. El origen de estos nombres est en la siguiente metfora que ilustra de forma grfica la diferencia entre compromiso e implicacin con el proyecto:Una gallina y un cerdo paseaban por la carretera. La gallina pregunt al cerdo: Quieres abrir un restaurante conmigo?.El cerdo consider la propuesta y respondi: S, me gustara. Y cmo lo llamaramos?. La gallina respondi: Jamn con huevos. El cerdo se detuvo, hizo una pausa y contest: Pensndolo mejor, creo que no voy a abrir un restaurante contigo. Yo estara realmente comprometido, mientras que tu estaras slo implicada.

Una observacin en este punto, sobre el rol de Scrum Master, por ser en ocasiones frecuente la duda de considerar si es un rol comprometido o implicado. Partiendo de que la divisin entre personas comprometidas y personas implicadas es ms conceptual que relevante, pero cuando se trabaja con este rol presente, su responsabilidad es el funcionamiento de un scrum tcnico en la organizacin. Su responsabilidad directa, su misin, es por tanto la forma de trabajo, siendo por tanto el producto elaborado en los proyectos un objetivo de segundo nivel, o indirecto. Por esta razn en el cuadro anterior no se considera el rol de Scrum Master, aunque que en cualquier caso no es una cuestin especialmente relevante. Si hubiera que forzar una respuesta, desde el criterio de que no est comprometido en el proyecto (sino en la mejora de la forma de trabajo) se debera considerar como un rol "implicado"

Propietario del producto

El propietario del producto es uno de losrolesde scrum tcnico.El propietario del producto (product owner) es quien toma las decisiones del cliente. Su responsabilidad es el valor del producto.

Para simplificar la comunicacin y toma de decisiones es necesario que este rol recaiga en una nica persona. Si el cliente es una organizacin grande, o con varios departamentos, puede adoptar la forma de comunicacin interna que consideren oportuna, pero en el equipo de desarrollo slo se integra una persona en representacin del cliente, y sta debe tener el conocimiento suficiente del producto y las atribuciones necesarias para tomar las decisiones que le corresponden.

En resumen, el propietario de producto es quien: Decide en ltima instancia cmo ser el resultado final, y el orden en el que se van construyendo los sucesivos incrementos: qu se pone y qu se quita de la pila del producto, y cul es la prioridad de las funcionalidades. Conoce el plan del producto, sus posibilidades y plan de inversin, as como del retorno esperado a la inversin realizada, y se responsabiliza sobre fechas y funcionalidades de las diferentes versiones del mismo.

En los desarrollos internos para la propia empresa, suele asumir este rol el product manager o el responsable de marketing. En desarrollos para clientes externos, el responsable del proceso de adquisicin del cliente. Segn las circunstancias del proyecto es posible incluso que delegue en el equipo de desarrollo, o en alguien de su confianza, pero la responsabilidad siempre es suya.

Para ejercer este rol es necesario: Conocer perfectamente el entorno de negocio del cliente, las necesidades y el objetivo que se persigue con el sistema que se est construyendo. Tener la visin del producto, as como las necesidades concretas del proyecto, para poder priorizar eficientemente el trabajo. Disponer de atribuciones y conocimiento del plan del producto suficiente para tomar las decisiones necesarias durante el proyecto, incluidas para cubrir las expectativas previstas de retorno de la Inversin del proyecto. Recibir y analizar de forma continua retroinformacin del entorno de negocio (evolucin del mercado, competencia, alternativas) y del proyecto (sugerencias del equipo, alternativas tcnicas, pruebas y evaluacin de cada incremento).

Es adems recomendable que el propietario de producto: Conozca scrum para realizar con solvencia las tareas que le corresponden: Desarrollo y administracin de la pila del producto. Exposicin de la visin e historias de usuario, y participacin en la reunin de planificacin de cada sprint. Conozca y haya trabajado previamente con el mismo equipo.La organizacin debe respetar sus decisiones y no modificar prioridades ni elementos de la pila del producto.

Equipo de desarrollo

El equipo de desarrollo es uno de losrolesde scrum tcnico.

Lo forman el grupo de profesionales que realizan el incremento de cada sprint.

Se recomienda que un equipo scrum tenga entre 4 y 8 personas. Ms all de 8 resulta ms difcil mantener la comunicacin directa, y se manifiestan con ms intensidad los roces habituales de la dinmica de grupos (que comienzan a aparecer a partir de 6 personas). En el cmputo del nmero de miembros del equipo de desarrollo no se consideran ni el Scrum Master ni el propietario del producto.

No se trata de un grupo de trabajo formado por un arquitecto, diseador o analista, programadores y testers. Es un equipo multifuncional, en el que todos los miembros trabajan de forma solidaria con responsabilidad compartida. Es posible que algunos miembros sean especialistas en reas concretas, pero la responsabilidad es el incremento de cada sprint y recae sobre el equipo de desarrollo en conjunto.

Las principales responsabilidades, ms all de la autoorganizacin y uso de tecnologas giles, son las que se marcan la diferencia entre grupo de trabajo y equipo. Un grupo de trabajo es un conjunto de personas que realizan un trabajo, con una asignacin especfica de tareas, responsabilidades y siguiendo un proceso o pautas de ejecucin. Los operarios de una cadena, forman un grupo de trabajo: aunque tienen un jefe comn, y trabajan en la misma organizacin, cada uno responde por su trabajo.

El equipo tiene espritu de colaboracin, y un propsito comn: conseguir el mayor valor posible para la visin del cliente. Un equipo scrum responde en su conjunto. Trabaja de forma cohesionada y autoorganizada. No hay un gestor para delimitar, asignar y coordinar las tareas. Son los propios miembros los que lo realizan.

En el equipo: Todos conocen y comprenden la visin del propietario del producto. Aportan y colaboran con el propietario del producto en el desarrollo de la pila del producto. Comparten de forma conjunta el objetivo de cada sprint y la responsabilidad del logro. Todos los miembros participan en las decisiones. Se respetan las opiniones y aportes de todos. Todos conocen el modelo de trabajo con scrum.

Scrum Master

Scrum Master es uno de losrolesdescrum tcnico.Es el responsable del cumplimiento de las reglas de un marco de scrum tcnico, asegurando que se entienden en la organizacin, y se trabaja conforme a ellas.

Proporciona la asesora y formacin necesaria alpropietario del productoy alequipo. Realiza su trabajo con un modelo de liderazgo servil: al servicio y en ayuda del equipo y del propietario del producto.

Proporciona: Asesora y formacin al equipo para trabajar de forma autoorganizada y con responsabilidad de equipo. Revisin y validacin de la pila del producto. Moderacin de las reuniones. Resolucin de impedimentos que en elsprintpueden entorpecer la ejecucin de las tareas. Gestin de las dinmicas de grupo en el equipo. Configuracin, diseo y mejora continua de las prcticas de scrum en la organizacin. Respeto de la organizacin y los implicados, con las pautas de tiempos y formas de scrum.

Al crecer la fluidez de la organizacin y evolucionar hacia un marco descrum ms pragmtico, puede eliminarse el rol de Scrum Master, cuando estas responsabilidades ya estn institucionalizadas en la organizacin.

Introduccin a las mtricas giles

Por qu medir?La informacin es la materia prima para la toma de decisiones, y la que puede ser cuantificada proporciona criterios objetivos de gestin y seguimiento.

Desde el nivel concreto de la programacin, hasta los ms generales de la gestin global de la organizacin, tres son los fondos de escala o niveles 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 primero se puede medir, por ejemplo, la proporcin de polimorfismo del cdigo de un programa, en el segundo, el porcentaje del plan del proyecto realizado, y en el tercero, tambin por ejemplo, el nivel de satisfaccin laboral.

Flexibilidad y sentido comnMedir es costosoAntes de incorporar un procedimiento de medicin, se debe cuestionar su conveniencia, y la forma en la que se aplicar.Medir no es un fin en s mismoNo se deben implantar procesos de medicin simplemente por que s. Tomar una lista ms o menos prestigiosa de mtricas, e incorporarla a los procedimientos de la empresa puede seducir, al ofrecer un marco de trabajo monitorizado con indicadores y mediciones, pero no dice mucho a favor de las razones por las que se han adoptado.Criterios para el diseo y aplicacin de mtricasCuantas menos, mejor Medir es costoso. Medir aade burocracia. El objetivo de un equipo scurm es ofrecer la mejor relacin valor / simplicidad.

Aspectos que deben cuestionarse antes de monitorizar y medir un indicador: Por qu? Qu valor proporciona esta medicin? Qu valor se pierde si se omite?El objetivo de scrum es producir el mayor valor posible de forma continua, y la cuestin clave para la incorporacin de indicadores en la gestin de proyectos es:Cmo contribuye el uso del indicador en el valor que el proyecto proporciona al cliente?

El indicador es apropiado para el fin que se debe conseguir?Medir no es, o no debera ser, un fin en s mismo. Cul es el fin? Cumplir agendas, mejorar la eficiencia del equipo, las previsiones? Sea crtico. Si despus de analizarlo no le convence, si prefiere no incorporar un indicador, o cambiarlo: usted es el gestor. Determinar qu medir es la parte ms difcil. En el mejor de los casos, las decisiones errneas slo supondrn un coste de gestin evitable; pero muchas veces empeorarn lo que se intentaba mejorar.

Ejemplo: Medicin de la eficiencia de los trabajos de programacinLa organizacin XYZ ha adoptado mtricas estndar de eficiencia de Ingeniera del Software: LOC/Hour: Nmero total de lneas de cdigo nuevas o modificadas en cada hora. Adems para aumentar la productividad, ha vinculado los resultados de esta mtrica a la retribucin por desempeo de los programadores, de forma que ha logrado producir ms lneas de cdigo sin incrementar la plantilla. Para evitar que se trate de un incremento hueco de lneas de cdigo, o aumente el nmero de 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: Test Defects/KLOC, Compile Defects/KLOC y Total Defects/KLOC, para controlar que no crezca el nmero de errores deslizados en el cdigo. Tambin se han incorporado indicadores appraisal time para medir tiempo y costes del diseo y la ejecucin de las revisiones de cdigo. Y por temor a que el sistema de medicin pueda resultar excesivamente costoso se incluyen indicadores de coste de calidad (COQ) que miden los tiempos de revisin y los contrastan con las mejoras en los tiempos eliminados por reduccin de fallos. Lo que vamos a medir es un indicador vlido de lo que queremos conocer? Hay tareas de programacin relativamente mecnicas, orientadas ms a la integracin y configuracin que en al desarrollo de nuevos sistemas. Para aquellas puede resultar medianamente acertado considerar la eficiencia como volumen de trabajo realizado por unidad de tiempo. Para las segundas sin embargo, es ms apropiado pensar en la cantidad de valor integrado por unidad de desarrollo; expresadas stas en horas, iteraciones o puntos de funcin. Qu queremos conocer: la cantidad de lneas, o el valor entregado al cliente? Est relacionado lo uno con lo otro? Se puede medir objetivamente el valor entregado al cliente? En nuestro trabajo son muchos los parmetros que se pueden medir con criterios objetivos y cuantificables: el tiempo de tarea, los tiempos delta, y los de las interrupciones, el n de puntos de funcin, la inestabilidad de los requisitos, la proporcin de acoplamiento, el n de errores por lnea de cdigo No estaremos muchas veces midiendo esto, simplemente porque es cuantificable? No estaremos midiendo el n de lneas que desarrollan las personas cuando en realidad queremos saber el valor de su trabajo? No nos estar pasando lo mismo cuando pretendemos medir: la facilidad de uso, la facilidad de mantenimiento, la flexibilidad, la transportabillidad, la complejidad, etc.?

Velocidad, trabajo y tiempo

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 / TiempoAs por ejemplo, se puede decir que la velocidad de un equipo de 4 miembros es de 20 puntos por semana o de 80 puntos por sprint.

TiempoPara mantener un ritmo de avance continuo, el desarrollo gil emplea dos tcticas posibles: incremento iterativo, o incremento continuo

El avance a travs de incrementos iterativos mantiene el ritmo apoyndose en pulsos de sprints. Por esta razn emplea normalmente el sprint como unidad de tiempo, y expresa la velocidad como trabajo o tareas realizadas en un sprint. Nota:scrum tcnicousaincremento iterativo, y por tanto define la velocidad como la cantidad de trabajo realizado en unsprint.

El avance a travs de unincremento continuomantiene un flujo de avance constantesin puntos muertos ni cuellos de botella. No hay sprints, y por tanto las unidades de tiempo son das, semanas o meses, de forma que que la la velocidad se espresa en puntos (cantidad de trabajo) por semana, da, o mes

Tiempo real y tiempo idealUna observacin importante: la diferencia entre tiempo real y tiempo ideal.

Tiempo real, es el tiempo de trabajo. Equivale a la jornada laboral.

Para un equipo de cuatro personas con jornada laboral de ocho horas el tiempo real en una semana (cinco das laborables) es: 4 * 8 * 5 = 160 horasTiempo ideal se refiere sin embargo al tiempo de trabajo en condiciones ideales, esto es, eliminando todo lo que no es estrictamente trabajo, suponiendo que no hay ninguna pausa por interrupcin o atencin de cuestiones ajenas a la tarea y que la persona se encuentra en buenas condiciones de concentracin y disponibilidad.

El tiempo ideal se emplea normalmente en estimaciones, como unidad de trabajo o esfuerzo necesario. Ej: Esa tarea tiene un tamao de 3 horas ideales. Es un concepto similar al quePSPdenomina Delta Time como la parte del tiempo laboral que es realmente tiempo efectivo de trabajo.

Tiempo ideal no se emplea como unidad de tiempo sino de trabajo o esfuerzo necesario.TrabajoMedir el trabajo puede ser necesario por dos razones: para registrar el ya hecho, o para estimar anticipadamente, el que se debe que realizar. En ambos casos se necesita una unidad, y un criterio objetivo de cuantificacin.Trabajo ya realizadoMedir el trabajo ya realizado no entraa especial dificultad.

Se puede hacer con unidades relativas al producto (p. ej. lneas de cdigo) o a los recursos empleados (coste, tiempo de trabajo)

Para medirlo, basta contabilizar lo ya realizado con la unidad empleada: lneas de cdigo, puntos de funcin, horas trabajadas, etc.

La gestin de proyectos gil no mide el esfuerzo realizado para calcular el avance del trabajo.

La gestin gil no determina el grado de avance del proyecto por el trabajo realizado, sino por el pendiente de realizar.Es posible que otros procesos de la organizacin necesiten registrar el esfuerzo invertido, y por lo tanto sea necesario su registro, pero no debe emplearse para calcular el avance del proyecto.

Trabajo pendiente de realizarScrum mide el trabajo pendiente para: Estimar esfuerzo y tiempo previsto para realizar un trabajo (tareas,historias de usuariooepics). Determinar el avance del proyecto, y en especial en cada sprint.Determinar con precisin, de forma cuantitativa y objetiva el trabajo que necesitar la construccin de un requisito, es un empeo cuestionableEl trabajo necesario para realizar de un requisito o una historia de usuario no se puede prever de forma absoluta, porque las funcionalidades no son realidades de solucin nica, y en el caso de que se pudiera, la complejidad de la medicin hara una mtrica demasiado pesada para la gestin gil.

Y si no resulta posible estimar con precisin la cantidad de trabajo que hay en un requisito, tampoco se puede saber cunto tiempo necesitar, porque adems de la incertidumbre del trabajo, se suman las inherentes al tiempo: No es realista hablar de la cantidad o de la calidad del trabajo que realiza una persona por unidad de tiempo, porque son muy grandes las diferencias de unas personas a otras. Una misma tarea, realizada por una misma personar requerir diferentes tiempos en o situaciones distintas.Sobre estas premisas: No es posible estimar con precisin, ni el trabajo de un requisito, ni el tiempo necesario para desarrollarlo. La complejidad de las tcnicas de estimacin crece exponencialmente en la medida que: Intentan incrementar la fiabilidad y precisin de los resultados. Aumenta el tamao del trabajo estimado.

La estrategia empleada por la gestin gil es: Trabajar con estimaciones aproximadas. Estimar con la tcnica juicio de expertos. Descomponer las tareas en subtareas ms pequeas, si las estimaciones superan rangos de medio, o un da de tiempo real.

Unidades de trabajoUn trabajo puede dimensionarse midiendo el producto que se construye, como los tradicionales puntos de funcin de COCOMO; o el tiempo que cuesta realizarlo.En gestin gil se suelen emplear puntos como unidad de trabajo, empleando denominaciones como puntos de historia o simplemente puntos puntos. La unidad Story Point de eXtreme Programming se define como la cantidad de trabajo que se realiza en un da ideal.Cada organizacin, segn sus circunstancias y su criterio institucionaliza su mtrica de trabajo definiendo el nombre y las unidades. Puede definir su punto Como tamao relativo de tareas conocidas que normalmente emplea. Ej: El equipo de un sistema de venta por internet, podra determinar que un punto representara el tamao tiene un listado de las facturas de un usuario. En base al tiempo tiempo ideal necesario para realizar el trabajo. Ej: Un equipo puede determinar que un punto es el trabajo realizado en 4 horas ideales.

Es importante que la mtrica empleada, su significado y la forma de aplicacin sea consistente en todas las mediciones de la organizacin, y conocida por todas las personas:

Que se trate de un procedimiento de trabajo institucionalizado.

VelocidadVelocidad es la magnitud determinada por la cantidad de trabajo realizada en un periodo de tiempo.

Velocidad en scrum tcnico es la cantidad de trabajo realizada por el equipo en un sprint. As por ejemplo, una velocidad de 150 puntos indica que el equipo realiza 150 puntos de trabajo en cada sprint.

Al trabajar en implantaciones de scrum pragmtico, que pueden realizar sprints de diferentes duraciones, o no siempre con el mismo nmero de miembros en el equipo, la velocidad se expresa indicando la unidad de tiempo y en su caso tambin si se refiere a la total del equipo, o a la media por persona. As por ejemplo: La velocidad media del equipo es de 100 puntos por semana. La velocidad media de una persona del equipo es de 5 puntos por da.

Incremento iterativo

Incremento iterativoAvance incremental del proyecto basado en pulsos de tiempo o timeboxing.Las entregas parciales (incrementos) se realizan en ciclos de tiempo breves (Sprints o iteraciones) de duracin prefijada, normalmente entre una semana y un mes y medio. Al inicio de cada ciclo se estima cunto trabajo se puede realizar y qu parte del proyecto se realizar.

Tiempo prefijado"Timeboxing" en inglsTcnica de administracin de tiempo, comnmente empleada en los modelos de gestin gil, consistente en dividir el trabajo en tareas con una asignacin de tiempo limitado y corto para su ejecucin. Facilita la priorizacin de los objetivos. Combate la ley de Parkinson (tendencia a dilatar el tiempo de cada tarea) y la procrastinacin. Incrementa los tiempos de transicin entre tareas, tiles para recuperar el ritmo y tomar retro-informacin de la evolucin del trabajoTrabajar con una tcnica de timeboxing requiere: Definicin clara de los objetivos. Reduccin de las interrupciones.

Incremento continuo

Incremento continuo

Historia de usuarioDescripcin de una funcionalidad que debe incorporar un sistema de software, y cuya implementacin aporta valor al cliente.La estructura de una historia de usuario est formada por: Nombre breve y descriptivo. Descripcin de la funcionalidad en forma de dilogo o monlogo del usuario describiendo la funcionalidad que desea realizar. Criterio de validacin y verificacin que determinar para considerar terminado y aceptable por el cliente el desarrollo de la funcionalidad descrita.Y adicionalmente por la informacin que resulte necesaria por el modelo de implementacin: Prioridad, Riesgo, Tamao, etc.Ejemplos:

Ejemplo de historia de usuario

Ejemplo de historia de usuario

EpicSe denomina Epic a unahistoria de usuarioque por su gran tamao, el equipo descompone en historias con un tamao ms adecuado para ser gestionada con los principios y tcnicas giles: estimacin y seguimiento cercano (normalmente diario).Trminos relacionados: Tema Historia de usuario Tarea Requisitos giles

Grfico de productoEl grfico de producto o grfico burn up es una herramienta de planificacin propia delpropietario de producto, que presenta visualmente la evolucin previsible del producto.Proyecta en el tiempo la construccin del producto, en base a lavelocidaddel equipo.La proyeccin se realiza sobre un diagrama cartesiano que representa en el eje de ordenadas el esfuerzo estimado para construir las diferentes historias de la pila del producto, y en el de las abscisas el tiempo medido en sprints.

Ejes del grfico de productoEjemploConvenciones empleadas por el equipo: Unidad para medicin del trabajo:puntos de scrum. Est previsto trabajar consprintsde duracin fija mensual (20 das laborables). El equipo est formado por 4 personas y desarrolla una velocidad media de 400 puntos por sprint.

Equipo de 4 personas velocidad de 400 puntos por sprint

Se traza en el grfico la lnea que representa el ritmo de avance previsto segn la velocidad media del equipo (en este ejemplo 400 puntos por sprint).Es recomendable trazar tambin los ritmos de avance con una previsin pesimista y otra optimista. Se dibujan basndose en informacin de los proyectos anteriores que han ido peor y mejor de lo previsto, o en su defecto estableciendo un margen segn el criterio del equipo (ej. +- 20%).

Ejes del grfico de productoA continuacin se toma lapila del producto.En este caso, el propietario del producto tiene previsto lanzar la versin 1.0 cuando disponga de las cuatro primerashistorias, que tienen un esfuerzo estimado de 950 puntos (150+250+250+300).Adems, segn refleja la imagen siguiente, tambin tiene esbozadas las previsiones para las versiones posteriores 1.1 y 1.2.

Pila de producto y versiones previstas

Para trazar la previsin se sita cada versin en el eje vertical en la posicin correspondiente al esfuerzo estimado para construir todas las historias que incluye.Siguiendo con el ejemplo, la posicin de la versin 1.0 se situara sobre el valor 950 del eje de ordenadas:

Se sitan las versiones previstas sobre el eje de ordenadas.

Los puntos de corte que marca esta posicin con las lneas de velocidad del equipo (pesimista, realista y optimista) proyectan en el eje horizontal la fecha o sprint en el que se completar la versin.

Pila de producto y versiones previstas

Esta es una herramienta para desarrollo gil.Proyecta la previsin de la pila del producto, que es un documento vivo cuya evolucin preestablece la del producto. Como herramienta gil no debe considerarse para representar planes estables, sino las previsiones tras cada evolucin de la pila del producto.

Punto de funcinTambin llamado en gestin gil: punto de scrum.Unidad de medida relativa que determina la cantidad de trabajo necesaria para construir una funcionalidad o historia de usuario.

Grfico de avanceEl grfico de avance o burndown es el grfico que actualiza el equipo en las reuniones de seguimiento del sprint, para monitorizar el ritmo de avance, y detectar de forma temprana posibles desviaciones sobre la previsin que pudieran comprometer la entrega al final de sprint.La estrategia gil para el seguimiento de los proyectos se basa en: Medir el esfuerzo que falta, no el realizado. Realizar un seguimiento muy cercano (diario de ser posible).Este grfico debe ser actualizado diariamente, y se registra: En el eje Y se registra el trabajo que an falta por realizar. En el eje X se registran los das del sprint.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. Esto es: 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.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.El avance ideal de un sprint estara representado por la diagonal que reduce el esfuerzo pendiente de forma continua y gradual hasta terminarlo en el ltimo da del sprint:

La superficie marcada muestra el esfuerzo pendienteLas grficas de diagonal perfecta no son lo habitual, y la siguiente imagen es un ejemplo de un patrn de avance ms normal.

El siguiente sera el aspecto de la grfica en un sprint subestimado

La estimacin que realiz el equipo en la reunin de inicio del sprint es inferior al esfuerzo real que estn requiriendo las tareas. Y el siguiente sera el patrn de grfica de un sprint sobrestimado.

Estimacin de pquerEs una prctica gil, para conducir las reuniones en las que se estima el esfuerzo y la duracin de tareas. James Grenning ide este juego de planificacin para evitar discusiones dilatadas que no terminan de dar conclusiones concretas.El modelo inicial de Grenning consta de 8 cartas, con los siguientes valores: , 1, 2, 3, 5, 6, 7 e infinito. Las mismas fueron desarrolladas para dar soporte a las estimaciones de versin eneXtreme Programming.

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 de xhoras ideales(el tamao mximo considerado por el equipo para una tarea), se levanta la carta infinito. Las tareas que exceden el tamao mximo deben descomponerse en subtareas de menor tamaoCada 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.

Variante: sucesin de FibonacciBasado en el hecho de que al aumentar el tamao de las tareas aumenta tambin el margen de error, surgi una variante que consiste en emplear nmeros de la sucesin de Fibonacci para realizar las estimaciones, de forma que: El juego de cartas est compuesto por nmeros en sucesin de Fibonacci. La estimacin no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo boca arriba la carta con la cifra ms aproximada a la estimacin.As, si por ejemplo una persona cree que el tamao adecuado de una tarea es 6, se ve obligado a reconsiderar y, o bien aceptar que parte de la incertidumbre apreciada no es tal y levantar la carta de 5, o bien aceptar una estimacin ms conservadora y levantar el 8.En particular, los nmeros de esta variacin del Planning Pquer son: 0, , 1, 2, 3, 5, 8, 13, 21, infinito.

Si se quiere emplear la planificacin de pquer para estimar requisitos a nivel de producto o de versin (funcionalidades, temas) adems de usarlo al nivel de tareas de sprint, se pueden aadir cartas al juego para permitir estimaciones de mayor tamao (34, 55, 89, 144, etc.)Es frecuente emplear una carta con un smbolo de duda o interrogacin para indicar que, por las razones que sean, no se puede precisar una estimacin. Tambin es posible incluir otra carta con alguna imagen alusiva, para indicar que se necesita un descanso.

Operativa Cada participante de la reunin tiene un juego de cartas. Para cada tarea (historia de usuario o funcionalidad, segn sea el nivel de requisitos que se va a estimar) el cliente, moderador o propietario del producto expone la descripcin empleando un tiempo mximo. Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las posibles preguntas del equipo. Cada participarte selecciona la carta, o cartas que representan su estimacin, y las separa del resto, boca abajo. Cuando todos han hecho su seleccin, se muestran boca arriba. Si la estimacin resulta infinito, por sobrepasar el lmite mximo establecido, la tarea debe dividirse en sub-tareas de menor tamao. Si las estimaciones resultan muy dispares, quien asume la responsabilidad de gestionar la reunin, con su criterio de gestin, y basndose en las caractersticas del proyecto, equipo, reunin, n de elementos pendientes de evaluar, puede optar por: Preguntar a las personas de las estimaciones extremas: Por qu crees que es necesario tanto tiempo?, y por qu crees que es necesario tan poco tiempo? Tras escuchar las razones, repetir la estimacin. Dejar a un lado la estimacin de esa tarea y retomar al final o en otro momento aquellas que hayan quedado pendientes. Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las funcionalidades resultantes. Tomar la estimacin menor, mayor, o la media.Este protocolo de moderacin, evita en la reunin los atascos de anlisis circulares en ping-pong entre diversas opciones de implementacin, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora de tiempo de estimacin de una funcionalidad, a escasos minutos, consigue alcanzar consensos sin discusiones, y adems resulta divertido y dinamiza la reunin.

Extreme programmingeXtreme Programming (XP) o programacin extrema es un conjunto de prcticas giles formuadas porKent Becken el libro que dio origen a su difusin como metodologa gil: "Extreme Programming Explained: Embrace Change" (Beck).Extreme Programming considera que las modificaciones de requisitos constantes son un aspecto natural, inevitable e incluso deseable en los desarrollos de software, configurndose de esta forma (como todos los modelos giles) en un modelo enfocado en la adaptabilidad antes que en la previsibilidad.Los principios originales de la programacin extrema son: simplicidad, comunicacin, retroalimentacin y coraje. En la segunda edicin de Extreme Programming Explained, se aadi un quinto principio: respeto.

Tiempo idealTambin llamado tiempo de tarea.Tiempo que se estima necesario para realizar una tarea en condiciones ideales: sin ninguna interrupcin, llamadas telefnicas, descansos, reuniones, etc.Es el concepto similar al quePSP(Personal Software Process) denomina "Delta Time".