ScrumManager: Gestión de proyectos ágiles

ScrumManager
Manual
ScrumManager: Gestin de proyectos
Ttulo
ScrumManager: Gestin de proyectos.
Autor
Juan Palacio.
Imagen de Portada
Philip A.
Edicin
Septiembre 2008
Impresin
Versin impresa disponible en http://www.lulu.com

http://www.lulu.com/content/3671394
Web del proyecto ScrumManager
Ms informacin en: http://www.scrummanager.net
Derechos
Derechos registrados en Safe Creative.

Consulta de derechos reservados y liberados en: http://www.safecreative.org/work/0808180903131
Contenido
Contenido 5
ScrumManager: Informacin 9
ScrumManager: Informacin 11
Qu es ScrumManager? 11
ScrumManager: Gestin de proyectos 11
Formacin abierta 11
Formacin y asesora profesional 12
Origen de la gestin de proyectos 13

Introduccin: Proyectos y operaciones 15
Definicin clsica de proyecto 15
Origen de la gestin de proyectos 15
Organizaciones referentes en la gestin de proyectos 16
Modelo vlido para cualquier industria. 16
Gestin predictiva o clsica 17
Gestin de proyectos clsica 17
mbito de la gestin de proyectos 17
Resumen 18
El nuevo escenario 19
Escenario de desarrollo en los 80 21
The New New Product Development Game 21
Caractersticas del nuevo escenario 22
Campos de scrum vs. modelo clsico de desarrollo. 23
Caractersticas del campo de scrum 23
Incertidumbre 23
Auto-organizacin 23
Fases de desarrollo solapadas 24
Control sutil 24
Difusin del conocimiento 24
Resumen 25
Gestin de proyectos gil 27

Introduccin 29
Objetivos de la gestin gil 29
1.-Valor 29
2.-Reduccin del tiempo de salida al mercado 29
3.-Agilidad 29
4.-Flexibilidad 29
5.- Resultados fiables 30
Las preferencias de la gestin gil. 30
El ciclo de desarrollo gil 30
1.- Concepto 30
2.- Especulacin 31
3.- Exploracin 31
4.- Revisin 31
2008 ScrumManager Project http://www.scrummanager.net

Contenido
5.- Cierre 31
Principales modelos de gestin gil 32
ASD 32
AUP 32
CRYSTAL 33
DSDM 33
SCRUM 34
XBreed Agile Enterprise 34
Resumen 34
Gestin de proyectos: formal o gil? 35

gil, clsica, predictiva ? 37
Premisas de la gestin de proyectos predictiva. 37
Caractersticas de la gestin de proyectos predictiva 37
Hay otras premisas 37
Cundo y por qu emplear uno u otro estilo de gestin 38
Caractersticas del proyecto 38
Prioridad de negocio 39
Estabilidad de los requisitos 39
Rigidez del producto 39
Coste de prototipado 39
Criticidad del sistema 40
Tamao del sistema 40
Condiciones de la organizacin 40
Nivel profesional 41
Cultura organizativa 41
Modelo de de desarrollo 41
Resumen 41
Introduccin al modelo Scrum para desarrollo de Software 43

El origen. 45
Introduccin al modelo 45
Control de la evolucin del proyecto 46
Revisin de las Iteraciones 46
Desarrollo incremental 46
Desarrollo evolutivo 46
Auto-organizacin 46
Colaboracin 46
Visin general del proceso 46
Las reuniones 47
Los elementos 47
Los roles 47
Valores 48
Resumen 48
Roles y responsabilidades de proyecto 51

Introduccin 53
Responsabilidades generales Scrum Management 53

Contenido
De management 53
De procesos 53
De produccin 53
Responsabilidades y roles en la ejecucin de proyectos 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 produccin 55
Los elementos de Scrum 57

Introduccin 59
Los requisitos en el desarrollo gil 59
Requisitos y visin 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

Introduccin 65
Planificacin del sprint 65
Descripcin general 65
Pre-condiciones 65
Entradas 65
Resultados 65
Formato de la reunin 66
1
Funciones del rol de Scrum Manager 66
Pizarra de trabajo 67
Un ejemplo de pizarra. 67
Seguimiento del sprint 68
Descripcin 68
Entradas 68
Resultados 68
Revisin del sprint 69
Descripcin 69
Objetivos 69
Pre-condiciones 69
Entradas 69
Resultados 69

Contenido
Resumen 69
Medicin: consideraciones 71
Introduccin 73
Por qu medir? 73
Flexibilidad y sentido comn 73
Criterios para el diseo y aplicacin de mtricas 73
Cuantas menos, mejor: 73
El indicador es apropiado para el fin que se debe conseguir? 74
Medicin de la eficiencia en la empresa: 74
Medicin del avance del proyecto. 74
Medicin de la eficiencia de los trabajos de programacin 74
Lo que vamos a medir es un indicador vlido de lo que queremos conocer? 75
Resumen 75
Medicin: Las Unidades 77

Velocidad, trabajo y tiempo 79
Tiempo 79
Tiempo real 79
Tiempo ideal 79
Trabajo 79
Trabajo ya realizado 79
Trabajo pendiente de realizar 79
Unidades de trabajo 80
Velocidad, o eficiencia? 81
Resumen 81
Medicin: Usos y herramientas 83

Grfico de producto: 85
Ejemplo: 85
Grfico de avance: monitorizacin del sprint 86
Estimacin de pker 87
Variante: sucesin de Fibonacci 88
Funcionamiento 88
Resumen 89
ndice 91
ndice 93

ScrumManager: Informacin
Qu es ScrumManager?
ScrumManager es un marco de gestin gil, flexible y sistmico para organizaciones basadas en
equipos.
gil:
ScrumManager prefiere el valor de las personas al de los procesos; el de la colaboracin al del contrato;
y la capacidad de cambio, adaptacin rpida y entrega temprana de valor, antes que la previsibilidad de
la planificacin cerrada.
Flexible:
ScrumManager no es un modelo basado en la aplicacin de prcticas cerradas, o de talla nica.
Se centra en los principios y valores de la agilidad, y supedita las prcticas y su formato a las
circunstancias de las organizaciones y los proyectos.
Sistmico
ScrumManager considera a las organizaciones como sistemas de reas relacionadas, de tal forma que la
agilidad va ms all de la implantacin de prcticas en el mbito de gestin de proyectos, o en el de
desarrollo de producto. Debe comprender a todas, y de forma alineada con una, cultura y gestin de la
organizacin, tambin gil.
Organizaciones basadas en equipos:

ScrumManager es un marco de gestin para equipos multi-disciplinares y auto-gestionados que se
1
desenvuelven en campos de scrum .
ScrumManager: Gestin de proyectos

Desde la consideracin sistmica de las organizaciones, el modelo ScrumManager
clasifica el conocimiento que comprende la agilidad en tres reas: proyecto, producto
y management.
Este manual es una gua de formacin de las prcticas recomendadas para la

primera de ellas: Gestin de proyectos.
Formacin abierta
ScrumManager apuesta por un modelo abierto de difusin del conocimiento, frente a los
patrones clsicos, que resultan ms costosos e inaccesibles.
Este libro es un recurso de formacin abierto para la gestin de proyectos en el marco

