Académique Documents
Professionnel Documents
Culture Documents
Manual
ScrumManager: Gestin de proyectos
Ttulo
Autor
Juan Palacio.
Imagen de Portada
Philip A.
Edicin
Septiembre 2008
Impresin
Derechos
ScrumManager: Informacin 9
ScrumManager: Informacin 11
Qu es ScrumManager? 11
ScrumManager: Gestin de proyectos 11
Formacin abierta 11
Formacin y asesora profesional 12
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
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
Las reuniones 47
Los elementos 47
Los roles 47
Valores 48
Resumen 48
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
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
Formato de la reunin 68
Revisin del sprint 69
Descripcin 69
Objetivos 69
Pre-condiciones 69
Entradas 69
Resultados 69
Formato de la reunin 69
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
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.
Formacin abierta
ScrumManager apuesta por un modelo abierto de difusin del conocimiento, frente a los
patrones clsicos, que resultan ms costosos e inaccesibles.
1
Hirotaka Takeuchi, Ikujiro Nonaka The New New Product Development Game, Harvard Business Review, 1986.
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.
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.
los 80
por esta razn, los puntos clave de la gestin
predictiva o clsica son:
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.
Control sutil
y la aportacin de soluciones valiosas
complementarias.
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
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:
3.-Agilidad
Capacidad para producir partes completas del
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
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.
gestin gil.
iteraciones y se realizan hasta que se decide no
evolucionar ms el producto.
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.
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.
CRYSTAL
(Extreme Programming, Scrum...)
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:
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
5
Scrum es el nombre que se da en Rugby a una determinada
formacin del equipo.
Premisas de la gestin de
producto previsto y elabora un plan de
desarrollo, a partir del cual calcula 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.
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.
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.
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.
Condiciones de la organizacin
Los elementos empleados por las organizaciones
para ejecutar proyectos son: personas, procesos
y tecnologa.
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.
Modelo de de desarrollo
Los entornos de desarrollo basados en procesos
son adecuados para modelos de gestin
predictiva.
Resumen
Trminos empleados para designar a los dos
modelos de gestin de proyectos:
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
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.
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.
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
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.
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.
De procesos
Configuracin de Scrum
Mejora continua
Garanta de funcionamiento de Scrum en
cada proyecto
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).
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
Resumen
Las responsabilidades del funcionamiento de
Scrum Management en la organizacin se
clasifican en tres niveles y son las siguientes:
Introduccin
Los elementos centrales del modelo de trabajo
Scrum son:
Los requisitos en el
desarrollo gil
La ingeniera del software clsica diferencia dos
reas de requisitos
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.
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.
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.
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.
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
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.
Entradas
Pila del sprint y grfico de avance (burn-down)
actualizados con la informacin de la reunin
anterior.
Informacin de las tareas realizadas por cada
componente del equipo
Resultados
Pila del sprint y grfico de avance (burn-down)
actualizados.
Identificacin de necesidades e impedimentos.
Formato de la reunin
Se recomienda realizarla de pie y emplear un
formato de pila de tareas en una pizarra, junto
con el grfico de avance del sprint, para que todo
el equipo pueda ver y anotar.
En la reunin est presente todo el equipo, y
pueden asistir tambin otras personas rela-
cionadas con el proyecto o la organizacin, pero
stas no pueden intervenir.
necesidades
cados.
e impedimentos identifi-
Resultados
Feedback para el propietario del
Entradas
Incremento terminado. Resumen
La gestin y evolucin de un proyecto con Scrum
se determina en tres reuniones:
Planificacin del sprint
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.
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.
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)
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
Velocidad, o eficiencia?
Los equipos que miden el trabajo con tiempo
ideal, hablan de Velocidad.
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.
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:
Ejemplo:
8
Las listas de producto y de versin evolucionan de forma
continua durante la vida del producto.
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.
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.
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.
Resumen
El grfico de producto o burn-up, muestra en
un vistazo el plan general de desarrollo del
producto.
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