Scrum Manager Proyecto Apuntes

Scrum Manager
Apuntes
Rev. 1.1

Scrum Manager
Proyectos
Apuntes de formación
Rev.1.1 May-2009

Título

Scrum Manager: Proyectos – apuntes de formación.

Autores

Juan Palacio, Claudia Ruata

Imagen de Portada

Philip A.

Edición

Enero – 2009

Más información, y última versión en: http://www.scrummanager.net

Derechos

Derechos registrados en Safe Creative.
Condiciones de uso, copia y distribución en: http://www.safecreative.org/work/0904193094566

Contenido
Contenido 5

Prólogo 9
Apuntes de formación Scrum Manager 11
Plataforma abierta para consulta y formación profesional Scrum Manager 11
Servicios profesionales para formación y asesoría Scrum Manager 11

Concepto clásico de gestión de proyectos 13
Introducción: Proyectos y operaciones 15
Definición clásica de proyecto 15
Origen de la gestión de proyectos 15
Organizaciones referentes en la gestión de proyectos 16
Modelo válido para cualquier industria 16
Planificación y seguimiento 16
Gestión predictiva o clásica 17
Ámbito de la gestión de proyectos 17
Resumen 17

El nuevo escenario 19
Escenario de desarrollo en los 80 21
The New New Product Development Game 21
Características del nuevo escenario 22
Campos de scrum vs. modelo clásico de desarrollo 23
Fases de desarrollo solapadas 23
Características del “campo de scrum” 24
Incertidumbre 24
Auto-organización 24
Control sutil 24
Difusión y transferencia del conocimiento 24
Resumen 25

Gestión de proyectos ágil 27
Introducción 29
Objetivos de la gestión ágil 29
1.-Valor 29
2.-Reducción del tiempo de salida al mercado 29
3.-Agilidad 29
4.-Flexibilidad 29
5.- Resultados fiables 30
Las preferencias de la gestión ágil 30
El ciclo de desarrollo ágil 30
1.- Concepto 30
2.- Especulación 31
3.- Exploración 31
4.- Revisión 31
5.- Cierre 31
Principales modelos de gestión ágil 31

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

Contenido

ASD 32
AUP 32
CRYSTAL 32
DSDM 33
SCRUM 33
XBreed – Agile Enterprise 34
Resumen 34

Gestión de proyectos: ¿formal o ágil? 35
¿Ágil, clásica, predictiva …? 37
Premisas de la gestión de proyectos predictiva 37
Características de la gestión de proyectos predictiva 37
Hay otras premisas 37
¿Cuándo y por qué emplear uno u otro estilo de gestión? 38
Características del proyecto 38
Prioridad de negocio 39
Estabilidad de los requisitos 39
Rigidez del producto 39
Coste de prototipado 39
Criticidad del sistema 40
Tamaño del sistema 40
Condiciones de la organización 40
Nivel profesional 41
Cultura organizativa 41
Entorno de desarrollo 41
Resumen 41

Introducción al modelo Scrum para desarrollo de Software 43
El origen 45
Introducción al modelo 45
Control de la evolución del proyecto 46
Revisión de las Iteraciones 46
Desarrollo incremental 46
Desarrollo evolutivo 46
Auto-organización 46
Colaboración 46
Visión general del proceso 46
Las reuniones 47
Los elementos 47
Los roles 47
Valores 48
Resumen 48

Roles y responsabilidades de proyecto 51
Introducción 53
Responsabilidades generales Scrum Management 53
De management 53
De procesos 53
De producción 53


Contenido

Responsabilidades y roles “del proyecto” 53
El propietario del producto 54
Para ejercer este rol es necesario: 54
El equipo 54
Scrum Manager – Team Leader 55
Resumen 55
De management 55
De procesos 55
De producción 55

Los elementos de Scrum 57
Introducción 59
Los requisitos en el desarrollo ágil 59
Requisitos y visión del producto 60
Pila del producto: los requisitos del cliente 60
Formato de la pila del producto 61
Pila del Sprint 61
Condiciones 61
Formato y soporte 61
Ejemplos 62
El Incremento 62
Resumen 62

Scrum: Las reuniones 63
Introducción 65
Planificación del sprint 65
Descripción general 65
Pre-condiciones 65
Entradas 65
Resultados 65
Formato de la reunión 66
1
Funciones del rol de Scrum Manager 66
Pizarra de trabajo 67
Un ejemplo de pizarra 67
Seguimiento del sprint 68
Descripción 68
Entradas 68
Resultados 68
Revisión del sprint 69
Descripción 69
Objetivos 69
Pre-condiciones 69
Entradas 69
Resultados 69
Resumen 70

Medición: consideraciones 71

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

Contenido

Introducción 73
¿Por qué medir? 73
Flexibilidad y sentido común 73
Criterios para el diseño y aplicación de métricas 73
Cuantas menos, mejor 73
¿El indicador es apropiado para el fin que se debe conseguir? 74
Medición de la eficiencia en la empresa 74
Medición del avance del proyecto 74
Medición de la eficiencia de los trabajos de programación 74
¿Lo que vamos a medir es un indicador válido de lo que queremos conocer? 75
Resumen 75

Medición: Las Unidades 77
Velocidad, trabajo y tiempo 79
Tiempo 79
Trabajo 79
Trabajo ya realizado 79
Trabajo pendiente de realizar 79
Unidades de trabajo 80
Velocidad 81
Resumen 81

Medición: Usos y herramientas 83
Gráfico de producto: 85

Ejemplo: 85
Gráfico de avance: monitorización del sprint 86
Estimación de póker 87
Variante: sucesión de Fibonacci 88
Funcionamiento 88
Resumen 89

Índice 91
Índice 93


Apuntes de formación Scrum Manager

Apuntes de formación Scrum Manager
Este es el libro de texto para formación del área de “Proyecto” del marco de gestión
®
“Scrum Manager ”.

Es un recurso educativo abierto (OER) y forma parte de la plataforma Scrum Manager
Open Knowledge: http://scrummanager.net/ok/

Se puede emplear de forma gratuita para consulta y auto-formación a título personal.

Plataforma abierta para consulta y formación profesional Scrum
Manager
Scrum Manager Open Knowledge es una plataforma de acceso libre para
consulta y formación, está disponible en http://scrummanager.net/ok/ donde
encontrarás la última versión de este manual, además de otros materiales,
foros, talleres, etc.

Un punto abierto en la Red para consultar y compartir conocimiento, y mantenerte profesionalmente
actualizado.

Servicios profesionales para formación y asesoría Scrum Manager
Puedes localizar profesionales y empresas certificadas para servicios
profesionales de formación y asesoría en la implantación y mejora de Scrum
Management, en el directorio de consultores Scrum Manager:

http://scrummanager.net/ o solicitar información en la dirección formacion@scrummanager.net

Información para formar parte de la red de consultores certificados Scrum Manager en la dirección
formacion@scrummanager.net.

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

Concepto clásico de gestión de proyectos

Origen de la gestión de proyectos

Introducción: Proyectos y Conjunto único de actividades necesarias
para producir un resultado definido en un
rango de fechas determinado y con una
operaciones asignación específica de recursos

Las construcciones de ingeniería civil, como
puentes o edificios, son ejemplos clásicos de
obras realizadas como proyectos, y en general lo
es el desarrollo de cualquier sistema singular.

Un proyecto tiene objetivos y características
únicas.
El desarrollo de productos, la prestación de Algunos necesitan el trabajo de una sola persona,
servicios, o incluso la organización de la propia y otros el de cientos de ellas; pueden durar unos
empresa son trabajos que pueden tomar la forma días o varios años.
de proyectos o de operaciones.
Algunos ejemplos de proyectos:
Ambos compantes tres características:
 Diseño de un nuevo ordenador portátil.
 Los realizan personas.  Construcción de un edificio.
 Se emplean recursos limitados.  Desarrollo de un sistema de software.
 Se llevan a cabo siguiendo una estrategia de  Implantación de una nueva línea de producto
actuación. en una empresa.
 Diseño de una campaña de marketing.
Aunque comparten estas tres características, la
diferencia clave entre operaciones y proyectos es
que:
Origen de la gestión de
Las operaciones se ejecutan de forma
repetitiva para obtener resultados de
proyectos
similares características
Los proyectos producen resultados Los proyectos han existido siempre.
únicos Cualquier trabajo para desarrollar algo único es
un proyecto, pero la gestión de proyectos es una
disciplina relativamente reciente que comenzó a
Se considera proyecto a la ejecución de un forjarse en los años sesenta.
trabajo que además de requerir personas, recur-
sos y ejecución controlada: La necesidad de su profesionalización surgió en
el ámbito militar.
Es un desarrollo único En los 50, el desarrollo de complejos sistemas
militares, requería coordinar el trabajo conjunto de
La teoría clásica de gestión de proyectos, añade equipos y disciplinas diferentes, en la cons-
a la característica anterior otra, que desde la trucción de sistemas únicos.
perspectiva de gestión predictiva tiene sentido, Bernard Schriever, arquitecto del desarrollo de
pero no tanto, como se verá, desde la perspectiva misiles balísticos Polaris, es considerado el padre
de gestión de proyectos ágil. de la gestión de proyectos, por la introducción del
concepto de “concurrencia”, para integrar todos
Se desarrolla en un marco temporal pre- los elementos del plan del proyecto en un solo
establecido. programa y presupuesto.

El objetivo de la concurrencia era ejecutar las
diferentes actividades de forma simultánea, y no
secuencialmente, y al aplicarla en los proyectos
Thor, Atlas y Minuteman se redujeron conside-
Definición clásica de proyecto rablemente los tiempos de ejecución.

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


La industria del automóvil siguió los pasos de la de una gestión de proyectos, para ofrecer garan-
militar, aplicando técnicas de gestión de tías de previsibilidad y calidad de los resultados.
proyectos para la coordinación del trabajo entre
áreas y equipos diferentes.
Este conocimiento se ha configurando como el
Comenzaron a surgir técnicas específicas, currículo de una nueva profesión: La gestión de
histogramas, cronogramas, los conceptos de ciclo proyectos predictiva.
de vida del proyecto o descomposición en tareas
(WBS Work Breakdown Structure). Las organizaciones más relevantes en esta línea
son:
En 1960, Meter Norden, del laboratorio de
investigación de IBM, en su seminario de Inge-  International Project Management Association
niería de Presupuesto y Control presentado ante (IPMA), fundada en 1965
American Management Association, indicó:  Project Management Institute (PMI)
constituído en 1965
 Más tarde surgió Prince2, que comenzó a
Es posible relacionar los nuevos trabajar en 1989.
proyectos con otros pasados y
terminados para estimar sus costes IPMA y PMI surgieron como organizaciones
Se producen regularidades en todos profesionales para desarrollar metodologías y
los proyectos procesos para la gestión de proyectos.
Es absolutamente necesario Prince2 ha tenido la evolución inversa. Comenzó
descomponer los proyectos en partes siendo una metodología, alrededor de la que se
de menor dimensión para realizar ha terminado creando una organización.
planificaciones.

Modelo válido para cualquier
industria
Organizaciones referentes También en este sentido la evolución ha sido
diferente para Prince2:
en la gestión de proyectos PMI e IPMA tuvieron desde el principio como
finalidad el desarrollo de un conocimiento de
gestión válido para cualquier proyecto.
La construcción de sistemas complejos que Sin embargo, Prince2 comenzó siendo un modelo
requerían el trabajo sincronizado de varias de referencia para proyectos específicos de
disciplinas hizo evidente en los 60 la necesidad Tecnologías de la Información, desarrollado por la
de nuevos métodos de organización para evitar Central Computer and Telecommunications
problemas recurrentes: Agency (CCTA) del Gobierno Británico; y a partir
de una revisión llevada a cabo en 1996 se decidió
 Desbordamiento de agendas. ampliar su ámbito de validez, para cualquier tipo
 Desbordamiento de costes. de proyecto.
 Calidad o utilidad del resultado obtenido.

Planificación y seguimiento

Para dar respuesta a esta necesidad, desde los
años 60 han surgido organizaciones que contri-
buyen al desarrollo del cuerpo de conocimiento

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


La gestión de proyectos desarrollada en las Grupos de procesos de la gestión de proyectos
últimas décadas del siglo pasado se basa en la PMBOK 2004
planificación del trabajo, y en el posterior
seguimiento y control de la ejecución.

La planificación se realiza sobre un análisis
detallado del trabajo que se quiere realizar y su Ámbito de la gestión de
proyectos
descomposición en tareas.
Parte por tanto de un proyecto de obra, o de unos
requisitos detallados de lo que se quiere hacer.
Sobre esa información se desarrolla un plan
adecuado a los recursos y tiempos disponibles; y
La solvencia demostrada por la gestión de
durante la construcción se sigue de cerca la
proyectos en la industria militar, y en la
ejecución para detectar posibles desviaciones y
automovilística para solucionar los problemas
tomar medidas para mantener el plan, o
habituales de calidad, tiempos y costes, coincide
determinar qué cambios va a experimentar.
en el tiempo con la presión que todas las
Se trata por tanto de una gestión “predictiva”, que
industrias experimentan en mayor o menor
vaticina a través del plan inicial cuáles van a ser
medida para reducir la agenda de salida al
la secuencia de operaciones de todo el proyecto,
mercado y los costes de producción. Como
su coste y tiempos.
resultado, en todos los sectores: farmacéutico,
químico, servicios, tecnologías de la información,
Su principal objetivo es conseguir que el producto
etc. se adoptan técnicas de gestión de proyectos,
final se obtenga según lo “previsto”; y basa el
dándoles de facto validez para todos los ámbitos.
éxito del proyecto en los tres puntos apuntados:
agendas, costes y calidad.

Gestión predictiva o clásica
La gestión de proyectos predictiva o clásica es
una disciplina formal de gestión, basada en la
planificación, ejecución y seguimiento a través de
procesos sistemáticos y repetibles.

 Establece como criterios de éxito: obtener el
producto definido, en el tiempo previsto y con
el coste estimado.
 Asume que el proyecto se desarrolla en un


entorno estable y predecible.
El objetivo de su esfuerzo es mantener el Resumen
cronograma, el presupuesto y los recursos.
 Divide el desarrollo en fases a las que  Definición clásica de proyecto: construcción
considera “ciclo de vida”, con una secuencia de un resultado único, en unas fechas
de tipo: concepto, requisitos, diseño, previstas y con unos recursos previstos de
planificación, desarrollo, cierre. antemano.
 La profesionalización de la gestión de
proyectos surgió en los 50 para dar respuesta
a las necesidades de la industria militar, y en
los años posteriores el resto de industrias han
adoptado sus principios.
 Las organizaciones más conocidas por la
investigación, y creación de comunidades
profesionales para la gestión de proyectos
son: PMI (Project Management Institute),
Internacional Project Management
Association (IPMA) y Prince2.
 Características de la gestión de proyectos
desarrollada en la segunda mitad del siglo
pasado:



 Gestión basada en la aplicación
sistemática de procesos repetibles y
escalables.
 Los criterios de éxito de un proyecto son:
calidad, costes y fechas.
 Carácter predictivo: ejecución según el
plan inicial previsto.
 Desarrollo sobre un entorno estable.
 El objetivo de la gestión es: desarrollar un
plan, y mantener el cronograma y los
recursos planificados.
 Ciclo de vida compuesto por fases
secuenciales.


El nuevo escenario

División del trabajo, especialización y producción
basada en procesos, fueron premisas que, como

Escenario de desarrollo en axiomáticas, asumió la gestión de proyectos, y
por esta razón, los puntos clave de la gestión

los 80
predictiva o clásica son:

 Estimar cuál va a ser el trabajo necesario, y a
continuación gestionar la ejecución para que
En los 80, el ciclo de vida de los proyectos era el se cumplan la estimación inicial.
denominado en cascada: el proyecto se divide en  El trabajo se desarrolla en fases.
fases, y éstas se ejecutan de forma secuencial:  División del trabajo en equipos de
definición del producto, diseño, construcción de especialistas.
elementos, integración, pruebas…  Desarrollo basado en procesos.

