Professional Documents
Culture Documents
.
Pizarra de corcho laminado y chinchetas para sujetar las fichas.
Pizarra de acero vitrificado y soportes magnticos para sujetar las fichas
.
2
En organizaciones en fase de implementacin de Scrum, en organizaciones con experiencia y madurez en gestin gil, en las que ya
no hay un rol especfico para garantizar el funcionamiento de Scrum, se refiere al puesto que haya asumido el rol (calidad, procesos,
team leader...)
Marco estndar de Scrum
28 2005 - 2013 ScrumManager Project http://www.scrummanager.net
Con cinta adhesiva removible se marcan lneas para delimitar:
Un rea superior donde el Scrum Master coloca al principio de la reunin la capacidad real del sprint
a 3, 4 y 5 semanas (A); y al final (D), las notas con: el objetivo establecido, duracin del sprint,
funcionalidades de la pila del producto comprometidas, hora fijada para las reuniones diarias y fecha
prevista para la reunin de revisin del sprint.
B.- Una franja para ordenar los elementos de la pila del producto de mayor a menor prioridad.
C.-Una franja paralela para descomponer cada elemento de la pila del producto en las
correspondientes tareas de la pila del sprint.
Seguimiento del sprint
Descripcin
Reunin diaria breve, de no ms de 15 minutos, en la que cada miembro del equipo informa al resto sobre
las tareas en las que est trabajando, si se ha encontrado o prev encontrarse con algn impedimento, y
actualiza sobre la pila del sprint las ya terminadas, o los tiempos de trabajo que les quedan.
Precondiciones
Los miembros del equipo han desarrollado las tareas definidas.
Se han identificado inconvenientes (o no).
Entradas
Pila del sprint y grfico de avance (burn-down) actualizados con la informacin de la reunin anterior.
Informacin de las tareas realizadas por cada componente del equipo.
Resultados
Pila del sprint y grfico de avance (burn-down) actualizados.
Identificacin de necesidades e impedimentos.
Formato de la reunin
Se recomienda realizarla de pie y emplear un formato de pila de tareas en una pizarra, junto con el grfico
de avance del sprint, para que todo el equipo pueda ver y anotar.
En la reunin est presente todo el equipo, y pueden asistir tambin otras personas relacionadas con el
proyecto o la organizacin, pero stas no pueden intervenir.
Cada miembro del equipo expone estas tres cuestiones:
1.- Tarea en la que trabaj ayer.
2.- Tarea o tareas en las que trabajar hoy.
3.- Si ha tenido algn inconveniente , o va a necesitar alguna cosa especial o prev algn impedimento para
realizar su trabajo.
Y actualiza sobre la pila del sprint el tiempo de trabajo que queda pendiente en las tareas que tiene
asignadas, o marca como finalizadas las ya completadas.
Al final de la reunin:
El equipo refresca el grfico de avance del sprint, con las estimaciones actualizadas,
El Scrum Master comienza la gestin de necesidades e impedimentos identificados.
Marco estndar de Scrum
2005-2013 ScrumManager - http://www.scrummanager.net
29
Revisin del sprint
Descripcin
Reunin realizada al final del sprint en la que, con una duracin mxima de 4 horas, el equipo presenta al
propietario del producto, clientes, usuarios, gestores, y otros el incremento construido en el sprint.
Objetivos:
El propietario del producto obtiene informacin objetiva del progreso del sistema. Esta reunin marca,
a intervalos regulares, el ritmo de construccin del sistema y la trayectoria que va tomando la visin
del producto.
Al ver y probar el incremento, el propietario del producto, y el equipo en general obtienen feedback
clave para definir la evolucin y dar ms valor a la pila del producto.
Otros ingenieros y programadores de la empresa tambin pueden asistir para conocer cmo trabaja
la tecnologa empleada.
El Scrum Master o el responsable de procedimientos de la organizacin obtiene retroinformacin
sobre buenas prcticas y problemas durante el sprint, necesaria para las prcticas de ingeniera de
procesos y mejora continua de la implementacin.
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.
Feedback para el Scrum Master: buenas prcticas y problemas durante el sprint.
Convocatoria de la reunin del siguiente sprint.
Formato de la reunin
Es una reunin informal. El objetivo es ver el incremento y trabajar en el entorno del cliente. 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.
Se trata de una reunin informativa. NO TIENE UNA MISIN ORIENTADA A TOMAR DECISIONES, NI A
CRITICAR EL INCREMENTO. Con la informacin generada en la preparacin del siguiente sprint se
expondrn y tratarn las posibles modificaciones sobre la visin del producto.
Un protocolo recomendado es el siguiente:
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 sobre lo visto. Esta parte genera informacin muy valiosa
para que el propietario del producto, y el equipo en general, puedan mejorar el valor de la visin del
producto.
Marco estndar de Scrum
30 2005 - 2013 ScrumManager Project http://www.scrummanager.net
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.
Retrospectiva
Desde la premisa de flexibilidad de Scrum Manager, se puede considerar tambin la realizacin de
reuniones retrospectivas al final de cada sprint, o de cada versin de producto o cada cierto periodo de
tiempo. Al igual que los modelos de procesos incorporan prcticas de ingeniera de procesos para
conseguir una mejora continua de su capacidad, en agilidad tambin van surgiendo prcticas para lo que es
el equivalente de mejora continua de la agilidad de la organizacin.
El hecho de que se realicen normalmente al final de cada sprint lleva a veces a confusin y a tomarlas como
reuniones de revisin de sprint, cuando suele ser aconsejable considerarlas como diferentes, porque sus
objetivos son diferentes.
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.
Las reuniones "retrospectivas" realizadas de forma peridica por el equipo para revisar y mejorar la forma
de trabajo, se consideran cada vez ms un componente del marco estndar de Scrum, si bien no es una
reunin para seguimiento de la evolucin del producto, sino para mejora del marco de trabajo.
Roles en el marco estndar de Scrum
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.
COMPROMETIDOS (CERDOS) IMPLICADOS (GALLINAS)
Propietario del producto
Otros interesados (direccin,
gerencias, comerciales,
marketing, etc.)
Miembros del equipo
Ilustracin 8: Roles estndar de Scrum
Propietario del producto: es la persona responsable de lograr el mayor valor de producto para los
clientes, usuarios y resto de implicados.
Equipo de desarrollo: grupo o grupos de trabajo que desarrollan el producto.
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, lo cierto es que en las
Marco estndar de Scrum
2005-2013 ScrumManager - http://www.scrummanager.net
31
organizaciones en las que se emplea, el rol de Scrum Master, tiene su responsabilidad directa en el
funcionamiento del marco Scrum en la organizacin. Su objetivo de responsabilidad directa es la mejora
de la organizacin y la mejora o resultado de los proyectos es por tanto un objetivo o resultado indirecto
a travs de la mejora de la organizacin.
Por esta razn en el cuadro anterior no se considera el rol de Scrum Master, considerando, 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 organizacin) se debera
considerar como un rol "implicado"
Valores
El marco estndar de Scrum es la carrocera de un vehculo que se asienta y tiene su motor en los
principios giles. Es una ayuda para organizar a las personas y el flujo de trabajo, como lo pueden ser otras
propuestas de formas de trabajo gil: Crystal, DSDM, otros.
La carrocera sin motor, sin los valores que dan sentido al desarrollo gil no funciona, y stos son:
Delegacin de atribuciones (empowerment) al equipo para que pueda autoorganizarse y tomar las
decisiones sobre el desarrollo.
Respeto entre las personas. Los miembros del equipo deben confiar entre ellos y respetar sus
conocimientos y capacidades.
Responsabilidad y autodisciplina (no disciplina impuesta).
Trabajo centrado en el valor para el cliente y el desarrollo de lo comprometido.
Informacin, transparencia y visibilidad del desarrollo del proyecto.
El propietario del producto
El propietario del producto o product owner es quien toma las decisiones del cliente.
Para simplificar la comunicacin y toma de decisiones es necesario que las responsabilidades de gestin
del producto las asuma 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.
Se responsabiliza de la financiacin del proyecto, y las decisiones sobre fechas y funcionalidades de
las diferentes versiones del producto, y conoce las posibilidades y plan de inversin, as como el
retorno esperado de la inversin del proyecto.
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.
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 suficientes 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).
Marco estndar de Scrum
32 2005 - 2013 ScrumManager Project http://www.scrummanager.net
Es adems recomendable que el propietario de producto:
Conozca Scrum para realizar con solvencia las tareas que le corresponden:
o Desarrollo y administracin de la pila del producto.
o 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.
El equipo
Se recomienda que los equipos que trabajan con Scrum tengan entre 4 y 8 personas. Ms all de 8 resulta
ms difcil mantener la agilidad en la comunicacin directa, y se manifiestan con ms intensidad las
rigideces habituales de la dinmica de grupos (que comienzan a aparecer a partir de 6 personas).
No se trata de un grupo de trabajo formado por un arquitecto, diseador o analista, programadores y testers.
Es un equipo multidisciplinario, en el que todos los componentes trabajan de forma solidaria con
responsabilidad compartida
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. Trabajan de forma cohesionada y autoorganizada. No hay un
gestor para delimitar, asignar y coordinar las tareas. Son los propios miembros del equipo 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
Es el responsable del funcionamiento de Scrum en el proyecto, cubriendo los aspectos que la organizacin
necesite segn el conocimiento y experiencia con el modelo: Asesora y formacin al propietario del
producto.
Asesora y formacin al equipo.
Revisin y validacin de la pila del producto.
Moderacin de las reuniones.
Resolucin de impedimentos que en el sprint pueden 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.
En implementaciones no estndar o acadmicas, basadas en responsabilidades (no en roles) es habitual no
contar con un rol especfico de Scrum Master, y la garanta de funcionamiento de Scrum las funciones
propias del scrum Master las suele asumir un puesto especfico para contar con esta garanta (Team Leader
o Gestor gil).
2005-2013 ScrumManager - http://www.scrummanager.net
33
Medicin y estimacin gil
Marco estndar de Scrum
34 2005 - 2013 ScrumManager Project http://www.scrummanager.net
Por qu medir?
La informacin es la materia prima para 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 generales 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.
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.
Ilustracin 9: mbirtos de medicin
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.
Flexibilidad y sentido comn
Antes de incorporar un procedimiento de medicin, se debe cuestionar su conveniencia, y la forma en la que
se aplicar.
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.
Medir no es un fin en s mismo
Medir es costoso
Medicin y estimacin gil
2005-2013 ScrumManager - http://www.scrummanager.net
35
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.
Aspectos que deben cuestionarse antes de implantar la medicin y registro de un 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?
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?
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. Decir que eso lo miden casi todos, 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.
Un ejemplo: 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.
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.
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.
Marco estndar de Scrum
36 2005 - 2013 ScrumManager Project http://www.scrummanager.net
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.?
Un ejemplo: 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.
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.
Se podra considerar una buena mtrica?
Medicin: Las unidades
2005-2013 ScrumManager - http://www.scrummanager.net
37
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 / Tiempo
As 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.
Tiempo
Para mantener un ritmo de avance continuo, el desarrollo gil emplea dos tcticas posibles: incremento
iterativo, o incremento continuo.
Ilustracin 10: Agilidad con incremento iterativo o continuo
El avance a travs de incrementos iterativos mantiene un ritmo continuo basado en pulsos de
sprints. Por esta razn emplea normalmente el sprint como unidad de tiempo, expresando la velocidad
como trabajo o tareas realizadas en un sprint.
Nota En Scrum acadmico esta es la definicin de velocidad, porque el marco acadmico de scrum emplea
nicamente incremento iterativo (sprints).
El avance a travs de un incremento continuo ajusta un flujo regular de trabajo evitando puntos
muertos y cuellos de botella. En este caso, para medir el tiempo se emplean das, semanas o meses, de
forma que para expresar la velocidad se habla de trabajo (tareas, puntos) por semana (o por da, mes)
Medicin: Las unidades
38 2005-2013 Navegapolis - http://www.navegapolis.net
Tiempo real y tiempo ideal
Antes de continuar, una observacin: la diferencia que
se hace en la gestin gil al hablar de tiempo, entre
tiempo real y tiempo ideal.
Tiempo real, es el efectivo 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 horas
Ilustracin 11: Tiempo ideal y tiempo real
Sin embargo el trmino tiempo ideal no se emplea para medir tiempo, sino trabajo o esfuerzo necesario, y
normalmente en estimaciones, porque se refiere al tiempo que en condiciones ideales hara falta para
completar una tarea, considerando condiciones ideales: sin ninguna pausa por distraccin interrupcin o
atencin a tareas ajenas al trabajo.
As para determinar el trabajo que se estima, necesario para realizar una tarea se puede hablar de x horas
ideales.
Es un concepto similar al que PSP
3
denomina Delta Time como la parte del tiempo laboral que es
realmente tiempo efectivo de trabajo.
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 cuantificacin.
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 con la unidad empleada: lneas de cdigo, puntos de funcin,
horas trabajadas, etc.
Medir el trabajo realizado para estimar el porcentaje de trabajo realizado NO es una mtrica gil.
Es posible que otros procesos de la organizacin necesiten registrarlo y medirlo, y por lo tanto sea
necesario su registro, pero no debe emplearse para calcular el avance del proyecto.
3
Personal Software Process
La gestin gil no determina el grado de avance del proyecto por el trabajo realizado, sino por el
pendiente de realizar.
Tiempo ideal no es una unidad de tiempo, sino de trabajo o esfuerzo necesario.
Medicin: Las unidades
2005-2013 ScrumManager - http://www.scrummanager.net
39
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.
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.
Ilustracin 12: Medicin del trabajo pendiente
El trabajo necesario para realizar de un requisito o una historia de usuario no se puede predecir 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 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 llevarlo a cabo, 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 o situaciones de trabajo diferentes.
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:
No empearse en estimaciones precisas.
Estimar con la tcnica juicio de expertos
Descomponer las tareas de los sprints en subtareas ms pequeas, si las estimaciones superan los rangos
de un da de trabajo efectivo.
Medicin: Las unidades
40 2005-2013 Navegapolis - http://www.navegapolis.net
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.
Ilustracin 13: Velocidad
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 estimado como 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:
Que se trate de un procedimiento de trabajo institucionalizado.
Velocidad
Velocidad es la magnitud determinada por la cantidad de trabajo realizada en un periodo de tiempo
Velocidad en un marco acadmico de Scrum 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 con incremento continuo o en implantaciones flexibles de scrum, que pueden tener 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 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.
Medicin: usos y herramientas
Grfico de producto.
El grfico de producto o grfico burn up es una herramienta de planificacin propia del propietario del
producto, que presenta visualmente la evolucin previsible del producto. Proyecta en el tiempo su
construccin, en base a la velocidad del 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.
Ilustracin 14: Grfico de producto
Ejemplo
Convenciones empleadas por el equipo:
Unidad para medicin de trabajo: puntos de scrum.
Est previsto trabajar con sprints de duracin fija: mensual (20 das laborables)
El equipo est formado por 4 personas, y desarrolla una velocidad media de 400 puntos por sprint.
Ilustracin 15: Grfico de producto como plan de producto
Medicin: usos y herramientas
42 2005-2013 ScrumManager - http://www.scrummanager.net
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).
Ilustracin 16: Grfico de producto: velocidad prevista
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%).
Ilustracin 17: Grfico de producto: velocidad optimista y pesimista
A continuacin se toma la pila del producto. La figura siguiente representa la empleada en este ejemplo:
Medicin: usos y herramientas
2005 - 2013 ScrumManager Project http://www.scrummanager.net
43
Ilustracin 18: Ejemplo de pila del producto
En este caso, el propietario del producto tiene previsto lanzar la versin 1.0 cuando disponga de las cuatro
primeras historias, que tienen un esfuerzo estimado de 950 puntos (150+250+250+300).
Adems tiene tambin esbozadas las previsiones para versiones posteriores: 1.1 y 1.2 tal y como muestra
la figura siguiente:
Ilustracin 19: Versiones del producto 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:
Ilustracin 20: Representacin de la versin 1 sobre el grfico de producto
Medicin: usos y herramientas
44 2005-2013 ScrumManager - http://www.scrummanager.net
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.
Ilustracin 21: Previsin de fechas sobre el grfico de producto
De igual forma se pueden proyectar las estimaciones tempranas de las futuras versiones previstas.
Ilustracin 22: previsin de lanzamiento de versiones sobre grfico de producto
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. .
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 por el contrario se puede ver comprometida
la entrega prevista al final de sprint.
La estrategia gil para el seguimiento de los proyectos se basa en:
Medicin: usos y herramientas
2005 - 2013 ScrumManager Project http://www.scrummanager.net
45
Medir el esfuerzo que falta, no el realizado.
Seguimiento cercano del avance (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.
Ilustracin 23: Grfico de avance
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).
Ilustracin 24: Pila del sprint
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.
Medicin: usos y herramientas
46 2005-2013 ScrumManager - http://www.scrummanager.net
Ilustracin 25: De la pila del sprint al grfico de avance
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:
Ilustracin 26: Grfica de avance previsto
Las grficas de diagonal perfecta no son lo habitual, y la siguiente imagen es un ejemplo de un patrn de
avance ms normal.
Ilustracin 27: Grfica de avance real
El siguiente sera el aspecto de la grfica en un sprint subestimado
Medicin: usos y herramientas
2005 - 2013 ScrumManager Project http://www.scrummanager.net
47
Ilustracin 28: Grfica de avance de 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 sobreestimado .
Ilustracin 29: Grfica de avance de un sprint sobreestimado
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 programadores
4
y trabajan con historias de usuario de
tamao mximo de 10 das.
5
4
eXtreme Programming trabaja con programacin por parejas.
5
Las tareas de mayor tamao se descomponen en sub-tareas hasta que stas tienen estimaciones mximas de 10 das.
Medicin: usos y herramientas
48 2005-2013 ScrumManager - http://www.scrummanager.net
Ilustracin 30: Cartas para planificacin de pquer
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 historia), 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 o historia que se va a estimar.
Lo relevante no es el nmero de cartas, la unidad de medida empleada, o si el tamao mximo debe ser 5,
7 10 das, sino trabajar con el modelo que el equipo considera ms apropiado, respetando los principios
siguientes:
No estimar trabajos 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.
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:
Ilustracin 31: Cartas para estimacin de pquer (Fibonacci)
Medicin: usos y herramientas
2005 - 2013 ScrumManager Project http://www.scrummanager.net
49
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:
o 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.
o Dejar a un lado la estimacin de esa tarea y retomar al final o en otro momento aquellas
que hayan quedado pendientes.
o Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada
una de las funcionalidades resultantes.
o 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.
Tabla de ilustraciones
Ilustracin 1: Marco Scrum estndar ............................................................................................................... 17
Ilustracin 2: Incremento iterativo / continuo ................................................................................................... 20
Ilustracin 3: Diagrama del ciclo iterativo Scrum ............................................................................................ 20
Ilustracin 4: Requisitos completos / evolutivos .............................................................................................. 21
Ilustracin 5: Ejemplo de pila de producto....................................................................................................... 23
Ilustracin 6: Ejemplo de pila de sprint con hoja de clculo ............................................................................ 24
Ilustracin 7: Ejemplo de pizarra de trabajo .................................................................................................... 27
Ilustracin 8: Roles estndar de Scrum ........................................................................................................... 30
Ilustracin 9: mbirtos de medicin ................................................................................................................. 34
Ilustracin 10: Agilidad con incremento iterativo o continuo ........................................................................... 37
Ilustracin 11: Tiempo ideal y tiempo real ....................................................................................................... 38
Ilustracin 12: Medicin del trabajo pendiente ................................................................................................ 39
Ilustracin 13: Velocidad.................................................................................................................................. 40
Ilustracin 14: Grfico de producto .................................................................................................................. 41
Ilustracin 15: Grfico de producto como plan de producto ............................................................................ 41
Ilustracin 16: Grfico de producto: velocidad prevista ................................................................................... 42
Ilustracin 17: Grfico de producto: velocidad optimista y pesimista .............................................................. 42
Ilustracin 18: Ejemplo de pila del producto .................................................................................................... 43
Ilustracin 19: Versiones del producto previstas ............................................................................................. 43
Ilustracin 20: Representacin de la versin 1 sobre el grfico de producto .................................................. 43
Ilustracin 21: Previsin de fechas sobre el grfico de producto .................................................................... 44
Ilustracin 22: previsin de lanzamiento de versiones sobre grfico de producto .......................................... 44
Ilustracin 23: Grfico de avance .................................................................................................................... 45
Ilustracin 24: Pila del sprint ............................................................................................................................ 45
Ilustracin 25: De la pila del sprint al grfico de avance ................................................................................. 46
Ilustracin 26: Grfica de avance previsto ...................................................................................................... 46
Ilustracin 27: Grfica de avance real ............................................................................................................. 46
Ilustracin 28: Grfica de avance de un sprint subestimado ........................................................................... 47
Ilustracin 29: Grfica de avance de un sprint sobreestimado ....................................................................... 47
Ilustracin 30: Cartas para planificacin de pquer ........................................................................................ 48
Ilustracin 31: Cartas para estimacin de pquer (Fibonacci) ........................................................................ 48
ndice
Reunin
Planificacin del sprint, 25
Agilidad, 12
manifiesto, 13
principios, 14
Autoorganizacin, 16
Burn-down, 25, 44
Cerdo, 30
Colaboracin, 16
Desarrollo incremental, 16
Epic, 39
Equipo, 32
Estimacin de pker, 47
Fibonacci, 47
Exploracin, 22
gallina, 30
Grfico de avance, 25, 28, 44
Grfico de producto, 41
Historia de usuario, 39
Incremento, 20, 24
Incremento continuo, 20, 37
Incremento iterativo, 20, 37
James Grening, 47
Jeff Sutherland, 15
Manifiesto gil, 12
Mtricas, 34
Estrategia de la gestin gil, 39
Pila del producto, 20, 22
Pila del sprint, 20, 23
Plan de producto, 44
Producto
Plan, 44
Propietario del producto, 31
Puntos de historia, 40
Requisitos del sistema, 21
Requisitos del software, 21
Reunin
de pie, 16
Planificacin del sprint, 25, 26
Retrospectiva, 25, 30
Revisin del sprint, 29
Seguimiento del sprint, 25, 28
Roles, 30
Scrum, 15
elementos, 20
Origen, 15
reuniones, 20
roles, 20
Scrum Master, 32
Sprint, 15
sobreestimado, 46
subestimado, 46
Story Point, 40
Tiempo, 37
Tiempo ideal, 38
Tiempo real, 38
Trabajo, 38
Valores, 31
Velocidad, 37, 40