Sie sind auf Seite 1von 29

CURSO: Mtricas giles

Apuntes
Rev. 1.0

http://www.scrummanager.net/ok

Scrum Manager Proyectos


Apuntes de formacin
Tema: Mtricas giles

Informacin de derechos y licencia de uso: http://www.safecreative.org/work/0910094662926

Ms informacin: http://www.scrummanager.net/ok

Contenido
Contenido Prlogo Apuntes de formacin Scrum Manager Plataforma abierta para consulta y formacin profesional Scrum Manager Medicin: consideraciones Introduccin Por qu medir? Flexibilidad y sentido comn Criterios para el diseo y aplicacin de mtricas Cuantas menos, mejor El indicador es apropiado para el fin que se debe conseguir? Medicin de la eficiencia en la empresa Medicin del avance del proyecto Medicin de la eficiencia de los trabajos de programacin Lo que vamos a medir es un indicador vlido de lo que queremos conocer? Resumen Medicin: Las Unidades Velocidad, trabajo y tiempo Tiempo Trabajo Trabajo ya realizado Trabajo pendiente de realizar Unidades de trabajo Velocidad Resumen Medicin: Usos y herramientas Grfico de producto: Ejemplo: Grfico de avance: monitorizacin del sprint Estimacin de pquer Variante: sucesin de Fibonacci Funcionamiento Resumen NOTAS 4 5 7 7 9 11 11 11 11 11 12 12 12 12 13 13 15 17 17 17 17 17 18 19 19 21 23 23 24 25 26 26 27 29

2005-2009 ScrumManager - http://www.scrummanager.net

Prlogo

Prlogo

Apuntes de formacin Scrum Manager


Es un recurso educativo abierto (OER) y forma parte de la plataforma Scrum Manager Open Knowledge. Son los apuntes del curso abierto: Mtricas giles, disponible en http://scrummanager.net/ok/

Se puede emplear de forma gratuita para consulta y auto-formacin a ttulo personal.

Plataforma abierta para consulta y formacin profesional Scrum Manager


Scrum Manager Open Knowledge es una plataforma de acceso libre para consulta y formacin, est disponible en http://scrummanager.net/ok/ donde encontrars la ltima versin de este curso, adems de otros materiales, foros, talleres, etc. Un punto abierto en la Red para consultar y compartir conocimiento, y mantenerte profesionalmente actualizado.

Ms informacin: http://www.scrummanager.net http://www.scrummanager.net/ok formacin@scrummanager.net

2008 2005-2009 ScrumManager - http://www.scrummanager.net

Medicin: consideraciones

Medicin: consideraciones

Introduccin
Por qu medir?
La informacin es la materia prima de la toma de decisiones, y la que puede ser objetivamente cuantificada proporciona criterios objetivos de gestin y seguimiento. Desde los niveles concretos de la programacin, hasta los ms amplios de la gestin global de la compaa, Scrum Management 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.

No se deben implantar procesos de medicin tan slo porque s. Tomar una lista ms o menos prestigiosa de mtricas e incorporarla a los procedimientos de la empresa, puede tentar por la imagen de profesionalidad que transmitir un escenario de trabajo monitorizado con indicadores y complejas mediciones, pero no dice mucho a favor de cmo se han analizado y adaptado esas mtricas a la realidad de los proyectos y la empresa.

Criterios para el diseo y aplicacin de mtricas


Cuantas menos, mejor
Medir es costoso Medir aade burocracia El objetivo de Scrum Management es trabajar con la mejor relacin valor / simplicidad.

En el primero se puede medir, por ejemplo, la proporcin de polimorfismo del cdigo de un programa, en el segundo, el porcentaje de trabajo realizado, y en el tercero, tambin por ejemplo, el nivel de satisfaccin laboral. Este curso cubre el rea de gestin de proyectos, desde una perspectiva gil; pero en esta introduccin se exponen consideraciones generales, comunes a los tres.

Cuestiones para cada indicador: Por qu se va a usar? Cul es el valor por incorporarlo? Cul por omitirlo? Se pueden tomar decisiones de gestin sin esa informacin? La cita No se puede gestionar lo que no se puede medir, por la redondez de su forma, tienta a considerarla incuestionable. Se desarrollan as patrones de gestin que renuncian a la experiencia, capacidad y sentido comn del gestor, incluso en las ocasiones en las que ste puede ser suficiente; y se termina reclamando mtricas, produciendo gestores mecanicistas. El sentido comn puede bastar, por ejemplo, para tomar decisiones de gestin de personal en una empresa de ingeniera de 10 empleados, sin necesidad de procedimientos de medicin del clima laboral; pero sin embargo stos son necesarios en empresas con cientos de personas en sedes y departamentos diferentes. El objetivo de la gestin Scrum es el valor, y la cuestin clave para la incorporacin de indicadores en la gestin de proyectos es: Cmo contribuye el uso de este indicador en el valor que el proyecto va a aportar al cliente?

