Está en la página 1de 92

Métricas

de
productiv
idad y
efectivida
d de la
entrega

Velocidad con que se completan objetivos/requisitos en cada iteración. Idealmente debería a
onsivi
dad a
neces
idade
s del
client
e,
Time
to
Marke
t,
tiemp
o de
servic
io),
en
funció
n de
la
critici
dad
de la
petici
ón
(urge
nte,
alor
de los
requis
itos
compl
etado
s,
para
comp
robar
si
existe
desali
neami
ento
con
los
objeti
vos
del
proye
cto y/
o la
estrat
egia

Métricas
de
resultado
s del
proyecto

Velocid
ad con
que se
aporta
valor al
negoci
o (desd
e el
punto
de vista
del
cliente).
Valor
acumul
ado.
Requisi
tos
comple
tados e
n la
iteració
n.

Próxi
mos
requis
itos a
desar
rollar.

Cam
bios
incor
pora
dos y
requi
sitos
añad
idos
sobre
el
alcan
ce
inicial
del
proye
cto.
Númer
o de
requisit
os
comple
tados
respect
o al
total de
requisit
os (mét
rica que
también
permite
observa
r
cambios
de
alcance)
.
Días de
trabajo
ideales
pendie
ntes (m
étrica
que
permite
proyect
ar la
fecha de
finalizaci
ón del
proyect
o).

Desvi
ación
de
result
ados
de
proye
cto
respe
cto a
planifi
cació
n
inicial
.

Métricas
de
situación
financiera
Retorno de Inversión (ROI) pendiente, el valor pendiente respecto al coste pendiente, para sa

Presup
uesto
disponi
ble y/o
presupu
esto
gastado.
Desvi
ación
financ
iera
respe
cto a
la
planifi
cació
n
inicial
.
Métricas
de
calidad

Expectat
ivas:
cción
del
cliente
/
usuario
,
respecto
a los
resultad
os del
proyect
o y a la
colabora
ción con
el

Ambient
e en el
equipo

Calidad
funcional
:
Incide
ncias
(defect
os
encont
rados
por el
cliente
o
usuari
os del
produc
to),
por
estado
y por
criticid
ad.

Errore
s (def
ectos
detect
ados
interna
mente,
bugs),
por
estado
y por
criticid
ad.

Cobert
ura de
las
prueb
as.
Trazab
ilidad.
Manteni
bilidad:
Cumpli
miento
de
estánda
res de
codificac
ión,
normati
vas,
regulaci
ones,
Coment
etc.
arios en
el
código.
Complej
idad
ciclomát
ica del
product
o.
Tamañ
o de
las
operac
iones.
Calida
d de la
docum
entaci
ón
(existe
ncia y
cobert
ura de
la
docum
entaci
ón
funcio
nal,
técnic
a, de
prueb
as, de
implan
tación,
operati
va,
etc.).

Métricas
de
riesgos,
impedime
ntos,
proceso y
mejora
continua
erando
lasde
pende
ncias
o
sinerg
ias
con
otros
equip
os o
proye
ctos,
la
implic
ación
del
client
e, los
probl
emas
tecnol
ógico
s,
el res
Leccion
es
aprendi
das.
Activid
ades de
mejora
a
planific
ar (co
munic
acion
es,
forma
cione
s,
sopor
te,
herra
mient
as,
etc.).
Uso
de
prácti
cas
espec
íficas:
núme
ro de
integr
acion
es,
tiemp
o de
refact
orizac
ión,
de
TDD,
revisi
ones
exper
tas,
etc.
Situaciones anómalas: sobreesfuerzo, requisitos no completados, terminaciones anormales d

% de
perso
nas
que
no
interv
ienen
en las
reuni
ones
diaria
s de
sincro
nizaci
ón.
Las métricas ágiles más importantes son:

El valor que se va entregando el cliente (Product Owner), que permite saber:

proye
cto
está
cump
liendo
con
las
expec
tativa
s del
client
e (un
objeti
vo no
aprob
ado
tiene
valor

Cuando ya no es interesante seguir con el proyecto.

La velo
cidad
de
desarro
llo del
equipo,
que
permite
:
fecha
de
finaliz
ación
del
proye
cto
y/o
saber
de
qué
objeti
vo/re
quisit
os se
dispo
ndrá
en
una
fecha
car
un
nuev
o
proye
cto a
partir
de la
histor
ia
anteri
dizaje
del
equip
o, ya
que
es
una
métri
ca
que
deber
ía
aume
ntar
Métricas
de
calidad
como
el núm
ero
de defe
ctos.
KPIs
para
medir
el
compr
omiso

Para medir
el
compromis
o del
equipo
podemos
utilizar los
siguientes
indicadores
:

Compromiso
= Puntos de
historia
planificados
y entregados
/ Puntos de
historia
planificados.
En este
caso se
incluyen
solo los
puntos de
historia
con los que
se inicia el
sprint y por
eso los
llamamos
“planificad
os”.

Compromiso
final =
Puntos de
historia
entregados /
Puntos de
historia
planificados.

Considera
mos todos
los puntos
de historia
entregados
incluyendo
los
planificado
s y los
añadidos
con el
sprint
iniciado y
lo
dividimos
por los
puntos de
historia
planificado
s.
KPIs
para
la
calida
d

Para medir
la calidad
del
producto
entregado
podemos
utilizar los
siguientes
indicadores
:

Numero de
incidencias
por sprint

KPIs
para
la
planifi
cación
Para medir
la
planificació
n del
equipo
podemos
utilizar los
siguientes
indicadores
:

Media de
puntos
añadidos por
sprint sin
considerar
las
incidencias

Media de
puntos de
historia
entregados
por sprint
Persona
s/
Equipo:
Aspecto
s
Human
os

Este grupo
de métricas
revelan los
problemas
que afectan
el lugar
sostenible y
el nivel de
compromis
o de un
equipo.
ea
transp
arenci
a con
respect
o a la
satisfa
cción
de los
miemb
ros del
equipo
.
Permit
e al
equipo
autoge
stionar
se y
mejora
r la
moral.
Para
ello se
puede
Mood
App:
Fue
diseña
do y
constr
uido
por
Atlassi
an
para
captur
ar los
comen
tarios
de los
emple
ados.
Team
Mood.
com:
Sigue
el
estado
de
ánimo
a nivel
de
equipo
con
alguno
s
análisi
s muy
agrada
bles.
baraja
de
cartas.
Los
miemb
ros del
equipo
votan
verde,
amarill
oo
rojo
para
cada
tarjeta
en la
reunió
n (o
antes
de la
reunió
n
como
una
encues
miemb
ros del
equipo
) han
aprend
ido.
Dirige
el
enfoqu
e a la
import
ancia
del
aprend
izaje.
Promu
eve el
aprend
izaje a
lo
largo
de un
proyec
to,
apoya
necido
cada
miemb
ro en
el
equipo
.
Fomen
ta
activid
ades
que
refleje
n la
perma
nencia
(tutorí
a para
los
nuevos
miemb
ros del
equipo
,
compa
rtir el
para
recibir
asisten
cia. Se
usa
para
evalua
r la
efectiv
idad
de las
activid
ades
de
interca
mbio
de
trabajo
,
docum
entaci
ón y
transfe
rencia
de
conoci
de
miemb
ros del
equipo
que
contrib
uyen a
un
ítem
de
trabajo
a lo
largo
de su
ciclo
de
vida.
Propor
ciona
una
métric
a
cuantit
ativa
para
evalua

Métricas
de la
salud
del
proceso
Esta
categoría
evalúa las
actividades
diarias del
equipo de
delivery
(entrega),
y evalúa
los cambios
del
proceso.

Lead
times
(tiemp
o
transc
urrido
entre
que un
cliente
realiza
un
pedido
y
recibe
el
produc
to
solicit
ado),
Trabaj
o en
progre
so
(WIP)
en las
diferen
Cycle
time
(cantid
ad de
tiempo
necesa
ria
para
compl
etar un
ítem),
prome
dio,
prome
dio
móvil,
desvia
ción
estánd
ar.
Obser
va la
dispers
ión
para
Porcen
taje de
Compl
eto y
Exacto
: Mide
el
númer
o de
ítems
compl
etados
y
acepta
bles
(de
calida
d) para
ayudar
al
equipo
en
mejora
r el
deliver
y.
existen
te
entre
el
Tiemp
o
dedica
do a
trabaja
r en un
ítem y
el
Tiemp
o que
espera
el
ítem.
El
equipo
puede
usarlo
para
calibra
r los
límites
la
cantid
ad de
tiempo
que un
ítem
estuvo
bloque
ado
mientr
as se
lo
compl
etaba.
Se
utiliza
para
determ
inar el
costo
de la
demor
ay
propon
er
medid
de
bloque
adores
: Mues
tra la
agrupa
ción y
frecue
ncia de
ítems
bloque
adores.
Ayuda
a
identif
icar las
mayor
es
fuente
s de
retraso
y
propon
er
mitiga
ciones

Métricas
de
release
(lanzami
ento)
Dirigen su
enfoque
hacia la
identificaci
ón de
impedimen
tos para el
delivery
continuo.

ren en
la
produc
ción.
Se
utiliza
para
identif
icar las
causas
raíz de
por
qué el
defect
o no se
detecta
antes
del
release
.
Tambi
én
permit
e crear
un
acuerd
evadid
o.
Propor
ciona
clarida
d
sobre
el
costo
no
planifi
cado
de
resolv
er
defect
os
evadid
os. Se
utiliza
para
ayudar
al
equipo
a
cliente
.
Fomen
ta la
asocia
ción
entre
el
equipo
y el
cliente
. El
objetiv
o final
es un
alto
porcen
taje de
release
s
acepta
dos
como
resulta
do de
un
o de
produc
ción.
Se
utiliza
para
estable
cer un
consen
so
sobre
el
costo /
tiempo
sosteni
ble
para el
release
en
produc
ción,
con el
objetiv
o final
de una
que el
equipo
realizó
el
release
de su
produc
to a
los
usuari
os
finales
. Poner
el
produc
to en
manos
de los
usuari
os
permit
e a los
equipo
s
incorp
orar
(planif
icada
y/o no
planifi
cada)
permit
e
consid
erar
factore
s
econó
micos
al
decidir
cuánd
o/sí se
lanzar
á.
Fomen
ta las
inversi
ones
para
reducir
el
mente
una
excele
nte
experi
encia
para el
cliente
, una y
otra
vez en
el
tiempo
"?
Podría
n estar
movié
ndose
rápido,
pero
¿se
están
movie
ndo
rápido
en la
nuevos
usuari
os
obteni
dos
por el
release
. Se
utiliza
para
evalua
r el
ROI
en el
desarr
ollo de
produc
tos y
validar
las
suposi
ciones
comer
ciales.
¿El

Métricas
de
desarrol
lo de
product
os
Ayudan a
medir la
alineación
de las
característi
cas del
producto
con las
necesidade
s del
usuario.

valor
comer
cial
propor
cionad
o por
cada
ítem,
epic,
feature

release
compl
etado.
Permit
e que
el
equipo
y los
Stakeh
olders
admini
stren
el
ROI,
la
cantid
ad de
riesgo
conoci
do y
no
mitiga
do que
se
muestr
a a lo
largo
de un
períod
o de
tiempo
.
Alient
a la
autoge
stión
del
equipo
para
reducir
ad de
ítems
compl
etados
y los
nuevos
items
agrega
dos.
Se
utiliza
para
evitar
que los
equipo
s se
vean
abrum
ados
con
trabajo
s que
puede
n
compr
de los
casos)
basada
s en el
rendim
iento
históri
co de
ítems
compl
etados.
Se usa
para
predec
ir
cuánd
o se
compl
etará
el
trabajo
futuro
utiliza
ndo el
recuen
to de
produc
to a un
colega
?
Permit
e
recopil
ar
feedba
ck de
los
usuari
os
sobre
si el
produc
to
satisfa
ce sus
necesi
dades,
y se
puede
utilizar
para
patron
es de
uso
emerg
entes
que
justific
an la
consid
eració
n de
futuras
inversi
ones.
Es
excele
nte
para
aumen
tar las
activid
ades
de
análisi
s de

Técnica
/
métricas
de
código

Ayudan a
determinar
la calidad
de la
implement
ación y la
arquitectur
a.
el
porcen
taje de
código
que ha
sido
revisa
do por
varios
tipos
de
prueba
s
autom
atizada
s. Guía
los
esfuer
zos/in
versio
nes
para
mejora
r la
cobert
ura de
Time
Build:
Mide
el
tiempo
de
compil
ación
y
ejecuci
ón de
prueba
s para
propor
cionar
feedba
ck al
equipo
de
desarr
ollo.
a,
determ
inado
por la
funcio
nalida
d o la
arquite
ctura
del
código
.
Ayuda
a
identif
icar
partes
de la
aplicac
ión/có
digo
donde
se
puede
mejora
cadas)
para
compl
etar un
ítem.
Se
puede
utilizar
para
evalua
r si la
cantid
ad de
código
modifi
cado
refleja
el ítem
aborda
do.
Promu
eve la
compr
ensión
de
frecue
ncia
con la
que los
miemb
ros del
equipo
cambi
an o
realiza
n
commi
t en la
base
del
código
. Se
utiliza
para
ilumin
ar,
evalua
ry
promo
ver la
determ
inada
por
una
herram
ienta.
Promu
eve
práctic
as de
ingeni
ería
para
crear
código
limpio
utiliza
ndo
datos
cuantit
ativos.
Permit
e al
equipo
evalua
utiliza
para
promo
ver los
estánd
ares de
codific
ación
acorda
dos
para
crear
código
limpio.
Permit
e el
aprend
izaje
en
equipo
para
alinear
mejor
el
código
con los
utiliza
para
realiza
r el
análisi
s de
causa
raíz
para
reducir
los
bloque
os.
Permit
e al
equipo
obtene
r
inform
ación
sobre
los
errores
del
produc

¿Cómo
elegir
las
métricas
?

Se debe
considerar
lo siguiente
al momento
de
seleccionar
las métricas
a utilizar:
1. ¿Por
qué
“esta
métric
a”? -
¿Por
qué es
import
ante?
¿A
quién
le
interes
a?

2.
¿Qué
ideas
podem
os
obtene
r de
“esta
métric
a”?
3.
¿Qué
se
espera
que
cambi
e?
¿Esta
mos
buscan
do
variabi
lidad,
consist
encia,
tenden
cias o
valore
s
absolu
tos?
¿Cóm
o
podría
ser
burlad
o,
usado
de
mala
maner
a (o
uso
indevi
5.
¿Cuále
s son
alguna
s
compe
nsacio
nes /
costos
de
mejora
?
¿Con
qué
frecue
ncia
nos
gustarí
a
"regist
rar los
datos"
7.
¿Cuánt
o
tiempo
llevare
mos a
cabo el
experi
mento
?
8.
¿Cóm
o saber
cuánd
o se ha
"termi
nado"
con
esta
métric
a?
9.
¿Cóm
o
hacer
que las
medici
ones
sean
transp
arentes
?
10.
¿La
métric
a es un
indica
dor
adelan
tado o
rezaga
do?

Recome
ndacion
es
No se
debe
intenta
r
utilizar
todas
la
métric
as al
mismo
tiempo
Es
.
recom
endabl
e
iniciar
con
una o
dos
métric
as,
luego
ir
agrega
ndo
otras
con el
tiempo
.
Depen
derá
del
equipo
elegir
qué
métric
as
consid
eran
útiles
para
probar.
Los
manag
ers y
coache
s no
puede
n
obligar
el uso
de
ningun
a
métric
a
específ
ica, ni
un
númer
o
mínim
o de
métric
as.
Ni los
equipo
s,
tampo
co los
manag
ers
deben
compa
rar las
métric
as
entre
los
equipo
s.
Cosas a realizar en el trabajo com
March 23, 2019 marcoviaweb Leave a comment

El
Scrum
Master

De acuerdo a la Guía de Scrum™:

El
Scrum
Master
es
respons
able de
promove
ry
apoyar
Scrum.
Los
Scrum
Masters
hacen
esto
ayudand
oa
todos a
entender
la teoría,
prácticas
, reglas
y valores
de
Scrum.
El
Scrum
Master
ayuda a
las
persona
s
externas
al
Equipo
Scrum a
entender
qué
interacci
ones
con el
Equipo
Scrum
pueden
ser útiles
y cuáles
no. El
Scrum
Master
ayuda a
todos a
modifica
r estas

La guía
también
especific
a los
servicios
que
brinda el
Scrum
Master
en su
interacci
ón con:
Produ
ct
Owner
Equip
o de
desarr
ollo, y
Organi
zación
guía, y
con el
objetivo
de que
los
Scrum
Masters
puedan
organiza
r sus
actividad
es
diarias,
comparti
mos
algunas
tareas
que
también
deberían
ser
consider
arlas, y
de esa
manera
alejar los
tristes
comenta
encuentr
an
basadas
en las
recomen
daciones
descritas
en “42
Tasks for
a Scrum
Master’s
Job” por
Bernd
Schiffer,
las
cuales
se
organiza
n en
diferente
s
agrupaci
ones
para
mostrar
sus
diferente
Reunion
es

Facilit
ar las
reunio
nes
para el
equipo
. Esto
incluy
e:
Prep
arac
ión
Mod
erac
ión
Proc
esa
mie
nto
post
erior
Celebr
ar
retros
pectiv
as.
Las
retros
pectiv
as por
ser
reunio
nes
especi
ales
se las
toma
en
cuenta
por
separa
do.

Dinámic
a del
equipo
Realiz
ar
coachi
ng a
miemb
ros del
equipo
(por
ejempl
o,
coachi
ngs
uno a
uno).

Mediar
conflic
tos.
Ayuda
r al
equipo
a
tomar
decisi
ones.

Fome
ntar la
autoor
ganiza
ción
del
equipo
de
desarr
ollo.
Mediar
el
conflic
to
gener
al de
objetiv
os
entre
el
equipo
de
desarr
ollo
(alta
calida
d
técnic
a) y el
Produ
ct
Owner
(más
featur
es).
una
unidad
cohere
nte
(por
ejempl
o, de
otras
áreas
de la
empre
sa que
desea
n
“quitar

person
as o el
tiempo
de las
person
as),
inclus
o de la
disolu
ción
compl
eta
Aprendi
zaje
Apren
der
contin
uamen
te
sobre
temáti
cas
relacio
nadas
a Agile
(por
ejempl
o,
visitar
comun
idades
,
asistir
a
confer
encias
, leer
libros,
escribi
r
blogs,
etc.).
Aseso
rar a
los
miemb
ros del
equipo
sobre
aspect
os
relacio
nados
a
Agile.
Ayudar al equipo a crear sus Radiadores de información.

Brinda
r
feedba
ck al
equipo
.ntar el
uso de
Práctic
as
ágiles
de
ingeni
ería
dentro
del
equipo
de
desarr
ollo
(por
ejempl
o, one
click
releas
es,
contin
uous
deliver
y,
featur
e
flags,
Desafi
ar al
equipo
con A
gile
manag
ement
innova
tions (
por
ejempl
o, Fed
Ex-
Days).

Conve
rsar
consta
nteme
nte
con
otros
Scrum
master
s de la
organi
zación
(por
ejempl
o, a
través
de una
Comu
nidad
de
práctic
a).

Realizar Gemba Walks.
Product
o

Ayudar a escribir o a realizar split de historias de usuarios.

Ayuda
ra
escribi
ro
adapta
r la
visión
del
produc
to.

Ayuda
ra
orden
ar los
items
del
Produ
ct
Backlo
g.
Ayuda
r con
la
elabor
ación
del
Relea
se
Planni
ng.

Estar
familia
rizado
con el
trabajo
del
equipo
(es
decir,
el
produc
to).

Panora
ma
general

Reunir
a las
person
as que
deben
hablar
entre
sí.
Mante
ner el
contac
to de
maner
a
regula
r con
todos
los
stakeh
olders.

Ayudar al equipo a realizar el report to management.

Ayuda
ra
promo
ver la
comun
idad
ágil
dentro
de la
organi
zación
.
Organi
zar
evento
s de
interca
mbio
como
Open
Space
soW
orld
Cafés
para el
equipo
, los
stakeh
olders
y la
organi
zación
.

Compartir información en toda la empresa (micro-blogging, blogging, conferencias i
Ser la
person
a de
contac
to
entre
el
equipo
y los
stakeh
olders
en los
que se
refiera
a
Agile.

Brindar oportunidades de aprendizaje a las personas en la organización (por ejemplo

Cambio
Ayudar al equipo a get rid eliminar impedimentos.

Sugerir el equipo nuevas métricas como catalizadores para el cambio.

Espejo

Reflej
ar al
equipo
los
valore
s de
Agile y
Scrum
.
Recor
dar al
equipo
sus
acuerd
os
(por
ejempl
o,
reglas)
.
Ayuda
r al
equipo
a
mejora
r
contin
uamen
te su
proces
o.

Reflej
ar al
equipo
sus
posibl
es
proble
mas
media
nte
una
observ
ación
extern
a.

Hacer
pregu
ntas
abierta
s.
Verific
ar
todos
los
model
os que
usa el
equipo
(por
ejempl
o,
Sprint
backlo
g,
métric
as,
etc.) y
mostra
rles
las
diferen
cias
entre
el
model
o y el
mundo
real.
Psicoló
gica
Visuali
zar el
futuro
(cómo
el
equipo
quiere
que el
trabajo
funcio
ne, el
próxim
o mes,
el
próxim
o año,
etc.)
Crear
y
articul
ar un
objetiv
o
común
(tambi
én
conoci
do
como
propós
ito
común
) para
el
equipo
(que
se
puede
transfo
rmar o
cambi
ar
periódi
camen
Ayuda
te).
ra
que en
el
equipo
emerja
n
valore
sy
ética.
Ayuda
ra
que
todos,
dentro
y fuera
del
equipo
,
compr
endan
el rol
de la
mental
idad
en el
rendim
iento
del
equipo
.
Ayuda
r al
equipo
a
mejora
r sus
habilid
ades
social
es,
especi
alment
e en lo
que se
refiere
a
conver
sacion
es
constr
uctiva
s.

Varios
Ayuda
r al
equipo
a
mante
ner el
enfoqu
e (por
ejempl
o,
actuan
do
como
un
amorti
guado
r entre
las
distrac
ciones
extern
as y el
equipo
).
Ayuda
r al
equipo
a
mante
ner
sus
herra
mienta
s
Scrum
(Story
board,
Action
board,
charts,
backlo
gs,
etc.).

Ayuda
r al
equipo
y al
Produ
ct
Owner
a
encont
rar un
adecu
ado:

definition of done

definition of ready
organiza
ción y
predispo
sición de
los
involucra
dos, ya
que por
ejemplo
en
algunos
lugares
un
Scrum
Master
está
asignad
o a más
de un
equipo,
también
se ve el
caso de
que no
se
generan
espacios
l trabajo como Scrum Master

También podría gustarte