Dos características de la construcción de nuevos
productos en esta década son:

 Ciclo de vida secuencial.
 División y especialización del trabajo.

The New New Product
Development Game
Es el título del artículo publicado en 1986 por
Hirotaka Takeuchi e Ikujijo Nonaka; que a su vez
Cada fase la realiza un departamento, personas o daba continuación a otro anterior de los mismos
equipos diferentes, profesionalmente especiali- autores junto con Kenichi Imai: “Managing the
zados en los conocimientos necesarios. New Product Development Process: How
Japanese Companies Learn and Unlearn”.
La gestión de proyectos desarrolla modelos de
estructuras organizativas de tipo matricial, con La publicación de “The New New Product
diferentes variaciones, para facilitar la comunica- Development Game” ha marcado el punto de
ción y coordinación entre equipos diferentes. inicio de una nueva forma de gestionar proyectos
en entornos rápidos e inestables.
En las mismas fechas, a la par de la consolida-
ción del conocimiento de gestión de proyectos, se Cuando la teoría de gestión de proyectos estaba
estaban desarrollando las teorías de producción alcanzando una cierta madurez, los autores ob-
basada en procesos, promovidas por Michel servaron que algunas empresas, en mercados
Hammer, como mejor medio para garantizar la muy competitivos, relacionados con productos de
calidad, eficiencia y repetitividad. vanguardia tecnológica, trabajaban ignorando esa
teoría.

“Muchas compañías han descubierto que para
mantenerse en el actual mercado competitivo
necesitan algo más que los conceptos básicos de
calidad elevada, costes reducidos y diferen-
ciación. Además de esto, también es necesario
velocidad y flexibilidad.”
“En 1981 las encuestas realizadas a 700
empresas americanas revelan que el 30% de sus
beneficios se debe a nuevos productos”.


El nuevo escenario

Hasta entonces, el desarrollo de nuevos produc-  La cámara Canon AE-1 (1976)
tos se realizaba como una carrera de relevos, en  Cámara Canon Auto Boy (1979).
la que un grupo de especialistas funcionales
pasaban el relevo al siguiente. En estas empresas el trabajo no recorría fases a
El proyecto avanzaba secuencialmente de fase través de diferentes equipos especializados.
en fase: creación del concepto, pruebas de viabi-
lidad, diseño del producto, diseño del proceso, “El producto emerge de la interacción constante
desarrollo de prototipo y producción final. de un equipo de élite, multidisciplinario que
trabaja conjuntamente desde el principio hasta el
Es un modelo de trabajo segmentado por final”
especialización de funciones.
La gente de marketing explora y estudia las Nonaka y Takeuchi compararon la forma de
necesidades de los clientes, para crear el con- trabajar de estos equipos únicos y multi-
cepto del producto. Los ingenieros de investi- disciplinarios, con los equipos de rugby, y el
gación y desarrollo elaboran un diseño adecuado, ambiente y entorno de trabajo que les
los ingenieros de producción llevan a cabo la proporcionaba la empresa lo llamaron “campo de
1
solución técnica… scrum ”.

Características del nuevo
La figura siguiente representa el ciclo de vida al
construir un producto con un patrón de gestión
secuencial, y cuál es la diferencia con la nueva
forma, observada por Nonaka y Takeuchi en
empresas que ignoraban los principios de la
escenario
gestión clásica de proyectos.

En los 40, 50 y 60 los productos tardaban años en
quedar obsoletos, y las empresas los producían
Los desarrollos secuenciales puros suelen ser con variaciones mínimas a lo largo del tiempo.
más teóricos que prácticos, y en realidad quienes
los adoptan, generalmente producen ciclos Apple ha desarrollado 6 versiones de su popular
“secuenciales con solapamiento”, donde una fase iPod, en sólo 6 años.
no suele necesitar para empezar que esté
completamente terminada la anterior. Hoy determinados productos permanecen en un
continuo estado “beta”. El entorno tecnológico es
Nonaka y Takeuchi observaron que empresas tan inestable, que las novedades se lanzan tras el
americanas y japonesas tecnológicas, de primera menor tiempo de desarrollo posible, dejando que
línea, que aventajaban a sus competidores en vayan evolucionando a través de versiones, en el
innovación y rapidez, compartían pautas de propio mercado. Que sea éste quien diga de
trabajo comunes, ajenas al clásico patrón secuen- forma continua cómo deben modificarse los
cial. “requisitos”.

Analizaron la forma de trabajo de: Fuji-Xerox, En estas circunstancias, las diferencias de lide-
Canon, Honda, Nec, Epson, Brother, 3M, Xerox y razgo entre unas empresas y otras no radica
Hewlett-Packard y en concreto la forma en la que tanto en la eficiencia y previsibilidad con la que se
abordaban el desarrollo de 6 productos: gestionan el lanzamiento de nuevos productos,
sino en la capacidad de agilidad y cambio durante
 La fotocopiadora Fuji-Xerox FX-3500. (1978) su construcción; y el principal valor para ocupar
 La copiadora personal Canon PC-10 (1982) puestos de cabeza es la innovación.
 El coche urbano de 1200cc de Honda (1981) 1
 El ordenador personal NEC PC 8000 (1979) Scrum es un término empleado en rugby para definir una
determinada formación del equipo.

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

El nuevo escenario

Campos de scrum vs.
regularmente incrementos de funcionalidad que
incrementan el valor al producto.

modelo clásico de Fases de desarrollo solapadas
desarrollo El concepto de “fase” que implica un trabajo
secuencial, se cambia ahora por el de “actividad”.
Requisitos, análisis, diseño, desarrollo no son
Estos son los principales contrastes que fases ejecutadas en un orden determinado. Son
diferencian el desarrollo tradicional del ágil: actividades que se pueden realizar en cualquier
momento, de forma simultánea; “a demanda”
cuando las necesita el equipo.

En el ciclo de vida secuencial de software se
habla de “modificación de requisitos”.
Este término lleva implícito el concepto de que
estamos “cambiando” algo que quedó cerrado en
la fase de requisitos.
En el desarrollo ágil, los requisitos evolucionan,
se desarrollan y enriquecen durante todo el ciclo
de vida, igual que el diseño y el código.

Takeuchi y Nonaka observaron dos tipos de
2
solapamiento: uno que denominaron “sashimi ”
No lo realizan equipos diferentes especializados. estableciendo analogía con el plato típico japonés
Es un equipo único, formado por personas muy porque se produce un solapamiento bastante
competentes, con perfiles y conocimientos que amplio, de tal forma, que en cualquier punto del
cubren las disciplinas necesarias para llevar a ciclo de vida, se encuentran de forma simultánea
3
cabo el trabajo. varias fases; y otro que denominaron “rugby ”,
que deja perdido por completo el concepto de
No hay fases. En realidad las fases pasan a ser fases, y en el que el equipo trabaja
tareas que se ejecutan cuando se necesitan. concurrentemente en todas las actividades desde
No se hace primero el diseño del concepto o los el primer día.
requisitos, más tarde el análisis, luego el
desarrollo, etc. En el solapamiento “sashimi” aún se mantiene el
Lo que aplicado al software serían las fases de: concepto de fase, aunque con un solapamiento
requisitos del sistema, requisitos del software, muy amplio.
análisis, diseño, construcción, pruebas e inte-
gración; y se ejecutarían de forma secuencial,
pasan a tareas que se llevan a cabo en el mo-
mento que hacen falta. Normalmente a lo largo de
pequeñas iteraciones durante todo el desarrollo. En el solapamiento “rugby” no son ya fases, sino
definitivamente tareas.
No se espera a disponer de requisitos detallados
para comenzar el análisis, ni a tener éste para En el desarrollo tradicional:
pasar a la codificación. Muchas veces los requi-  Las transiciones entre fases, acaban
sitos no se pueden conocer si no avanza el funcionando como fronteras. Cada equipo se
desarrollo y se va viendo y “tocando” el resultado. siente responsable de su parte de trabajo, de
Otras veces el mercado es tan rápido que a mitad lo que debe entregar a la siguiente fase, pero
de trabajo las tendencias o la competencia no del resultado final.
obligarán a modificar el producto.  Los documentos de diseño, los requisitos o
Además, la participación de todo el equipo en el los prototipos pueden acabar siendo
diseño aporta gran cantidad de talento innovador; barricadas en la frontera de cada fase, que
un valor clave en el mercado de productos y lejos favorecer la comunicación directa
servicios TIC. fomentan la fragmentación.

Los equipos ágiles empiezan a trabajar sin 2
Nombre que dieron al tipo de solapamiento uqe empleaba el
conocer con detalle cómo será el producto final. equipo de desarrollo de la FX-3500 en Fuji-Xerox.
Parten de la visión general, y sobre ella, producen 3
Con este nombre denominaron a la combinación simultánea
de todas las fases desde el primer día, empleada por los
equipo de Honda.


El nuevo escenario

 Los retrasos de cada fase son cuellos de  Auto-superación. El equipo va desarrollando
botella del proyecto. El solapamiento diluye el soluciones, que evalúa, analiza y mejora.
ruido y los problemas entre fases.  Auto-enriquecimiento. La multi-disciplinaridad
del equipo favorece el enriquecimiento mutuo
y la aportación de soluciones valiosas

Características del “campo complementarias.

de scrum” Control sutil
El equipo dispone de autonomía, pero no debe
Las características “ambientales” en las empresas derivar en caos.
que desarrollan los nuevos productos con La gestión establece puntos de control suficientes
modelos de gestión ágil son: para evitar que el escenario de ambigüedad,
inestabilidad y tensión del “campo de scrum”
 Incertidumbre consustancial al entorno y la evolucione hacia el descontrol.
cultura de la organización.
 Equipos auto-organizados. Pero debe gestionarse sin un control rígido que
 Control sutil. impediría la creatividad y la espontaneidad.
 Difusión y transferencia del conocimiento. El término “control sutil” se refiere a la creación de
un ecosistema que potencia y desarrolla el “auto-

Incertidumbre
control entre iguales”, como consecuencia de la
responsabilidad y del gusto por el trabajo
realizado.
Se trabaja en entornos de incertidumbre consus-
tancial. Algunas acciones para generar este ecosistema
En estas empresas, la dirección apunta cuál es la son:
meta genérica a la que se pretende arribar, o la
dirección estratégica que hay que seguir. No se  Selección de las personas adecuadas para el
proporciona el plan detallado del producto. proyecto.
Al mismo tiempo se dá al equipo un margen de  Análisis de los cambios en la dinámica del
amplia libertad. grupo para incorporar o retirar a miembros si
Los ingredientes que sirven de acicate para la resulta necesario.
creatividad y el compromiso son:  Creación de un espacio de trabajo abierto.
 Animar a los ingenieros a “mezclarse” con el
 La “tensión” que crea la visión difusa y el reto mundo real de las necesidades de los
que supone el grado de dificultad que clientes.
encierra.  Sistemas de evaluación y reconocimiento
 El margen de autonomía, libertad y basados en el rendimiento del equipo.
responsabilidad.  Gestión de las diferencias de ritmo a través
del proceso de desarrollo.

Auto-organización  Tolerancia y previsión con los errores;
considerando que son un medio de
aprendizaje, y que el miedo al error merma la
Son equipos auto-organizados, sin roles de
creatividad y la espontaneidad.
gestión ni pautas de asignación de tareas.
 Implicar a los proveedores en el proyecto y
No se trata de equipos auto-dirigidos, sino auto-
animarles a su propia auto-organización.
organizados. La gestión es la que marca la
dirección, pero no la organización.

Parten de cero. Deben empezar por crear su pro-
Difusión y transferencia del
pia organización y buscar el conocimiento que
necesitan. conocimiento
Son similares a una “Start-up” que comienza. Tanto a nivel de proyecto como de organización.
Para lograr la auto-organización los equipos Los equipos son multidisciplinarios, y todos los
deben reunir tres características: miembros aportan y aprenden:
 Autonomía. Son libres para elegir la  del resto del equipo,
estrategia de la solución. En este sentido la
dirección de la empresa actúa como un
capitalista de capital-riesgo.


El nuevo escenario

 de las investigaciones para mejorar el valor y  Características ambientales en estos entor-
el componente innovador que espera el nos llamados “campos de scrum”
cliente,  Incertidumbre
 de la experiencia del desarrollo.  Auto-organización
 Control sutil
Las personas que participan en un proyecto, con  Difusión del conocimiento
el tiempo pasan a otros equipos y proyectos de la  Fases de desarrollo solapadas
empresa, de manera que comparten y comunican
el conocimiento a lo largo de toda la organización.

Los equipos y las empresas mantienen libre
acceso a la información, herramientas y políticas
de gestión del conocimiento

Resumen
 Hasta los 80, para el desarrollo de nuevos
productos se empleaban:
 Ciclos de vida secuencial.
 División y especialización del trabajo.
 En los 80 se desarrolla la teoría de
producción basada en procesos para propor-
cionar eficiencia calidad y repetibilidad.
 En esos años, algunas empresas de tecno-
logía (Caon, Fuji-Xerox, Honda, Epson, HP,
etc.) logran más valor y mejores resultados en
el desarrollo de nuevos productos, desafiando
al desarrollo secuencial y a la división del
trabajo.
 Nonaka y Takeuchi son los primeros en
identificar estos nuevos entornos de produc-
ción a los que denominan “campos de scrum”
en el artículo The New New Product Develop-
ment Game”.
 Las principales diferencias con el desarrollo
tradicional de producto son:
 No trabajan departamentos especializa-
dos, sino un único equipo multi-
disciplinario.
 Solapamiento de las fases del desarrollo.
 No se parte de unos requisitos detallados
sino de la visión del resultado.
 No se sigue un plan pre-elaborado.


Gestión de proyectos ágil
Conceptos

Gestión de proyectos ágil: conceptos

Su objetivo es dar el mayor valor posible al
producto, cuando éste se basa en:

Introducción  Innovación
 Flexibilidad
Muchas empresas trabajan en escenarios que se
parecen ya muy poco a los que impulsaron la La permanencia de estas empresas depende de
gestión de proyectos predictiva y necesitan su capacidad de innovación continua. Del
estrategias diferentes para gestionar el lanzamiento continuo de novedades, que com-
lanzamiento de sus productos: estrategias orien- piten con los productos de otras empresas que
tadas a la entrega temprana de resultados tan- también están en continua innovación.
gibles, y con la suficiente agilidad y flexibilidad
para trabajar en entornos inestables y rápidos. Flexibilidad.
El producto no sólo es valioso por su valor en el
Ahora necesitan construir el producto al mismo momento de su lanzamiento, sino también por su
tiempo que cambian y aparecen nuevos requisi- capacidad de adaptación y evolución a través de
tos; y como las circunstancias de los mercados y actualizaciones y ampliaciones.
de las empresas no se pueden cambiar, son las
formas en las que gestionan sus proyectos las
que tienen que cambiar para dar respuesta a las
nuevas necesidades. 2.-Reducción del tiempo de
El cliente conoce la visión de su producto pero salida al mercado
por la novedad, el valor de innovación que
necesita y la velocidad a la que se va a mover el En la década de los 90, el tiempo medio de salida
escenario tecnológico y de negocio, durante el al mercado de los nuevos productos en EE.UU.
4
desarrollo, no puede detallar cómo será el se redujo de 35,5 a 11 meses
producto final.
Este tiempo es un factor competitivo clave en
¡Ah!. Pero, ¿existe el producto final?. determinados sectores.

Quizá ya no hay “productos finales”, sino Las estrategias de la gestión ágil para producir
productos en evolución, mejora o incremento resultados en menos tiempo que la gestión
continuo, desde la primera versión beta. tradicional son:

 Solapamiento de las fases de desarrollo.
 Entrega temprana de las primeras partes del
El resultado es la gestión ágil de producto, que corresponden con las de mayor
proyectos, que no se formula sobre el urgencia para el cliente, de forma que puede
concepto de anticipación (requisitos, lanzar la primera versión en el menor tiempo
diseño, planificación y seguimiento) sino posible.
sobre el de adaptación (visión,
exploración y adaptación)
3.-Agilidad
Capacidad para producir partes completas del
producto en periodos breves de tiempo