Flexibilidad y sentido comn


Medir es costoso Antes 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 mismo

2005-2009 ScrumManager - http://www.scrummanager.net

11

Medicin: consideraciones

La implantacin del indicador ha dado buenos resultados: desde su puesta en marcha, el departamento de RR.HH. 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 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. El que lo haga, o diga que lo hace la mayora, no es una razn. Si despus de analizarlo no le convence, si prefiere no incorporar esa mtrica, o modificarla: 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. La organizacin XYZ 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


La 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 motivar la productividad, ha vinculado los resultados de esta mtrica a la retribucin por desempeo de los programadores. 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: Test Defects/KLOC, Compile Defects/KLOC y Total Defects/KLOC, para controlar que no aumenten el nmero de errores deslizados en el cdigo. Tambin se incorporaron indicadores appraisal time para medir tiempo y costes del diseo y la ejecucin de las revisiones de cdigo.

Medicin de la eficiencia en la empresa


La organizacin XYZ, dedicada al desarrollo de software, est integrando un sistema de calidad y mejora integral para toda la empresa, que incluye mtricas para conocer el grado de eficiencia en cada departamento. Para el de RR.HH. se ha diseado e implantado un indicador habitual para estos casos, que determina la eficiencia en los procesos de seleccin de personal. Mide el coste de cada proceso de seleccin (anuncios, seleccin de currculos, entrevistas) y lo divide por el nmero de puestos cubiertos. Como no slo es importante la eficiencia, sino tambin la satisfaccin del cliente (interno en este caso, que ser el departamento que solicita personal) esta mtrica se combina con otra para determinarlo: tiempo de respuesta. Cunto tiempo se tarda en cubrir las vacantes.
12 2008 ScrumManager Project http://www.scrummanager.net

Medicin: consideraciones Y por el temor a que el sistema de medicin pueda resultar excesivamente costoso se incorporan tambin 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.

En el diseo e implantacin de mtricas se debe considerar: Usar el menor nmero de mtricas posible. El indicador es apropiado para el fin que se debe conseguir? Lo que vamos a medir es un indicador vlido de lo que queremos conocer?

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 de programa, o el valor que entregamos 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.?

Resumen
Las mtricas se pueden aplicar en el nivel de gestin de la organizacin, de gestin de los proyectos o de construccin de la solucin tcnica.
2005-2009 ScrumManager - http://www.scrummanager.net 13

Medicin: Las Unidades

Medicin: Las unidades distraccin o atencin a tareas ajenas a la tarea del sprint que se tiene asignada. 2 Es el concepto similar al que PSP denomina Delta Time.

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 en por unidad de tiempo. Velocidad = Trabajo / Tiempo

Trabajo
Medir el trabajo puede ser necesario por dos razones: para registrar el 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.

Tiempo
El desarrollo gil emplea la tcnica timeboxing para gestin de tiempo. En el caso de Scrum, la unidad de tiempo para cada incremento de producto es el Sprint.
1

Tiempo real y tiempo ideal


Antes de continuar, una observacin: la diferencia, al hablar de tiempo, entre tiempo real y tiempo ideal.

Trabajo ya realizado
Medir 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, empleando las unidades con las que se opere: lneas de cdigo, horas trabajadas (reales o tericas) Medir el trabajo realizado NO es una mtrica gil. LA GESTIN GIL NO DETERMINA EL GRADO DE AVANCE DEL PROYECTO POR EL TRABAJO YA REALIZADO, SINO POR EL PENDIENTE DE REALIZAR

Tiempo real, es el efectivo de trabajo. Es equivalente 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 horas El tiempo real de ese equipo en un sprint de 12 das de trabajo es: 4 * 8 * 12 = 384 horas Sin embargo el trmino tiempo ideal se refiere al tiempo de trabajo necesario, en condiciones ideales, esto es, sin ninguna interrupcin, pausa,
1

