PDF de programación - La medición funcional de software con SCRUM

La medición funcional de
software con SCRUM

Guilherme Siqueira Simões

www.fattocs.com

1

Agenda

• Introducción
• El contexto SCRUM
• El contexto de la medición funcional de software
• Combinando los dos
• Prejuicios comunes sobre la medición funcional
• Cierre

www.fattocs.com

2

Introducción

• Hoy las metodologías agiles se han destacado en el
mercado de desarrollo de software. SCRUM es el
más popular



• Las mediciones funcionales de software también

crecen en uso por todo el mundo



• Pero muchas personas del mundo ágil desconocen
las mediciones funcionales o piensan que son
conceptos incompatibles

www.fattocs.com

3

Agenda

• Introducción
• El contexto SCRUM
• El contexto de la medición funcional de software
• Combinando los dos
• Prejuicios comunes sobre la medición funcional
• Cierre

www.fattocs.com

4

Qué es SCRUM

• Es un proceso de desarrollo iterativo e incremental (o
creciente) para la gestión y el desarrollo de proyectos
de software

• Equipos pequeños: 3-9 personas
• Ciclos de entrega cortos

Ciclo de vida SCRUM

www.fattocs.com

5

Product Backlog

• La Lista de Producto es una

lista ordenada (y
los
dinámica, cambia constantemente) de todo
requisitos del producto, y es la única fuente de
requisitos para cualquier cambio a realizarse en éste

www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf

www.fattocs.com

6

Historia de Usuario

frases en

• Es una especificación de requisito escrito en una o
lenguaje común del usuario,
dos
acompañadas de las discusiones con él y las pruebas
de validación

• Formato

– Como (rol) quiero (algo) para poder (beneficio)
– Ej.: Como alumno quiero reservar un libro para poder

estudiar

• Es el ítem más utilizado en la Lista de Producto

http://es.wikipedia.org/wiki/Historias_de_usuario

www.fattocs.com

7

Sprint

• El corazón de Scrum es el Sprint, es un bloque de
tiempo (time-box) de un mes o menos durante el
cual
incremento de producto
“Terminado”, utilizable y potencialmente desplegable

crea un

se

www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf

www.fattocs.com

8

Sprint Backlog

• La Lista de Pendientes del Sprint es el conjunto de
elementos de la Lista de Producto seleccionados para
el Sprint, más un plan para entregar el incremento de
producto y conseguir el Objetivo del Sprint

www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf

www.fattocs.com

9

Micro Estimaciones

• La dinámica del SCRUM se caracteriza por micro

estimaciones
– De los Sprints
– De las Historias de Usuario
– Estimaciones Botton-up



• Una de las estrategias más populares de estimación
en equipos ágiles son los Puntos de Historia (Story
Points)

www.fattocs.com

10

Puntos de Historia (Story Points)

• Es una evaluación de manera relativa de las historias
de usuario en cuanto a: complejidad, esfuerzo, riesgo
– Se selecciona una historia de usuario para asignarle una
complejidad nominal que servirá de referencia para
catalogar al resto de historias de usuario

– Basada en la experiencia del equipo y analogía con otras

historias

• Resultados con significado sólo para el propio

equipo. Medida subjetiva.
• No se puede comparar

los puntos de historia

medidos por un equipo con los de otros equipos

www.fattocs.com

11

Velocidad (Productividad)

• Velocidad es el número de puntos de historia que un

equipo consigue entregar en una iteración (sprint)
– Si el equipo trabajó junto en algunos proyectos pasados,
hay (o debería haber) datos para derivarse una velocidad
promedia

– A lo largo del proyecto, la velocidad es ajustada con la

experiencia de las iteraciones más recientes

– Para nuevos equipos, descubrir la velocidad inicial es más

complicado, porque no hay datos históricos

www.fattocs.com

12

Agenda

• Introducción
• El contexto SCRUM
• El contexto de la medición funcional de software
• Combinando los dos
• Prejuicios comunes sobre la medición funcional
• Cierre

www.fattocs.com

13

Medición Funcional de Software

• Surgió en IBM (1979) resultado de un estudio de

productividad en desarrollo de software
– Solución para analizar proyectos desarrollados con

lenguajes de programación distintos

– Desarrollado por Allan Albrecht* y llamado “Análisis de

Puntos de Función” o “Function Point Analisys”

– Su trabajo motivó varias propuestas de mejora para este

método de diversos investigadores

– A lo largo del tiempo, cinco métodos se consolidaron como
estándares (de acuerdo con la ISO/IEC 14143) derivados de
la propuesta original de IBM : IFPUG, COSMIC, NESMA,
MKII y FISMA