Objetivos de la gestión ágil 4.-Flexibilidad
La gestión ágil de proyectos tiene como objetivo Capacidad para adaptar la forma y el curso del
dar garantías a las demandas principales de la desarrollo a las características del proyecto, y a la
industria actual: valor, reducción del tiempo de
evolución de los requisitos.
desarrollo, agilidad, flexibilidad y fiabilidad.

1.-Valor
La gestión ágil se necesita en los mercados
rápidos. 4
Wujec, Tom, and Sandra Muscat. Return on Imagination:
Realizing the Power of Ideas, London: Financial Times
Prentice Hall, 2002



5.- Resultados fiables El ciclo de desarrollo ágil
El objetivo de la gestión predictiva es ejecutar el
trabajo planificado (y conocido de antemano) en
el plazo planificado y por el coste previsto.

La gestión ágil no tiene un carácter predictivo o
de anticipación. No conoce de antemano el de-
talle del producto que va a desarrollar, y por eso
su objetivo no es fiabilidad en el cumplimiento de
los planes, sino en el valor del resultado.

Los procesos de la gestión tradicional son buenos
cuando consiguen desarrollar de forma repetible
los productos especificados en el tiempo y con los
costes previstos.

Los procesos de la gestión ágil son buenos, El desarrollo ágil parte de la visión, del concepto
cuando consiguen entregar de forma temprana y general del producto, y sobre ella el equipo
continua un valor innovador. produce de forma continua incrementos en la
dirección apuntada por la visión; y en el orden de
prioridad que necesita el negocio del cliente.

Las preferencias de la Los ciclos breves de desarrollo, se denominan
iteraciones y se realizan hasta que se decide no
gestión ágil evolucionar más el producto.

Este esquema está formado por cinco fases:
La gestión ágil, a diferencia de la tradicional,
muestra las preferencias resumidas en el 1.- Concepto
manifiesto ágil: 2.- Especulación
3.- Exploración
1.- La capacidad de respuesta al cambio, 4.- Revisión
sobre el seguimiento de un plan. 5.- Cierre

1.- Concepto
2.- Los productos que funcionan frente a
especificaciones y documentaciones inne-
cesarias.
En esta fase se crea la visión del producto y se
3.- La colaboración con el cliente frente a la determina el equipo que lo llevará a cabo.
negociación contractual.
Partir sin una visión genera esfuerzo baldío.
4.- A las personas y su interacción por encima La visión es un factor crítico para el éxito del
de los procesos y las herramientas. proyecto.
Se necesita tener el concepto de lo que se quiere,
y conocer el alcance del proyecto. Es además
una información que deben compartir todos los
miembros del equipo



2.- Especulación 4.- Revisión
Una vez que se sabe qué hay que construir, el Equipo y usuarios revisan lo construido hasta ese
equipo especula y formula hipótesis basadas en momento.
la información de la visión, que per se es muy Trabajan y operan con el producto real
general e insuficiente para determinar las contrastando su alineación con el objetivo.
implicaciones de un desarrollo (requisitos, diseño,
costes…).

En esta fase se determinan las limitaciones
impuestas por el entorno de negocio: costes y
agendas principalmente, y se cierra la primera
aproximación de lo que se puede producir.

La gestión ágil investiga y construye a partir de la
visión del producto. Durante el desarrollo
confronta las partes terminadas: su valor, posi-
bilidades, y la situación del entorno en cada
momento.

5.- Cierre
La fase de especulación se repite en cada
iteración, y teniendo como referencia la visión y el
alcance del proyecto consiste en:
Al llegar a la fecha de entrega de una versión de
 Desarrollo y revisión de los requisitos producto (fijada en la fase de concepto y revisada
generales. en las diferentes fases de especulación), se
 Mantenimiento de una lista con las obtiene el producto esperado.
funcionalidades esperadas.
 Mantenimiento de un plan de entrega: fechas Posiblemente éste seguirá en el mercado, y por
en las que se necesitan las versiones, hitos e emplear gestión ágil, es presumible que se trata
iteraciones del desarrollo. Este plan refleja ya de un producto que necesita versiones y mejoras
el esfuerzo que consumirá el proyecto frecuentes para no quedar obsoleto. El cierre no
durante el tiempo. implica el fin del proyecto.
 En función de las características del modelo
de gestión y del proyecto puede incluir Lo que se denomina “mantenimiento” supondrá la
también una estrategia o planes para la continuidad del proyecto en ciclos incrementales
gestión de riesgos. hacia la siguiente versión para ir acercándose a la
visión del producto.
Si las exigencias formales de la organización lo
requieren, también se produce información admi-
nistrativa y financiera.
Principales modelos de
gestión ágil
Si hubiera que determinar cuál es el origen de la
gestión ágil de proyectos, a falta de mejor infor-
mación, habría que situarlo en las prácticas adop-
tadas en los 80 por empresas como Honda, 3M,
Canon, Fuji, Nec, Xerox, hp o Epson para el
5
desarrollo de nuevos productos .

3.- Exploración
La industria del software ha sido la primera en
seguir su adopción, y muchos de sus
profesionales han documentado y propagado las
Se desarrolla un incremento del producto, que formas particulares en las que han implementado
incluye las funcionalidades determinadas en la
fase anterior. 5
Hirotaka Takeuchi e Ikujiro Nonaka, 1986 “The New New
Development Game”



los principios de la agilidad en sus equipos de ESPECULACIÓN, compuesta por 5 pasos:
trabajo. 1.- Inicio para determinar la misión del proyecto.
De esta forma han aparecido en las últimas 2.- Fijación del marco temporal del proyecto.
décadas los nombres: 3.- Determinación del nº de iteraciones y la
duración de cada una.
 AD - Agile Database Techniques 4.- Definición del objetivo de cada iteración.
 AM - Agile Modeling 5.- Asignación de funcionalidad a cada iteración.
 ASD - Adaptive Software Development
 AUP - Agile Unified Process COLABORACIÓN
 Crystal Desarrollo concurrente del trabajo de cons-
 FDD - Feature Driven Development trucción y gestión del producto.
 DSDM - Dynamic Systems Development
Method APRENDIZAJE
 Lean Software Development En cada iteración se revisa:
 Scrum  Calidad, con criterios de cliente.
 TDD - Test-Driven Design  Calidad, con criterios técnicos.
 XBreed  Funcionalidad desarrollada.
 XP - eXtreme Programming  Estado del proyecto.

Éstos son los modelos que se encuentran Las características básicas de ASD son:
inscritos en la organización Agile Alliance  Trabajo orientado y guiado por la misión del
(www.agilealliance.org) para promocionar y proyecto.
difundir su conocimiento.  Basado en la funcionalidad.
 Desarrollo iterativo.
Cada una de ellos expone formas concretas de  Desarrollo acotado temporalmente.
aplicación de principios ágiles en el desarrollo de  Guiado por los riesgos.
software.  Trabajo tolerante al cambio.
Algunos determinan cómo realizar las pruebas, o

AUP
la duración que emplean para desarrollar cada
iteración, o el protocolo para realizar las
reuniones de trabajo.
Agile Unified Process es una versión simplificada
Unos métodos cubren áreas concretas de la de Rational Unified Process, desarrollada por
ingeniería del software (diseño, desarrollo Scott Amber.
pruebas), como es caso de AD, AM o XP, y otros
se centran en la gestión del proyecto. Divide el ciclo de desarrollo en 4 fases:

Éstos últimos son: INICIO: identificación del alcance y dimensión del
proyecto, propuesta de la arquitectura y del
 ASD - Adaptive Software Development presupuesto del cliente.
 AUP - Agile Unified Process ELABORACIÓN: Confirmación de la idoneidad de
 Crystal la arquitectura.
 DSDM - Dynamic Systems Development CONSTRUCCIÓN: Desarrollo incremental del
Method sistema, siguiendo las prioridades funcionales de
 Scrum los implicados.
 XBreed TRANSICIÓN: Validación e implantación del
sistema.
Por ejemplo, el principio de desarrollo ágil
iterativo e incremental, tiene reflejo en ciclos de
30 días empleados por scrum, o de entre 1 y 4 CRYSTAL
meses empleado por los modelos Cristal.
Concebido por Alistair Cockburn, este modelo no
describe una metodología cerrada, sino un
ASD conjunto de ellas, junto con los criterios para
seleccionar y adecuar la más apropiada al
Adaptive Software Development es el modelo de proyecto. Los parámetros para determinarla son
implementación de patrones ágiles para de- la criticidad y el tamaño del sistema que se va a
sarrollo de software, diseñado por Jim Highsmith, construir.
que materializa las fases de la gestión ágil de la
siguiente forma:



Es un modelo que estuvo representado en la
firma del Manifiesto Ágil: Arie van Bennekum,
firmante del manifiesto, era miembro del
consorcio en Benelux, consultor y formador de
DSDM.

En 2001, año del Manifiesto Ágil, DSDM publicó
la versión 4.1 de su modelo, y se consideró una
metodología ágil; y aunque mantuvo las siglas,
cambió la denominación original (Dynamis
Systems Development Method) por Framework
for Business Centred Development.

Procesos del ciclo de desarrollo DSDM

El ciclo de desarrollo de DSDM está compuesto
Los criterios empleados para la medición de estos de 5 fases, precedidas de un pre-proyecto y un
parámetros son: post-proyecto.

Criticidad (dimensión de las pérdidas que 1. Pre-proyecto
ocasionaría un malfuncionamiento del sistema) 2. Estudio de viabilidad
3. Estudio de negocio
1 (c): Pérdida de confort o usabilidad. 4. Iteración de modelado funcional
2 (d): Pérdidas económicas moderadas. 5. Iteración de diseño y desarrollo
3 (e): Pérdidas económicas graves. 6. Implementación
4 (l): Pérdida de vidas humanas. 7. Post-desarrollo

Estos criterios corresponden a los niveles de
integridad de un sistema definidos por el estándar
IEEE 1012-1998.

Dimensión.
Crystal determina el tamaño del sistema por el nº
de personas empleadas en su desarrollo. (6 - 20 -
40 - 80)

Fundamentos de Crystal:

 Desarrollo iterativo e incremental.
 Duración máxima de una iteración: 4 meses.
Recomienda duraciones entre 1 y 3 meses.
 Especial énfasis en la importancia de las


personas sobre los procesos.
Especial énfasis en la comunicación directa.
SCRUM
 Modelo abierto a la adaptación e introducción Jeff Sutherland en 1993 trabajaba en Easel
de prácticas de otros modelos ágiles Corporation (compañía que en los macrojuegos
(eXtreme Programming, Scrum...) de compras y fusiones se integraría en VMARK, y
luego en Informix y finalmente en Ascential

DSDM
Software Corporation). Tras conocer el trabajo de
Nonaka y Takeuchi, Jeff identificó paralelismos
con la industria del software, y aplicó un modelo
DSDM es el acrónimo que dá nombre a un de desarrollo ágil, iterativo e incremental para
modelo de procesos para desarrollo de sistemas desarrollar y mantener sistemas de software.
de software, concebido por el DSDM Consortium,
que se fundó en Inglaterra en 1994, y que En 1996 lo presentó junto con Ken Schwaber
actualmente tiene presencia en Inglaterra, como proceso formal para gestión del desarrollo
EE.UU., Benelux, Dinamarca, Francia y Suiza; y de software en OOPSLA 96, con el nombre que
con interés y contactos para futuras Nonaka y Takeuchi habían dado a estos equipos
representaciones en Australia, India y China [...]



de trabajo: "Scrum", por la comparación que  La gestión ágil se basa en los principios del
6
hicieron con los equipos de Rugby manifiesto ágil y centra el valor:
 Más en las personas y su interacción que
en los procesos y las herramientas
 Más en los resultados que funcionan que
en la documentación exhaustiva
 Más en la colaboración con el cliente que
en la negociación contractual
 Más en la capacidad de respuesta al
cambio que en el seguimiento de un plan

 El desarrollo ágil comprende cinco fases:
concepto, especulación, exploración, revisión
y cierre.

 El desarrollo ágil surgió en empresas de
Se basa en el principio ágil de desarrollo iterativo
productos tecnológicos, fue identificado por
e incremental.
Nonaka y Takeuchi en los años 80 y a partir
Al período de trabajo para desarrollar un
de los 90 diferentes profesionales del
incremento de producto se lo denomina “sprint”, y
desarrollo del software incorporaron sus
se recomienda una duración de 30 días, si bien
principios en sus entornos de trabajo.
pueden contemplarse casos de hasta 60 días
De esas implementaciones ágiles, las que
(según Ken Schwaber, o 45 según Jeff
abordan la gestión del proyecto son: ASD,
Shuterland).
AUP, Crystal, DSDM, Scrum.
Establece una reunión al inicio de cada sprint
para determinar el trabajo que se va a realizar,
otra al final para evaluar el resultado, y revisiones
diarias que realiza el equipo en su auto-gestión.

XBreed – Agile Enterprise
Propuesto por Mike Breedle, que colaboró con
Ken Schwaber en la definición de Scrum, es una
combinación de Scrum para la gestión del
proyecto, y Extreme Programming como prácticas
de desarrollo.

Esta es una combinación comúnmente empleada
independientemente de su definición como
Xbreed que hasta la fecha no ha tenido especial
relevancia. También denominado “Agile
Enterprise”.

Resumen
 La gestión ágil de proyectos no es una
gestión de anticipación (requisitos, diseño,
planificación y seguimiento) sino de adap-
tación (visión, exploración y adaptación).

 La gestión ágil tiene como objetivos: valor,
reducción del tiempo de desarrollo, agilidad,
flexibilidad y fiabilidad.

6
Scrum es el nombre que se dá en Rugby a una determinada
formación del equipo.


Gestión de proyectos: ¿formal o ágil?


¿Ágil, clásica, predictiva …?
Al surgir en los 80 una nueva forma de gestionar
proyectos, se hizo necesario añadir un “apellido”
al término “gestión de proyectos” para matizar si
se refiere a la nueva o a la de siempre.

La nueva, al autodenominarse ágil, obligó a dar
un apellido al modelo de gestión de proyectos que
hasta entonces, por único, no lo había nece-
sitado.
Características de la gestión
Las denominaciones empleadas para cada tipo
son:
de proyectos predictiva
Estas premisas han dado dos características a la
Clásica gestión de proyectos predictiva:
Tradicional
Gestión de proyectos Predictiva 1.- Universalidad
Formal Los proyectos, pese a su diversidad, comparten
Pesada patrones comunes de ejecución.
Las prácticas de gestión se basan en estos
patrones comunes y resultan válidas para
cualquier tipo de proyecto.
Ágil
Gestión de proyectos Adaptable
Adaptativa

En algunos ámbitos, hay cierta rivalidad acadé-
mica o profesional entre defensores de uno y otro
modelo. Preferimos por tanto no emplear el
término “pesado” que puede aportar connota-
ciones peyorativas.

También preferimos no emplear “adaptativa” y
usar en su lugar “adaptable”, para evitar un
anglicismo innecesario. 2.- Carácter predictivo
La gestión clásica define con detalle cuál es el
“producto previsto” y elabora un plan de
Premisas de la gestión de desarrollo, a partir del cual calcula costes y
fechas.

proyectos predictiva
Durante la ejecución realiza actividades de
seguimiento y vigilancia para evitar desviaciones
sobre lo planificado.
Premisas sobre las que se desarrolló la gestión

Hay otras premisas
de proyectos tradicional:

1.- Todos los proyectos mantienen caracterís-
ticas y comportamientos regulares (Meter
Norden 1960) Las dos premisas que cimentan el desarrollo de la
gestión de proyectos:
2.- El objetivo de la ejecución de un proyecto  Todos los proyectos comparten idénticos
es lograr el producto previsto en el tiempo patrones de ejecución.
planificado sin desbordar los costes  El objetivo es conseguir el producto definido
estimados. en costes y fechas.
son cuestionables:



1.- No hay una forma única y válida para Se pedía un proyecto, pero no se quería
gestionar cualquier tipo de proyecto garantizar la ejecución de un plan, sino obtener el
máximo valor en las líneas marcadas.