ScrumManager. La versin electrnica es gratuita y puede descargarse libremente desde
la comunidad ScrumManager.
(http://www.scrummanager.net)
Para colaborar con el proyecto, se recomienda adquirir la versin impresa (Disponible en

http://www.lulu.com : http://www.lulu.com/content/3671394
1
Hirotaka Takeuchi, Ikujiro Nonaka The New New Product Development Game, Harvard Business Review, 1986.
2008 ScrumManager Project http://www.scrummanager.net 11

Formacin y asesora profesional

La formacin, acceso a la comunidad y acreditacin profesional son libres para profesionales, a ttulo
personal.
Para servicios de formacin presencial, asesora o certificacin a empresas; as como para uso del
material del proyecto con nimo de lucro, o la prestacin de servicios como partner de consultora, se
puede consultar o solicitar informacin en: http://www.scrummanager.net.
12 2008 ScrumManager Project http://www.scrummanager.net

Origen de la gestin de proyectos
Definicin clsica de proyecto

Introduccin: Proyectos y
operaciones Conjunto nico de actividades necesarias
para producir un resultado definido en un
rango de fechas determinado y con una
asignacin especfica de recursos
Las construcciones de ingeniera civil, como

puentes o edificios, son ejemplos clsicos de
obras realizadas como proyectos, y en general lo
El desarrollo de productos, la prestacin de es el desarrollo de cualquier sistema singular.
servicios, o incluso la organizacin de la propia
empresa son trabajos que pueden tomar la forma Un proyecto tiene objetivos y caractersticas
de proyectos o de operaciones. nicas.
Algunos necesitan el trabajo de una sola persona,
Ambos compartes tres caractersticas: y otros el de cientos de ellas; pueden durar unos
das o varios aos.
Los realizan personas.
Se emplean recursos limitados. Algunos ejemplos de proyectos:
Se llevan a cabo siguiendo una estrategia de
actuacin. Diseo de un nuevo ordenador porttil.
Construccin de un edificio.
Aunque comparten estas tres caractersticas, la Desarrollo de un sistema de software.
diferencia clave entre operaciones y proyectos es Implantacin de una nueva lnea de producto
que: en una empresa.
Diseo de una campaa de marketing.
Las operaciones se ejecutan de forma

repetitiva para obtener resultados de
similares caractersticas Origen de la gestin de
proyectos
Los proyectos producen resultados
nicos
Los proyectos han existido siempre.

Se considera proyecto a la ejecucin de un Cualquier trabajo para desarrollar algo nico es
trabajo que adems de requerir personas, recur- un proyecto, pero la gestin de proyectos es una
sos y ejecucin controlada: disciplina relativamente reciente que comenz a
forjarse en los aos sesenta.
Es un desarrollo nico
La necesidad de su profesionalizacin surgi en
La teora clsica de gestin de proyectos, aade el mbito militar.
a la caracterstica anterior otra, que desde la En los 50, el desarrollo de complejos sistemas
perspectiva de gestin predictiva tiene sentido, militares, requera coordinar el trabajo conjunto de
pero no tanto, como se ver, desde la perspectiva equipos y disciplinas diferentes, en la cons-
de gestin de proyectos gil. truccin de sistemas nicos.
Bernard Schriever, arquitecto del desarrollo de
Se desarrolla en un marco temporal pre- misiles balsticos Polaris, es considerado el padre
establecido. de la gestin de proyectos, por la introduccin del
concepto de concurrencia, para integrar todos
los elementos del plan del proyecto en un solo
programa y presupuesto.
El objetivo de la concurrencia era ejecutar las

diferentes actividades de forma simultnea, y no

secuencialmente, y al aplicarla en los proyectos

Thor, Atlas y Minuteman se redujeron conside- Para dar respuesta a esta necesidad, desde los
rablemente los tiempos de ejecucin. aos 60 han surgido organizaciones que contri-
buyen al desarrollo del cuerpo de conocimiento
La industria del automvil sigui los pasos de la de una gestin de proyectos, para ofrecer garan-
militar, aplicando tcnicas de gestin de tas de previsibilidad y calidad de los resultados.
proyectos para la coordinacin del trabajo entre
reas y equipos diferentes.
Este conocimiento se ha configurando como el
Comenzaron a surgir tcnicas especficas, currculo de una nueva profesin: La gestin de
histogramas, cronogramas, los conceptos de ciclo proyectos predictiva.
de vida del proyecto o descomposicin en tareas
(WBS Work Breakdown Structure). Las organizaciones ms relevantes en esta lnea
son:
En 1960, Meter Norden, del laboratorio de
investigacin de IBM, en su seminario de Inge- Internacional Project Managenet Association
niera de Presupuesto y Control presentado ante (IPMA), fundada en 1965
American Management Association, indic: Project Management Institute (PMI)
constituido en 1965
Ms 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 metodologas y
los proyectos procesos para la gestin de proyectos.
Es absolutamente necesario Prince2 ha tenido la evolucin inversa. Comenz
descomponer los proyectos en partes siendo una metodologa, alrededor de la que se
de menor dimensin para realizar ha terminado creando una organizacin.
planificaciones.
Modelo vlido para cualquier

industria.
Organizaciones referentes Tambin en este sentido el sentido de evolucin
ha sido diferente para Prince2.
en la gestin de proyectos PMI e IPMA tuvieron desde el principio como
finalidad el desarrollo de un conocimiento de
gestin vlido para cualquier proyecto.
La construccin de sistemas complejos que Sin embargo, Prince2 comenz siendo un modelo
requeran el trabajo sincronizado de varias de referencia para proyectos especficos de
disciplinas hizo evidente en los 60 la necesidad Tecnologas de la Informacin, desarrollado por la
de nuevos mtodos de organizacin para evitar Central Computer and Telecommunications
problemas recurrentes: Agency (CCTA) del Gobierno Britnico; y a partir
de una revisin 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.

Gestin predictiva o clsica

de tipo: Concepto, requisitos, diseo,
planificacin, desarrollo, cierre.
La gestin de proyectos desarrollada en las

ltimas dcadas del siglo pasado se basa en la Grupos de procesos de la gestin de proyectos
planificacin del trabajo, y en el posterior PMBOK 2004
seguimiento y control de la ejecucin.
La planificacin se realiza sobre un anlisis

detallado del trabajo que se quiere realizar y su
descomposicin en tareas.
Parte por tanto de un proyecto de obra, o de unos
mbito de la gestin de
requisitos detallados de lo que se quiere hacer.
Sobre esa informacin se desarrolla un plan
proyectos
adecuado a los recursos y tiempos disponibles; y
durante la construccin se sigue de cerca la
ejecucin para detectar posibles desviaciones y La solvencia demostrada por la gestin de
tomar medidas para mantener el plan, o proyectos en la industria militar, y en la
determinar qu cambios va a experimentar. automovilstica para solucionar los problemas
Se trata por tanto de una gestin predictiva, que habituales de calidad, tiempos y costes, coincide
vaticina a travs del plan inicial cules van a ser en el tiempo con la presin que todas las
la secuencia de operaciones de todo el proyecto, industrias experimentan en mayor o menor
su coste y tiempos. medida para reducir la agenda de salida al
mercado y los costes de produccin. Como
Su principal objetivo es conseguir que el producto resultado, en todos los sectores: farmacutico,
final se obtenga segn lo previsto; y basa el qumico, servicios, tecnologas de la informacin,
xito del proyecto en los tres puntos apuntados: etc. se adoptan tcnicas de gestin de proyectos,
agendas, costes y calidad. dndoles de facto validez para todos los mbitos.
Gestin de proyectos clsica

La gestin de proyectos predictiva o clsica es
una disciplina formal de gestin, basada en la
planificacin, ejecucin y seguimiento a travs de
procesos sistemticos 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
cronograma, el presupuesto y los recursos.
Divide el desrrollo en fases a las que
considera ciclo de vida, con una secuencia

Resumen
Definicin clsica de proyecto: construccin
de un resultado nico, en unas fechas
previstas y con unos recursos previstos de
antemano.
La profesionalizacin de la gestin de
proyectos surgi en los 50 para dar respuesta
a las necesidades de la industria militar, y en
los aos posteriores el resto de industrias han
adoptado sus principios.
Las organizaciones ms conocidas por la
investigacin, y creacin de comunidades
profesionales para la gestin de proyectos
son: PMI (Project Management Institute),
Internacional Project Managenet Association
(IPMA) y Prince2.
Caractersticas de la gestin de proyectos
desarrollada en la segunda mitad del siglo
pasado:
Gestin basada en la aplicacin
sistemtica de procesos repetibles y
escalables.
Los criterios de xito de un proyecto son:
calidad, costes y fechas.
Carcter predictivo: ejecucin segn el
plan inicial previsto.
Desarrollo sobre un entorno estable.
El objetivo de la gestin es: desarrollar un
plan, y mantener el cronograma y los
recusos planificados.
Ciclo de vida compuesto por fases
secuenciales.

El nuevo escenario
El nuevo escenario
Divisin del trabajo, especializacin y produccin
Escenario de desarrollo en basada en procesos, fueron premisas que, como

axiomticas, asumi la gestin de proyectos, y
los 80
por esta razn, los puntos clave de la gestin
predictiva o clsica son:
Estimar cul va a ser el trabajo necesario, y a

En los 80, el ciclo de vida de los proyectos era el continuacin gestionar la ejecucin para que
denominado en cascada: El proyecto se divide en se cumplan la estimacin inicial.
fases, y stas se ejecutan de forma secuencial: El trabajo se desarrolla en fases.
definicin del producto, diseo, construccin de Divisin del trabajo en equipos de
elementos, integracin, pruebas especialistas.
Desarrollo basado en procesos.
Dos caractersticas de la construccin de nuevos
productos en esta dcada son:
Ciclo de vida secuencial.

Divisin y especializacin del trabajo.
The New New Product

Development Game
Es el ttulo del artculo publicado en 1986 por
Cada fase la realiza un departamento, personas o Hirotaka Takeuchi e Ikujijo Nonaka; que a su vez
equipos diferentes, profesionalmente especiali- daba continuacin a otro anterior de los mismos
zados en los conocimientos necesarios. autores junto con Kenichi Imai: Managing the
New Product Development Process: How
La gestin de proyectos desarrolla modelos de Japanese Companies Learn and Unlearn.
estructuras organizativas de tipo matricial, con
diferentes variaciones, para facilitar la comunica- La publicacin de The New New Product
cin y coordinacin entre equipos diferentes. Development Game ha marcado el punto de
inicio de una nueva forma de gestionar proyectos
En las mismas fechas, a la par de la consolida- en entornos rpidos e inestables.
cin del conocimiento de gestin de proyectos, se
estaban desarrollando las teoras de produccin Cuando la teora de gestin de proyectos estaba
basada en procesos, promovidas por Michel alcanzando una cierta madurez, los autores ob-
Hammer, como mejor medio para garantizar la servaron que algunas empresas, en mercados
calidad, eficiencia y repetibilidad. muy competitivos, relacionados con productos de
vanguardia tecnolgica, trabajaban ignorando esa
teora.
Muchas compaas han descubierto que para

mantenerse en el actual mercado competitivo
necesitan algo ms que los conceptos bsicos de
calidad elevada, costes reducidos y diferen-
ciacin. Adems de esto, tambin 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
El ordenador personal NEC PC 8000 (1979)

Hasta entonces, el desarrollo de nuevos produc- La cmara Canon AE-1 (1976)
tos se realizaba como una carrera de relevos, en Cmara Canon Auto Boy (1979).
la que un grupo de especialistas funcionales
pasaban el relevo al siguiente. En estas empresas el trabajo no recorra fases a
El proyecto avanzaba secuencialmente de fase travs de diferentes equipos especializados.
en fase: creacin del concepto, pruebas de viabi-
lidad, diseo del producto, diseo del proceso, El producto emerge de la interaccin constante
desarrollo de prototipo y produccin final. de un equipo de lite, multidisciplinar que trabaja
conjuntamente desde el principio hasta el final
Es un modelo de trabajo segmentado por
especializacin de funciones. Nonaka y Takeuchi compararon la forma de
La gente de marketing explora y estudia las trabajar de estos equipos nicos y multi-
necesidades de los clientes, para crear el con- disciplinares, con los equipos de rugby, y el
cepto del producto. Los ingenieros de investi- ambiente y entorno de trabajo que les
gacin y desarrollo elaboran un diseo adecuado, proporcionaba la empresa lo llamaron campo de
2
los ingenieros de produccin llevan a cabo la scrum .
solucin tcnica
La figura siguiente representa el ciclo de vida al Caractersticas del nuevo

construir un producto con un patrn de gestin
secuencial, y cul es la diferencia con la nueva
forma, observada por Nonaka y Takeuchi en
escenario
empresas que ignoraban los principios de la
gestin clsica de proyectos.
En los 40, 50 y 60 los productos tardaban aos en

quedar obsoletos, y las empresas los producan
con variaciones mnimas a lo largo del tiempo.
Los desarrollos secuenciales puros suelen ser
ms tericos que prcticos, y en realidad quienes Apple ha desarrollado 6 versiones de su popular
los adoptan, generalmente producen ciclos iPod, en slo 6 aos.
secuenciales con solapamiento, donde una fase
no suele necesitar para empezar que est Hoy determinados productos permanecen en un
completamente terminada la anterior. continuo estado beta. El entorno tecnolgico es
tan inestable, que las novedades se lanzan tras el
Nonaka y Takeuchi observaron que empresas menor tiempo de desarrollo posible, dejando que
americanas y japonesas tecnolgicas, de primera vayan evolucionando a travs de versiones, en el
lnea, que aventajaban a sus competidores en propio mercado. Que sea ste quien diga de
innovacin y rapidez, compartan pautas de forma continua cmo deben modificarse los
trabajo comunes, ajenas al clsico patrn secuen- requisitos.
cial.
En estas circunstancias, las diferencias de lide-
Analizaron la forma de trabajo de: Fuji-Xerox, razgo entre unas empresas y otras no radica
Canon, Honda, Nec, Epson, Brother, 3M, Xerox y tanto en la eficiencia y previsibilidad con la que se
Hewlett-Packard y en concreto la forma en la que gestionan el lanzamiento de nuevos productos,
abordaban el desarrollo de 6 productos: sino en la capacidad de agilidad y cambio durante
su construccin; y el principal valor para ocupar
La fotocopiadora Fuji-Xerox FX-3500. (1978) puestos de cabeza es la innovacin.
La copiadora personal Canon PC-10 (1982) 2
Scrum es un trmino empleado en rugby para definir una
El coche urbano de 1200cc de Honda (1981) determinada formacin del equipo.

El nuevo escenario
Campos de scrum vs.

regularmente incrementos de funcionalidad que
incrementan el valor al producto.
modelo clsico de Caractersticas del campo

desarrollo. de scrum
Estos son los principales contrastes que
diferencian el desarrollo tradicional del gil: Las caractersticas ambientales en las empresas
que desarrollan los nuevos productos con
modelos de gestin gil son:
Incertidumbre consustancial al entorno y la

cultura de la organizacin.
Equipos auto-organizados.
Control sutil
Difusin y transferencia del conocimiento
Incertidumbre
Se trabaja en entornos de incertidumbre consus-
tancial.
En estas empresas, la direccin apunta cul es la
No lo realizan equipos diferentes especializados.
meta genrica a la que se apunta, o la direccin
Es un equipo nico, formado por personas muy
estratgica que hay que segur. No se proporciona
competentes, con perfiles y conocimientos que
el plan detallado del producto.
cubren las disciplinas necesarias para llevar a
Al mismo tiempo se da al equipo un margen de
cabo el trabajo.
libertad amplio.
Los ingredientes que sirven de acicate para la
No hay fases. En realidad las fases pasan a ser
creatividad y el compromiso son:
tareas que se ejecutan cuando se necesitan.
No se hace primero el diseo del concepto o los
La tensin que crea la visin difusa y el reto
requisitos, ms tarde el anlisis, luego el
que supone el grado de dificultad que
desarrollo, etc.
encierra.
Lo que aplicado al software seran las fases de:
El margen de autonoma, libertad y
requisitos del sistema, requisitos del software,
responsabilidad.
anlisis, diseo, construccin, pruebas e inte-
gracin; y se ejecutaran de forma secuencial,
pasan a tareas que se llevan a cabo en el mo-
mento que hacen falta. Normalmente a lo largo de
Auto-organizacin
pequeas iteraciones durante todo el desarrollo. Son equipos auto-organizados, sin roles de
gestin ni pautas de asignacin de tareas.
No se espera a disponer de requisitos detallados No se trata de equipos auto-dirigidos, sino auto-
para comenzar el anlisis, ni a tener ste para organizados. La gestin es la que marca la
pasar a la codificacin. Muchas veces los requi- direccin, pero no la organizacin.
sitos no se pueden conocer si no avanza el
desarrollo y se va viendo y tocando el resultado. Parten de cero. Deben empezar por crear su pro-
Otras veces el mercado es tan rpido que a mitad pia organizacin y buscar el conocimiento que
de trabajo las tendencias o la competencia necesitan.
obligarn a modificar el producto. Son similares a una Start-up que comienza.
Adems, la participacin de todo el equipo en el
diseo aporta gran cantidad de talento innovador; Para lograr la auto-organizacin los equipos
un valor clave en el mercado de productos y deben reunir tres caractersticas:
servicios TIC.
Autonoma. Son libres para elegir la
Los equipos giles empiezan a trabajar sin estrategia de la solucin. En este sentido la
conocer con detalle cmo ser el producto final. direccin de la empresa acta como un
Parten de la visin general, y sobre ella, producen capitalista de capital-riesgo.

El nuevo escenario
Auto-superacin. El equipo va desarrollando Los retrasos de cada fase son cuellos de

soluciones, que evala, analiza y mejora. botella del proyecto. El solapamiento diluye el
Auto-enriquecimiento. La multi-disciplinaridad ruido y los problemas entre fases
del equipo favorece el enriquecimiento mutuo
Control sutil
y la aportacin de soluciones valiosas
complementarias.
El equipo dispone de autonoma, pero no debe

Fases de desarrollo solapadas derivar en caos.
La gestin establece puntos de control suficientes
El concepto de fase que implica un trabajo para evitar que el escenario de ambigedad,
secuencial, se cambia ahora por el de actividad. inestabilidad y tensin del campo de scrum
Requisitos, anlisis, diseo, desarrollo no son evolucione hacia el descontrol.
fases ejecutadas en un orden determinado. Son
actividades que se pueden realizar en cualquier Pero debe gestionarse sin un control rgido que
momento, de forma simultnea; a demanda impedira la creatividad y la espontaneidad.
cuando las necesita el equipo. El trmino control sutil se refiere a la creacin de
un ecosistema que potencia y desarrolla el auto-
En el ciclo de vida secuencial de software se control entre iguales, como consecuencia de la
habla de modificacin de requisitos. responsabilidad y del gusto por el trabajo
Este trmino lleva implcito el concepto de que realizado.
estamos cambiando; algo que qued cerrado en
la fase de requisitos. Algunas acciones para generar este ecosistema
En el desarrollo gil, los requisitos evolucionan, son:
se desarrollan y enriquecen durante todo el ciclo
de vida, igual que el diseo y el cdigo Seleccin de las personas adecuadas para el
proyecto.
Takeuchi y Nonaka observaron dos tipos de Anlisis de los cambios en la dinmica del
solapamiento: uno que denominaron sashimi grupo para incorporar o retirar a miembros si
estableciendo analoga con el plato tpico japons resulta necesario.
porque se produce un solapamiento bastante Creacin de un espacio de trabajo abierto.
amplio, de tal forma, que en cualquier punto del Animar a los ingenieros a mezclarse con el
ciclo de vida, se encuentran de forma simultnea mundo real de las necesidades de los
varias fases; y otro que denominaron rugby, que clientes.
deja perdido por completo el concepto de fases, y Sistemas de evaluacin y reconocimiento
en el que el equipo trabaja concurrentemente en basados en el rendimiento del equipo.
todas las actividades desde el primer da. Gestin de las diferencias de ritmo a travs
del proceso de desarrollo.
En el solapamiento sashimi an se mantiene el Tolerancia y previsin con los errores;
concepto de fase, aunque con un solapamiento considerando que son un medio de
muy amplio. aprendizaje, y que el miedo al error merma la
creatividad y la espontaneidad.
Implicar a los proveedores en el proyecto y
animarles a su propia auto-organizacin
Difusin del conocimiento

En el solapamiento scrum no son ya fases, sino
definitivamente tareas.
En el desarrollo tradicional: Tanto a nivel de proyecto como de organizacin.

Las transiciones entre fases, acaban
funcionando como fronteras. Cada equipo se Los equipos son multidisciplinares, y todos los
siente responsable de su parte de trabajo, de miembros aportan y aprenden:
lo que debe entregar a la siguiente fase, pero
no del resultado final. del resto del equipo,
Los documentos de diseo, los requisitos o de las investigaciones para mejorar el valor y
los prototipos pueden acabar siendo el componente innovador que espera el
barricadas en la frontera de cada fase, que cliente,
lejos favorecer la comunicacin directa de la experiencia del desarrollo.
fomentan la fragmentacin.
Las personas que participan en un proyecto, con
el tiempo pasan a otros equipos y proyectos de la

El nuevo escenario
empresa, de forma que comparten y comunican el

conocimiento a lo largo de toda la organizacin.
Los equipos y las empresas mantienen libre

acceso a la informacin, herramientas y polticas
de gestin del conocimiento
Resumen
Hasta los 80, para el desarrollo de nuevos
productos se empleaban:
Ciclos de vida secuencial.
Divisin y especializacin del trabajo.
En los 80 se desarrolla la teora de
produccin basada en procesos para propor-
cionar eficiencia calidad y repetibilidad.
En esos aos, algunas empresas de tecno-
loga (Caon, Fuji-Xerox, Honda, Epson, HP,
etc.) logran ms valor y mejores resultados en
el desarrollo de nuevos productos, desafiando
al desarrollo secuencial y a la divisin del
trabajo.
Nonaka y Takeuchi son los primeros en
identificar estos nuevos entornos de produc-
cin a los que denominan campos de Scrum
en el artculo 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-disciplinar.
Solapamiento de las fases del desarrollo.
No se parte de unos requisitos detallados
sino de la visin del resultado.
No se sigue un plan pre-elaborado.
Caractersticas ambientales en estos entor-
nos llamados campos de scrum
Incertidumbre
Auto-organizacin
Fases de desarrollo solapadas
Control sutil
Difusin del conocimiento

Gestin de proyectos gil
Conceptos
Gestin de proyectos gil: conceptos
Su objetivo es dar el mayor valor posible al

producto, cuando ste se basa en:
Introduccin Innovacin
Flexibilidad.
Muchas empresas trabajan en escenarios que se Innovacin
parecen ya muy poco a los que impulsaron la
gestin de proyectos predictiva; y necesitan La permanencia de estas empresas depende de
estrategias diferentes para gestionar el su capacidad de innovacin continua. Del
lanzamiento de sus productos: estrategias orien- lanzamiento continuo de novedades, que com-
tadas a la entrega temprana de resultados tan- piten con los productos de otras empresas que
gibles, y con la suficiente agilidad y flexibilidad tambin estn en continua innovacin.
para trabajar en entornos inestables y rpidos.
Flexibilidad.
Ahora necesitan construir el producto al mismo El producto no solo es slo valioso por su valor en
tiempo que cambian y aparecen nuevos requisi- el momento de su lanzamiento, sino tambin por
tos; y como las circunstancias de los mercados y su capacidad de adaptacin y evolucin, a travs
de las empresas no se pueden cambiar, son las de, actualizaciones y ampliaciones.
formas en las que gestionan sus proyectos las
que tienen que cambiar para dar respuesta a las
nuevas necesidades.
2.-Reduccin del tiempo de
salida al mercado
El cliente conoce la visin de su producto pero
por la novedad, el valor de innovacin que
necesita y la velocidad a la que se va a mover el
escenario tecnolgico y de negocio, durante el En la dcada de los 90, el tiempo medio de salida
desarrollo, no puede detallar cmo ser el al mercado de los nuevos productos en EE.UU.
3
producto final. se redujo de 35,5 a 11 meses
Ah!. Pero, existe el producto final?. Este tiempo es un factor competitivo clave en
determinados sectores.
Quiz ya no hay productos finales, sino
productos en evolucin, mejora o incremento Las estrategias de la gestin gil para producir
continuo, desde la primera versin beta. resultados en menos tiempo que la gestin
tradicional son:
Solapamiento de las fases de desarrollo.

El resultado es la gestin gil de Entrega temprana de las primeras partes del
proyectos, que no se formula sobre el producto, que corresponden con las de mayor
concepto de anticipacin (requisitos, urgencia para el cliente, de forma que puede
diseo, planificacin y seguimiento) sino lanzar la primera versin en el menor tiempo
sobre el de adaptacin (visin, posible.
exploracin y adaptacin)
3.-Agilidad
Capacidad para producir partes completas del
Objetivos de la gestin gil producto en periodos breves de tiempo
La gestin gil de proyectos tiene como objetivo 4.-Flexibilidad

dar garantas a las demandas principales de la Capacidad para adaptar la forma y el curso del
industria actual: valor, reduccin del tiempo de
desarrollo a las caractersticas del proyecto, y a la
desarrollo, agilidad, flexibilidad y fiabilidad. evolucin de los requisitos.
1.-Valor
La gestin gil se necesita en los mercados 3
Wujec, Tom, and Sandra Muscat. Return on Imagination:
rpidos. Realizing the Power of Ideas, London: Financial Times
Prentice Hall, 2002

5.- Resultados fiables El ciclo de desarrollo gil

El objetivo de la gestin predictiva es ejecutar el
trabajo planificado (y conocido de antemano) en
el plazo planificado y por el coste previsto.
La gestin gil no tiene un carcter predictivo o

de anticipacin. 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 gestin tradicional son buenos

cuando consiguen desarrollar de forma repetible
los productos especificados en el tiempo y con los
costes previstos.
Los procesos de la gestin gil son buenos, El desarrollo gil parte de la visin, del concepto
cuando consiguen entregar de forma temprana y general del producto, y sobre ella el equipo
continua valor innovador. produce de forma continua incrementos en la
direccin apuntada por la visin; y en el orden de
prioridad que necesita el negocio del cliente.
Las preferencias de la Los ciclos breves de desarrollo, se denominan
gestin gil.
iteraciones y se realizan hasta que se decide no
evolucionar ms el producto.
Este esquema est formado por cinco fases:

La gestin gil, a diferencia de la tradicional,
muestra las preferencias resumidas en el 1.- Concepto
manifiesto gil: 2.- Especulacin
3.- Exploracin
1.- La capacidad de respuesta al cambio, 4.- Revisin
sobre el seguimiento de un plan. 5.- Cierre
2.- Los Productos que funcionan frente a

especificaciones y documentaciones inne-
cesarias.
1.- Concepto
En esta fase se crea la visin del producto y se
3.- La colaboracin con el cliente frente a la determina el equipo que lo llevar a cabo.
negociacin contractual.
Partir sin una visin genera esfuerzo baldo.
4.- A las personas y su interaccin por encima La visin es un factor crtico 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 adems
una informacin que deben compartir todos los
miembros del equipo

3.- Exploracin
2.- Especulacin Se desarrolla un incremento del producto, que
incluye las funcionalidades determinadas en la
Una vez que se sabe qu hay que construir, el
fase anterior
equipo especula y formula hiptesis basadas en
la informacin de la visin, que per se es muy
general e insuficiente para determinar las
implicaciones de un desarrollo (requisitos, diseo,
4.- Revisin
costes). Equipo y usuarios revisan lo construido hasta ese
momento.
En esta fase se determinan las limitaciones Trabajan y operan con el producto real
impuestas por el entorno de negocio: costes y contrastando su alineacin con el objetivo
agendas principalmente, y se cierra la primera
aproximacin de lo que se puede producir.
La gestin gil investiga y construye a partir de la

visin del producto. Durante el desarrollo
confronta las partes terminadas: su valor, posi-
bilidades, y la situacin del entorno en cada
momento.
La fase de especulacin se repite en cada

iteracin, y teniendo como referencia la visin y el
alcance del proyecto consiste en:
Desarrollo y revisin de los requisitos

generales.
Mantenimiento de una lista con las
funcionalidades esperadas
5.- Cierre
Mantenimiento de un plan de entrega: Fechas Al llegar a la fecha de entrega de una versin de
en las que se necesitan las versiones, hitos e producto (fijada en la fase de concepto y revisada
iteraciones del desarrollo. Este plan refleja ya en las diferentes fases de especulacin), se
el esfuerzo que consumir el proyecto obtiene el producto esperado.
durante el tiempo.
En funcin de las caractersticas del modelo Posiblemente ste seguir en el mercado, y por
de gestin y del proyecto puede incluir emplear gestin gil, es presumible que se trata
tambin una estrategia o planes para la de un producto que necesita versiones y mejoras
gestin de riesgos. frecuentes para no quedar obsoleto. El cierre no
implica el fin del proyecto.
Si las exigencias formales de la organizacin lo
requieren, tambin se produce informacin admi- Lo que se denomina mantenimiento supondr la
nistrativa y financiera. continuidad del proyecto en ciclos incrementales
hacia la siguiente versin para ir acercndose a la
visin del producto.

Principales modelos de
AUP - Agile Unified Process
Crystal
DSDM - Dynamic Systems Development
gestin gil
Method
Scrum
XBreed
Si hubiera que determinar cul es el origen de la
gestin gil de proyectos, a falta de mejor infor- Por ejemplo, el principio de desarrollo gil
macin, habra que situarlo en las prcticas adop- iterativo e incremental, tiene reflejo en ciclos de
tadas en los 80 por empresas como Honda, 3M, 30 das empleados por scrum, o de entre 1 y 4
Canon, Fuji, Nec, Xerox, hp o Epson para el meses empleado por los modelos Cristal.
4
desarrollo de nuevos productos
ASD
La industria del software ha sido la primera en
Adaptive Software Development es el modelo de
seguir su adopcin, y muchos de sus
implementacin de patrones giles para de-
profesionales han documentado y propagado las
sarrollo de software, diseado por Jim Highsmith,
formas particulares en las que han implementado
que materializa las fases de la gestin gil de la
los principios de la agildad en sus equipos de
siguiente forma:
trabajo.
De esta forma han aparecido en la ltima dcada
ESPECULACIN, compuesta por 5 pasos:
los nombres:
1.- Inicio para determinar la misin del proyecto.
2.- Fijacin del marco temporal del proyecto.
AD - Agile Database Techniques
3.- Determinacin del n de iteraciones y la
AM - Agile Modeling
duracin de cada una.
ASD - Adaptive Software Development
4.- Definicin del objetivo de cada iteracin.
AUP - Agile Unified Process
5.- Asignacin de funcionalidad a cada iteracin.
Crystal
FDD - Feature Driven Development
COLABORACIN
DSDM - Dynamic Systems Development
Desarrollo concurrente del trabajo de cons-
Method
truccin y gestin del producto
Lean Software Development
Scrum
APRENDIZAJE
TDD - Test-Driven Design
En cada iteracin se revisa:
XBreed
Calidad, con criterios de cliente.
XP - eXtreme Programming
Calidad, con criterios tcnicos.
Funcionalidad desarrollada
stos son los modelos que se encuentran
Estado del proyecto
inscritos en la organizacin Agile Alliance
(www.agilealliance.org) para promocionar y
Las caractersticas bsicas de ASD son:
difundir su conocimiento.
Trabajo orientado y guiado por la misin del
proyecto.
Cada una de ellos expone formas concretas de
Basado en la funcionalidad
aplicacin de principios giles en el desarrollo de
Desarrollo iterativo
software.
Desarrollo acotado temporalmente
Algunos determinan cmo realizar las pruebas, o
Guiado por los riesgos
la duracin que emplean para desarrollar cada
Trabajo tolerante al cambio.
iteracin, o el protocolo para realizar las
reuniones de trabajo.
Unos mtodos cubren reas concretas de la

AUP
ingeniera del software (diseo, desarrollo Agile Unified Process es una versin simplificada
pruebas), como es caso de AD, AM o XP, y otros de Rational Unified Process, desarrollada por
se centran en la gestin del proyecto. Scott Amber.
stos ltimos son: Divide el ciclo de desarrollo en 4 fases:
ASD - Adaptive Software Development INCEPCIN: identificacin del alcance y dimen-
sin del proyecto, propuesta de la arquitectura y
4
Hirotaka Takeuchi e Ikujiro Nonaka, 1986 The New New del presupuesto del cliente.
Development Game,

ELABORACIN: Confirmacin de la idoneidad de Desarrollo iterativo e incremental.

la arquitectura. Duracin mxima de una iteracin: 4 meses.
CONSTRUCCIN: Desarrollo incremental del Recomienda duraciones entre 1 y 3 meses.
sistema, siguiendo las prioridades funcionales de Especial nfasis en la importancia de las
los implicados. personas sobre los procesos.
TRANSICIN: Validacin e implantacin del Especial nfasis en la comunicacin directa.
sistema. Modelo abierto a la adaptacin e introduccin
de prcticas de otros modelos giles
CRYSTAL
(Extreme Programming, Scrum...)
Concebido por Alistair Cockburn, este modelo no

describe una metodologa cerrada, sino un
DSDM
conjunto de ellas, junto con los criterios para DSDM es el acrnimo que da nombre a un
seleccionar y adecuar la ms apropiada al modelo de procesos para desarrollo de sistemas
proyecto. Los parmetros para determinarla son de software, desarrollado y concebido por el
la criticidad y el tamao del sistema que se va a DSDM Consortium, que se fund en Inglaterra en
construir. 1994, y que actualmente tiene presencia en
Inglaterra, EE.UU. Benelux, Dinamarca, Francia y
Suiza; y con inters y contactos para futuras
representaciones en Australia, India y China [...]
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, ao del Manifiesto gil, DSDM public

la versin 4.1 de su modelo, y se consider una
metodologa gil; y aunque mantuvo las siglas,
cambi la denominacin original (Dynamis
Systems Development Method) por Framework
for Business Centred Development.
Procesos del ciclo de desarrollo DSDM
Los criterios empleados para la medicin de estos El ciclo de desarrollo de DSDM est compuesto
parmetros son: de 5 fases, precedidas de un pre-proyecto y un
post-proyecto.
Criticidad (dimensin de las prdidas que
ocasionara un malfuncionamiento del sistema) 1. Pre-proyecto
2. Estudio de viabilidad
1 (c): Prdida de confort o usabilidad. 3. Estudio de negocio
2 (d): Prdidas econmicas moderadas. 4. Iteracin de modelado funcional
3 (e): Prdidas econmicas graves. 5. Iteracin de diseo y desarrollo
4 (l): Prdida de vidas humanas. 6. Implementacin
7. Post-desarrollo
Estos criterios corresponden a los niveles de
integridad de un sistema definidos por el estndar
IEEE 1012-1998.
Dimensin.
Crystal determina el tamao del sistema por el n
de personas empleadas en su desarrollo. (6 - 20 -
40 - 80)
Fundamentos de Crystal:

otra al final para evaluar el resultado, y revisiones

diarias que realiza el equipo en su auto-gestin.
XBreed Agile Enterprise

Propuesto por Mike Breedle, que colabor con
Ken Schwaber en la definicin de Scrum, es una
combinacin de Scrum para la gestin del
proyecto, y Extreme Programming como prcticas
de desarrollo.
Esta es una combinacin comnmente empleada

independientemente de su definicin como
Xbreed que hasta la fecha no ha tenido especial
relevancia.
SCRUM Tambin denominado Agile Enterprise
Resumen
Jeff Sutherland en 1993 trabajaba en Easel
Corporation (compaa que en los macrojuegos
de compras y fusiones se integrara en VMARK, y
luego en Informix y finalmente en Ascential
Software Corporation). Tras conocer el trabajo de La gestin gil de proyectos no es una
Nonaka y Takeuchi, Jeff identific paralelismos gestin de anticipacin (requisitos, diseo,
con la industria del software, y aplic un modelo planificacin y seguimiento, sino de adap-
de desarrollo gil, iterativo e incremental para tacin (visin, exploracin y adaptacin)
desarrollar y mantener sistemas de software.
La gestin gil tiene como objetivos: valor,
En 1996 lo present junto con Ken Schwaber reduccin del tiempo de desarrollo, agilidad,
como proceso formal para gestin del desarrollo flexibilidad y fiabilidad.
de software en OOPSLA 96, con el nombre que
Nonaka y Takeuchi haban dado a estos equipos La gestin gil se basa en los principios del
de trabajo: "Scrum", por la comparacin que manifiesto gil y centra el valor:
hicieron con los equipos de Rugby
5 Ms en las personas y su interaccin que
en los procesos y las herramientas
Ms en los resultados que funcionan que
en la documentacin exhaustiva
Ms en la colaboracin con el cliente que
en la negociacin contractual
Ms en la capacidad de respuesta al
cambio que en el seguimiento de un plan
El desarrollo gil comprende cinco fases:

concepto, especulacin, exploracin, revisin
y cierre.
El desarrollo gil surgi en empresas de

productos tecnolgicos, fu identificado por
Se basa en el principio gil de desarrollo iterativo Nonaka y Takeuchi en los aos 80 y a partir
e incremental. de los 90 diferentes profesionales del
Al periodo de trabajo para desarrollar un desarrollo del software incorporaron sus
incremento de producto lo denomina sprint, y principios en sus entornos de trabajo.
recomienda una duracin de 30 das, si bien De esas implementaciones giles, las que
pueden contemplarse casos de hasta 60 (segn abordan la gestin del proyecto son: ASD,
Ken Schwaber, o 45 segn Jeff Suterland). AUP, Crystal, DSDM, Scrum.
Establece una reunin al inicio de cada sprint

para determinar el trabajo que se va a realizar,
5
Scrum es el nombre que se da en Rugby a una determinada
formacin del equipo.

Gestin de proyectos: formal o gil?
gil, clsica, predictiva ?

Al surgir en los 80 una nueva forma de gestionar
proyectos, se hizo necesario aadir un apellido
al trmino gestin 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 gestin de proyectos que
hasta entonces, por nico, no lo haba nece-
sitado. Caractersticas de la gestin
Las denominaciones empleadas para cada tipo
son:
de proyectos predictiva
Clsica Estas premisas han dado dos caractersticas a la
gestin de proyectos predictiva:
Tradicional
Gestin de proyectos Predictiva
1.- Universalidad.
Formal
Los proyectos, pese a su diversidad, comparten
Pesada patrones comunes de ejecucin.
Las prcticas de gestin se basan en estos
patrones comunes y resultan vlidas para
cualquier tipo de proyecto.
gil
Gestin 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
trmino pesado que puede aportar connota-
ciones peyorativas.
Tambin preferimos no emplear adaptativa y

usar en su lugar adaptable, para evitar un
anglicismo innecesario.
2.- Carcter predictivo.
La gestin clsica define con detalle cul es el
Premisas de la gestin de
producto previsto y elabora un plan de
desarrollo, a partir del cual calcula costes y
fechas.
proyectos predictiva. Durante la ejecucin realiza actividades de

seguimiento y vigilancia para evitar desviaciones
sobre lo planificado.
Premisas sobre las que se desarroll la gestin
de proyectos tradicional:
1.- Todos los proyectos mantienen caracters- Hay otras premisas

ticas y comportamientos regulares (Meter
Norden 1960) Las dos premisas que cimientan el desarrollo de
la gestin de proyectos:
2.- El objetivo de la ejecucin de un proyecto Todos los proyectos comparten idnticos
es lograr el producto previsto en el tiempo patrones de ejecucin.
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 vlida para Se peda un proyecto, pero no se quera
gestionar cualquier tipo de proyecto garantizar la ejecucin de un plan, sino obtener el
mximo valor en las lneas marcadas.
Es cierto que muchas caractersticas que dife- Hay proyectos en los que importa ms el valor y
rencian unos proyectos de otros son superficiales la innovacin que el cumplimiento del plan.
y resultan indiferentes para el modelo de gestin; Innovacin
pero hay otras que permiten adoptar estrategias
de gestin muy diferentes en cada caso.
La gestin predictiva pide al equipo el
Caractersticas diferenciales: cumplimiento del plan.
La gestin adaptable pide al equipo el
Componente innovador que se espera del mayor valor posible para una visin 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 gestin de proyectos predictiva, al auto-

considerarse vlida para cualquier proyecto no
contempla que segn las caractersticas del
proyecto, puedan resultar ms apropiados otros
criterios de gestin.
Conseguir el mayor valor innovador del

producto no es uno de sus objetivos, y por
tanto no aplica prcticas diferentes segn el
grado innovador que se desee.
Considera que los requisitos deben
Cundo y por qu emplear

permanecer estables durante la ejecucin. Si
no ocurre esto presupone que se debe a
deficiencias en el proceso de la fase de
requisitos; porque no contempla posibles
evoluciones rpidas o inestabilidades del uno u otro estilo de gestin
entorno tecnolgico o de negocio.
Para obtener los mayores beneficios que cada
El objetivo es la eficiencia, el cumplimiento estilo de gestin puede ofrecer ste tiene que ser
del plan, y no el valor del producto. Desde compatible no slo con las caractersticas del
este punto de vista, el re-trabajo siempre es proyecto, sino tambin con las de la organizacin
caro. No se considera la relacin entre el que las va a aplicar.
coste del re-trabajo y el valor proporcionado.
2.- Hay proyectos en los que no se quiere

Caractersticas del proyecto
hacer el producto descrito en las fechas Las caractersticas relevantes para decidir el
y con los costes estimados estilo de gestin ms adecuado son:
Principal prioridad de negocio.

Cuando en 1978 la direccin de Honda encarg el Estabilidad de los requisitos.
diseo de un nuevo automvil, slo dio dos Rigidez del producto.
instrucciones al equipo de ingenieros: Coste de prototipado.
Primero: necesitamos un concepto de automvil Criticidad del sistema.
completamente diferente a lo que cualquier otra Tamao del sistema.
compaa haya hecho nunca; y segundo: debe
ser un coche econmico, pero no barato. El orden expuesto se corresponde con nuestro
criterio de relevancia, siendo por tanto la prioridad
El resultado fue el Honda Civic. de negocio la principal razn de compatibilidad o

incompatibilidad, y el tamao 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 gestin gil, estos de Gantt o rutas crticas sobre una visin general.
criterios no estn an consensuados. As por
ejemplo mientras algunos textos opinan que el Cuanto mayor valor se desea en uno u otro
tamao o la criticidad del sistema son aspectos extremo (valor o prediccin), ms contraprodu-
muy relevantes, hay opiniones autorizadas en cente resulta emplear el estilo de gestin
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 descripcin de requisitos
Outsourced Teams " que demostraba los detallada al inicio del proyecto, y sta se man-
buenos resultados obtenidos con prcticas de tendr estable durante el desarrollo?
gestn giles en un desarrollo de grandes O lo que es lo mismo, Se puede saber con cer-
dimensiones: un milln de lneas de cdigo teza y detalle qu es lo que se quiere construir,
Java, y un equipo de 50 personas distribuidos siendo improbable que cambien los criterios o las
en dos empresas ubicadas en pases necesidades?
distintos.
El modelo especfico de Scrum desarrollado Rigidez del producto

por Ken Schwaber para Software contempla
Cmo de fcil resulta modificar el producto?
el desarrollo de sistemas crticos, incluyendo
Esta es una razn importante, porque no es lo
los requerimientos de conformidad tambin
mismo modificar software, circuitos electrnicos,
como resultados entregables de las
construcciones civiles
iteraciones junto con las funcionalidades a las
que afectan.
Modificar la estructura de una base de datos para
aadir algunas tablas no es lo mismo que
modificar la estructura de un edificio para
rectificar el n de plantas.
Coste de prototipado
Otra cuestin relevante para el modelo de gestin
gil es la relacin: coste de prototipar / valor
conseguido para el producto. Este factor suele
estar relacionado con la rigidez del producto.
Ver, tocar, e interactuar con las partes ya desa-

rrolladas o con simulaciones o prototipos genera
Prioridad de negocio
ideas y posibilidades que sobre el concepto inicial
y el papel no llegan a concebirse.
Cul es la principal prioridad para los intereses El prototipado y el feed-back que proporciona son
de negocio del cliente? extremadamente importantes, sobre todo en el
Qu tiene ms importancia: el cumplimiento de desarrollo de nuevos productos, o de sistemas
agendas y fechas o el valor innovador del innovadores.
producto? A medida que el equipo lo va tocando y
probando surgen funcionalidades y posibilidades
Este es el primer aspecto que se debe considerar. nuevas que aportan mayor valor al concepto
La gestin predictiva es una modelo construido y inicial.
especializado en garantizar el cumplimiento de
los planes. En este sentido, el argumento: la forma ms
La gestin adaptable es un modelo construido y eficiente de desarrollar un trabajo es hacerlo bien
especializado en dar el mayor valor posible al a la primera, que se emplea con frecuencia para
producto. defender la validez de la gestin predictiva en
cualquier proyecto, resulta tendencioso.

La afirmacin per se es obviamente cierta; pero Producir prdidas econmicas.

tambin son ciertas dos circunstancias rela- Fallar la finalidad principal del sistema.
cionadas: Fallarn funcionalidades auxiliares del
sistema.
Se puede hacer bien a la primera cuando es Se producirn fallos ergonmicos o de
posible conocer con detalle el resultado sin comodidad para los usuarios.
necesidad de hacer pruebas antes.
Las posibilidades al hacer un trabajo no son slo Tamao del sistema

bien o mal.
Bien es un trmino amplio. Puede ser aceptable o Una de las principales bases del desarrollo gil es
suficientemente bien, o lo mejor posible. la preferencia de la comunicacin e interaccin
directa de los implicados en el proyecto.
Estos factores, junto con la relacin entre coste Los grandes proyectos implican equipos nume-
de prototipado y valor que aporta deben tenerse rosos y en ocasiones fsicamente distantes,
tambin en cuenta para elegir el modelo de circunstancias que dificultan la comunicacin
gestin ms adecuado para el proyecto. directa.
No obstante hay desarrollos incipientes de
prcticas giles que implantan esquemas de
agrupamiento y comunicacin directa en
estructuras celulares de equipos de hasta 6
personas.
Condiciones de la organizacin
Los elementos empleados por las organizaciones
para ejecutar proyectos son: personas, procesos
y tecnologa.
Los resultados de la gestin gil dependen ms

del valor de las personas que del de los procesos
de la organizacin.
Criticidad del sistema Las personas tienen caractersticas propias:
Cul es el grado de criticidad del sistema que va
a desarrollar? Sus resultados son sensibles al entorno. La
Considerando por anlisis de criticidad: falta de motivacin y los ambientes laborales
hostiles reducen significativamente el valor
La evaluacin estructurada de las caractersticas intelectual del trabajo.
del producto (p. ej. Seguridad, complejidad, Cuando el trabajo depende del talento, la
rendimiento) para determinar la severidad del diferencia de valor entre los mediocres y los
impacto de un fallo del sistema, de su mejores es muy grande.
degradacin o de su no cumplimiento con los
requisitos o los objetivos del sistema Adoptar modelos de desarrollo gil no consiste
slo en realizar las prcticas formales: equipo
O lo que es lo mismo: nico, reuniones peridicas, desarrollo evolutivo
de los requisitos, etc.
Si el sistema falla, se degrada o no consigue Si la organizacin mantiene un modelo de
realizar las funciones de los requisitos, qu desarrollo basado en procesos y no en personas,
impacto tiene en la seguridad o en el ren- y no tiene alineadas con los principios giles: la
dimiento? cultura y estructura organizativa, no obtiene los
resultados propios del desarrollo gil.
Un ejemplo de criterios de criticidad, ordenados
de mayor a menor podra ser:
Si el sistema falla las consecuencias sern:
Causar dao a las personas.

Causar dao al medio ambiente.
Producir prdidas econmicas graves.

predictiva, clsica, tradicional, formal.

gil, adaptable.
Nivel profesional La gestin de proyectos predictiva se ha

desarrollado sobre las premisas
En el mundo del diseo informtico, los mejores Todos los proyectos mantienen
lo hacen entre 50 y 100 veces mejor que el caractersticas y comportamientos
promedio, y la cifra aumenta, conforme se regulares.
incrementa la complejidad de la tecnologa El objetivo de la ejecucin de un proyecto
Pilar Jeric. La gestin del talento
es lograr el producto previsto en el tiempo
planificado, sin desbordar los costes
estimados.
La diferencia entre los promedios y los mejores
ya no es de 1:2, como en el pasado. Es 1:100 o
Las caractersticas de la gestin de proyectos
incluso 1:1000
Nathan Myhrvold (Ex-director de I+D de Microsoft)
predictiva son: validez para cualquier tipo de
proyecto y carcter predictivo
Si el proyecto, ms que innovacin lo que
requiere es la ejecucin controlada de un plan La gestin gil surge al cuestionar la validez
detallado, posiblemente sean los procesos de la de las premisas de la gestin tradicional:
organizacin los garantes del resultado; y con un No hay una forma nica y vlida para
modelo de gestin 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 caractersticas relevantes del proyecto
proyecto, se emplea un modelo de desarrollo gil, para decidir el estilo de gestin ms 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. tamao del sistema.
Las caractersticas relevantes de la orga-

Cultura organizativa nizacin para facilitar el desarrollo del modelo
de gestin ms adecuado son: nivel
Para la ejecucin sistemtica y controlada de profesional, cultura organizativa y modelo de
procesos no resulta especialmente relevante el desarrollo.
tipo de cultura de la organizacin.
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.
Modelo de de desarrollo
Los entornos de desarrollo basados en procesos
son adecuados para modelos de gestin
predictiva.
Los entornos de desarrollo basados en las

personas son adecuados para modelos de
gestin gil.
Resumen
Trminos empleados para designar a los dos
modelos de gestin de proyectos:

Introduccin al modelo Scrum para
desarrollo de Software
Introduccin al modelo Scrum para desarrollo de software
El origen.
Scrum es una metodologa gil de desarrollo de
proyectos que toma su nombre y principios de las
observaciones sobre nuevas prcticas de pro-
duccin, realizadas por Hirotaka Takeuchi e Ikujijo
Nonaka a mediados de los 80. (v. Gestin
Predictiva y Gestin gil: El Nuevo Escenario)
Aunque las prcticas observadas por estos Estructura del desarrollo gil
autores surgieron en empresas de productos
tecnolgicos, tambin se emplean en entornos Comparte los principios estructurales del
que trabajan con requisitos inestables y que desarrollo gil: a partir del concepto o visin de la
requieren rapidez y flexibilidad, situaciones necesidad del cliente, construye el producto de
frecuentes en el desarrollo de determinados forma incremental a travs de iteraciones breves
sistemas de software. que comprenden fases de especulacin
exploracin y revisin. 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 da por cerrado el
en 1993 en Easel Corporation (Empresa que en producto.
los macro-juegos de compras y fusiones se
integrara en VMARK, luego en Informix y Se comienza con la visin 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, tambin para gestin del negocio, y que pueden llevarse a cabo en un
desarrollo de software en OOPSLA 96. Ms tarde, periodo de tiempo breve (segn los casos pueden
en 2001 seran dos de los promulgadores del tener duraciones desde una semana hasta no
Manifiesto_gil. ms de dos meses).
Cada uno de estos periodos de desarrollo es una
iteracin que finaliza con la entrega de una parte
Introduccin al modelo (incremento) operativa del producto.
Estas iteraciones son la base del desarrollo gil, y

Scrum es una metodologa de desarrollo muy Scrum gestiona su evolucin en reuniones breves
simple, que requiere trabajo duro, porque no se diarias donde todo el equipo revisa el trabajo
basa en el seguimiento de un plan, sino en la realizado el da anterior y el previsto para el
adaptacin continua a las circunstancias de la siguiente.
evolucin del proyecto.
Como mtodo gil:
Es un modo de desarrollo adaptable, antes

que predictivo.
Orientado a las personas, ms que a los
procesos.
Emplea el modelo de construccin incre-
mental basado en iteraciones y revisiones.
(v. Gestin Predictiva y Gestin gil)
Estructura central de Scrum

Control de la evolucin del

niveles. La gestin predictiva confa la respon-
sabilidad de su resolucin al gestor de proyectos.
En Scrum los equipos son auto-organizados (no
proyecto auto-dirigidos), con margen de decisin suficiente

para tomar las decisiones que consideren
oportunas.
Scrum controla de forma emprica y adaptable la
evolucin del proyecto, a travs de las siguientes
prcticas de la gestin gil: Colaboracin
Las prcticas y el entorno de trabajo giles
Revisin de las Iteraciones facilitan la colaboracin del equipo. sta es
necesaria, porque para que funcione la auto-
Al finalizar cada iteracin (sprint) se lleva a cabo organizacin como un control eficaz cada
una revisin con todas las personas implicadas miembro del equipo debe colaborar de forma
en el proyecto. Es por tanto la duracin del sprint, abierta con los dems, segn sus capacidades y
el periodo mximo que se tarda en reconducir una no segn su rol o su puesto.
desviacin en el proyecto o en las circunstancias
del producto.
Visin general del proceso
Desarrollo incremental Scrum denomina sprint a cada iteracin de
desarrollo y segn las caractersticas del proyecto
Las personas implicadas no trabajan con diseos y las circunstancias del sprint puede determinarse
o abstracciones. una duracin desde una hasta dos meses,
El desarrollo incremental implica que al final de aunque no suele ser recomendable hacerlos de
cada iteracin se dispone de una parte de ms de un mes.
producto operativa, que se puede inspeccionar y
evaluar. El sprint es el ncleo central que proporciona la
base de desarrollo iterativo e incremental.
Desarrollo evolutivo
Los modelos de gestin gil se emplean para
trabajar en entornos de incertidumbre e inestabi-
lidad de requisitos.
Intentar predecir en las fases iniciales cmo ser
el resultado final, y sobre dicha prediccin
desarrollar el diseo y la arquitectura del producto
no es realista, porque las circunstancias obligarn
a remodelarlo muchas veces.
Para qu predecir los estados finales de la

arquitectura o del diseo si van a estar Los elementos que conforman el desarrollo
cambiando? Scrum considera a la inestabilidad Scrum son:
como una premisa, y se adoptan tcnicas de
trabajo para permitir la evolucin sin degradar la
calidad de la arquitectura que tambin evoluciona
durante el desarrollo.
Durante el desarrollo se genera el diseo 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-organizacin
En la ejecucin de un proyecto son muchos los
factores impredecibles en todas las reas y

Las reuniones
Los roles
Planificacin del sprint: Jornada de trabajo
previa al inicio de cada sprint en la que se Todas las personas que intervienen, o tienen
determina cul va a ser el trabajo y los relacin directa o indirecta con el proyecto, se
objetivos que se deben conseguir en la clasifican en dos grupos: comprometidos e
iteracin. implicados.
Seguimiento del sprint: Breve revisin En crculos de Scrum es frecuente llamar a los
diaria, en la que cada miembro describe tres primeros (sin ninguna connotacin peyorativa)
cuestiones: cerdos y a los segundos gallinas.
1.- El trabajo que realiz el da anterior.
2.- El que tiene previsto realizar. El origen de estos nombres es esta metfora que
3.- Cosas que puede necesitar o impedi- ilustra de forma grfica la diferencia entre
mentos que deben suprimirse para realizar el compromiso e implicacin con el proyecto:
trabajo.
Cada persona actualiza en la pila del sprint el Una gallina y un cerdo paseaban por la carretera.
tiempo pendiente de sus tareas, y con esta La gallina pregunt al cerdo: Quieres abrir un
informacin se actualiza tambin el grfico restaurante conmigo?.
con el que el equipo monitoriza el avance del El cerdo consider la propuesta y respondi: S,
sprint (burn-down) me gustara. Y cmo lo llamaramos?.
La gallina respondi: Huevos con beicon.
El cerdo se detuvo, hizo una pausa y contest:
Revisin del sprint: Anlisis y revisin del Pensndolo mejor, creo que no voy a abrir un
incremento generado. restaurante contigo. Yo estara realmente
comprometido, mientras que tu estaras slo
implicada.
Los elementos
Pila del producto: (product backlog) lista de
requisitos de usuario que a partir de la visin
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

COMPROMETIDOS
(cerdos)
IMPLICADOS
(gallinas)
Resumen
Otros interesados Scrum es un modelo gil de desarrollo, que toma
Propietario del pro-
(Direccin general forma de las prcticas de trabajo, que a partir de
ducto
Direccin comercial los 80 comienzan a adoptar algunas empresas
Equipo
Marketing Usuarios, tecnolgicas, y que Nonaka y Takeuchi acuaron
etc) como "Campos de Scrum".
Propietario del producto: es la persona respo- El modelo Scrum, aplicado al desarrollo de
nsable de lograr el mayor valor de producto software, emplea el principio gil: "desarrollo
para los clientes, usuarios y resto de iterativo e incremental", denominando sprint a
implicados. cada iteracin de desarrollo.
Equipo de desarrollo: grupo o grupos de
trabajo que desarrollan el producto. Las prcticas empleadas por Scrum para mante-
Scrum Manager Tem Leader: Responsable ner un control gil en el proyecto son:
del funcionamiento de la metodologa Scrum.
Revisin de las iteraciones
Algunas implementaciones de modelo Scrum, Desarrollo incremental
consideran el rol de gestor de Scrum como Desarrollo evolutivo
comprometido y necesario (ScrumMaster) Auto-organizacin del equipo
Colaboracin
Con el criterio de Scrum Management, es
recomendable que las responsabilidades que Los artefactos del modelo son:
cubre este rol, estn identificadas en una nica Elementos:
persona cuando se comienzan a aplicar prcticas Pila del producto o product backlog
de Scrum en una organizacin. En organi- Pila del sprint o sprint backlog
zaciones giles maduras puede tener menos Incremento
sentido.
En cualquier caso, las responsabilidades de Roles:
Scrum Manager no son del proyecto, sino del Propietario del producto
grupo de procesos y mtodos de la organizacin, Equipo
por lo que no debe considerarse ni cerdo ni Otros interesados
gallina.
Reuniones:
Planificacin del sprint
Valores Seguimiento del sprint
Revisin del sprint
Scrum es una carrocera que da forma a los Los valores que hacen posible a las prcticas de
principios giles. Es una ayuda para organizar a Scrum crear "campos de scrum" son:
las personas y el flujo de trabajo; como lo pueden
ser otras propuestas de formas de trabajo gil: Autonoma (empowerment) del equipo
Crystal, DSDM, etc. Respeto en el equipo
Responsabilidad y auto-disciplina
La carrocera sin motor, sin los valores que dan Foco en la tarea
sentido al desarrollo gil, no funciona: Informacin transparencia y visibilidad
Delegacin de atribuciones (empowerment) al

equipo para que pueda auto-organizarse y
tomar las decisiones sobre el desarrollo.
Respeto entre las personas. Los miembros
del equipo deben confiar entre ellos y
respetar sus conocimientos y capacidades.
Responsabilidad y auto-disciplina (no
disciplina impuesta).
Trabajo centrado en el desarrollo de lo
comprometido
Informacin, transparencia y visibilidad del
desarrollo del proyecto


Roles y responsabilidades de proyecto
De produccin
Introduccin

Producto
Auto-organizacin
Tecnologa gil
El grado de xito de Scrum Management en una
empresa no depende slo de los roles y las
Responsabilidades y roles
responsabilidades directamente relacionadas con
el desarrollo de los proyectos (cliente y equipo).
Las organizaciones son realidades sistmicas,
inter-relacionadas, y aunque este libro cubre slo
el rea de gestin de los proyectos, veremos los
roles implicados directamente en la ejecucin del
en la ejecucin de proyectos
proyecto o solucin tcnica, y el rea directiva o
de management de la organizacin.
El conjunto de responsabilidades que se deben

cubrir de forma coordinada y alineada con la
visin de la organizacin, se clasifican en las tres
categoras 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

definicin desde la visin, la priorizacin del
trabajo y la financiacin del proyecto.
Las del equipo, relativas a la auto-organizacin y

uso de prcticas tecnolgicas giles.
Tambin pertenece al grupo de responsabilidades

del proyecto: la garanta de ejecucin y
funcionamiento correcto de las prcticas Scrum
en cada proyecto.
Lo ms comn en las fases de implantacin,
De management cuando los equipos no estn familiarizados con el

modelo, es la asignacin de esta responsabilidad
en una persona experta en Scrum, ajena al
Equilibrio sistmico de la organizacin
equipo: el gestor de Scrum, o Scrum Manager:
Coherencia del modelo
Team Leader.
Medios y formacin
De procesos
Configuracin de Scrum
Mejora continua
Garanta de funcionamiento de Scrum en
cada proyecto

Es responsable de la financiacin del proyecto, y

las decisiones sobre fechas y funcionalidades de
las diferentes versiones del producto, y el retorno
de la inversin del proyecto.
En los desarrollos internos para la propia

empresa, suele asumir este rol el product
manager o el responsable de marketing. En
desarrollos para clientes externos: el responsable
del proceso de adquisicin del cliente.
El equipo
El propietario del producto Se recomienda un tamao de equipo entre 4 y 8
personas.
Ms all de 10 resulta ms difcil mantener la
El propietario del producto o product owner es la agilidad en la comunicacin directa, y se
persona que toma las decisiones del cliente. manifiestan con ms intensidad las rigideces
habituales de la dinmica 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, diseador o analista, programadores,
pruebas
necesario: Es un equipo multidisciplinar, 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, ms all de la
se persigue con el sistema que se est auto-organizacin y uso de tecnologas 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 asignacin
Conocer Scrum para realizar con solvencia especfica de tareas, responsabilidades y siguien-
las tareas que le corresponden: do un proceso o pautas de ejecucin.
Los operarios de una cadena, forman un grupo de
Desarrollo y administracin de la pila del trabajo: aunque tienen un jefe comn, y trabajan
producto. en la misma organizacin, cada uno responde de
Presentacin y participacin en la reunin su trabajo.
de planificacin de cada sprint.
El equipo tiene espritu de colaboracin, y un
Recibir y analizar de forma continua retro- propsito comn: conseguir el mayor valor posible
informacin del negocio (evolucin del para la visin del cliente.
mercado, competencia, alternativas) y del
proyecto (sugerencias del equipo, alternativas Un equipo Scrum responde en su conjunto.
tcnicas, pruebas y evaluacin 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 cmo 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 visin
pone y qu se quita de la pila del producto, y cul 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 sistmico de la organizacin
decisiones. Coherencia del modelo
Se respetan las opiniones y aportaciones Medios y formacin
de todos
Todos conocen el modelo de trabajo con
Scrum. De procesos
Configuracin de Scrum
Hay un responsable o lder del equipo que asume
Mejora continua
las responsabilidades de garanta de fun-
Garanta de funcionamiento de Scrum en
cionamiento del campo de Scrum en el proyecto.
cada proyecto
En las fases de implementacin de Scrum, con
equipos sin demasiada experiencia en desarrollo
gil con Scrum, y en organizaciones con
De produccin
demasiada rotacin de personas de los equipos Producto
entre proyectos, es recomendable la figura de un Auto-organizacin
gestor de Scrum o Scrum Manager - Team Tecnologa gil
Leader para asumir estas responsabilidades.
El rol de propietario del producto tiene las
responsabilidades de producto.
El equipo:
Auto - organizacin
Scrum Manager Team El uso de tecnologa y tcnicas giles en el
desarrollo del sistema
Leader
Garanta de funcionamiento de Scrum en el
proyecto, cuando no hay un Scrum Manager
Es el responsable del funcionamiento de Scrum El resto de las responsabilidades no son propias

en el proyecto, cubriendo los aspectos siguientes del proyecto, y por tanto propias del equipo; sino
que la organizacin necesite segn el cono- de la organizacin.
cimiento, experiencia con el modelo o aquellos
que no cubra con otras personas con la formacin
e idoneidad adecuada.
Asesora y formacin al Propietario del pro-

ducto.
Asesora y formacin al equipo.
Revisin y validacin de la pila del producto.
Moderacin de las reuniones.
Resolucin de impedimentos que en el sprint
pueden entorpecer la ejecucin de las tareas.
Gestin de la dinmica de grupo en el
equipo
Respeto de la organizacin y los implicados,
con las pautas de tiempos y formas de Scrum
Configuracin, diseo y mejora continua de
las prcticas de Scrum en la organizacin.
Resumen
Las responsabilidades del funcionamiento de
Scrum Management en la organizacin se
clasifican en tres niveles y son las siguientes:

Los elementos de Scrum
Introduccin
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 gestin tradicional o gil.
Incremento: Parte del sistema desarro- La descripcin 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 ingeniera de requisitos a travs del
primeros forman los requisitos del sistema, y el proceso de obtencin (elicitacin) con el
tercero es valor que se le entrega al cliente al final cliente. En Scrum la visin 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 las aportaciones de todo el
No se deben considerar como incrementos: equipo.
prototipos mdulos o subrutinas pendientes de
pruebas o de integracin.
Los requisitos en el
desarrollo gil
La ingeniera del software clsica diferencia dos
reas de requisitos
Requisitos del sistema

Requisitos del software Pero la responsabilidad es del cliente; del
propietario del producto en el caso de Scrum ",
Los requisitos del sistema forman parte del que debe decidir qu se incluye en la pila del
proceso de adquisicin (ISO 12207), y por tanto producto, y el orden de prioridad.
es responsabilidad del cliente la definicin del
problema y de las funcionalidades que debe
aportar la solucin.

Requisitos y visin 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 sita en el rea de

necesidades de negocio desde el punto de vista
Pila del producto: los

del cliente. Es el rea que en la ingeniera del
software tradicional, cubren los requisitos del
sistema o ConOps (Concept of Operations.
La pila del sprint cubre la especificacin 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, tecnologa y correccin de
errores que deben incorporarse al producto a
Estas listas no tienen por qu cumplir con un travs de las sucesivas iteraciones de desarrollo.
determinado formato scrum-estndar, pueden, y
deben, adoptar la forma ms 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 Estos son algunos ejemplos de posibles entradas
de un backlog:
Lo relevante no es tanto la forma como:
Permitir a los usuarios la consulta de las
Requisitos del Sistema (pila del producto): obras publicadas por un determinado
Las funcionalidades que incluye dan autor.
forma a una visin del producto definida y Reducir el tiempo de instalacin del
conocida por todo el equipo. programa.
Las funcionalidades estn indivi- Mejorar la escalabilidad del sistema.
dualmente definidas, priorizadas y pre- Permitir la consulta de una obra a travs
estimadas. de un API web.
Estn realizados y gestionados por el
cliente (propietario del producto) A diferencia de un documento de requisitos del
sistema, la pila del producto nunca se da por
Requisitos del software (pila del sprint): completada; est en continuo crecimiento y
evolucin.
Incluyen todas las tareas necesarias para Habitualmente se comienza a elaborar con el
construir el incremento de un sprint. resultado de una reunin de "fertilizacin cruzada"
El equipo ha estimado el esfuerzo de o brainstorming; o un proceso de Exploracin
cada tarea. (Extreme Programming) donde colabora todo el
El equipo ha asignado cada tarea a un equipo a partir de la visin del propietario del
miembro. producto.
Las duraciones estimadas de las tareas
no son ni inferiores, ni superiores a los El formato de la visin no es relevante. Segn los
lmites definidos en el equipo. casos, puede ser una presentacin informal del
responsable del producto, un informe de
requisitos del departamento de marketing, etc.
S que es importante sin embargo disponer de
una visin real, comprendida y compartida por
todo el equipo.

Pila del Sprint

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 La pila del sprint, es la lista que descompone las
visin de los objetivos de negocio que se quieren funcionalidades de la pila del producto en las
conseguir con el proyecto, comprendida y tareas necesarias para construir un incremento:
conocida por todo el equipo, y elementos una parte completa y operativa del producto.
suficientes en la pila para llevar a cabo el primer
sprint. Cada tarea de la pila del sprint tiene asignada una
persona, y la indicacin del tiempo que an falta
para terminarla.
Formato de la pila del Es til porque descompone el proyecto en

unidades de tamao adecuado para determinar el
producto avance a diario, e identificar riesgos y problemas

sin necesidad de procesos complejos de gestin.
Es tambin una herramienta de soporte para la
El desarrollo gil prefiere la comunicacin directa, comunicacin directa del equipo.
a la comunicacin con documentos.
La pila del producto no es un documento de
requisitos, sino una herramienta de referencia Condiciones
para el equipo.
Si se emplea formato de lista, es recomendable Realizada de forma conjunta por todos
que al menos incluya la siguiente informacin en los miembros del equipo.
cada lnea: Cubre todas las tareas identificadas por el
equipo para conseguir el objetivo del
Identificador nico de la funcionalidad o sprint.
trabajo. Slo el equipo lo puede modificar durante
Descripcin de la funcionalidad. el sprint.
Campo o sistema de priorizacin. El tamao de cada tarea est en un rango
Estimacin de 2 a 16 horas de trabajo.
Es visible para todo el equipo. Idealmente
Dependiendo del tipo de proyecto, funcionamiento en una pizarra o pared en el mismo
del equipo y la organizacin, pueden resultar espacio fsico donde trabaja el equipo.
aconsejables otros campos:
Observaciones Formato y soporte

Criterio de validacin Tres son las opciones:
Persona asignada
N de Sprint en el que se realiza Hoja de clculo.
Mdulo del sistema al que pertenece Pizarra fsica o pared.
Etc. Herramienta colaborativa o de gestin de
proyectos.
Es preferible no adoptar ningn protocolo de
trabajo de forma rgida. El formato del product Y sobre la que mejor se adeca a las carac-
backlog no es cerrado. tersticas del proyecto, oficina y equipo, lo
Los resultados de Scrum Management no apropiado es disear el formato ms cmodo
dependen de la rigidez en la aplicacin del para todos, teniendo en cuenta los siguientes
protocolo, sino de la institucionalizacin de sus criterios:
principios y la implementacin en un formato
adecuado a las caractersticas de la empresa y Incluye la informacin: lista de tareas,
del proyecto. persona responsable de cada una, estado
en el que se encuentra y tiempo de
trabajo que queda para completarla.
Slo incluye la informacin estrictamente
necesaria.
El medio y modelo elegido es la opcin
posible que ms facilita la consulta y
comunicacin diaria y directa del equipo.

Sirve de soporte para registrar en cada no a trabajos internas del tipo diseo de
reunin diaria del sprint, el tiempo que le la base de datos
queda a cada tarea. Se produce un incremento en cada
iteracin.
Ejemplos Sin embargo suele ser una excepcin habitual el

primer sprint. En el que objetivos del tipo
contrastar la plataforma y el diseo pueden ser
normales, e implican trabajos de diseo o
desarrollo de prototipos para probar la solvencia
de la plataforma que se va a emplear, etc.
Teniendo en cuenta esta excepcin habitual,
Incremento es:
Parte de producto realizada en un sprint, y

potencialmente entregable: TERMINADA Y
PROBADA
Si el proyecto o el sistema requiere docu-

mentacin, o procesos de validacin y verificacin
documentados, o con niveles de independencia
que implican procesos con terceros, stos
tambin 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 segn la
prioridad para l.
Es un documento vivo, en constante evolucin
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 grfico 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 caractersticas: 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.
No se trata por tanto de mdulos o partes a falta
de pruebas, o documentacin o
Idealmente en el desarrollo gil:
Cada funcionalidad de la pila del producto

se refiere a funcionalidades entregables,

Scrum: Las reuniones
Scrum: Las Reuniones
El propietario del producto tiene pre-

parada la pila del producto, con su criterio
Introduccin de prioridad para el negocio, y un n

suficiente de elementos para desarrollar
en el sprint.
Scrum realiza el seguimiento y la gestin del Siempre que sea posible, el propietario
proyecto a travs de las tres reuniones que del producto debe haber trabajado antes
forman parte del modelo: con el equipo. De esta forma su
estimacin previa del trabajo que se
Planificacin del sprint puede realizar en el sprint ser bastante
Seguimiento del sprint ajustada.
Revisin del sprint El equipo tiene un conocimiento de las
tecnologas empleadas, y del negocio del
Este tema describe los objetivos y protocolos producto suficiente para realizar esti-
recomendados para cada una. 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
travs de los sucesivos incrementos
(excepto si se trata del primer sprint)
Circunstancias de las condiciones de
negocio del cliente y del escenario tec-
nolgico empleado.

Descripcin general
En esta reunin, toma como base: las prioridades
y necesidades de negocio del cliente, y determina
cules y cmo van a ser las funcionalidades que
incorporar el producto tras el siguiente sprint.
En realidad es una reunin que consiste en dos:
En la primera, que puede tener una duracin de
una a cuatro horas, se decide qu elementos de Resultados
la pila del producto se van a desarrollar.
En la segunda se desglosan stos para deter-
minar las tareas necesarias, estimar el esfuerzo Pila del sprint.
para cada una, y asignarlas a las personas del Duracin del sprint y fecha de la reunin
equipo. de revisin.
La planificacin del sprint no debe durar ms de Objetivo del sprint.
un da.
Las caractersticas de la reunin son: Es una reunin conducida por el responsable del
funcionamiento de Scrum (team leader, o Scrum
Pre-condiciones Manager Team Leader), a la que deben asistir

el propietario del producto y el equipo al
completo, y a la que tambin pueden asistir otros
La organizacin tiene determinados los
implicados en el proyecto.
recursos disponibles para llevar a cabo el
La reunin comienza con la presentacin del
sprint.
propietario del producto del backlog, en la que
expone los resultados que por orden de prioridad

necesita; especialmente los que prev, se podrn durante el sprint sirve de criterio de referencia en
desarrollar en el siguiente sprint. las decisiones que auto-gestiona el equipo.
Si la pila del producto ha tenido cambios
significativos desde la anterior reunin; explica las
causas que los han ocasionado.
El objetivo es que todo el equipo conozca las
razones y los detalles con el nivel necesario para
estimar el trabajo necesario.
Formato de la reunin
Esta reunin marca el inicio de cada sprint. Una
persona con la responsabilidad de procesos en la
6
organizacin es el responsable de su organi-
zacin y gestin.
Duracin mxima: un da.
Deben asistir: el propietario del producto, el Segunda parte:
equipo y el Scrum Manager.
Pueden asistir: es una reunin abierta a todos los En la segunda parte, que puede alargarse hasta
que puedan aportar informacin til. el final de la jornada:
Consta de dos partes separadas por una pausa El equipo desglosa cada funcionalidad en tareas,
de caf o comida, segn la duracin. y estima el tiempo para cada una de ellas,
determinando de esta forma las tareas de la pila
Primera parte: del sprint.
En este desglose el equipo tiene en cuenta los
Duracin de 1 a 4 horas. elementos de diseo y arquitectura que deber
Propietario del producto: incorporar el sistema.
Presenta las funcionalidades de la pila del Los miembros del equipo se auto-asignan las
producto que tienen mayor prioridad y diferentes tareas tomando como criterios sus co-
que estima se pueden realizar en el nocimientos, intereses y distribucin homognea
sprint. del trabajo.
La presentacin se hace con un nivel de Esta segunda parte debe considerarse como una
detalle suficiente para transmitir al equipo reunin del equipo, en la que deben estar todos
toda la informacin necesaria para cons- sus miembros y ser ellos quienes descomponen,
truir el incremento. estiman y asignan el trabajo.
El equipo
Realiza las preguntas y solicita las El papel del propietario del producto es atender a
aclaraciones necesarias. dudas y comprobar que el equipo comprende y
Propone sugerencias, modificaciones y comparte su objetivo.
soluciones alternativas. El Scrum Manager1 acta de moderador de la
reunin.
Las aportaciones del equipo pueden suponer
Funciones del rol de Scrum

modificaciones en la pila. De hecho no es que
puedan es que deben suponerlas.
Esta reunin es un punto caliente del protocolo de
Scrum para favorecer la fertilizacin cruzada de
ideas en equipo y aadir valor a la visin del
Manager1
producto. El Scrum Manager es responsable y garante de:
Tras reordenar y replantear las funcionalidades
de la pila del producto, el equipo define el 1.- Se realiza esta reunin antes de cada sprint.
objetivo del sprint o frase que sintetiza cul es el 2.-Antes de la reunin el propietario del producto
valor que se le va a entregar al cliente. dispone de una pila adecuada y suficiente para
realizar el sprint.
Exceptuando sprints dedicados exclusivamente a 3.- El dilogo principal de la reunin se realiza
re-factorizacin o a colecciones de tareas entre el propietario del producto y el equipo. Otros
deslavazadas (que deberan ser los menos), la asistentes pueden participar, pero su colabo-
elaboracin de este lema de forma conjunta en la racin no puede implicar toma de decisiones ni
reunin es una garanta de que todo el equipo limitar el dilogo principal.
comprende y comparte la finalidad del trabajo; y 4.- La reunin es un trabajo de colaboracin
activa entre los dos protagonistas: cliente y
6
Team Leader / Scrum Manager Team Leader

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 Segn la distribucin y espacio de la oficina,
sprint. quiz se reutilice la pizarra o las notas para el
5.- Ell equipo comprende la visin y necesidades seguimiento del sprint; o quiz no.
de negocio del cliente.
6.- El equipo ha realizado una descomposicin y Algunos soportes que se suelen emplear:
estimacin del trabajo realistas, y ha considerado Pizarra blanca y fichas adhesivas tipo
las posibles tareas necesarias de anlisis, Post-it
investigacin o apoyo. Pizarra de corcho laminado y chinchetas
7.- Al final de la reunin estn objetivamente para sujetar las fichas.
determinados: Pizarra de acero vitrificado y soportes
magnticos para sujetar las fichas.
Los elementos de la pila del producto que
se van a ejecutar. Se puede conseguir una solucin prctica y
El objetivo del sprint. econmica empleando fichas adhesivas (Post-it)
La pila del sprint con todas las tareas y usando como pizarra cartn pluma blanco de
estimadas y asignadas. 5mm. fijado con puntas directamente sobre la
La duracin del sprint y la fecha de la pared.
reunin de revisin. El cartn pluma es un material ligero, de acabado
satinado que puede adquirirse en tiendas de
El Scrum Manager modera la reunin para que no materiales para bellas artes y manualidades.
dure ms de un da. Debe evitar que el equipo
comience a profundizar en trabajos de anlisis o
arquitectura que son propios del sprint.
Pizarra de trabajo
Es recomendable, que el propietario del producto
emplee una hoja de clculo, 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 reunin, proyec-
tndola sobre la pantalla de la sala. Con cinta adhesiva removible se marcan lneas
Es mucho mejor trabajar y manipular elementos para delimitar:
fsicos; y usar una pizarra y fichas removibles
(adhesivas, chinchetas, magnticas). Un rea superior donde el Scrum
Manager coloca al principio de la reunin
la capacidad real del sprint a 3, 4 y 5
semanas (A); y al final (D), las notas con:
el objetivo establecido, duracin del
sprint, funcionalidades de la pila del
producto comprometidas, hora fijada para
las reuniones diarias y fecha prevista
para la reunin de revisin del sprint.
B.- Una franja para ordenar los elementos
de la pila del producto de mayor a menor
prioridad.
C.- Una franja paralela para descomponer
cada elemento de la pila del producto en
las correspondientes tareas de la pila del
Un ejemplo de pizarra. sprint.
En cada ficha se refleja la informacin bsica

La pizarra facilita la comunicacin y el trabajo de
para las decisiones de la reunin: priorizacin,
la reunin.
estimacin, descomposicin y asignacin a los
Al final de la reunin el propietario del producto
miembros del equipo.
registrar en la hoja de clculo, o en la herra-
Las siguientes imgenes muestran un ejemplo de
mienta que emplee, el estado y las modifica-
uso:
ciones en la pila del producto.

Seguimiento del sprint

Descripcin
Reunin diaria breve, de no ms 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 algn
impedimento, y actualiza sobre la pila del sprint
las ya terminadas, o los tiempos de trabajo que
les quedan.
Entradas
Pila del sprint y grfico de avance (burn-down)
actualizados con la informacin de la reunin
anterior.
Informacin de las tareas realizadas por cada
componente del equipo
Resultados
Pila del sprint y grfico de avance (burn-down)
actualizados.
Identificacin de necesidades e impedimentos.
Se recomienda realizarla de pie y emplear un
formato de pila de tareas en una pizarra, junto
con el grfico de avance del sprint, para que todo
el equipo pueda ver y anotar.
En la reunin est presente todo el equipo, y
pueden asistir tambin otras personas rela-
cionadas con el proyecto o la organizacin, pero
stas no pueden intervenir.
Cada miembro del equipo expone estas tres

cuestiones:
1.- Tarea en la que trabaj ayer.

2.- Tarea o tareas en las que trabajar hoy.
3.- Si va a necesitar alguna cosa especial o prev
algn impedimento para realizar su trabajo.
Y actualiza sobre el sprint backlog el tiempo de

trabajo que queda pendiente en las tareas que
tiene asignadas, o marca como finalizadas las ya
Algunas marcas comerciales, entre ellas Post-it completadas.
comercializan tarjetas adhesivas, con fondo
rallado, similares a fichas que resultan especia- Al final de la reunin:
lmente apropiadas, porque no se adhieren entre Con las estimaciones actualizadas, el
ellas, pero s a las pizarras. team leader refresca el grfico de avance
del sprint.
El responsable de la gestin de procesos
de la organizacin comienza la gestin de

necesidades
cados.
e impedimentos identifi-
Resultados
Feedback para el propietario del
Revisin del sprint producto: hito de seguimiento de la

construccin del sistema, e informacin
para mejorar el valor de la visin del
producto.
Descripcin Feedback para el responsable de
procesos: buenas prcticas y problemas
Reunin realizada al final del sprint en la que, con durante el sprint.
una duracin mxima de 4 horas, el equipo Convocatoria de la reunin del siguiente
presenta al propietario del producto, clientes, sprint.
usuarios, gestores el incremento construido en
el sprint.
Objetivos Es una reunin informal. El objetivo es ver el
incremento, trabajar en el entorno del cliente.
El propietario del producto obtiene Estn prohibidas las presentaciones grficas y
informacin objetiva del progreso del powerpoints.
sistema. Esta reunin marca a intervalos El equipo no debe invertir ms de una hora en
regulares, el ritmo de construccin del preparar la reunin, y lo que se muestra es el
sistema y la trayectoria que va tomando resultado final: terminado, probado y operando en
la visin del producto. el entorno del cliente (incremento).
Al ver y probar el incremento, el Segn las caractersticas del proyecto puede
propietario del producto, y el equipo en incluir tambin documentacin de usuario, o
general obtienen feedback clave para tcnica.
evolucionar y dar ms valor a la pila del
producto. Es una reunin informativa. NO TIENE UNA
Otros ingenieros y programadores de la MISIN ORIENTADA A TOMAR DECISIONES,
empresa tambin pueden asistir para NI A CRITICAR EL INCREMENTO. Con la infor-
conocer cmo trabaja la tecnologa macin generada en la preparacin del siguiente
empleada. sprint se expondrn y tratarn las posibles
El responsable de procesos o calidad de modificaciones sobre la visin del producto.
la organizacin obtiene retro-informacin
sobre buenas prcticas y problemas Un protocolo recomendado:
durante el sprint, necesaria para las 1.- El team leader expone el objetivo del sprint, la
prcticas de ingeniera de procesos y lista de funcionalidades que se incluan y las que
mejora continua de la implementacin se han desarrollado.
Scrum Management. 2.- El equipo hace una introduccin general del
sprint y demuestra el funcionamiento de las
partes construidas.
Pre-condiciones 3.- Se abre un turno de preguntas y sugerencias
sobre lo visto. Esta parte genera informacin muy
Se ha concluido el sprint. valiosa para que el propietario del producto, y el
Asiste todo el equipo de desarrollo, el equipo en general, puedan mejorar el valor de la
propietario del producto, el responsable visin del producto.
de procesos de la empresa y todas las 4.- El responsable del proceso, de acuerdo con
personas implicadas en el proyecto que lo las agendas del propietario del producto y el
deseen. equipo cierra la fecha para la reunin de
preparacin del siguiente sprint.
Entradas
Incremento terminado. Resumen
La gestin y evolucin de un proyecto con Scrum
se determina en tres reuniones:


Revisin del sprint

Duracin mxima 1 da
Se determinan las funcionalidades que se
desarrollarn 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

Breve reunin diaria en la que el equipo
revisa la evolucin del sprint.
Cada uno expone la tarea en la que ha
estado trabajando, en cul va a trabajar y
si necesita algo para poderla realizar.
Cada miembro actualiza la estimacin de
tiempo pendiente de sus tareas
Revisin del sprint

Duracin mxima 4 horas
Muestra el incremento desarrollado a
todas las personas implicadas en el
proyecto.

Medicin: consideraciones
Medir no es un fin en s mismo
Introduccin No se deben implantar procesos de medicin tan

slo porque s.
Por qu medir? Tomar una lista ms o menos prestigiosa de
mtricas e incorporarla a los procedimientos de la
La informacin es la materia prima de la toma de empresa, puede tentar por la imagen de
decisiones, y la que puede ser objetivamente profesionalidad que transmitir un escenario de
cuantificada proporciona criterios objetivos de trabajo monitorizado con indicadores y complejas
gestin y seguimiento. mediciones, pero no dice mucho a favor de cmo
se han analizado y adaptado esas mtricas a la
Desde los niveles concretos de la programacin, realidad de los proyectos y la empresa.
hasta los ms amplios de la gestin global de la
compaa, Scrum Management considera tres
fondos de escala, o de zoom con los que se
puede medir el trabajo
Criterios para el diseo y
Desarrollo y gestin de la solucin tcnica.

Gestin de proyecto.
aplicacin de mtricas
Gestin de la organizacin.
En el primero se puede medir, por ejemplo, la

Cuantas menos, mejor:
proporcin de polimorfismo del cdigo de un Medir es costoso
programa, en el segundo, el porcentaje de trabajo Medir aade burocracia
realizado, y en el tercero, tambin por ejemplo, el El objetivo de Scrum Management es
nivel de satisfaccin laboral. trabajar con la mejor relacin valor /
simplicidad.
Este libro cubre el rea de gestin de proyectos,
Cuestiones para cada indicador:
Este libro cubre el rea de gestin de proyectos,
desde una perspectiva gil; pero en esta Por qu se va a usarlo?
introduccin se exponen consideraciones Cul es el valor por incorporarlo?
generales, comunes a los tres. Cul por omitirlo?
Se pueden tomar decisiones de gestin sin
esa informacin?
La cita No se puede gestionar lo que no se

puede medir, por la redondez de su forma, tienta
a considerarla incuestionable. Se desarrollan as
patrones de gestin que renuncian a la
experiencia, capacidad y sentido comn del
gestor, incluso en las ocasiones en las que ste
puede ser suficiente; y se termina reclamando
mtricas, produciendo gestores mecanicistas.
El sentido comn puede bastar, por ejemplo, para

tomar decisiones de gestin de personal en una
Flexibilidad y sentido comn empresa de ingeniera de 10 empleados, sin

necesidad de procedimientos de medicin del
clima laboral; pero sin embargo stos son
necesarios en empresas con cientos de personas
Medir es costoso en sedes y departamentos diferentes.
El objetivo de la gestin Scrum es el valor, y la

Antes de incorporar un procedimiento de cuestin clave para la incorporacin de
medicin, se debe cuestionar su conveniencia, y indicadores en la gestin de proyectos es:
la forma en la que se aplicar.

Cmo contribuye el uso de este indicador en Como no slo es importante la eficiencia, sino
el valor que el proyecto va a aportar al cliente? tambin la satisfaccin del cliente (interno en este
caso, que ser el departamento que solicita
personal) esta mtrica se combina con otra para
determinarlo: tiempo de respuesta.
Cunto tiempo se tarda en cubrir las vacantes.
La implantacin del indicador ha dado buenos

resultados: Desde su puesta en marcha, el
departamento de RR.HH. ha comenzado a ser
ms eficiente y conseguir mayor satisfaccin de
su cliente:
1.- Va reduciendo los costes que suponen la
incorporacin de nuevas personas a la empresa.
2.- Va reduciendo los tiempos de respuesta a los
departamentos que solicitan nuevo personal.
El indicador es apropiado para Medicin del avance del proyecto.

el fin que se debe conseguir? La organizacin XYZ ha diseado un cuadro de
informacin para mostrar el grado de avance de
Medir no es, o no debera ser, un fin en s mismo.
cada proyecto.
Cul es el fin?
Los indicadores de progreso de los proyectos, y
Cumplir agendas, mejorar la eficiencia del
de las tareas en las que se descomponen, se
equipo, las previsiones?
elaboran con el sistema clsico de la gestin de
proyectos predictiva:
Sea crtico. El que lo haga, o diga que lo hace, la
mayora, no es una razn. Si despus de anali-
1.- Se realiza la estimacin del tiempo de trabajo
zarlo no le convence, si prefiere no incorporar esa
necesario para cada tarea
mtrica, o modificarla: usted es el gestor.
2.- Diariamente se actualizan los tiempos de
trabajo invertidos
Determinar qu medir es la parte ms difcil. En el
3.- La diferencia muestra el porcentaje ejecutado
mejor de los casos, las decisiones errneas slo
de las tareas, y por tanto, el de cada proyecto.
supondrn un coste de gestin evitable; pero
muchas veces empeorarn lo que se intentaba
mejorar.
Medicin de la eficiencia de los
Algunos ejemplos de errores en la incorporacin
de mtricas, en los tres niveles de gestin: Por trabajos de programacin
qu pueden resultar contraproducentes?
La organizacin XYZ ha adoptado mtricas
estndar de eficiencia de Ingeniera del Software:
Medicin de la eficiencia en la LOC/Hour: Nmero total de lneas de cdigo
nuevas o modificadas en cada hora.
empresa: Adems para motivar la productividad, ha
vinculado los resultados de esta mtrica a la
La organizacin XYZ, dedicada al desarrollo de
retribucin por desempeo de los programadores.
software, est integrando un sistema de calidad y
El resultado ha sido producir ms lneas de
mejora integral para toda la empresa, que incluye
cdigo sin incrementar la plantilla.
mtricas para conocer el grado de eficiencia en
cada departamento.
Para evitar que se trate de un incremento hueco
de lneas de cdigo, o que conlleve un aumento
Para el de RR.HH. se ha diseado e implantado
de los errores por programar ms deprisa, se ha
un indicador habitual para estos casos, que
dotado de mayor rigor al sistema de mtrica,
determina la eficiencia en los procesos de
incorporando al poco tiempo otras mtricas para
seleccin de personal.
complementar y mejorar el sistema de calidad:
Mide el coste de cada proceso de seleccin
(anuncios, seleccin de currculos, entrevistas)
Test Defects/KLOC, Compile Defects/KLOC y
y lo divide por el nmero de puestos cubiertos.
Total Defects/KLOC, para controlar que no

Resumen
aumenten el nmero de errores deslizados en el
cdigo.
Tambin se incorporaron indicadores appraisal
time para medir tiempo y costes del diseo y la
ejecucin de las revisiones de cdigo. Las mtricas se pueden aplicar en el nivel de
gestin de la organizacin, de gestin de los
Y por el temor a que el sistema de medicin proyectos o de construccin de la solucin
pueda resultar excesivamente costoso se tcnica.
incorporan tambin indicadores de coste de
calidad (COQ) que miden los tiempos de revisin En el diseo e implantacin de mtricas se debe
y los contrastan con las mejoras en los tiempos considerar:
eliminados por reduccin de fallos.
Usar el menor nmero de mtricas posible.
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 vlido de
indicador vlido de lo que lo que queremos conocer?
queremos conocer?
Hay tareas de programacin relativamente mec-
nicas, orientadas ms a la integracin y configu-
racin que en al desarrollo de nuevos sistemas.
Para aquellas puede resultar medianamente
acertado considerar la eficiencia como volumen
de trabajo realizado por unidad de tiempo.
Para las segundas sin embargo, es ms

apropiado pensar en la cantidad de valor
integrado por unidad de desarrollo; expresadas
estas en horas, iteraciones o puntos de funcin.
Qu queremos conocer: la cantidad de lneas de

programa, o el valor que entregamos al cliente?
Est relacionado lo uno con lo otro?
Se puede medir objetivamente el valor entre-
gado al cliente?
En nuestro trabajo son muchos los parmetros

que se pueden medir con criterios objetivos y
cuantificables: el tiempo de tarea, los tiempos
delta, y los de las interrupciones, el n de puntos
de funcin, la inestabilidad de los requisitos, la
proporcin de acoplamiento, el n de errores por
lnea de cdigo
No estaremos muchas veces midiendo esto,

simplemente porque es cuantificable?
No estaremos midiendo el n de lneas que

desarrollan las personas cuando en realidad
queremos saber el valor de su trabajo?
No nos estar pasando lo mismo cuando
pretendemos medir: la facilidad de uso, la
facilidad de mantenimiento, la flexibilidad, la
transportabillidad, la complejidad, etc.?

Medicin: Las Unidades
Medicin: Las unidades
En ambos casos se necesita una unidad, y un

criterio objetivo de cmo se cuantifica.
Velocidad, trabajo y tiempo

Velocidad, trabajo y tiempo son las tres
magnitudes que mide la gestin de proyectos gil,
y componen la frmula de la velocidad,
definindola como: cantidad de trabajo realizada
en por unidad de tiempo.
Velocidad = Trabajo / Tiempo
Tiempo
En las mtricas giles el tiempo se puede
considerar de dos formas diferentes: como real o
Trabajo ya realizado
como ideal.
Ambas son vlidas, y cada organizacin opta por
la que considera ms adecuada para ella.
Medir el trabajo ya realizado no entraa especial
Sea cual sea criterio, ste se debe mantener de dificultad.
forma homognea en todas las mtricas y Se puede hacer con unidades relativas al
estimaciones. producto (p. ej. lneas de cdigo) o a los recursos
empleados (coste, tiempo de trabajo)
Tiempo real Para medirlo basta contabilizar lo ya realizado,

empleando las unidades con las que se opere:
Tiempo efectivo de trabajo. Es equivalente a la lneas de cdigo, horas trabajadas (reales o
jornada laboral. tericas)
Para un equipo de cuatro personas con jornada
laboral de ocho horas el tiempo real en una Medir el trabajo realizado NO es una mtrica gil.
semana (cinco das laborables) es:
4 * 8 * 5 = 160 horas LA GESTIN GIL NO DETERMINA EL

GRADO DE AVANCE DEL PROYECTO
El tiempo real de ese equipo en un sprint de 12 POR EL TRABAJO YA REALIZADO, SINO
das de trabajo es: POR EL PENDIENTE DE REALIZAR
4 * 8 * 12 = 384 horas
Es posible que otros procesos de la organizacin
Tiempo ideal necesiten registrarlo y medirlo, pero no la gestin
gil de proyectos.
Tiempo de trabajo en condiciones ideales, esto
es, sin ninguna interrupcin, pausa, distraccin o
atencin a tareas ajenas a la tarea del sprint que
se tiene asignada.
7
Trabajo pendiente de realizar
Es el concepto similar al que PSP denomina Scrum mide el trabajo pendiente para:
Delta Time.
Estimar el esfuerzo y la duracin prevista
Trabajo
para cada tarea.
Determinar el avance del proyecto, y en
Medir el trabajo puede ser necesario por dos especial de cada sprint.
razones: para registrar el ya hecho, o para
estimar anticipadamente, el que hay que realizar.
7
Personal Software Process

Descomponer las tareas de los sprints en

sub-tareas ms pequeas, si las estimaciones
superan los rangos de las 16-20 horas de de
trabajo.
Para Scrum Management, estimar con precisin,

de forma cuantitativa y objetiva el trabajo que
necesitar la construccin de un requisito, es un
empeo ms que cuestionable.
El trabajo de un requisito no se puede cuantificar

de forma absoluta, porque las funcionalidades no
son realidades de solucin nica. Unidades de trabajo
La cantidad de trabajo que consumir cada Las unidades para medir el trabajo pueden estar
funcionalidad o cada historia de usuario no se relacionadas directamente con el producto, como
puede calcular de forma absoluta y objetiva; y en los tradicionales puntos de funcin de COCOMO;
o indirectamente, a travs del tiempo necesario
el caso de que se pudiera, la complejidad de la
para realizarlo.
medicin hara que la mtrica resultante fuera
demasiado pesada para la gestin gil.
La gestin gil suele llamar a las unidades que
Y si no resulta posible estimar con precisin la emplea para medir el trabajo puntos, puntos de
cantidad de trabajo que hay en un requisito, funcionalidad puntos de historia pero se trata
siempre de medicin a travs del tiempo, no del
tampoco se puede saber cunto tiempo costar,
producto.
porque adems de la incertidumbre del trabajo, se
suman las inherentes al tiempo:
As por ejemplo la unidad de medida Story Point
No es realista hablar de de la cantidad o de la de Extreme Programming define: la cantidad de
trabajo que se realiza en un da de trabajo terico.
calidad del trabajo que realiza una persona al
da, o a la hora, porque hay diferencias muy
Cada organizacin, segn sus circunstancias y su
grandes de estos resultados, segn las
personas. criterio institucionaliza su mtrica de trabajo
Un misma tarea, realizada por las mismas definiendo el nombre y las unidades, teniendo en
personas consumir diferentes tiempos reales cuenta que se basan en el tiempo necesario para
ejecutarlo.
en entornos de trabajo diferentes
Sobre estas premisas: Pueden ser: puntos, puntos de funcin, puntos de

historia, das, horas y referirse a tiempo real o
No es posible estimar con precisin, ni el tiempo terico.
trabajo de un requisito, ni el tiempo necesario
Lo importante no es si emplea uno u otro nombre,
para desarrollarlo.
si se refiere al trabajo realizado en cuatro o en
La complejidad de las tcnicas de estimacin
crece exponencialmente en la medida que: ocho horas, o si stas son reales o ideales.
o Intentan incrementar la fiabilidad y Lo importante es que la mtrica empleada, su
precisin de los resultados. significado y la forma de aplicacin sea
o Aumenta el tamao de la tarea consistente en todas las mediciones, en todos los
proyectos de la organizacin y conocida por todas
estimada.
las personas:
La estrategia empleada por la gestin gil es:
Que se trate de un procedimiento de trabajo
No empearse en estimaciones precisas. institucionalizado.
Estimar con la tcnica juicio de expertos

Velocidad, o eficiencia?
Los equipos que miden el trabajo con tiempo
ideal, hablan de Velocidad.
En los que usan tiempo real se dice que es

eficiencia.
Decir, por ejemplo, que la velocidad del equipo en

el sprint ha sido de 23, se refiere a que han
completado tareas que medan en toral 23 story
points.
Si en el sprint siguiente consiguen una velocidad

Resumen
mayor, querr decir que han logrado programar
ms story points en el mismo tiempo, o lo que es Tiempo real: tiempo total de trabajo, equivale a la
lo mismo que han conseguido aumentar el jornada laboral
porcentaje de tiempo ideal en la jornada de
trabajo: han reducido los tiempos de inte- Tiempo ideal: Tiempo de trabajo en condiciones
rrupciones, distracciones o dedicados a otras ideales, esto es: sin ninguna interrupcin, pausa,
tareas. distraccin, o atencin a tareas ajenas a la que se
tiene asignada en el sprint.
Para los equipos que miden el trabajo con tiempo
real, la frmula de la velocidad, como concepto Para determinar el grado de avance de un
velocidad, pierde sentido. proyecto, la gestin gil no mide el trabajo ya
realizado, sino el pendiente de realizar.
Velocidad = trabajo / tiempo
Tomando como premisas
Como el trabajo se mide en tiempo real,
numerador y denominador emplean la misma No es posible estimar con precisin, ni el
cifra: trabajo de un requisito, ni el tiempo necesario
para desarrollarlo.
Velocidad = Trabajo que se puede realizar en la La complejidad de las tcnicas de estimacin
unidad de tiempo / tiempo crece exponencialmente en la medida que:
o Intentan incrementar la fiabilidad y
Estos equipos no incrementan la velocidad por precisin de los resultados.
dedicar ms tiempo efectivo, puesto que no o Aumenta el tamao de la tarea
diferencian entre tiempo efectivo y tiempo total. estimada.
Parece ms propio decir que lo que incrementan La estrategia empleada por la gestin gil es:
no es la velocidad sino la eficiencia, porque lo que
consiguen es realizar ms trabajo en el mismo No profundiza en estimaciones precisas.
tiempo. Emplea la tcnica de juicio de expertos
Descompone las tareas de los sprints en sub-
En realidad es el mismo perro con diferente tareas ms pequeas, si las estimaciones
collar superan los rangos de las 16-20 horas de de
trabajo.
El objetivo en el primer caso es aumentar el
porcentaje de tiempo ideal, y en el segundo Velocidad y eficiencia son trminos similares. Se
aumentar los story points que se pueden realizar. suele preferir velocidad cuando las mediciones
se basan en tiempo tericos, y eficiencia cuando
Se le puede llamar velocidad o eficiencia, lo lo hacen en tiempo real.
importante no son los nombres, ni merece la pena
entrar en cuestiones bizantinas.
Quiz sea ms consecuente hablar de velocidad

su se trabaja con tiempo ideal, y eficiencia si se
hace con tiempo real.

Medicin: Usos y herramientas
La figura anterior representa la situacin actual

8
del product backlog: el propietario del producto
Grfico de producto: tiene previsto cerrar la versin 1.0 cuando dis-

ponga de los cuatro primeros temas, y su
estimacin inicial de trabajo para llevarlos a cabo
En ingls: grfico burn-up. es de 950 puntos.
Este grfico muestra en un vistazo, el plan La versin 1.2 incluir 3 temas ms que, segn la
general de desarrollo del producto, y la evolucin estimacin inicial, supondrn unos 750 puntos de
prevista. trabajo.
Es un diagrama cartesiano que representa en el Y estn tambin trazados los temas con los que
eje de ordenadas el trabajo estimado para piensa cerrar la versin 1.3, que se prevn con
desarrollar el producto, y en el de abcisas las 850 puntos ms de trabajo.
fechas, medidas segn 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:
Representacin del plan del producto, a partir de

los temas previstos en el product backlog.
A continuacin se traza en el grfico la lnea de
velocidad prevista.
Convenciones empleadas por el equipo:
Siguiendo con el ejemplo, la lnea roja de la
Unidad para medicin de trabajo: tiempo ideal
imagen representa la velocidad de 300 puntos por
Tiene previsto realizar sprints de duracin fija
sprint.
mensual.
El equipo est formado por 4 personas, y
Tambin puede resultar til esbozar una estima-
viene desarrollando una velocidad de 300
cin optimista y otra pesimista para tener la visin
puntos por sprint (300 horas ideales de
de una holgura de fechas aceptable.
trabajo)
8
Las listas de producto y de versin 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 lnea de velocidad proyecta sobre el eje X la el esfuerzo pendiente.
fecha o sprint en el que previsiblemente se Esto es: el primer da, en la pila de tareas figura
completarn las versiones representadas en el para cada tarea el esfuerzo que se ha estimado,
eje Y. puesto que an no se ha trabajado en ninguna de
ellas.
Grfico de avance:
Da a da, cada miembro del equipo actualiza en
la pila del sprint el tiempo que le queda a las
tareas que va desarrollando, hasta que se
monitorizacin del sprint terminan y van quedando a 0 los tiempos
pendientes.
La figura siguiente muestra un ejemplo de pila en
Tambin se suele emplear la denominacin el sexto da del sprint: las tareas terminadas ya no
inglesa: grfico burn-down. tienen esfuerzo pendiente, y del esfuerzo total
previsto para el sprint: 276 puntos (A), en el
Es el grfico 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 a ser
posible)
Y en este grfico toman forma los dos principios:
En el eje Y se registra el trabajo que an falta

por realizar
Se actualiza a diario Con esta informacin de la pila del sprint se
actualiza el grfico poniendo cada da el esfuerzo
pendiente total de todas las tareas que an no se
han terminado.

La estimacin que realiz el equipo en la reunin

de inicio del sprint es inferior al esfuerzo real que
estn requiriendo las tareas.
Y el siguiente sera el patrn de grfica de un

sprint sobre-estimado.
El avance ideal de un sprint estara representado

por la diagonal que reduce el esfuerzo pendiente
de forma continua y gradual hasta terminarlo en el
ltimo da del sprint:
Estimacin de pker
Es una prctica gil, til para conducir las reunio-
nes en las que se estima el esfuerzo y la duracin
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 grficas de diagonal perfecta no son lo ficacin como ayuda para conducir la reunin.
habitual, y la siguiente imagen es un ejemplo de
un patrn de avance ms normal. El modelo inicial de Grening consta de 8 cartas,
con los nmeros representados en siguiente
figura, porque James lo ide para las
estimaciones de versin en Extreme Progra-
mming, con equipos que emplean como unidad
de esfuerzo: das de trabajo de cada par de
9
programadores y trabajan con tareas de tamao
10
mximo de 10 das.
El siguiente sera el aspecto de la grfica en un

sprint sub-estimado
9
Extreme Programming trabaja con programacin por parejas.
10
Las tareas de mayor tamao se descomponen en sub-
tareas hasta que stas tienen estimaciones mximas de 10
das.

El funcionamiento es muy simple: cada Si se quiere emplear la planificacin de pker

participante dispone de un juego de cartas, y en para estimar requisitos a nivel de producto o de
la estimacin de cada tarea, todos vuelven boca versin (funcionalidades, temas) adems de
arriba la combinacin que suma el esfuerzo usarlo al nivel de tareas de sprint, se pueden
estimado. aadir cartas al juego para permitir estimaciones
de mayor tamao (34, 55, 89, 144)
Cuando se considera que ste es mayor de 10
horas (o del tamao mximo considerado por el Es frecuente emplear una carta con un smbolo
equipo para una tarea), se levanta la carta de duda o interrogacin para indicar que, por las
razones que sean, no se puede precisar una
Cada equipo u organizacin puede utilizar un estimacin.
juego de cartas con las numeraciones adecuadas Tambin 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
tamao mximo de tarea que se va a estimar. descanso.
Lo relevante no es el nmero de cartas, la unidad

de medida empleada, o si el tamao mximo de Funcionamiento
tarea debe ser 5, 7 10 das, sino trabajar con el
Cada participante de la reunin tiene un juego
modelo que el equipo considera ms apropiado,
de cartas.
respetando los principios siguientes:
Para cada tarea (historia de usuario o
funcionalidad, segn sea el nivel de requisitos
No definir tareas demasiado grandes, porque
que se va a estimar) el cliente, moderador o
entorpece la precisin de las estimaciones y
propietario del producto expone la descripcin
la identificacin de riesgos.
empleando un tiempo mximo.
No definir tareas con duraciones inferiores a
Hay establecido otro tiempo para que el
medio da ideal de trabajo.
cliente o propietario del producto atienda a las
Utilizar al misma unidad de medida (story
posibles preguntas del equipo.
points, das, horas) en todos los grficos y
Cada participarte selecciona la carta, o cartas
pilas.
que representan su estimacin, y las separa
del resto, boca abajo.
Variante: sucesin de Fibonacci Cuando todos han hecho su seleccin, se
muestran boca arriba.
Basado en el hecho de que al aumentar el tama- Si la estimacin resulta infinito, por sobre-
o de las tareas, aumenta tambin el margen de pasar el lmite mximo establecido, la tarea
error, se ha desarrollado una variante que con- debe dividirse en sub-tareas de menor
siste en emplear slo nmeros de la sucesin de tamao.
Fibonacci para realizar las estimaciones, de forma Si las estimaciones resultan muy dispares, el
que: moderador, con su criterio de gestin, y
basndose en las caractersticas del pro-
El juego de cartas est compuesto por yecto, equipo, reunin, n de elementos pen-
nmeros de la sucesin de Fibonacci. dientes de evaluar puede optar por:
La estimacin 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 ms crees que es necesario tanto
aproximada a la estimacin. tiempo?, y por qu crees que es
necesario tan poco tiempo? Tras
Para estimar tareas puede ser vlido un juego de escuchar las razones, repetir la esti-
cartas como ste: macin.
Dejar a un lado la estimacin 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 estimacin menor, mayor, o
la media.

Este protocolo de reunin evita los atascos de

anlisis circulares en ping-pong entre diversas
opciones de implementacin, hace participar a
todos los asistentes, reduce el cuarto de hora o la
media hora de tiempo de estimacin de una
funcionalidad, a escasos minutos, consigue alcan-
zar consensos sin discusiones, y adems... resul-
ta divertido y dinamiza la reunin.
Resumen
El grfico de producto o burn-up, muestra en
un vistazo el plan general de desarrollo del
producto.
A partir de la velocidad del equipo y las

estimaciones de trabajo previstas en la pila del
producto, representa las fechas o sprints en los
que previsiblemente se irn terminando las
diferentes versiones.
El grfico de avance o burn-down es una

herramienta gil que monitoriza el ritmo de trabajo
(normalmente de un sprint).
En el eje vertical de un diagrama cartesiano

representa el trabajo pendiente a lo largo del
tiempo del sprint (eje horizontal).
Las desviaciones sobre, o bajo la lnea diagonal

que representara el avance ideal del sprint
alertan de forma temprana de desviaciones sobre
el ritmo de desarrollo previsto.
La estimacin de pker es una prctica gil para

conducir las dificultades habituales en las
reuniones de trabajo para planificacin por juicio
de expertos.
En ella los participantes emplean un juego de
cartas para concretar las unidades de esfuerzo
que estiman para cada tarea.
Hay dos variantes:

Natural: los participantes pueden estimar el
esfuerzo con la cifra exacta que crean ms
adecuada.
Fibonacci
Las estimaciones solo se pueden realizar em-
pleando nmeros de la sucesin de Fibonacci.
En cada caso, el juego de cartas empleado tiene

la numeracin apropiada.

ndice
ndice
A F
Adaptive Software Development 32 Fases de desarrollo 23, 24
Agile Alliance 32 Fertilizacin cruzada 60, 66
Agile Enterprise 34 Flexibilidad 29
Agile Unified Process 32
Arie van Bennekum 33
ASD 32 G
AUP 32
Gestin 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 Caractersticas diferenciales 38
Clsica
mbito 17
C Objetivo 17
Otras denominaciones 37
Campo de scrum 22 Premisas 37
Caractersticas 23 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 24 Predictiva 16
Cierre 31 Grficos
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 organizacin 41 H
Hirotaka Takeuchi 21
D
DSDM 33 I
IEEE 1012-1998 33
E Ikukiro Nonaka 21
Incepcin 32
Eficiencia (medicin) 81 Incertidumbre 23
Equipo (rol) 48, 54 Incremento 47, 59
Equipos Definicin 62
Auto-organizacin 23, 24 Innovacin
Caractersticas 23 Como valor 22, 29
Caractersticas 54 Integridad 33
Control sutil 24 ISO 12207 59
Difusin del conocimiento 24
Especializacin 21
Especializacin 22 J
Especulacin 31
Estimacin de pker 87 James Grening 87
Fibonacci 88 Jeff Sutherland 34
Exploracin 31, 60
Re-trabajo 38
K Reuniones
Seguimiento del sprint 86
Ken Schwaber 34 Revisin 31
M S
Mantenimiento 31 Sashimi 24
Meter Norden 16 Scrum 34
Mtricas Campo de 22
reas de medicin Scrum Management 73 Control gil del proyecto 46
Estrategia de la gestin gil 80 Estructura central 45
Tiempo 79 Origen 45
Tiempo ideal 79 Reuniones 65
Tiempo real 79 Planificacin del sprint 47, 65
Trabajo 79 Formato 66
Trabajo pendiente 79 Revisin del sprint
Trabajo realizado 79 Formato 69
Unidades de trabajo 80 Seguimiento del sprint 47
Velocidad 79 Formato 68
Michel Hammer 21 Revisin del sprint 47
Mike Breedle 34 Roles 47
Solapamiento 24
Valores 48
P Scrum Management
Responsabilidades 53
Personas Scrum Manager
Sensibilidad al entorno 40 Team leader 66
Pila del producto 47, 59 Team leader (rol) 48, 55
Caractersticas 60 ScrumManager 11
Definicin 60 Formacin 11
Formato 61 Solapamiento 22
Pila del sprint 47, 59 Sashimi 24
Caractersticas 60 Scrum 24
Definicin 61 Tipos 24
Formato 61 Sprint 34, 45
Plan de producto 86 Story Point 80
Procesos 40
Produccin 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
Coste 39
Proyecto
Caractersticas 15
V
Definicin clsica 15
Puntos de historia 80 Velocidad 81
Visin 30
R
W
Requisitos
giles 59 WBS 16
Del sistema 59
Del software 59
Estabilidad 39 X
Inestabilidad 29
Modificacin 24 XBreed 34
Responsabilidad 59

ScrumManager: Gestión de proyectos ágiles

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ScrumManager: Gestión de proyectos ágiles

Caricato da

Copyright:

Formati disponibili

ScrumManager

ScrumManager: Gestin de proyectos.

Versin impresa disponible en http://www.lulu.com

Web del proyecto ScrumManager

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

Derechos registrados en Safe Creative.

Origen de la gestin de proyectos 13

Gestin de proyectos gil 27

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

Gestin de proyectos: formal o gil? 35

Introduccin al modelo Scrum para desarrollo de Software 43

Roles y responsabilidades de proyecto 51

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

Los elementos de Scrum 57

Scrum: Las reuniones 63

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

Medicin: Las Unidades 77

Medicin: Usos y herramientas 83

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

Organizaciones basadas en equipos:

ScrumManager: Gestin de proyectos

Este manual es una gua de formacin de las prcticas recomendadas para la

Este libro es un recurso de formacin abierto para la gestin de proyectos en el marco

Para colaborar con el proyecto, se recomienda adquirir la versin impresa (Disponible en

2008 ScrumManager Project http://www.scrummanager.net 11

Formacin y asesora profesional

12 2008 ScrumManager Project http://www.scrummanager.net

Definicin clsica de proyecto

Las construcciones de ingeniera civil, como

Las operaciones se ejecutan de forma

Los proyectos han existido siempre.

El objetivo de la concurrencia era ejecutar las

2008 ScrumManager Project http://www.scrummanager.net 15

secuencialmente, y al aplicarla en los proyectos

Modelo vlido para cualquier

16 2008 ScrumManager Project http://www.scrummanager.net

Gestin predictiva o clsica

La gestin de proyectos desarrollada en las

La planificacin se realiza sobre un anlisis

Gestin de proyectos clsica

Establece como criterios de xito: obtener el

2008 ScrumManager Project http://www.scrummanager.net 17

18 2008 ScrumManager Project http://www.scrummanager.net

Divisin del trabajo, especializacin y produccin

Escenario de desarrollo en basada en procesos, fueron premisas que, como

Estimar cul va a ser el trabajo necesario, y a

Ciclo de vida secuencial.

The New New Product

Muchas compaas han descubierto que para

2008 ScrumManager Project http://www.scrummanager.net 21

El ordenador personal NEC PC 8000 (1979)

La figura siguiente representa el ciclo de vida al Caractersticas del nuevo

En los 40, 50 y 60 los productos tardaban aos en

22 2008 ScrumManager Project http://www.scrummanager.net

Campos de scrum vs.

modelo clsico de Caractersticas del campo

Incertidumbre consustancial al entorno y la

2008 ScrumManager Project http://www.scrummanager.net 23

Auto-superacin. El equipo va desarrollando Los retrasos de cada fase son cuellos de

El equipo dispone de autonoma, pero no debe

Difusin del conocimiento

En el desarrollo tradicional: Tanto a nivel de proyecto como de organizacin.

24 2008 ScrumManager Project http://www.scrummanager.net