14
*www.fattocs.com/files/es/articulos/midiendo_productividad_desarrollo_aplicativos.pdf

www.fattocs.com

¿Qué es la Medición Funcional de Software?

• Es un análisis basado en la identificación de las
funciones del software bajo el punto de vista del
usuario
– Cada función identificada tiene un tamaño, una cantidad

de puntos de función

– Usuario es cualquier persona o cosa que se comunica o

interactúa con el software en cualquier momento

• El análisis es independiente de cualquier aspecto de

implementación del software

• Considera sólo parte de los requisitos: los requisitos
funcionales (lo que el software debe hacer en
términos de tareas y servicios)

• Medida objetiva; con un conjunto de reglas

replicables

www.fattocs.com

15

¿Por qué medición funcional?

• Estimación de esfuerzo, costo o plazo
• Seguimiento y control del proyecto
• Benchmarking de productividad
• Mejora de procesos de software
• Gestión de contratos de desarrollo
• Gobierno corporativo de las aplicaciones
• Valoración de activos de software
• Indicadores para mejor visibilidad del proceso

– Productividad: horas / puntos de función
– Costo: $ / puntos de función
– Calidad: defectos / puntos de función

www.fattocs.com

16

¿Para quién la medición funcional?

• Visión Operacional (nivel del proyecto)

– Equipo
– Ej.: Planificación, seguimiento y control de proyectos



• Visión Táctica y Estratégica (nivel organizacional)

– Media y alta administración
– Ej.: Seguimiento y control de programas y portafolios

www.fattocs.com

17

Agenda

• Introducción
• El contexto SCRUM
• El contexto de la medición funcional de software
• Combinando los dos
• Prejuicios comunes sobre la medición funcional
• Cierre

www.fattocs.com

18

SCRUM con Medición funcional

• Medición de las historias, sprints y product backlog

en puntos de función

• Estimación de esfuerzo de las historias de usuario y

sprints a partir de los puntos de función

• Ayudar a definir el numero de sprints en una release

o la cantidad de historias por sprint

• Apoyar la definición de velocidad (o productividad)

en sprint: horas / puntos de función


• Pero, ¿los puntos de historia ya no cumplen estos

objetivos ?

www.fattocs.com

19

¿Cambiar los Puntos de Historia?

• No, si esto ya funciona bien



• Pero mediante el uso más de un método es posible
conciliar las estimaciones hecha por cada uno de
ellos, asegurando más calidad a la estimación


• La velocidad

inicial puede ser más fácilmente
obtenida con puntos de función porque es una
medida objetiva y estándar entre proyectos


• La ventaja de cambiar de método es utilizar una

medida objetiva en lugar de una subjetiva

www.fattocs.com

20

Más allá de puntos de historia

• La medición funcional soporta una visión Táctica y

Estratégica sobre el desarrollo de software


• Estimaciones de esfuerzo o costo antes del inicio del

proyecto (análisis de viabilidad)

• Benchmarking: comparación del desempeño del
la

equipo con otros, entre aplicaciones, de
organización con otras del mercado

a

las

variaciones

• Ayudar

comprender

de
productividad y crecimiento de alcance entre
proyectos

www.fattocs.com

21

Más allá de puntos de historia (2)

• Seguimiento y control del proyecto: aunque que se
utilice gráficos como burndown, burnup o cumulative
flow para seguimiento del trabajo diario por el
equipo, es necesario ofrecer maneras para el
seguimiento de los proyectos en un ámbito externo
al proyecto, por ejemplo, para
la oficina de
administración de proyectos (PMO) o la dirección de
la empresa



• Gestión de contratos de desarrollo externo de
software: es necesaria una métrica estándar para
medir las entregas de los distintos proveedores

www.fattocs.com

22

Más allá de puntos de historia (3)

• Iniciativas de Mejora de Procesos (SPI): para medir
los resultados de estas iniciativas son necesarios
datos a lo largo del tiempo, de varios proyectos y
equipos. Los puntos de historia no pueden ser
comparados entre proyectos y equipos distintos


• Gobierno corporativo de

las aplicaciones: basar
decisiones de reingeniería de aplicaciones, generar
indicadores de costos de mantenimiento, calcular el
costo real de las aplicaciones (todo su ciclo de vida)


www.fattocs.com

23

Agenda

• Introducción
• El contexto SCRUM
• El contexto de la medición funcional de software
• Combinando los dos
• Prejuicios comunes sobre la medición funcional
• Cierre

www.fattocs.com

24

Prejuicio 1

• “La medición funcional es un método para proyectos
desarrollados en modelo de cascada” – INCORRECTO
• “La medición funcional no sirve para proyectos con

diseños orientados a objetos ” – INCORRECTO

• La