Es cierto que muchas características que dife- Hay proyectos en los que importa más el valor y
rencian unos proyectos de otros son superficiales la innovación que el cumplimiento del plan.
y resultan indiferentes para el modelo de gestión;
pero hay otras que permiten adoptar estrategias
de gestión muy diferentes en cada caso.
La gestión predictiva pide al equipo el
Características diferenciales: cumplimiento del plan.
La gestión adaptable pide al equipo el
 Componente innovador que se espera del mayor valor posible para una visión de
resultado. producto
 Grado de estabilidad de los requisitos durante
el desarrollo.
 Coste de prototipado.
 Maleabilidad del producto para modificar su
funcionalidad una vez desarrollado.

La gestión de proyectos predictiva, al auto-
considerarse válida para cualquier proyecto no
contempla que según las características del
proyecto, puedan resultar más apropiados otros
criterios de gestión.

 Conseguir el mayor valor innovador del
producto no es uno de sus objetivos, y por
tanto no aplica prácticas diferentes según el
grado innovador que se desee.

 Considera que los requisitos deben
permanecer estables durante la ejecución. Si
no ocurre esto presupone que se debe a
deficiencias en el proceso de la fase de
¿Cuándo y por qué emplear
requisitos; porque no contempla posibles
evoluciones rápidas o inestabilidades del uno u otro estilo de gestión?
entorno tecnológico o de negocio.
Para obtener los mayores beneficios que cada
 El objetivo es la eficiencia, el cumplimiento estilo de gestión puede ofrecer, éste tiene que ser
del plan, y no el valor del producto. Desde compatible no sólo con las características del
este punto de vista, el re-trabajo siempre es proyecto, sino también con las de la organización
caro. No se considera la relación entre el que las va a aplicar.
coste del re-trabajo y el valor proporcionado.

2.- Hay proyectos en los que no se quiere
Características del proyecto
“hacer el producto descrito en las fechas Las características relevantes para decidir el
y con los costes estimados” estilo de gestión más adecuado son:

 Principal prioridad de negocio.
 Estabilidad de los requisitos.
Cuando en 1978 la dirección de Honda encargó el  Rigidez del producto.
diseño de un nuevo automóvil, sólo dió dos  Coste de prototipado.
instrucciones al equipo de ingenieros:  Criticidad del sistema.
“Primero: necesitamos un concepto de automóvil  Tamaño del sistema.
completamente diferente a lo que cualquier otra
compañía haya hecho nunca; y segundo: debe El orden expuesto se corresponde con nuestro
ser un coche económico, pero no barato”. criterio de relevancia, siendo por tanto la prioridad
de negocio la principal razón de compatibilidad o
El resultado fue el Honda Civic.



incompatibilidad, y el tamaño del sistema la Por supuesto los dos objetivos son deseables,
menos relevante. pero hay que elegir, porque simplemente son
excluyentes. No se pueden planificar diagramas
Por la relativa novedad de la gestión ágil, estos de Gantt o rutas críticas sobre una visión general.
criterios no están aún consensuados. Así por
ejemplo mientras algunos textos opinan que el Cuanto mayor valor se desea en uno u otro
tamaño o la criticidad del sistema son aspectos extremo (valor o predicción), más contraprodu-
muy relevantes, hay opiniones autorizadas en cente resulta emplear el estilo de gestión
sentido contrario: inadecuado.


Estabilidad de los requisitos
En la "International Conference on Complex
Systems 2006", Jeff Sutherland presentó el
informe "Adaptive Engineering of Large
Software Projects with Distributed / ¿Se puede obtener una descripción de requisitos
Outsourced Teams " que demostraba los detallada al inicio del proyecto, y ésta se man-
buenos resultados obtenidos con prácticas de tendrá estable durante el desarrollo?
gestión ágiles en un desarrollo de grandes
dimensiones: un millón de líneas de código O lo que es lo mismo, ¿Se puede saber con cer-
Java, y un equipo de 50 personas distribuidos teza y detalle qué es lo que se quiere construir,
en dos empresas ubicadas en países siendo improbable que cambien los criterios o las
distintos. necesidades?

 El modelo específico de Scrum desarrollado
por Ken Schwaber para Software contempla Rigidez del producto
el desarrollo de sistemas críticos, incluyendo
¿Cuán fácil resulta modificar el producto?
los requerimientos de conformidad también
como resultados entregables de las
Esta es una razón importante, porque no es lo
iteraciones junto con las funcionalidades a las
mismo modificar software, circuitos electrónicos,
que afectan.
construcciones civiles…

Modificar la estructura de una base de datos para
añadir algunas tablas no es lo mismo que
modificar la estructura de un edificio para
rectificar el número de plantas.

Coste de prototipado
Otra cuestión relevante para el modelo de gestión
ágil es la relación: coste de prototipar / valor
conseguido para el producto. Este factor suele
estar relacionado con la rigidez del producto.

Prioridad de negocio Ver, tocar, e interactuar con las partes ya desa-
rrolladas (o con simulaciones o prototipos) genera
ideas y posibilidades que sobre el concepto inicial
¿Cuál es la principal prioridad para los intereses
y el papel no llegan a concebirse.
de negocio del cliente?
¿Qué tiene más importancia: el cumplimiento de
El prototipado y el feed-back que proporciona son
agendas y fechas o el valor innovador del
extremadamente importantes, sobre todo en el
producto?
desarrollo de nuevos productos, o de sistemas
innovadores.
Este es el primer aspecto que se debe considerar.
La gestión predictiva es un modelo construido y
A medida que el equipo lo va “tocando” y
especializado en garantizar el cumplimiento de
“probando” surgen funcionalidades y posibilidades
los planes.
nuevas que aportan mayor valor al concepto
inicial.
La gestión adaptable es un modelo construido y
especializado en dar el mayor valor posible al
En este sentido, el argumento: “la forma más
producto.
eficiente de desarrollar un trabajo es hacerlo bien
a la primera”, que se emplea con frecuencia para



defender la validez de la gestión predictiva en  Producirá pérdidas económicas graves.
cualquier proyecto, resulta tendencioso. La  Producirá pérdidas económicas.
afirmación “per se” es obviamente cierta; pero  Fallará la finalidad principal del sistema.
también son ciertas dos circunstancias rela-  Fallarán funcionalidades auxiliares del
cionadas: sistema.
 Se producirán fallos ergonómicos o de
 se puede hacer “bien a la primera” cuando es comodidad para los usuarios.
posible conocer con detalle el resultado sin

Tamaño del sistema
necesidad de hacer pruebas antes.

 Las posibilidades al hacer un trabajo no son
sólo “bien” o “mal”. Bien es un término amplio. Una de las principales bases del desarrollo ágil es
Puede ser aceptable o suficientemente bien, la preferencia de la comunicación e interacción
o lo mejor posible. directa de los implicados en el proyecto.

Estos factores, junto con la relación entre coste Los grandes proyectos implican equipos nume-
de prototipado y valor que aporta deben tenerse rosos y en ocasiones físicamente distantes,
también en cuenta para elegir el modelo de circunstancias que dificultan la comunicación
gestión más adecuado para el proyecto. directa.
No obstante hay desarrollos incipientes de
prácticas ágiles que implantan esquemas de
agrupamiento y comunicación directa en
estructuras celulares de equipos de hasta 6
personas.

Condiciones de la organización
Los elementos empleados por las organizaciones
para ejecutar proyectos son: personas, procesos
y tecnología.

Los resultados de la gestión ágil dependen más
del valor de las personas que de los procesos de
la organización.
Criticidad del sistema Las personas tienen características propias:
¿Cuál es el grado de criticidad del sistema que va
a desarrollar?  Sus resultados son “sensibles” al entorno. La
falta de motivación y los ambientes laborales
Considerando por análisis de criticidad: hostiles reducen significativamente el valor
intelectual del trabajo.
La evaluación estructurada de las características  Cuando el trabajo depende del talento, la
del producto (p. ej.: seguridad, complejidad, diferencia de valor entre los mediocres y los
rendimiento) para determinar la severidad del mejores es muy grande.
impacto de un fallo del sistema, de su
degradación o de su no cumplimiento con los Adoptar modelos de desarrollo ágil no consiste
requisitos o los objetivos del sistema. sólo en realizar las prácticas formales: equipo
único, reuniones periódicas, desarrollo evolutivo
O lo que es lo mismo: de los requisitos, etc.
Si la organización mantiene un modelo de
Si el sistema falla, se degrada o no consigue desarrollo basado en procesos y no en personas,
realizar las funciones de los requisitos, ¿qué y no tiene alineadas con los principios ágiles: la
impacto tiene en la seguridad o en el ren- cultura y estructura organizativa, no obtiene los
dimiento? resultados propios del desarrollo ágil.

Un ejemplo de criterios de criticidad, ordenados
de mayor a menor, puede ser:

 Causará daño a las personas.
 Causará daño al medio ambiente.



Resumen
 Términos empleados para designar a los dos
modelos de gestión de proyectos:
 Predictiva, clásica, tradicional, formal.
 Ágil, adaptable.

 La gestión de proyectos predictiva se ha

Nivel profesional desarrollado sobre las premisas
 Todos los proyectos mantienen
características y comportamientos
“En el mundo del diseño informático, los mejores regulares.
lo hacen entre 50 y 100 veces mejor que el  El objetivo de la ejecución de un proyecto
promedio, y la cifra aumenta, conforme se es lograr el producto previsto en el tiempo
incrementa la complejidad de la tecnología” planificado, sin desbordar los costes
Pilar Jericó. “La gestión del talento”
estimados.
“La diferencia entre los promedios y los mejores
 Las características de la gestión de proyectos
ya no es de 1:2, como en el pasado. Es 1:100 o
predictiva son: validez para cualquier tipo de
incluso 1:1000”
Nathan Myhrvold (Ex-director de I+D de Microsoft) proyecto y carácter predictivo.
Si el proyecto, más que innovación lo que
requiere es la ejecución controlada de un plan  La gestión ágil surge al cuestionar la validez
detallado, posiblemente sean los procesos de la de las premisas de la gestión tradicional:
organización los garantes del resultado; y con un  No hay una forma única y válida para
modelo de gestión predictiva, el factor relevante gestionar cualquier tipo de proyecto.
sea la capacidad de los procesos empleados, y  Hay proyectos que tienen como objetivo
no tanto el nivel profesional de las personas del valor para el producto, y no funcionalidad,
equipo. fecha y costes.

Si por ser el valor del producto el objetivo del  Las características relevantes del proyecto
proyecto, se emplea un modelo de desarrollo ágil, para decidir el estilo de gestión más ade-
son las personas, y no los procesos, los cuado son: prioridad del negocio, estabilidad
encargados de proporcionarlo, y en ese caso el de los requisitos, rigidez del producto, coste
equipo debe estar compuesto por personas con el de prototipado, criticidad del sistema y
mayor conocimiento y experiencia posible. tamaño del sistema.

 Las características relevantes de la orga-
Cultura organizativa nización para facilitar la elección del modelo
de gestión más adecuado son: nivel
Para la ejecución sistemática y controlada de profesional, cultura organizativa y entorno de
procesos no resulta especialmente relevante el desarrollo.
tipo de cultura de la organización.

Sin embargo, para el desarrollo de trabajo basado
en el talento de las personas resultan inhibidores
los ambientes laborales basados en el control,
excesivamente normalizados y jerarquizados.

Entorno de desarrollo
Los entornos de desarrollo basados en procesos
son adecuados para modelos de gestión
predictiva.

Los entornos de desarrollo basados en las
personas son adecuados para modelos de
gestión ágil.


Introducción al modelo Scrum para
desarrollo de Software

Introducción al modelo Scrum para desarrollo de software

El origen
Scrum es una metodología ágil de desarrollo de
proyectos que toma su nombre y principios de las
observaciones sobre nuevas prácticas de pro-
ducción, realizadas por Hirotaka Takeuchi e Ikujijo
Nonaka a mediados de los 80. (ver Gestión
Predictiva y Gestión Ágil: El Nuevo Escenario)
Estructura del desarrollo ágil
Aunque las prácticas observadas por estos
autores surgieron en empresas de productos
tecnológicos, también se emplean en entornos Comparte los principios estructurales del
que trabajan con requisitos inestables y que desarrollo ágil: a partir del concepto o visión de la
requieren rapidez y flexibilidad, situaciones necesidad del cliente, construye el producto de
frecuentes en el desarrollo de determinados forma incremental a través de iteraciones breves
sistemas de software. que comprenden fases de especulación –
exploración y revisión. Estas iteraciones (en
Jeff Sutherland aplicó los principios observados Scrum llamadas sprints) se repiten de forma
por Nonaka y Takeuchi al desarrollo de software continua hasta que el cliente dá por cerrado el
en 1993 en Easel Corporation (Empresa que en producto.
los macro-juegos de compras y fusiones se
integraría en VMARK, luego en Informix y Se comienza con la visión general del producto,
finalmente en Ascential Software Corporation). En especificando y dando detalle a las funciona-
1996 lo presentó junto con Ken Schwaber como lidades o partes que tienen mayor prioridad de
proceso formal, también para gestión del negocio, y que pueden llevarse a cabo en un
desarrollo de software en OOPSLA 96. Más tarde, periodo de tiempo breve (según los casos pueden
en 2001 serían dos de los promulgadores del tener duraciones desde una semana hasta no
Manifiesto_ágil. más de dos meses).
Cada uno de estos periodos de desarrollo es una
iteración que finaliza con la entrega de una parte

Introducción al modelo
(incremento) operativa del producto.

Estas iteraciones son la base del desarrollo ágil, y
Scrum gestiona su evolución en reuniones breves
Scrum es una metodología de desarrollo muy diarias donde todo el equipo revisa el trabajo
simple, que requiere trabajo duro, porque no se realizado el día anterior y el previsto para el
basa en el seguimiento de un plan, sino en la siguiente.
adaptación continua a las circunstancias de la
evolución del proyecto.

Como método ágil:

 Es un modo de desarrollo adaptable, antes
que predictivo.
 Orientado a las personas, más que a los
procesos.
 Emplea el modelo de construcción incre-
mental basado en iteraciones y revisiones.

(ver Gestión Predictiva y Gestión Ágil)

Estructura central de Scrum



Control de la evolución del
niveles. La gestión predictiva confía la respon-
sabilidad de su resolución al gestor de proyectos.
En Scrum los equipos son auto-organizados (no

proyecto auto-dirigidos), con margen de decisión suficiente
para tomar las decisiones que consideren
oportunas.
Scrum controla de forma empírica y adaptable la
evolución del proyecto, a través de las siguientes
prácticas de la gestión ágil: Colaboración
Las prácticas y el entorno de trabajo ágiles
Revisión de las Iteraciones facilitan la colaboración del equipo. Ésta es
necesaria, porque para que funcione la auto-
Al finalizar cada iteración (sprint) se lleva a cabo organización como un control eficaz cada
una revisión con todas las personas implicadas miembro del equipo debe colaborar de forma
en el proyecto. Es por tanto la duración del sprint, abierta con los demás, según sus capacidades y
el periodo máximo que se tarda en reconducir una no según su rol o su puesto.
desviación en el proyecto o en las circunstancias
del producto.
Visión general del proceso
Desarrollo incremental Scrum denomina “sprint” a cada iteración de
desarrollo y según las características del proyecto
Las personas implicadas no trabajan con diseños y las circunstancias del sprint puede determinarse
o abstracciones. una duración desde una hasta dos meses,
aunque no suele ser recomendable hacerlos de
El desarrollo incremental implica que al final de más de un mes.
cada iteración se dispone de una parte de
producto operativa, que se puede inspeccionar y El sprint es el núcleo central que proporciona la
evaluar. base de desarrollo iterativo e incremental.

Desarrollo evolutivo
Los modelos de gestión ágil se emplean para
trabajar en entornos de incertidumbre e inestabi-
lidad de requisitos.
Intentar predecir en las fases iniciales cómo será
el resultado final, y sobre dicha predicción
desarrollar el diseño y la arquitectura del producto
no es realista, porque las circunstancias obligarán
a remodelarlo muchas veces.