Es posible que otros procesos de la organizacin necesiten registrarlo y medirlo, pero no la gestin gil de proyectos.

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 o epics). Determinar el avance del proyecto, y en especial en cada sprint.
Personal Software Process 17

Timeboxing, se suele traducir por tiempo limitado es un aspecto comn de las metodologas giles, que marcan iteraciones para cada incremento, determinando qu tareas se van a realizar, y en qu tiempo. 2005-2009 ScrumManager - http://www.scrummanager.net

Medicin: Las unidades Descomponer las tareas de los sprints en sub-tareas ms pequeas, si las estimaciones superan los rangos de las 16-20 horas de de trabajo.

Para Scrum Management, estimar con precisin, de forma cuantitativa y objetiva el trabajo que necesitar la construccin de un requisito, es un empeo ms que cuestionable. El trabajo de un requisito no se puede cuantificar de forma absoluta, porque las funcionalidades no son realidades de solucin nica. La cantidad de trabajo que consumir cada funcionalidad o cada historia de usuario no se puede calcular de forma absoluta y objetiva; y en el caso de que se pudiera, la complejidad de la medicin hara que la mtrica resultante fuera 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 costar, 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 da, o por hora, porque hay diferencias muy grandes de estos resultados, segn las personas. Una misma tarea, realizada por las mismas personas consumir diferentes tiempos reales en entornos de trabajo diferentes.

Unidades de trabajo
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.

La gestin gil suele llamar a las unidades que emplea para medir el trabajo puntos, puntos de funcionalidad puntos de historia As por ejemplo la unidad de medida Story Point de eXtreme Programming define: la cantidad de trabajo que se realiza en un da de trabajo ideal. Cada organizacin, segn sus circunstancias y su criterio institucionaliza su mtrica de trabajo definiendo el nombre y las unidades. Puede basarse en Estimacin del tamao relativo y emplear puntos Estimacin del tiempo ideal necesario para realizar la tarea que se mide. 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:

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: o Intentan incrementar la fiabilidad y precisin de los resultados. o Aumenta el tamao de la tarea estimada.

La estrategia empleada por la gestin gil es:


18

No empearse en estimaciones precisas. Estimar con la tcnica juicio de expertos


2005-2009 Navegapolis - http://www.navegapolis.net

Medicin: Las unidades Que se trate de un procedimiento de trabajo institucionalizado. No profundiza en estimaciones precisas. Emplea la tcnica de juicio de expertos Descompone las tareas de los sprints en subtareas ms pequeas, si las estimaciones superan los rangos de las 16-20 horas de de trabajo.

Velocidad
Velocidad es la magnitud que viene determinada por la cantidad de trabajo realizada en un periodo de tiempo (Timebox) Los equipos que miden el trabajo con tiempo ideal, hablan de Velocidad. Decir, por ejemplo, que la velocidad del equipo en el sprint ha sido de 23, se refiere a que han completado tareas que medan en toral 23 story points. 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, lo importante no son los nombres, ni merece la pena entrar en cuestiones bizantinas.

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.

Resumen
Tiempo real: tiempo total de trabajo, equivale a la jornada laboral Tiempo ideal: Tiempo de trabajo en condiciones ideales, esto es: sin ninguna interrupcin, pausa, distraccin, o atencin a tareas ajenas a la que se tiene asignada en el sprint. Para determinar el grado de avance de un proyecto, la gestin gil no mide el trabajo ya realizado, sino el pendiente de realizar. Tomando como 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: o Intentan incrementar la fiabilidad y precisin de los resultados. o Aumenta el tamao de la tarea estimada.

La estrategia empleada por la gestin gil es:

2005-2009 ScrumManager - http://www.scrummanager.net

19

Medicin: Usos y herramientas

Grfico de producto:
En ingls: grfico 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. Es un diagrama cartesiano que representa en el eje de ordenadas el trabajo estimado para desarrollar el producto, y en el de abcisas las fechas, medidas segn las duraciones previstas para los sprints.

primeros temas, y su estimacin inicial de trabajo para llevarlos a cabo es de 950 puntos.

La versin 1.1 incluir 3 temas ms que, segn la estimacin inicial, supondrn unos 750 puntos de trabajo. Y estn tambin trazados los temas con los que piensa cerrar la versin 1.2, que se prevn con 850 puntos ms de trabajo. Para representar el plan del producto con un Burn-Up, se representan, con los fondos de escala apropiados: Eje X = Fechas de los sprints previstos Eje Y = Puntos de trabajo