¿Para qué predecir los estados finales de la Los elementos que conforman el desarrollo
arquitectura o del diseño si van a estar Scrum son:
cambiando? Scrum considera a la inestabilidad
como una premisa, y se adoptan técnicas de
trabajo para permitir la evolución sin degradar la
calidad de la arquitectura que también evoluciona
durante el desarrollo.

Durante el desarrollo se genera el diseño y la
arquitectura final de forma evolutiva. Scrum no los
considera como productos que deban realizarse
en la primera “fase” del proyecto.
(El desarrollo ágil no es un desarrollo en fases)

Auto-organización
En la ejecución de un proyecto son muchos los
factores impredecibles en todas las áreas y



Las reuniones

Los roles
 Planificación del sprint: Jornada de trabajo Todas las personas que intervienen, o tienen
previa al inicio de cada sprint en la que se relación directa o indirecta con el proyecto, se
determina cuál va a ser el trabajo y los clasifican en dos grupos: comprometidos e
objetivos que se deben conseguir en la implicados.
iteración.
En círculos de Scrum es frecuente llamar a los
 Seguimiento del sprint: Breve revisión primeros (sin ninguna connotación peyorativa)
diaria, en la que cada miembro describe tres “cerdos” y a los segundos “gallinas”.
cuestiones:
1.- El trabajo que realizó el día anterior. El origen de estos nombres es esta metáfora que
2.- El que tiene previsto realizar. ilustra de forma gráfica la diferencia entre
3.- Cosas que puede necesitar o impedi- “compromiso” e “implicación” con el proyecto:
mentos que deben suprimirse para realizar el
trabajo. Una gallina y un cerdo paseaban por la carretera.
Cada persona actualiza en la pila del sprint el La gallina preguntó al cerdo: “¿Quieres abrir un
tiempo pendiente de sus tareas, y con esta restaurante conmigo?”.
información se actualiza también el gráfico El cerdo consideró la propuesta y respondió: “Sí,
con el que el equipo monitoriza el avance del me gustaría. ¿Y cómo lo llamaríamos?”.
sprint (burn-down) La gallina respondió: “Jamón con huevos”.
El cerdo se detuvo, hizo una pausa y contestó:
“Pensándolo mejor, creo que no voy a abrir un
 Revisión del sprint: Análisis y revisión del restaurante contigo. Yo estaría realmente
incremento generado. comprometido, mientras que tu estarías sólo
implicada”.

Los elementos
 Pila del producto: (product backlog) lista de
requisitos de usuario que a partir de la visión
inicial del producto crece y evoluciona durante
el desarrollo.

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

 Incremento: Resultado de cada sprint



 Información, transparencia y visibilidad del
desarrollo del proyecto
COMPROMETIDOS IMPLICADOS
(cerdos) (gallinas)
Propietario del pro-
ducto
Otros interesados
(Dirección general Resumen
Dirección comercial
Equipo
Marketing Usuarios, Scrum es un modelo ágil de desarrollo, que toma
etc) forma de las prácticas de trabajo, que a partir de
los 80 comienzan a adoptar algunas empresas
 Propietario del producto: es la persona respo- tecnológicas, y que Nonaka y Takeuchi acuñaron
nsable de lograr el mayor valor de producto como "Campos de Scrum".
para los clientes, usuarios y resto de
implicados. El modelo Scrum, aplicado al desarrollo de
 Equipo de desarrollo: grupo o grupos de software, emplea el principio ágil: "desarrollo
trabajo que desarrollan el producto. iterativo e incremental", denominando sprint a
 Scrum Manager: Responsable del fun- cada iteración de desarrollo.
cionamiento de la metodología Scrum en la
organización. Las prácticas empleadas por Scrum para mante-
ner un control ágil en el proyecto son:
Algunas implementaciones de modelo Scrum,
consideran el rol de gestor de Scrum como  Revisión de las iteraciones
“comprometido” y necesario (ScrumMaster)  Desarrollo incremental
 Desarrollo evolutivo
Con el criterio de Scrum Management, es  Auto-organización del equipo
recomendable que las responsabilidades que  Colaboración
cubre este rol, estén identificadas en una única
persona cuando se comienzan a aplicar prácticas Los artefactos del modelo son:
de Scrum en una organización. En organi-  Elementos:
zaciones ágiles maduras puede tener menos  Pila del producto o product backlog
sentido.  Pila del sprint o sprint backlog
En cualquier caso, las responsabilidades de  Incremento
Scrum Manager no son del proyecto, sino del
grupo de procesos y métodos de la organización,  Roles:
por lo que no debe considerarse ni cerdo ni  Propietario del producto
gallina.  Equipo
 Scrum Manager
 Otros interesados

Valores  Reuniones:
 Planificación del sprint
Scrum es una “carrocería” que dá forma a los  Seguimiento del sprint
principios ágiles. Es una ayuda para organizar a  Revisión del sprint
las personas y el flujo de trabajo; como lo pueden
ser otras propuestas de formas de trabajo ágil: Los valores que hacen posible a las prácticas de
Crystal, DSDM, etc. Scrum crear "campos de Scrum" son:

La carrocería sin motor, sin los valores que dan  Autonomía (empowerment) del equipo
sentido al desarrollo ágil, no funciona:  Respeto en el equipo
 Responsabilidad y auto-disciplina
 Delegación de atribuciones (empowerment) al  Foco en la tarea
equipo para que pueda auto-organizarse y  Información transparencia y visibilidad
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 auto-disciplina (no
disciplina impuesta).
 Trabajo centrado en el desarrollo de lo
comprometido



2008 – ScrumManager Project – http://www.scrummanager.net 49

Roles y responsabilidades de proyecto


De producción
Introducción 

Producto
Auto-organización
 Tecnología ágil
El grado de éxito de Scrum Management en una
empresa no depende sólo de los roles y las

Responsabilidades y roles
responsabilidades directamente relacionadas con
el desarrollo de los proyectos (cliente y equipo).
Las organizaciones son realidades sistémicas,
inter-relacionadas, y aunque este libro cubre sólo
el área de gestión de los proyectos, veremos los
roles implicados directamente en la ejecución del
“del proyecto”
proyecto o solución técnica, y el área directiva o
de management de la organización.

El conjunto de responsabilidades que se deben
cubrir de forma coordinada y alineada con la
visión de la organización, se clasifican en las tres
categorías siguientes:

Responsabilidades
generales Scrum
Management Éstas son las directamente implicadas en el
desarrollo del producto. Las asumen los roles
“comprometidos” (cerdos): el propietario del
producto y el equipo.

Las del propietario del producto, relativas a la
definición desde la visión, la priorización del
trabajo y la financiación del proyecto.

Las del equipo, relativas a la auto-organización y
uso de prácticas tecnológicas ágiles.

También pertenece al grupo de responsabilidades
del proyecto: la garantía de ejecución y
funcionamiento correcto de las prácticas Scrum
en cada proyecto.
Lo más común en las fases de implantación,

De management cuando los equipos no están familiarizados con el
modelo, es la asignación de esta responsabilidad
en una persona experta en Scrum, ajena al
 Equilibrio sistémico de la organización
equipo: el gestor de Scrum, o Scrum Manager.
 Coherencia del modelo
 Medios y formación

De procesos
 Configuración de Scrum
 Mejora continua
 Garantía de funcionamiento de Scrum en
cada proyecto



Es responsable de la financiación del proyecto, y
las decisiones sobre fechas y funcionalidades de
las diferentes versiones del producto, y el retorno
de la inversión 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 adquisición del cliente.

El equipo
El propietario del producto Se recomienda un tamaño de equipo entre 4 y 8
personas.
Más allá de 8 resulta más difícil mantener la
El propietario del producto o “product owner” es la agilidad en la comunicación directa, y se
persona que toma las decisiones del cliente. manifiestan con más intensidad las rigideces
habituales de la dinámica de grupos (que
Es una única persona. comienzan a aparecer a partir de 6 personas).

No se trata de un grupo de trabajo formado por un
Para ejercer este rol es arquitecto, diseñador o analista, programadores,
pruebas…
necesario: Es un equipo multidisciplinario, en el que todos
trabajan de forma conjunta para realizar cada
 Conocer perfectamente el entorno de negocio sprint.
del cliente, las necesidades y el objetivo que Las principales responsabilidades, más allá de la
se persigue con el sistema que se está auto-organización y uso de tecnologías ágiles,
construyendo. son las que se derivan de la diferencia entre
“grupo de trabajo” y “equipo”.
 Tener atribuciones suficientes para tomar las
decisiones necesarias durante el proyecto. Un grupo de trabajo es un conjunto de personas
que realizan un trabajo, con una asignación
 Conocer Scrum para realizar con solvencia específica de tareas, responsabilidades y siguien-
las tareas que le corresponden: do un proceso o pautas de ejecución.
Los operarios de una cadena, forman un grupo de
 Desarrollo y administración de la pila del trabajo: aunque tienen un jefe común, y trabajan
producto. en la misma organización, cada uno responde por
 Presentación y participación en la reunión su trabajo.
de planificación de cada sprint.
El equipo tiene espíritu de colaboración, y un
 Recibir y analizar de forma continua retro- propósito común: conseguir el mayor valor posible
información del negocio (evolución del para la visión del cliente.
mercado, competencia, alternativas…) y del
proyecto (sugerencias del equipo, alternativas Un equipo Scrum responde en su conjunto.
técnicas, pruebas y evaluación de cada Trabajan de forma cohesionada y auto-
incremento…). organizada.
No hay un gestor que delimita, asigna y coordina
 Es recomendable conocer y haber trabajado las tareas. Son los propios componentes del
previamente con el mismo equipo. equipo los que lo realizan.

Es quien decide en última instancia cómo será el En el equipo:
resultado final, y el orden en el que se van
construyendo los sucesivos incrementos: qué se  Todos conocen y comprenden la visión
pone y qué se quita de la pila del producto, y cuál del propietario del producto.
es la prioridad de las funcionalidades.  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 De management
logro.
 Todos los miembros participan en las  Equilibrio sistémico de la organización
decisiones.  Coherencia del modelo
 Se respetan las opiniones y aportaciones  Medios y formación
de todos
 Todos conocen el modelo de trabajo con
Scrum. De procesos
 Configuración de Scrum
Hay un responsable o líder del equipo que asume
 Mejora continua
las responsabilidades de garantía de fun-
 Garantía de funcionamiento de Scrum en
cionamiento del campo de Scrum en el proyecto.
cada proyecto
En las fases de implementación de Scrum, con
equipos sin demasiada experiencia en desarrollo
ágil con Scrum, y en organizaciones con
De producción
demasiada rotación de personas de los equipos  Producto
entre proyectos, es recomendable la figura de un  Auto-organización
gestor de Scrum o Scrum Manager para asumir  Tecnología ágil
estas responsabilidades.
El rol de propietario del producto tiene las
responsabilidades de producto.

El equipo:
 Auto - organización
 El uso de tecnología y técnicas ágiles en el
Scrum Manager – Team desarrollo del sistema
 Garantía de funcionamiento de Scrum en el

Leader
proyecto, cuando no hay un Scrum Manager

El resto de las responsabilidades no son propias
Es el responsable del funcionamiento de Scrum del proyecto, y por tanto propias del equipo; sino
en el proyecto, cubriendo los aspectos siguientes de la organización.
que la organización necesite según el cono-
cimiento, experiencia con el modelo… o aquellos
que no cubra con otras personas con la formación
e idoneidad adecuada.

 Asesoría y formación al Propietario del pro-
ducto.
 Asesoría y formación al equipo.
 Revisión y validación de la pila del producto.
 Moderación de las reuniones.
 Resolución de impedimentos que en el sprint
pueden entorpecer la ejecución de las tareas.
 Gestión de la “dinámica de grupo” en el
equipo
 Respeto de la organización y los implicados,
con las pautas de tiempos y formas de Scrum
 Configuración, diseño y mejora continua de
las prácticas de Scrum en la organización.

Resumen
Las responsabilidades del funcionamiento de
Scrum Management en la organización se
clasifican en tres niveles y son las siguientes:


Los elementos de Scrum

Introducción
Los elementos centrales del modelo de trabajo
Scrum son:

 Pila del producto (Product Backlog): Lista
de funcionalidades que necesita el
cliente.
 Pila del sprint (Sprint Backlog): Lista de
tareas que se realizan en un sprint No importa si se trata de gestión tradicional o ágil.
 Incremento: Parte del sistema desarro- La descripción del sistema es responsabilidad del
llada en un sprint cliente, aunque se aborda de forma diferente en
cada caso.
 En los proyectos predictivos, los requi-
sitos del sistema suelen especificarse en
documentos formales; mientras que en
los proyectos ágiles toman la forma de
pila del producto o lista de historias de
usuario.
 Los requisitos del sistema formales se
especifican de forma completa y cerrada
al inicio del proyecto; sin embargo una
pila del producto es un documento vivo,
que evoluciona durante el desarrollo.
 Los requisitos del sistema los desarrolla
una persona o equipo especializado en
Este tema describe estos tres elementos. Los dos ingeniería de requisitos a través del
primeros forman los requisitos del sistema, y el proceso de obtención (elicitación) con el
tercero es valor que se le entrega al cliente al final cliente. En Scrum la visión del cliente es
de cada sprint. conocida por todo el equipo (el cliente
forma parte del equipo) y la pila del
Cada incremento es una parte del producto producto se realiza y evoluciona de forma
completamente terminada y operativa. continua con los aportes de todo el
equipo.
No se deben considerar como incrementos:
prototipos, módulos o subrutinas pendientes de
pruebas o de integración.

Los requisitos en el
desarrollo ágil
La ingeniería del software clásica diferencia dos
áreas de requisitos

 Requisitos del sistema Pero la responsabilidad es del cliente; del
 Requisitos del software “propietario del producto” en el caso de Scrum,
que debe decidir qué se incluye en la pila del
Los requisitos del sistema forman parte del producto, y el orden de prioridad.
proceso de adquisición (ISO 12207), y por tanto
es responsabilidad del cliente la definición del
problema y de las funcionalidades que debe
aportar la solución.



Requisitos y visión del
producto
Scrum, aplicado al software, emplea dos formatos
para registrar los requisitos:

 Pila del producto (Product Backlog)
 Pila del sprint (Sprint Backlog)

La pila del producto se sitúa en el área de
necesidades de negocio desde el punto de vista

Pila del producto: los
del cliente. Es el área que en la ingeniería del
software tradicional, cubren los requisitos del
sistema o ConOps (Concept of Operations).

La pila del sprint cubre la especificación de los requisitos del cliente
requisitos de software necesarios para dar res-
puesta a las funcionalidades esperadas por el La pila del producto es el inventario de fun-
cliente. cionalidades, mejoras, tecnología y corrección de
errores que deben incorporarse al producto a
Estas listas no tienen por qué cumplir con un través de las sucesivas iteraciones de desarrollo.
determinado “formato scrum-estándar”. Pueden, y
deben, adoptar la forma más adecuada al sistema Representa todo aquello que esperan los clientes,
equipo-proyecto. usuarios, y en general los interesados. Todo lo
que suponga un trabajo que debe realizar el
Algunos equipos ágiles emplean pilas de equipo tiene que estar reflejado en esta pila.
requisitos, otros historias de usuario, tarjetas
kanban, etc… Estos son algunos ejemplos de posibles entradas
de un backlog:
Lo relevante no es tanto la forma, sino que:
 Permitir a los usuarios la consulta de las
Requisitos del Sistema (pila del producto): obras publicadas por un determinado
autor.
 Las funcionalidades que incluye dan  Reducir el tiempo de instalación del
forma a una visión del producto definida y programa.
conocida por todo el equipo.  Mejorar la escalabilidad del sistema.
 Las funcionalidades están indivi-  Permitir la consulta de una obra a través
dualmente definidas, priorizadas y pre- de un API web.
estimadas.
 Están realizados y gestionados por el A diferencia de un documento de requisitos del
cliente (propietario del producto) sistema, la pila del producto nunca se dá por
completada; está en continuo crecimiento y
Requisitos del software (pila del sprint): evolución.

 Incluyen todas las tareas necesarias para Habitualmente se comienza a elaborar con el
construir el incremento de un sprint. resultado de una reunión de "fertilización cruzada"
 El equipo ha estimado el esfuerzo de o brainstorming; o un proceso de “Exploración”
cada tarea. (eXtreme Programming) donde colabora todo el
 El equipo ha asignado cada tarea a un equipo a partir de la visión del propietario del
miembro. producto.
 Las duraciones estimadas de las tareas
no son ni inferiores, ni superiores a los El formato de la visión no es relevante. Según los
límites definidos en el equipo. casos, puede ser una presentación informal del
responsable del producto, un informe de
requisitos del departamento de marketing, etc.
Sí que es importante sin embargo disponer de
una visión real, comprendida y compartida por
todo el equipo.



La pila evolucionará de forma continua mientras
el producto esté en el mercado, para darle valor
de forma continua, y mantenerlo útil y competitivo.

Para dar comienzo al desarrollo se necesita una
visión de los objetivos de negocio que se quieren

Pila del Sprint
conseguir con el proyecto, comprendida y
conocida por todo el equipo, y elementos
suficientes en la pila para llevar a cabo el primer
sprint.
La pila del sprint, es la lista que descompone las
funcionalidades de la pila del producto en las

Formato de la pila del
tareas necesarias para construir un incremento:
una parte completa y operativa del producto.

producto Cada tarea de la pila del sprint tiene asignada una
persona, y la indicación del tiempo que aún falta
para terminarla.
El desarrollo ágil prefiere la comunicación directa,
a la comunicación con documentos. Es útil porque descompone el proyecto en
unidades de tamaño adecuado para determinar el
La pila del producto no es un documento de avance a diario, e identificar riesgos y problemas
requisitos, sino una herramienta de referencia sin necesidad de procesos complejos de gestión.
para el equipo. Es también una herramienta de soporte para la
comunicación directa del equipo.
Si se emplea formato de lista, es recomendable
que al menos incluya la siguiente información en
cada línea: Condiciones
 Identificador único de la funcionalidad o  Realizada de forma conjunta por todos
trabajo. los miembros del equipo.
 Descripción de la funcionalidad.  Cubre todas las tareas identificadas por el
 Campo o sistema de priorización. equipo para conseguir el objetivo del
 Estimación sprint.
 Sólo el equipo lo puede modificar durante
Dependiendo del tipo de proyecto, funcionamiento el sprint.
del equipo y la organización, pueden resultar  El tamaño de cada tarea está en un rango
aconsejables otros campos: de 2 a 16 horas de trabajo.
 Es visible para todo el equipo. Idealmente
 Observaciones en una pizarra o pared en el mismo
 Criterio de validación espacio físico donde trabaja el equipo.
 Persona asignada


Nº de Sprint en el que se realiza
Módulo del sistema al que pertenece Formato y soporte
 Etc. Tres son las opciones:
Es preferible no adoptar ningún protocolo de  Hoja de cálculo.
trabajo de forma rígida. El formato del product  Pizarra física o pared.
backlog no es cerrado.  Herramienta colaborativa o de gestión de
proyectos.
Los resultados de Scrum Management no
dependen de la rigidez en la aplicación del Y sobre la que mejor se adecua a las carac-
protocolo, sino de la institucionalización de sus terísticas del proyecto, oficina y equipo, lo
principios y la implementación en un formato apropiado es diseñar el formato más cómodo
adecuado a las características de la empresa y para todos, teniendo en cuenta los siguientes
del proyecto. criterios:

 Incluye la información: lista de tareas,
persona responsable de cada una, estado



en el que se encuentra y tiempo de No se trata por tanto de módulos o partes a falta
trabajo que queda para completarla. de pruebas, o documentación o…
 Sólo incluye la información estrictamente Idealmente en el desarrollo ágil:
necesaria.
 El medio y modelo elegido es la opción  Cada funcionalidad de la pila del producto
posible que más facilita la consulta y se refiere a funcionalidades entregables,
comunicación diaria y directa del equipo. no a trabajos internas del tipo “diseño de
 Sirve de soporte para registrar en cada la base de datos”
reunión diaria del sprint, el tiempo que le  Se produce un “incremento” en cada
queda a cada tarea. iteración.

Ejemplos
Sin embargo suele ser una excepción habitual el
primer sprint. En el que objetivos del tipo
“contrastar la plataforma y el diseño” pueden ser
normales, e implican trabajos de diseño o
desarrollo de prototipos para probar la solvencia
de la plataforma que se va a emplear, etc.
Teniendo en cuenta esta excepción habitual,
Incremento es:

Parte de producto realizada en un sprint, y
potencialmente entregable: TERMINADA Y
PROBADA

Si el proyecto o el sistema requiere docu-
mentación, o procesos de validación y verificación
documentados, o con niveles de independencia
que implican procesos con terceros, éstos
también tienen que estar realizados para
considerar que el producto está “terminado”.

Resumen
La pila del producto es la lista de funcionalidades
que desea el cliente, ordenadas según la
prioridad para él.

Es un documento vivo, en constante evolución
durante el desarrollo del sistema.

Durante el sprint, el equipo actualiza sobre la pila La pila del sprint es la lista de tareas en las que
del sprint, a diario, los tiempos pendientes de se han descompuesto las funcionalidades de la
cada tarea. pila del producto que se van a desarrollar en un
Al mismo tiempo, con estos datos traza el gráfico sprint.
de avance o “burn-down”, que se verá en el tema Para cada tarea de la pila del sprint se indica la
de “herramientas”. persona que la tiene asignada y el tiempo de
trabajo previsto.

Durante el sprint el equipo actualiza a diario en la

El Incremento pila del sprint los tiempos pendientes de cada
tarea.

El incremento es la parte de producto producida Incremento es la parte de producto desarrollada
en un sprint, y tiene como características: que en un sprint, y se debe encontrar completamente
está completamente terminada y operativa, en terminada y probada.
condiciones de ser entregada al cliente final.


Scrum: Las Reuniones

Pre-condiciones
Introducción  La organización tiene determinados los
recursos disponibles para llevar a cabo el
sprint.
Scrum realiza el seguimiento y la gestión del
 El propietario del producto tiene pre-
proyecto a través de las tres reuniones que
parada la pila del producto, con su criterio
forman parte del modelo:
de prioridad para el negocio, y un nº
suficiente de elementos para desarrollar
 Planificación del sprint
en el sprint.
 Seguimiento del sprint
 Siempre que sea posible, el propietario
 Revisión del sprint
del producto debe haber trabajado antes
con el equipo. De esta forma su
Este tema describe los objetivos y protocolos
estimación previa del trabajo que se
recomendados para cada una.
puede realizar en el sprint será bastante
ajustada.
 El equipo tiene un conocimiento de las
tecnologías empleadas, y del negocio del
producto suficiente para realizar esti-
maciones basadas en "juicio de exper-
tos”, y para comprender los conceptos del
negocio que expone el propietario del
producto.

Entradas
 La pila del producto.
 El producto desarrollado hasta la fecha a
través de los sucesivos incrementos

Planificación del sprint
(excepto si se trata del primer sprint)
 Circunstancias de las condiciones de
negocio del cliente y del escenario tec-
nológico empleado.
Descripción general
En esta reunión se toman como base las
prioridades y necesidades de negocio del cliente,
y se determina cuáles y cómo van a ser las
funcionalidades que incorporará el producto tras
el siguiente sprint.

En realidad es una reunión que consta de dos
partes:

En la primera, que puede tener una
duración de una a cuatro horas, se decide
qué elementos de la pila del producto se

Resultados
van a desarrollar.

En la segunda se desglosan éstos para
determinar las tareas necesarias, estimar  Pila del sprint.
el esfuerzo para cada una, y asignarlas a  Duración del sprint y fecha de la reunión
las personas del equipo. de revisión.
 Objetivo del sprint.
La planificación del sprint no debe durar más de
un día. Las características de la reunión son: Es una reunión conducida por el responsable del
funcionamiento de Scrum (Scrum Manager, o un
miembro del equipo en equipos ya expertos en
trabajo con Scrum) a la que deben asistir el



propietario del producto y el equipo completo, y a Tras reordenar y replantear las funcionalidades
la que también pueden asistir otros implicados en de la pila del producto, el equipo define el
el proyecto. “objetivo del sprint” o frase que sintetiza cuál es el
La reunión comienza con la presentación del valor que se le va a entregar al cliente.
propietario de la pila de producto (product
backlog), en la que expone los resultados que por Exceptuando sprints dedicados exclusivamente a
orden de prioridad necesita; especialmente los re-factorización o a colecciones de tareas
que prevé, se podrán desarrollar en el siguiente desordenadas (que deberían ser los menos), la
sprint. elaboración de este lema de forma conjunta en la
Si la pila del producto ha tenido cambios reunión es una garantía de que todo el equipo
significativos desde la anterior reunión; explica las comprende y comparte la finalidad del trabajo; y
causas que los han ocasionado. durante el sprint sirve de criterio de referencia en
El objetivo es que todo el equipo conozca las las decisiones que auto-gestiona el equipo.
razones y los detalles con el nivel necesario para
estimar el trabajo necesario.

Formato de la reunión
Esta reunión marca el inicio de cada sprint. Una
persona con la responsabilidad de procesos en la
7
organización es el responsable de su organi-
zación y gestión.
Duración máxima: un día.
Deben asistir: el propietario del producto, el
equipo y el Scrum Manager (o responsable de
este rol)
Pueden asistir: es una reunión abierta a todos los
que puedan aportar información útil. Segunda parte:
Consta de dos partes separadas por una pausa
de café o comida, según la duración. En la segunda parte, que puede alargarse hasta
el final de la jornada:
Primera parte: El equipo desglosa cada funcionalidad en tareas,
y estima el tiempo para cada una de ellas,
Duración de 1 a 4 horas. determinando de esta forma las tareas de la pila
Propietario del producto: del sprint.
Presenta las funcionalidades de la pila del En este desglose el equipo tiene en cuenta los
producto que tienen mayor prioridad y elementos de diseño y arquitectura que deberá
que estima se pueden realizar en el incorporar el sistema.
sprint. Los miembros del equipo se auto-asignan las
La presentación se hace con un nivel de diferentes tareas tomando como criterios sus co-
detalle suficiente para transmitir al equipo nocimientos, intereses y distribución homogénea
toda la información necesaria para cons- del trabajo.
truir el incremento. Esta segunda parte debe considerarse como una
El equipo “reunión del equipo”, en la que deben estar todos
Realiza las preguntas y solicita las sus miembros y ser ellos quienes descomponen,
aclaraciones necesarias. estiman y asignan el trabajo.
Propone sugerencias, modificaciones y
soluciones alternativas. El papel del propietario del producto es atender a
dudas y comprobar que el equipo comprende y
Las aportaciones del equipo pueden suponer comparte su objetivo.
modificaciones en la pila. De hecho no es que El Scrum Manager1 actúa de moderador de la
“puedan” es que “deben” suponerlas. reunión.
Esta reunión es un punto caliente del protocolo de

Funciones del rol de Scrum
Scrum para favorecer la fertilización cruzada de
ideas en equipo y añadir valor a la visión del
producto.
Manager1
7
En las organizaciones en fase de implantación es
recomendable la figura de un “Scrum Manager” que centraliza
El Scrum Manager es responsable y garante de:
todas las responsabilidades para garantizar el funcionamiento
de Scrum en la organización.



1.- Se realiza esta reunión antes de cada sprint.
2.-Antes de la reunión el propietario del producto

Un ejemplo de pizarra
dispone de una pila adecuada y suficiente para
realizar el sprint.
3.- El diálogo principal de la reunión se realiza
entre el propietario del producto y el equipo. Otros La pizarra facilita la comunicación y el trabajo de
asistentes pueden participar, pero su colabo- la reunión.
ración no puede implicar toma de decisiones ni Al final de la reunión el propietario del producto
limitar el diálogo principal. registrará en la hoja de cálculo, o en la herra-
4.- La reunión es un trabajo de colaboración mienta que emplee, el estado y las modifica-
activa entre los dos protagonistas: cliente y ciones en la pila del producto.
equipo, y concluyen con un acuerdo sobre el El equipo hará lo mismo con la pila del sprint.
incremento de producto que van a realizar en el Según la distribución y espacio de la oficina,
sprint. quizá se reutilice la pizarra o las notas para el
5.- El equipo comprende la visión y necesidades seguimiento del sprint; o quizá no.
de negocio del cliente.
6.- El equipo ha realizado una descomposición y Algunos soportes que suelen emplearse:
estimación del trabajo realistas, y ha considerado  Pizarra blanca y fichas adhesivas tipo
las posibles tareas necesarias de análisis, “Post-it”
investigación o apoyo.  Pizarra de corcho laminado y chinchetas
7.- Al final de la reunión están objetivamente para sujetar las fichas.
determinados:  Pizarra de acero vitrificado y soportes
magnéticos para sujetar las fichas.
 Los elementos de la pila del producto que
se van a ejecutar. Se puede conseguir una solución práctica y
 El objetivo del sprint. económica empleando fichas adhesivas (“Post-it”)
 La pila del sprint con todas las tareas y usando como pizarra cartón pluma blanco de
estimadas y asignadas. 5mm. fijado con puntas directamente sobre la
 La duración del sprint y la fecha de la pared.
reunión de revisión. El cartón pluma es un material ligero, de acabado
satinado que puede adquirirse en tiendas de
El Scrum Manager modera la reunión para que no materiales para bellas artes y manualidades.
dure más de un día. Debe evitar que el equipo
comience a profundizar en trabajos de análisis o
arquitectura que son propios del sprint.

Pizarra de trabajo
Es recomendable, que el propietario del producto
emplee una hoja de cálculo, alguna herramienta
similar, o el soporte de una intranet, para guardar
en formato digital la pila del producto
Pero no es aconsejable emplearla como base
para trabajar sobre ella en la reunión, proyec-
tándola sobre la pantalla de la sala. Con cinta adhesiva removible se marcan líneas
Es mucho mejor trabajar y manipular elementos para delimitar:
físicos; y usar una pizarra y fichas removibles
(adhesivas, chinchetas, magnéticas).  Un área superior donde el Scrum
Manager coloca al principio de la reunión
la capacidad real del sprint a 3, 4 y 5
semanas (A); y al final (D), las notas con:
el objetivo establecido, duración del
sprint, funcionalidades de la pila del
producto comprometidas, hora fijada para
las reuniones diarias y fecha prevista
para la reunión de revisión 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.

En cada ficha se refleja la información básica
para las decisiones de la reunión: priorización,
estimación, descomposición y asignación a los
miembros del equipo.
Las siguientes imágenes muestran un ejemplo de
uso:

Algunas marcas comerciales, entre ellas Post-it
comercializan tarjetas adhesivas, con fondo
rayado, similares a fichas que resultan especial-
mente apropiadas, porque no se adhieren entre
ellas, pero sí a las pizarras.

Seguimiento del sprint
Descripción
Reunión diaria breve, de no más de 15 minutos,
en la que cada miembro del equipo dice las
tareas en las que está trabajando, si se ha
encontrado o prevé encontrarse con algún
impedimento, y actualiza sobre la pila del sprint
las ya terminadas, o los tiempos de trabajo que
les quedan.

Entradas
Pila del sprint y gráfico de avance (burn-down)
actualizados con la información de la reunión
anterior.
Información de las tareas realizadas por cada
componente del equipo

Resultados
Pila del sprint y gráfico de avance (burn-down)
actualizados.
Identificación de necesidades e impedimentos.

Se recomienda realizarla de pie y emplear un
formato de pila de tareas en una pizarra, junto
con el gráfico de avance del sprint, para que todo
el equipo pueda ver y anotar.
En la reunión está presente todo el equipo, y
pueden asistir también otras personas rela-
cionadas con el proyecto o la organización, pero
éstas no pueden intervenir.