Ejemplo:
Representacin del plan del producto, a partir de los temas previstos en la pila de producto (product backlog). Convenciones empleadas por el equipo: 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.

A continuacin se traza en el grfico la lnea de velocidad prevista. Siguiendo con el ejemplo, la lnea roja de la imagen representa la velocidad de 300 puntos por sprint. Tambin puede resultar til esbozar una estimacin optimista y otra pesimista para tener la visin de una holgura de fechas aceptable.

La figura siguiente representa la situacin actual 3 del pila del producto (product backlog: ) el propietario del producto tiene previsto cerrar la versin 1.0 cuando disponga de los cuatro

Las listas de producto y de versin evolucionan de forma continua durante la vida del producto.

Medicin: Usos y herramientas

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.

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. La figura siguiente muestra un ejemplo de pila en el sexto da del sprint: las tareas terminadas ya no tienen esfuerzo pendiente, y del esfuerzo total previsto para el sprint: 276 puntos (A), en el momento actual quedan 110 (B).

Grfico de avance: monitorizacin del sprint


Tambin se suele emplear la denominacin inglesa: grfico burn-down. 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 de sprint. La estrategia gil para el seguimiento de los proyectos se basa en: Medir el esfuerzo que falta, no el realizado. Seguimiento muy cercano (diario de ser posible).

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

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.

24

2005-2009 ScrumManager - http://www.scrummanager.net

Medicin: Usos y herramientas 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 sobre-estimado.

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:

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. El modelo inicial de Grening consta de 8 cartas, con los nmeros representados en siguiente figura, porque James lo ide para las estimaciones de versin en eXtreme Programming, con equipos que emplean como unidad de esfuerzo: das de trabajo de cada par de 4 programadores y trabajan con tareas de tamao 5 mximo de 10 das.

Las 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 sub-estimado

4 5

eXtreme Programming trabaja con programacin por parejas. Las tareas de mayor tamao se descomponen en sub-tareas hasta que stas tienen estimaciones mximas de 10 das. 2005 - 2009 ScrumManager Project http://www.scrummanager.net 25

Medicin: Usos y herramientas 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 10 horas (o del 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. Lo relevante no es el nmero de cartas, la unidad de medida empleada, o si el tamao mximo de tarea debe ser 5, 7 10 das, sino trabajar con el modelo que el equipo considera ms apropiado, respetando los principios siguientes: 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 al misma unidad de medida (story points, das, horas) en todos los grficos y pilas.

Si se quiere emplear la planificacin de pker 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) 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.

Funcionamiento
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

Variante: sucesin de Fibonacci


Basado en el hecho de que al aumentar el tamao de las tareas, aumenta tambin el margen de error, se ha desarrollado una variante que consiste en emplear slo nmeros de la sucesin de Fibonacci para realizar las estimaciones, de forma que: El juego de cartas est compuesto por nmeros de la 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.

Para estimar tareas puede ser vlido un juego de cartas como ste:

26

2005-2009 ScrumManager - http://www.scrummanager.net

Medicin: Usos y herramientas 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. Natural: los participantes pueden estimar el esfuerzo con la cifra exacta que crean ms adecuada. Fibonacci: las estimaciones solo se pueden realizar empleando nmeros de la sucesin de Fibonacci. En cada caso, el juego de cartas empleado tiene la numeracin apropiada.

Este protocolo de reunin evita 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.

Resumen
El grfico de producto o burn-up, muestra en un vistazo el plan general de desarrollo del producto. A partir de la velocidad del equipo y estimaciones de trabajo previstas en la pila producto, representa las fechas o sprints en que previsiblemente se irn terminando diferentes versiones. las del los las

El grfico de avance o burn-down es una herramienta gil que monitoriza el ritmo de trabajo (normalmente de un sprint). En el eje vertical de un diagrama cartesiano representa el trabajo pendiente a lo largo del tiempo del sprint (eje horizontal). Las desviaciones sobre, o bajo la lnea diagonal que representara el avance ideal del sprint alertan de forma temprana de desviaciones sobre el ritmo de desarrollo previsto. La estimacin de pker es una prctica gil para reducir las dificultades habituales en las reuniones de trabajo para planificacin por juicio de expertos. En ella los participantes emplean un juego de cartas para concretar las unidades de esfuerzo que estiman para cada tarea. Hay dos variantes:

2005 - 2009 ScrumManager Project http://www.scrummanager.net

27

NOTAS

Das könnte Ihnen auch gefallen