Cada miembro del equipo expone estas tres
cuestiones: Pre-condiciones
1.- Tarea en la que trabajó ayer.  Se ha concluido el sprint.
2.- Tarea o tareas en las que trabajará hoy.  Asiste todo el equipo de desarrollo, el
3.- Si va a necesitar alguna cosa especial o prevé propietario del producto, el responsable
algún impedimento para realizar su trabajo. de procesos de la empresa y todas las
personas implicadas en el proyecto que lo
Y actualiza sobre el sprint backlog el tiempo de deseen.
trabajo que queda pendiente en las tareas que
tiene asignadas, o marca como finalizadas las ya
completadas. Entradas
 Incremento terminado.
Al final de la reunión:
 Con las estimaciones actualizadas, el
equipo refresca el gráfico de avance del
sprint.
Resultados
 El Scrum Manager (o responsable de la  Feedback para el propietario del
gestión de procesos de la organización) producto: hito de seguimiento de la
comienza la gestión de necesidades e construcción del sistema, e información
impedimentos identificados. para mejorar el valor de la visión del
producto.
 Feedback para el Scrum Manager (o
Revisión del sprint responsable de la gestión de procesos de
la organización): buenas prácticas y
problemas durante el sprint.

Descripción  Convocatoria de la reunión del siguiente
sprint.
Reunión realizada al final del sprint en la que, con
una duración máxima de 4 horas, el equipo
presenta al propietario del producto, clientes,
usuarios, gestores… el incremento construido en Es una reunión informal. El objetivo es ver el
el sprint. incremento y trabajar en el entorno del cliente.
Están prohibidas las presentaciones gráficas y

Objetivos “powerpoints”.
El equipo no debe invertir más de una hora en
preparar la reunión, y lo que se muestra es el
 El propietario del producto obtiene resultado final: terminado, probado y operando en
información objetiva del progreso del el entorno del cliente (incremento).
sistema. Esta reunión marca a intervalos Según las características del proyecto puede
regulares, el ritmo de construcción del incluir también documentación de usuario, o
sistema y la trayectoria que va tomando técnica.
la visión del producto.
 Al ver y probar el incremento, el Es una reunión informativa. NO TIENE UNA
propietario del producto, y el equipo en MISIÓN ORIENTADA A TOMAR DECISIONES,
general obtienen feedback clave para NI A CRITICAR EL INCREMENTO. Con la infor-
evolucionar y dar más valor a la pila del mación generada en la preparación del siguiente
producto. sprint se expondrán y tratarán las posibles
 Otros ingenieros y programadores de la modificaciones sobre la visión del producto.
empresa también pueden asistir para
conocer cómo trabaja la tecnología Un protocolo recomendado:
empleada. 1.- El equipo expone el objetivo del sprint, la lista
 El Scrum Manager obtiene retro- de funcionalidades que se incluían y las que se
información sobre buenas prácticas y han desarrollado.
problemas durante el sprint, necesaria 2.- El equipo hace una introducción general del
para las prácticas de ingeniería de sprint y demuestra el funcionamiento de las
procesos y mejora continua de la partes construidas.
implementación Scrum Management. 3.- Se abre un turno de preguntas y sugerencias
sobre lo visto. Esta parte genera información muy
valiosa para que el propietario del producto, y el



equipo en general, puedan mejorar el valor de la
visión del producto.
4.- El Scrum Manager, de acuerdo con las
agendas del propietario del producto y el equipo
cierra la fecha para la reunión de preparación del
siguiente sprint.

Resumen
La gestión y evolución de un proyecto con Scrum
se determina en tres reuniones:
 Planificación del sprint.
 Seguimiento del sprint.
 Revisión del sprint.

Planificación del sprint
 Duración máxima 1 día.
 Se determinan las funcionalidades que se
desarrollarán en el sprint.
 Cada funcionalidad se desglosa en tareas
 Cada tarea se estima y se asigna a una
persona del equipo.
 El resultado es la pila del sprint.

Seguimiento del sprint
 Breve reunión diaria en la que el equipo
revisa la evolución del sprint.
 Cada uno expone la tarea en la que ha
estado trabajando, en cuál va a trabajar y
si necesita algo para poderla realizar.
 Cada miembro actualiza la estimación de
tiempo pendiente de sus tareas.

Revisión del sprint
 Duración máxima 4 horas.
 Muestra el incremento desarrollado a
todas las personas implicadas en el
proyecto.


Medición: consideraciones

No se deben implantar procesos de medición tan

Introducción sólo porque sí.
Tomar una lista más o menos “prestigiosa” de
métricas e incorporarla a los procedimientos de la

¿Por qué medir?
empresa, puede tentar por la imagen de
profesionalidad que transmitirá un escenario de
trabajo monitorizado con indicadores y complejas
La información es la materia prima de la toma de mediciones, pero no dice mucho a favor de cómo
decisiones, y la que puede ser objetivamente se han analizado y adaptado esas métricas a la
cuantificada proporciona criterios objetivos de realidad de los proyectos y la empresa.
gestión y seguimiento.

Desde los niveles concretos de la programación,
hasta los más amplios de la gestión global de la
compañía, Scrum Management considera tres
Criterios para el diseño y
fondos de escala, o de zoom con los que se
puede medir el trabajo
aplicación de métricas


Desarrollo y gestión de la solución técnica.
Gestión de proyecto. Cuantas menos, mejor
 Gestión de la organización.
 Medir es costoso
En el primero se puede medir, por ejemplo, la  Medir añade burocracia
 El objetivo de “Scrum Management” es
proporción de polimorfismo del código de un
programa, en el segundo, el porcentaje de trabajo trabajar con la mejor relación valor /
realizado, y en el tercero, también por ejemplo, el simplicidad.
nivel de satisfacción laboral.
Cuestiones para cada indicador:
Este libro cubre el área de gestión de proyectos,
¿Por qué se va a usarlo?
desde una perspectiva ágil; pero en esta
¿Cuál es el valor por incorporarlo?
introducción se exponen consideraciones
¿Cuál por omitirlo?
generales, comunes a los tres.
¿Se pueden tomar decisiones de gestión sin
esa información?

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 gestión que renuncian a la
experiencia, capacidad y sentido común del
gestor, incluso en las ocasiones en las que éste
puede ser suficiente; y se termina reclamando
métricas, produciendo gestores mecanicistas.

El sentido común puede bastar, por ejemplo, para
tomar decisiones de gestión de personal en una

Flexibilidad y sentido común
empresa de ingeniería de 10 empleados, sin
necesidad de procedimientos de medición del
clima laboral; pero sin embargo éstos son
necesarios en empresas con cientos de personas
Medir es costoso en sedes y departamentos diferentes.

El objetivo de la gestión Scrum es el valor, y la
cuestión clave para la incorporación de
Antes de incorporar un procedimiento de indicadores en la gestión de proyectos es:
medición, se debe cuestionar su conveniencia, y
la forma en la que se aplicará. ¿Cómo contribuye el uso de este indicador en
el valor que el proyecto va a aportar al cliente?
Medir no es un fin en sí mismo



La implantación del indicador ha dado buenos
resultados: desde su puesta en marcha, el
departamento de RR.HH. ha comenzado a ser
más eficiente y conseguir mayor satisfacción de
su cliente:
1.- Va reduciendo los costes que suponen la
incorporación de nuevas personas a la empresa.
2.- Va reduciendo los tiempos de respuesta a los
departamentos que solicitan nuevo personal.

Medición del avance del proyecto
¿El indicador es apropiado para La organización XYZ ha diseñado un cuadro de
información para mostrar el grado de avance de
el fin que se debe conseguir? cada proyecto.

Los indicadores de progreso de los proyectos, y
Medir no es, o no debería ser, un fin en sí mismo.
de las tareas en las que se descomponen, se
elaboran con el sistema clásico de la gestión de
¿Cuál es el fin?
proyectos predictiva:
¿Cumplir agendas, mejorar la eficiencia del
equipo, las previsiones…?
1.- Se realiza la estimación del tiempo de trabajo
necesario para cada tarea.
Sea crítico. El que lo haga, o diga que lo hace la
2.- Diariamente se actualizan los tiempos de
mayoría, no es una razón. Si después de anali-
trabajo invertidos.
zarlo no le convence, si prefiere no incorporar esa
3.- La diferencia muestra el porcentaje ejecutado
métrica, o modificarla: usted es el gestor.
de las tareas, y por tanto, el de cada proyecto.
Determinar qué medir es la parte más difícil. En el
mejor de los casos, las decisiones erróneas sólo
supondrán un coste de gestión evitable; pero
Medición de la eficiencia de los
muchas veces empeorarán lo que se intentaba
mejorar. trabajos de programación
La organización XYZ ha adoptado métricas
estándar de eficiencia de Ingeniería del Software:
Medición de la eficiencia en la LOC/Hour: Número total de líneas de código
nuevas o modificadas en cada hora.
empresa Además para motivar la productividad, ha
vinculado los resultados de esta métrica a la
La organización XYZ, dedicada al desarrollo de
retribución por desempeño de los programadores.
software, está integrando un sistema de calidad y
El resultado ha sido producir más líneas de
mejora integral para toda la empresa, que incluye
código sin incrementar la plantilla.
métricas para conocer el grado de eficiencia en
cada departamento.
Para evitar que se trate de un incremento “hueco”
de líneas de código, o que conlleve un aumento
Para el de RR.HH. se ha diseñado e implantado
de los errores por programar más deprisa, se ha
un indicador habitual para estos casos, que
dotado de mayor “rigor” al sistema de métrica,
determina la eficiencia en los procesos de
incorporando al poco tiempo otras métricas para
selección de personal.
complementar y mejorar el sistema de calidad:
Mide el coste de cada proceso de selección
(anuncios, selección de currículos, entrevistas…)
Test Defects/KLOC, Compile Defects/KLOC y
y lo divide por el número de puestos cubiertos.
Total Defects/KLOC, para controlar que no
aumenten el número de errores deslizados en el
Como no sólo es importante la eficiencia, sino
código.
también la satisfacción del cliente (interno en este
También se incorporaron indicadores “appraisal
caso, que será el departamento que solicita
time” para medir tiempo y costes del diseño y la
personal) esta métrica se combina con otra para
ejecución de las revisiones de código.
determinarlo: tiempo de respuesta.
Cuánto tiempo se tarda en cubrir las vacantes.

74 2008 – ScrumManager Project – http://www.scrummanager.net


Y por el temor a que el sistema de medición
pueda resultar excesivamente costoso se En el diseño e implantación de métricas se debe
incorporan también indicadores de coste de considerar:
calidad (COQ) que miden los tiempos de revisión
y los contrastan con las mejoras en los tiempos Usar el menor número de métricas posible.
eliminados por reducción de fallos.
¿El indicador es apropiado para el fin que se

¿Lo que vamos a medir es un
debe conseguir?

¿Lo que vamos a medir es un indicador válido de
indicador válido de lo que lo que queremos conocer?

queremos conocer?
Hay tareas de programación relativamente mecá-
nicas, orientadas más a la integración y configu-
ración 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 más
apropiado pensar en la cantidad de valor
integrado por unidad de desarrollo; expresadas
éstas en horas, iteraciones o puntos de función.

¿Qué queremos conocer: la cantidad de líneas de
programa, o el valor que entregamos al cliente?
¿Está relacionado lo uno con lo otro?
¿Se puede medir objetivamente el valor entre-
gado al cliente?

En nuestro trabajo son muchos los parámetros
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 función, la inestabilidad de los requisitos, la
proporción de acoplamiento, el nº de errores por
línea de código…

¿No estaremos muchas veces midiendo esto,
simplemente porque es cuantificable?

¿No estaremos midiendo el nº de líneas 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 métricas se pueden aplicar en el nivel de
gestión de la organización, de gestión de los
proyectos o de construcción de la solución
técnica.


Medición: Las unidades

ideales”, esto es, sin ninguna interrupción, pausa,
distracción o atención a tareas ajenas a la tarea

Velocidad, trabajo y tiempo del sprint que se tiene asignada.
9
Es el concepto similar al que PSP denomina
“Delta Time”.
Velocidad, trabajo y tiempo son las tres
magnitudes que mide la gestión de proyectos ágil,
y componen la fórmula de la velocidad, Trabajo
definiéndola como: cantidad de trabajo realizada
Medir el trabajo puede ser necesario por dos
en por unidad de tiempo.
razones: para registrar el ya hecho, o para
estimar anticipadamente, el que hay que realizar.
Velocidad = Trabajo / Tiempo
En ambos casos se necesita una unidad, y un
criterio objetivo de cómo se cuantifica.
Tiempo
8
El desarrollo ágil emplea la técnica “timeboxing”
para gestión de tiempo. En el caso de Scrum, la
unidad de tiempo para cada incremento de
producto es el Sprint.

Tiempo real y tiempo ideal
Antes de continuar, una observación: la
Trabajo ya realizado
diferencia, al hablar de tiempo, entre tiempo “real” Medir el trabajo ya realizado no entraña especial
y tiempo “ideal”. dificultad.
Se puede hacer con unidades relativas al
producto (p. ej. líneas de código) o a los recursos
empleados (coste, tiempo de trabajo…)

Para medirlo basta contabilizar lo ya realizado,
empleando las unidades con las que se opere:
líneas de código, horas trabajadas (reales o
teóricas)…

Medir el trabajo realizado NO es una métrica
Ágil.

LA GESTIÓN ÁGIL NO DETERMINA EL
GRADO DE AVANCE DEL PROYECTO
POR EL TRABAJO YA REALIZADO, SINO
Tiempo real, es el efectivo de trabajo. Es equiva- POR EL PENDIENTE DE REALIZAR
lente a la jornada laboral.
Para un equipo de cuatro personas con jornada
laboral de ocho horas el tiempo real en una
semana (cinco días laborables) es: Es posible que otros procesos de la organización
necesiten registrarlo y medirlo, pero no la gestión
4 * 8 * 5 = 160 horas ágil de proyectos.

El tiempo real de ese equipo en un sprint de 12

Trabajo pendiente de realizar
días de trabajo es:

4 * 8 * 12 = 384 horas
Sin embargo el término “tiempo ideal” se refiere al Scrum mide el trabajo pendiente para:
tiempo de trabajo necesario, en “condiciones
 Estimar el esfuerzo y la duración prevista
8
Timeboxing, se suele traducir por “tiempo limitado” es un para cada tarea.
aspecto común de las metodologías ágiles, que marcan
iteraciones para cada incremento, determinando qué tareas se
9
van a realizar, y en qué tiempo. Personal Software Process



 Determinar el avance del proyecto, y en
especial de cada sprint.  No empeñarse en estimaciones precisas.
 Estimar con la técnica “juicio de expertos”
 Descomponer las tareas de los sprints en
sub-tareas más pequeñas, si las estimaciones
superan los rangos de las 16-20 horas de de
trabajo.

Para Scrum Management, estimar con precisión,
de forma cuantitativa y objetiva el trabajo que
necesitará la construcción de un requisito, es un
empeño más que cuestionable.

El trabajo de un requisito no se puede cuantificar
de forma absoluta, porque las funcionalidades no Unidades de trabajo
son realidades de solución única.
Las unidades para medir el trabajo pueden estar
La “cantidad de trabajo” que consumirá cada relacionadas directamente con el producto, como
funcionalidad o cada historia de usuario no se los tradicionales puntos de función de COCOMO;
puede calcular de forma absoluta y objetiva; y en o indirectamente, a través del tiempo necesario
el caso de que se pudiera, la complejidad de la para realizarlo.
medición haría que la métrica resultante fuera
demasiado pesada para la gestión ágil.

Y si no resulta posible estimar con precisión la
cantidad de trabajo que hay en un requisito,
tampoco se puede saber cuánto tiempo costará,
porque además 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 día, o por hora, porque hay diferencias La gestión ágil suele llamar a las unidades que
muy grandes de estos resultados, según las emplea para medir el trabajo “puntos”, “puntos de
personas. funcionalidad” “puntos de historia”…
 Una misma tarea, realizada por las mismas Así por ejemplo la unidad de medida “Story Point”
personas consumirá diferentes tiempos reales de eXtreme Programming define: la cantidad de
en entornos de trabajo diferentes. trabajo que se realiza en un día de trabajo ideal.

Sobre estas premisas: Cada organización, según sus circunstancias y su
criterio institucionaliza su métrica de trabajo
 No es posible estimar con precisión, ni el definiendo el nombre y las unidades.
trabajo de un requisito, ni el tiempo necesario
para desarrollarlo. Puede basarse en
 La complejidad de las técnicas de estimación Estimación del tamaño relativo y emplear
crece exponencialmente en la medida que: puntos
o Intentan incrementar la fiabilidad y Estimación del tiempo ideal necesario
precisión de los resultados. para realizar la tarea que se mide.
o Aumenta el tamaño de la tarea
estimada. Lo importante es que la métrica empleada, su
significado y la forma de aplicación sea
La estrategia empleada por la gestión ágil es: consistente en todas las mediciones, en todos los



proyectos de la organización y conocida por todas
las personas: La estrategia empleada por la gestión ágil es:

Que se trate de un procedimiento de trabajo  No profundiza en estimaciones precisas.
institucionalizado.  Emplea la técnica de “juicio de expertos”
 Descompone las tareas de los sprints en sub-
tareas más pequeñas, si las estimaciones

Velocidad superan los rangos de las 16-20 horas de de
trabajo.

Velocidad es la magnitud que viene determinada Velocidad y eficiencia son términos similares. Se
por la cantidad de trabajo realizada en un periodo suele preferir “velocidad” cuando las mediciones
de tiempo (Timebox) Los equipos que miden el se basan en tiempo teóricos, y “eficiencia” cuando
trabajo con tiempo ideal, hablan de “Velocidad”. lo hacen en tiempo real.

Decir, por ejemplo, que la velocidad del equipo en
el sprint ha sido de 23, se refiere a que han
completado tareas que medían en toral 23 story
points.

Si en el sprint siguiente consiguen una velocidad
mayor, querrá decir que han logrado programar
más 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 inte-
rrupciones, 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.

Resumen
Tiempo real: tiempo total de trabajo, equivale a la
jornada laboral

Tiempo ideal: Tiempo de trabajo en “condiciones
ideales”, esto es: sin ninguna interrupción, pausa,
distracción, o atención a tareas ajenas a la que se
tiene asignada en el sprint.

Para determinar el grado de avance de un
proyecto, la gestión ágil no mide el trabajo ya
realizado, sino el pendiente de realizar.

Tomando como premisas

 No es posible estimar con precisión, ni el
trabajo de un requisito, ni el tiempo necesario
para desarrollarlo.
 La complejidad de las técnicas de estimación
crece exponencialmente en la medida que:
o Intentan incrementar la fiabilidad y
precisión de los resultados.
o Aumenta el tamaño de la tarea
estimada.


Medición: Usos y herramientas


La figura anterior representa la situación actual
10
del pila del producto (product backlog: ) el

Gráfico de producto: propietario del producto tiene previsto cerrar la
versión 1.0 cuando disponga de los cuatro
primeros temas, y su estimación inicial de trabajo
En inglés: gráfico “burn-up”. para llevarlos a cabo es de 950 puntos.

Este gráfico muestra en un vistazo, el plan La versión 1.1 incluirá 3 temas más que, según la
general de desarrollo del producto, y la evolución estimación inicial, supondrán unos 750 puntos de
prevista. trabajo.

Es un diagrama cartesiano que representa en el Y están también trazados los temas con los que
eje de ordenadas el trabajo estimado para piensa cerrar la versión 1.2, que se prevén con
desarrollar el producto, y en el de abcisas las 850 puntos más de trabajo.
fechas, medidas según las duraciones previstas
para los sprints. 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:

Representación del plan del producto, a partir de
los temas previstos en la pila de producto
A continuación se traza en el gráfico la línea de
(product backlog).
velocidad prevista.
Convenciones empleadas por el equipo:
Siguiendo con el ejemplo, la línea roja de la
imagen representa la velocidad de 300 puntos por
 Unidad para medición de trabajo: tiempo ideal
sprint.
 Tiene previsto realizar sprints de duración fija
mensual.
También puede resultar útil esbozar una estima-
 El equipo está formado por 4 personas, y
ción optimista y otra pesimista para tener la visión
viene desarrollando una velocidad de 300
de una holgura de fechas aceptable.
puntos por sprint (300 horas ideales de
trabajo)

10
Las listas de producto y de versión evolucionan de forma
continua durante la vida del producto.



El equipo dispone en la pila del sprint, de la lista
de tareas que va a realizar, y en cada uno figura
La línea de velocidad proyecta sobre el eje X la el esfuerzo pendiente.
fecha o sprint en el que previsiblemente se Esto es: el primer día, en la pila de tareas figura
completarán las versiones representadas en el para cada tarea el esfuerzo que se ha estimado,
eje Y. puesto que aún no se ha trabajado en ninguna de
ellas.

Gráfico de avance:
Día a día, cada miembro del equipo actualiza en
la pila del sprint el tiempo que le queda a las
tareas que va desarrollando, hasta que se
monitorización del sprint terminan y van quedando en 0 los tiempos
pendientes.
La figura siguiente muestra un ejemplo de pila en
También se suele emplear la denominación el sexto día del sprint: las tareas terminadas ya no
inglesa: gráfico “burn-down”. tienen esfuerzo pendiente, y del esfuerzo total
previsto para el sprint: 276 puntos (A), en el
Es el gráfico que actualiza el equipo en las momento actual quedan 110 (B).
reuniones de seguimiento del sprint, para com-
probar 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 gráfico toman forma los dos principios:

 En el eje Y se registra el trabajo que aún falta
por realizar.
 Se actualiza a diario. Con esta información de la pila del sprint se
actualiza el gráfico poniendo cada día el esfuerzo
pendiente total de todas las tareas que aún no se
han terminado.



La estimación que realizó el equipo en la reunión
de inicio del sprint es inferior al esfuerzo real que
están requiriendo las tareas.

Y el siguiente sería el patrón de gráfica de un
“sprint sobre-estimado”.

El avance ideal de un sprint estaría representado
por la diagonal que reduce el esfuerzo pendiente
de forma continua y gradual hasta terminarlo en el
último día del sprint:

Estimación de póker
Es una práctica ágil, útil para conducir las reunio-
nes en las que se estima el esfuerzo y la duración
de tareas.

Para evitar en estos casos las discusiones dila-
tadas que no terminan de dar conclusiones con-
cretas, James Grening ideó este juego de plani-
Las gráficas de diagonal perfecta no son lo ficación como ayuda para conducir la reunión.
habitual, y la siguiente imagen es un ejemplo de
un patrón de avance más normal. El modelo inicial de Grening consta de 8 cartas,
con los números representados en siguiente
figura, porque James lo ideó para las
estimaciones de versión en eXtreme Program-
ming, con equipos que emplean como unidad de
esfuerzo: días de trabajo de cada par de
11
programadores y trabajan con tareas de tamaño
12
máximo de 10 días.

El siguiente sería el aspecto de la gráfica en un
“sprint sub-estimado”

11
eXtreme Programming trabaja con programación por
parejas.
12
Las tareas de mayor tamaño se descomponen en sub-
tareas hasta que éstas tienen estimaciones máximas de 10
días.



El funcionamiento es muy simple: cada Si se quiere emplear la planificación de póker
participante dispone de un juego de cartas, y en para estimar requisitos a nivel de producto o de
la estimación de cada tarea, todos vuelven boca versión (funcionalidades, temas…) además de
arriba la combinación que suma el esfuerzo usarlo al nivel de tareas de sprint, se pueden
estimado. añadir cartas al juego para permitir estimaciones
de mayor tamaño (34, 55, 89, 144…)
Cuando se considera que éste es mayor de 10
horas (o del tamaño máximo considerado por el Es frecuente emplear una carta con un símbolo
equipo para una tarea), se levanta la carta “ ” de duda o interrogación para indicar que, por las
razones que sean, no se puede precisar una
Cada equipo u organización puede utilizar un estimación.
juego de cartas con las numeraciones adecuadas También es posible incluir otra carta con alguna
a la unidad de esfuerzo con la que trabajan, y el imagen alusiva, para indicar que se necesita un
tamaño máximo de tarea que se va a estimar. descanso.

Lo relevante no es el número de cartas, la unidad
de medida empleada, o si el tamaño máximo de Funcionamiento
tarea debe ser 5, 7 ó 10 días, sino trabajar con el
 Cada participante de la reunión tiene un juego
modelo que el equipo considera más apropiado,
de cartas.
respetando los principios siguientes:
 Para cada tarea (historia de usuario o
funcionalidad, según sea el nivel de requisitos
 No definir tareas demasiado grandes, porque
que se va a estimar) el cliente, moderador o
entorpece la precisión de las estimaciones y
propietario del producto expone la descripción
la identificación de riesgos.
empleando un tiempo máximo.
 No definir tareas con duraciones inferiores a
 Hay establecido otro tiempo para que el
medio día ideal de trabajo.
cliente o propietario del producto atienda a las
 Utilizar al misma unidad de medida (story
posibles preguntas del equipo.
points, días, horas…) en todos los gráficos y
 Cada participarte selecciona la carta, o cartas
pilas.
que representan su estimación, y las separa
del resto, boca abajo.
Variante: sucesión de Fibonacci  Cuando todos han hecho su selección, se
muestran boca arriba.
Basado en el hecho de que al aumentar el tama-  Si la estimación resulta “infinito”, por sobre-
ño de las tareas, aumenta también el margen de pasar el límite máximo establecido, la tarea
error, se ha desarrollado una variante que con- debe dividirse en sub-tareas de menor
siste en emplear sólo números de la sucesión de tamaño.
Fibonacci para realizar las estimaciones, de forma  Si las estimaciones resultan muy dispares, el
que: Scrum Manager, con su criterio de gestión, y
basándose en las características del pro-
 El juego de cartas está compuesto por yecto, equipo, reunión, nº de elementos pen-
números de la sucesión de Fibonacci. dientes de evaluar, puede optar por:
 La estimación no se realiza levantando varias  Preguntar a las personas de las
cartas para componer la cifra exacta, sino estimaciones extremas: ¿Por qué
poniendo boca arriba la carta con la cifra más crees que es necesario tanto
aproximada a la estimación. tiempo?, y ¿por qué crees que es
necesario tan poco tiempo? Tras
Para estimar tareas puede ser válido un juego de escuchar las razones, repetir la esti-
cartas como éste: mación.
 Dejar a un lado la estimación de esa
tarea y retomar al final o en otro
momento aquellas que hayan que-
dado pendientes.
 Pedir al cliente o propietario del
producto que descomponga la fun-
cionalidad y valorar cada una de las
funcionalidades resultantes.
 Tomar la estimación menor, mayor, o
la media.



Este protocolo de reunión evita los atascos de
análisis circulares en ping-pong entre diversas
opciones de implementación, hace participar a
todos los asistentes, reduce el cuarto de hora o la
media hora de tiempo de estimación de una
funcionalidad, a escasos minutos, consigue alcan-
zar consensos sin discusiones, y además resulta
divertido y dinamiza la reunión.

Resumen
El gráfico de producto o burn-up, muestra en
un vistazo el plan general de desarrollo del
producto.

A partir de la velocidad del equipo y las
estimaciones de trabajo previstas en la pila del
producto, representa las fechas o sprints en los
que previsiblemente se irán terminando las
diferentes versiones.

El gráfico 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 línea diagonal
que representaría el avance ideal del sprint
alertan de forma temprana de desviaciones sobre
el ritmo de desarrollo previsto.

La estimación de póker es una práctica ágil para
reducir las dificultades habituales en las
reuniones de trabajo para planificación 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:
Natural: los participantes pueden estimar el
esfuerzo con la cifra exacta que crean más
adecuada.
Fibonacci: las estimaciones solo se pueden
realizar empleando números de la sucesión de
Fibonacci.

En cada caso, el juego de cartas empleado tiene
la numeración apropiada.


Índice
A F
Adaptive Software Development · 32 Fases de desarrollo · 23
Agile Alliance · 32 Fertilización cruzada · 60, 66
Agile Enterprise · 34 Flexibilidad · 29
Agile Unified Process · 32
Arie van Bennekum · 33
ASD · 32 G
AUP · 32
Gestión de proyectos
Adaptable · 37
B Ágil · 29
Modelos · 32
Bernard Schriever · 15 Objetivos · 29
Burn-down · 47, 62, 68, 86 Origen · 21, 32
Burn-up · 85 Características diferenciales · 38
Clásica
Ámbito · 17
C Objetivo · 17
Otras denominaciones · 37
Campo de scrum · 22 Premisas · 37
Características · 24 Principios · 17, 21
Cascada · 21 Criterios para seleccionar un modelo · 38
Ciclo de desarrollo ágil · 30 Organizaciones · 16
Ciclo de vida secuencial · 21, 22 Origen · 15
Problemas · 23 Predictiva · 16
Cierre · 31 Gráficos
Concept of Operations (ConOps) · 60 Burn-down · 86
Concepto · 30 De avance (burn-down) · 47, 62, 68
Concurrencia · 15 De producto (burn-up) · 85
Criticidad · 40
Crystal · 33
Cultura de la organización · 41 H
Hirotaka Takeuchi · 21
D
DSDM · 33 I
IEEE 1012-1998 · 33
E Ikukiro Nonaka · 21
Incepción · 32
Equipo (rol) · 48, 54 Incertidumbre · 24
Equipos Incremento · 47, 59
Auto-organización · 23, 24 Definición · 62
Características · 24 Innovación
Características · 54 Como valor · 22, 29
Control sutil · 24 Integridad · 33
Difusión del conocimiento · 24 ISO 12207 · 59
Especialización · 21
Especialización · 22
Especulación · 31 J
Estimación de póker · 87
Fibonacci · 88 James Grening · 87
Exploración · 31, 60 Jeff Sutherland · 34

Índice

Re-trabajo · 38
K Reuniones
Seguimiento del sprint · 86
Ken Schwaber · 34 Revisión · 31

M S
Mantenimiento · 31 Sashimi · 23
Meter Norden · 16 scrum
Métricas Campo de · 22
Áreas de medición Scrum Management · 73 Solapamiento · 23
Estrategia de la gestión ágil · 80 Scrum · 34
Tiempo ideal · 79 Control ágil del proyecto · 46
Tiempo real · 79 Estructura central · 45
Trabajo · 79 Origen · 45
Trabajo pendiente · 80 Reuniones · 65
Trabajo realizado · 79 Planificación del sprint · 47, 65
Unidades de trabajo · 80 Formato · 66
Velocidad · 79 Revisión del sprint
Michel Hammer · 21 Formato · 69
Mike Breedle · 34 Seguimiento del sprint · 47
Formato · 68
Revisión del sprint · 47
P Roles · 47
Valores · 48
Personas Scrum Management
Sensibilidad al entorno · 40 Responsabilidades · 53
Pila del producto · 47, 59 Scrum Manager
Características · 60 Team leader · 66
Definición · 60 Team leader (rol) · 48, 55
Formato · 61 Solapamiento · 22
Pila del sprint · 47, 59 Sashimi · 23
Características · 60 scrum · 23
Definición · 61 Tipos · 23
Formato · 61 Sprint · 34, 45, 79
Plan de producto · 86 Story Point · 80
Procesos · 40
Producción basada en · 21
Producto T
Plan · 86
Rigidez · 39 Team leader (rol) · 55
Propietario del producto (rol) · 48, 54 Tiempo de salida al mercado · 29
Prototipado Timeboxing · 79, 81
Coste · 39
Proyecto
Características · 15
Definición clásica · 15
V
Puntos de historia · 80
Velocidad · 81
Visión · 30
R
Requisitos
W
Ágiles · 59
Del sistema · 59 WBS · 16
Del software · 59
Estabilidad · 39
Inestabilidad · 29 X
Modificación · 23
Responsabilidad · 59 XBreed · 34


Scrum Manager Proyecto Apuntes

Más contenido relacionado

La actualidad más candente (6)

Destacado (20)

Similar a Scrum Manager Proyecto Apuntes (20)

Último (20)

Scrum Manager Proyecto Apuntes