Agile Development Espanol

MANUAL
Agile Development
52
C O M U N I DA D
E S T R AT E G I A S VA L E N C I A N A
CENTROS EUROPEOS DE
EMPRESAS INNOVADORAS
EDICIÓN Centros Europeos de Empresas Innovadoras de la Comunidad Valenciana
(CEEI CV)
DIRECCIÓN Centros Europeos de Empresas Innovadoras de la Comunidad Valenciana

(CEEI CV)
Este manual ha sido elaborado por Aday Francisco Guerra Escohotado de

Nestor&Co.
© 2017 DE ESTA EDICIÓN Centro Europeo de Empresas Innovadoras de Valencia (CEEI Valencia)
Avda. Benjamín Franklin, 12. Parc Tecnològic
46980 Paterna (Valencia)
DISEÑO Debase Estudio Gráfico
MAQUETACIÓN Selket Comunicación
DERECHOS RESERVADOS Queda rigurosamente prohibido, según autorización escrita de los titulares
de Copyright, bajo una sanción establecida por Ley, la reproducción total o
parcial de esta obra por cualquier medio o procedimiento, incluidas la re-
prografía o tratamiento informático y la distribución de ejemplares mediante
préstamo público.

Este Manual se ha editado gracias al apoyo prestado por el IVACE (Instituto

Valenciano de Competitividad Empresarial de la Generalitat Valenciana) a
través del Convenio singular de colaboración para el desarrollo del Programa
de Asistencia al Emprendedor.
52
Agile Development
Manual
Financiado por:
Esta iniciativa está promovida y financiada por la Generalitat Valenciana,

a través del IVACE, dentro de su política de apoyo al emprendimiento y la
www.redceei.com pyme, y cofinanciada por los fondos FEDER de la Unión Europea, dentro del
www.emprenemjunts.es Programa Operativo FEDER de la Comunitat Valenciana 2014-2020
I n d i c e
I n d i c e
I n d i c e
1. INTRODUCCIÓN 7
2. EL MANIFIESTO ÁGIL 8
4.1 EL MANIFIESTO ÁGIL 8
4.2 PRINCIPIOS DEL MANIFIESTO ÁGIL 11
3. GESTIÓN ÁGIL VS GESTIÓN TRADICIONAL 14
4. SCRUM 16
4.1 FRAMEWORK SCRUM 16
4.2 ROLES SCRUM 17
4.3 EVENTOS SCRUM 24
4.4 ARTEFACTOS SCRUM 27
4.5 DEFINICIÓN DE TERMINADO 28
4.5 MÉTRICAS 28
5. PASOS PARA TU PRIMER EQUIPO/PROYECTO SCRUM 33
6. REFERENCIAS 35
estrategias estrategias estrategias estra-
tegias estrategias estrategias estrategias
estrategias estrategias estrategias estrate-
gias estrategias estrategias estrategias es-
trategias estrategias estrategias estrategias
AGILE DEVELOPMENT estrategias estrategias estrategias estrate-
estrategias estrategias estrategias
estrategias estrategias estrategias estrategias
estrategiasestrategias
estrategiases-es
trategias estrategias estrategias
trategias estrategias estrategiasestrategias
estrategias estrategias
estrategias estra-es
trategias estrategias estrategias estrategias estrategias estrategias estrategias estrategia
tegias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrate-
gias estrategias estrategias
estrategias estrategiases
trategias estrategias
estrategias estrategiasestrategias estrategias
estrategias estra
estrategias
tegias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrate
gias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrategia
estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrategias es
trategias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estra
estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrategias es
trategias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estra
INTRODUCCIÓN
01
Con este manual se pretende ayudar a cualquier persona

que vaya a empezar a utilizar un marco de trabajo como es
el Scrum como método de gestión ágil de sus proyectos de
software.
Por eso, a lo largo de estas páginas, se explicará cómo

surge el agilismo como método de gestión de proyectos
software, así como el marco de trabajo Scrum. Para facilitar
su comprensión y validar su puesta en práctica se añaden
una serie de ejercicios y formularios de control.
Aparte de todo lo anterior, se ofrece un proceso paso a paso

de cómo se debería empezar un nuevo proyecto Scrum que
esperamos sea de utilidad a los equipos nuevos que ponen
este marco de trabajo en práctica.
Espero que disfrutéis este manual tanto como yo he dis-

frutado creándolo, y que os sirva a para poder poner en
práctica la gestión de proyectos con métodos ágiles.
7
estrategias
estrategias es-
rategias
trategiasestrategias
estrategias estrategias estrategiasestrategias
estrategias es-
estra-
rategias estrategias
tegias estrategias estrategias
estrategias estrate-
estrategias es-
estrategias
estrategias estra-
estrategias
egias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrate-
gias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrategias
estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrategias es-
rategias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estra-
EL MANIFIESTO ÁGIL
02
2.1 EL MANIFIESTO ÁGIL

El manifiesto ágil se creó como propósito de crear unas
reglas base para entender cómo se caracterizan los pro-
yectos ágiles en todos los aspectos.
Mucha gente cree que este manifiesto fue la base para

la creación de los diferentes marcos de trabajo sobre los
que se ha basado la gestión de proyectos de manera ágil,
como Extreme Programming, Scrum, DSDM, Adaptative
Software Development, Crystal, Feature-Drive Develop-
ment, y otros. Pero en verdad, el Manifiesto Ágil, surge
de las necesidades encontradas por los creadores de
estos marcos de trabajo a la hora de afrontar los proyec-
tos de desarrollo de software, debido a que los métodos
tradicionales no cubrían las necesidades con las que se
enfrentaban. Cada uno de ellos creó su manera más ade-
cuada para solventar los problemas que se encontraban
muy a menudo en sus proyectos.
Para poner en común estos descubrimientos, se decidie-

ron reunir en 2001 en un resort de esquí, en Utah. Y de
sus conversaciones explicando cómo habían solventado
o, mejor dicho, aplacado sus proyectos utilizando cada
sus diferentes métodos.
Aunque no pensaban que podría salir algo realmente im-

portante de aquella reunión, ya que cada uno usaba méto-
dos diferentes. Se sacó un conjunto de valores y princi-
pios básicos a los cuales denominaron Manifiesto Ágil. Y
eso que algunos tenían sus reticencias con el nombre, ya
que los americanos no sabían pronunciar correctamente
agile, que es la palabra para “ágil” en inglés.
8
trategias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estra-
AGILE DEVELOPMENT
estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrategias
Estos valores y principios son la esencia del agilí- Los proyectos se aceptan, dimensionan, y los de-
simo, y las organizaciones tienen que empezar en- ciden las personas y su interactuación. Es esencial
tendiendo, asimilando y poniendo en práctica esto centrarse en las fases tempranas del proyecto, en
valores si quieren tener éxito a la hora de aplicar las personas involucradas y en la manera que van a
métodos agiles en sus organizaciones. interactuar para poder ayudar a configurar las bases
del éxito del proyecto.
En caso contrario, y por desgracia, un problema co-
mún, es que muchas organizaciones escuchan, oyen, Con todo esto no quiere decir que las herramientas
les comentan los beneficios de la gestión ágil de y los procesos no sean necesarios y no ayuden en
proyectos, y en vez de empezar por la comprensión el proyecto, pero hay que tener en cuenta que los
de sus valores y principios, intentan aplicar algún proyecto son, al final, hechos por personas.
framework o marco de trabajo ágil, siendo esto un
gran problema. ya que llevan la gestión a la forzosa Valor 2. Software funcionando sobre documenta-
adaptación de las tareas y a una micro-gestión de ción extensiva
los trabajos de los equipos, en vez en centrarse en
Aquí nos centramos en la necesidad de entregar al
la confianza que se les tiene que dar a los mismos.
cliente. Este valor nos recuerda que el propósito o el
Es esencial que las organizaciones se centren como valor de negocio que estamos intentando entregar es
primeros pasos en entender los valores y principios el producto, no el papeleo.
que se muestran a continuación como base para po-
Es verdad que en ciertas industrias sí se necesita
der aplicar con éxito alguno de los métodos ágiles
mucha documentación, y, en este caso, esta docu-
existentes.
mentación es necesaria para cumplir la legislación
actual, con lo que sí entrega valor. Pero la documen-
Valores del Agilismo tación a la que se hace referencia en este valor es
la documentación que no ayuda a que el trabajo se
Individuos e interacciones sobre procesos y he-
acabe o se haga de manera correcta.
rramientas.
Hay que centrarse en dar producto funcionando y que
Software funcionando sobre documentación exten-
aporte valor, foco del agilismo, más que meros do-
siva.
cumentos descriptivos de cómo debe ser dicho pro-
Colaboración con el cliente sobre negociación con- ducto, aspecto común en los proyectos tradicionales.
tractual.
Valor 3. Colaboración con el cliente sobre nego-
Respuesta ante el cambio sobre seguir un plan. ciación contractual
Es importante acordarse de ser flexibles e intentar

adaptarnos, por encima de ser estrictos y no ser co-
Valor 1. Individuos e interacciones sobre proce- operativos. Muy comúnmente ocurre que lo que se
sos y herramientas define en los estados iniciales al proyecto no tiene
nada que ver con lo que se acaba construyendo. Esto
Aunque los procesos y las herramientas son impor- quiere decir que, si nos forzásemos a crear lo que
tantes, tenemos que hacer que el equipo de desarro- se definió muchas veces, por no decir siempre, en
llo ponga foco en los individuos y las interacciones un estado inicial, acabaríamos creando algo que no
que les involucran. Esto es porque los proyectos los aporta un verdadero valor a nuestros clientes.
llevan adelante las personas, no las herramientas, así
como los problemas son resueltos por las personas y Esto ocurre porque las cosas cambian, cambia el
no por los procesos. mercado, cambian las necesidades, cambia la tecno-
9
logía y no podemos forzar a que lo que se definió en Ejercicio de Valores

un momento no cambie.
Para comprobar que hemos aprendido los valores
Por eso, en vez de que el cliente se tenga que adap- indicados en el Manifiesto Ágil, intenta rellenar los
tar a lo que diga el contrato, lo que tenemos que espacios que se quedan en la imagen que se muestra
hacer desde un primer momento es asimilar y tener a continuación y explica cada una de las sentencias
claro de que las cosas van a cambiar. Porque además a los compañeros.
es extremadamente complicado definir una solución
completa desde un principio y que esta no cambie.
Para que esto funcione bien, lo que tiene que haber

es una relación de verdadera confianza y modelos de
contratos más flexibles de los que actualmente se
suelen ver en los proyectos.
Valor 4. Respuesta ante el cambio sobre seguir

un plan
En proyectos del dominio del conocimiento, sabemos

que los planes iniciales rara vez se cumplen y por
norma suelen ser inadecuados. Esto es debido a que
normalmente se basan en un conjunto insuficiente
de la información necesaria para poder completar el
proyecto.
En vez de intentar forzar las acciones para cumplir

un plan que se prevé desencaminado, los equipos de-
bería esforzarse en adaptarse a los cambios que van
surgiendo en el proceso.
Esto en ningún momento quiere decir que no se nece-

siten planes, por supuesto que se necesitan planes. Lo
que tenemos que aceptar también es que los planes
que podamos tener de un inicio pueden cambiar y que
nos tenemos que adaptar y actualizar en función de
dichos cambios.
10
AGILE DEVELOPMENT
2.2 PRINCIPIOS DEL MANIFIESTO y se trataba y gestionaba para evitarse. Está gestión
no es beneficiosa para los proyectos y es muy pro-
ÁGIL blemática en proyectos de entornos altamente cam-
biantes.
Los firmantes del Manifiesto Ágil siguen y proponen
seguir estos principios, que se muestran y detallan a El agilismo abraza el cambio como una ventaja, en
continuación: vez de buscar la manera de suprimirlo, utilizan méto-
dos ligeros y de alta visibilidad.
Nuestra mayor prioridad es satisfacer al clien-
te mediante la entrega temprana y continua de Entregamos software funcional frecuentemente,
software con valor. entre dos semanas y dos meses, con preferencia
al periodo de tiempo más corto posible.
Este principio abarca mucho; lo primero que tenemos
que hacer es satisfacer a nuestro cliente. No sólo La mejor manera de validar lo creado y nuestro co-
vale con crear documentación o procesos muy bien nocimiento sobre algo es tener feedbacks o comen-
estipulados, necesitamos crear algo que satisfaga a tarios cuanto antes. Si no mostramos lo creado hasta
nuestros clientes. el final, nos estamos haciendo un flaco favor.
Y, además, se debe hacer de manera temprana posi- Este principio se centra en cuán importante es la
ble y con entregas constantes. Esto lo que indica es entrega de software, o producto, funcionando para
que tenemos que estructurar el proyecto para que el poder conseguir comentarios de nuestros usuarios y
equipo de desarrollo pueda entregar valor de manera obtener validaciones lo antes posible. Consiguiendo
fácil, rápida y constante. además que los involucrados en el proyecto estén
mucho más comprometidos.
Los pasos de producción o de entornos de pruebas
reales son el momento de la verdad y en los que te Los responsables de negocio y los desarrollado-
das cuenta de lo que falta y, en muchas ocasiones, no res trabajamos juntos de forma cotidiana duran-
te hubieras dado cuenta hasta llegar ese momento de te todo el proyecto.
la verdad. Esta es una de las razones por las que es
importante hacer entregas tempranas y frecuentes. Los equipos deben conseguir trabajar unidos duran-
te el proyecto, facilitando la comunicación. Esto se
Por último, se debe entregar valor, cuanto antes, y consigue gracias a diferentes tipos de eventos y re-
no trabajo realizado, o documentación. Entendiendo uniones en las que participan, interesados, el dueño
valor por algo por lo que el cliente puede sacar algún de producto y equipos de desarrollo. Con esto se
beneficio por pequeño que sea. consigue potenciar la confianza, la transparencia y el
fluir del conocimiento.
Aceptamos que los requisitos cambien, incluso
en etapas tardías del desarrollo. Los procesos Siempre es mejor una reunión cara a cara en la que
Ágiles aprovechan el cambio para proporcionar se transmite mucho mejor el conocimiento y la infor-
ventaja competitiva al cliente. mación que otros medios menos interactivos como
emails, llamadas de teléfono o mensajes instantáneos.
Los cambios ocurren de manera intrínseca en los
Esta es una manera en la que el conocimiento del
proyectos, y es algo bueno, porque lo que se consigue
dominio del negocio se trasmita de una manera más
es crear el producto que más valor aporta. Los cam-
sencilla entre todos los equipos.
bios nos permiten entregar lo que más importancia y
valor pueden aportar al cliente. Los proyectos se desarrollan en torno a indivi-
duos motivados. Hay que darles el entorno y el
En los procesos tradicionales los cambios de consi-
apoyo que necesitan, y confiarles la ejecución
deraban algo malo y que podía generar altos riesgos,
del trabajo.
11
Está claramente demostrado que equipos expertos y En los procesos tradicionales, por los fallos llevados
altamente motivados son mucho mejores que tener en las estimaciones acaban impactando en los equi-
los mejores procesos y herramientas. pos que acaban teniendo que dedicar jornadas ma-
ratonianas para llegar a la fecha establecida, siendo
Es complicado tener a los mejores equipos, pero esto totalmente contraproducente para el proyecto.
siempre se puede motivar y dar el poder a los equi- Estas horas extras acaban haciendo bajar la calidad
pos. Los equipos trabajan mejor si se les da una auto- de software creado debido al cansancio de los equi-
nomía para seleccionar cómo quieren hacer las cosas, pos.
sin que se les asigne lo que tienen que hacer en cada
momento, como ocurría en los procesos tradicionales. Otro de los problemas de estas tácticas de trabajo
in extremis, es que los equipos acaban descontentos
Esto cobra mucho más sentido cuando estamos tra- y se termina perdiendo personas de alto valor para
tando con trabajos que abarcan el dominio del cono- la organización.
cimiento y que son complejos y se necesita gente
altamente especializada. Estas personas consiguen Con este principio el agilismo lo que sostiene es que
sacar lo mejor de cada uno de ellos si se les deja a se genere soluciones mejores en las que los equipos
ellos tomar las decisiones. puedan mantener un proceso productivo adecuado y
balanceado.
El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus La atención continua a la excelencia técnica y al
miembros es la conversación cara a cara. buen diseño mejora la Agilidad.
Como hemos hablando previamente, la documentación Los equipos no sólo se tienen que centrar en crear
es una buena manera de almacenar un gran volumen las soluciones adecuadas y que den valor al cliente
de información. Pero no es la mejor manera de co- sino también en crear con alta calidad en su cons-
municar y facilitar la comprensión de la información. trucción y haciéndolas lo más optimas posibles.
Las reuniones cara a cara, en cambio, sí son una de En procesos tradicionales en que las estimaciones o
las mejores maneras y más rápidas en las que se las planificaciones no se acomodan con la realidad,
puede transmitir el conocimiento y evitar malenten- el tiempo es lo que primero empieza a faltar. Y con
didos. tiempos escasos, el equipo siempre acaba sacando
soluciones que cubren los mínimos sin que se pien-
El software funcionando es la medida principal se en arquitecturas sólidas, ni en soluciones de alta
de progreso. calidad.
Es interesante el concepto de tener software o pro- La simplicidad, o el arte de maximizar la canti-
ducto funcionando como medida de progreso. Esto dad de trabajo no realizado, es esencial.
hace referencia a dejarnos los documentos o los pro-
cesos que se tenían como una medida del avance de Dos hechos muy importantes: el primero es que las
un proyecto, y utilizar el resultado que da valor como características más fiables son aquellas que no te-
la medición del avance. Está claro que da mucho más nemos que crear, ya que al no tener que hacerlas no
valor si el producto y cuánto del producto está ter- tendrán fallos. Y esto nos lleva al estudio obtenido
minado y funciona que si se tienen los documentos del informe CHAOS en el que se indica que el 45%
de alguna especificación terminados. de las funcionalidades del software no se usan jamás
y que el 19% se usan raras veces. Con lo que un 64%
Los procesos Ágiles promueven el desarrollo de las funcionalidades del software no tienen sentido.
sostenible. Los promotores, desarrolladores y
usuarios debemos ser capaces de mantener un Este volumen de funcionalidades no utilizadas, hacen
ritmo constante de forma indefinida. que lo sistemas sean altamente complejos. Esto es lo
12
AGILE DEVELOPMENT
que hace que el agilismo quiera centrarse en lo que Ejercicio de Principio

realmente da valor a los clientes y hacer soluciones
que se centren en la simplicidad, evitando proyectos Una vez introducidos los principios al equipo, lo que
altamente complejos y que tienen mayor riesgo. interesa es periódicamente, verificar cómo considera
el equipo que está cumpliendo con estos principios.
Las mejores arquitecturas, requisitos y diseños
emergen de equipos autoorganizados. Un miembro del equipo ha de leer el título del prin-
cipio y entre todo el equipo se ha de discutir a qué
La manera de conseguir obtener lo mejor de los equi- nivel del 1 al 10 se cumple ese principio dentro del
pos es dejarles que se auto organicen a la hora de equipo, organización o empresa.
crear las soluciones. Al fin y al cabo ellos son los
expertos y los que están más en contacto y en un Apuntad los resultados obtenidos para cada princi-
nivel de comprensión del proyecto mucho más alto pio y rellena el siguiente gráfico. Guardadlo hasta la
que cualquier otro. siguiente revisión, para verificar el avance que está
teniendo el equipo y la organización en la asimilación
A intervalos regulares el equipo reflexiona so- de los principios agiles. Haciendo el gráfico radial se
bre cómo ser más efectivo para, a continuación, puede ver la progresión de una manera sencilla.
ajustar y perfeccionar su comportamiento en
consecuencia.
Un punto importante es la constante mejora que pro-

pone el agilismo. Si pretendes aprender qué tal ha ido
el proyecto cuando ya está terminado, es demasiado
tarde para mejorar el proceso productivo, el siguiente
proyecto lo más seguro es que no tenga nada que
ver.
La mejor manera es mejorar de manera periódica y

cada poco tiempo, haciendo que los equipos evolu-
cionen a la misma manera que avanza el proyecto.
13
estrategias
estrategias es-
rategias
estrategias es-
estra-
estrategias es-
estrategias
estrategias estra-
estrategias
GESTIÓN ÁGIL VS
GESTIÓN TRADICIONAL
03
En las siguientes gráficas vamos a entender la compa-

rativa entre la gestión de proyectos con agilismo y de
manera tradicional. En dichas gráficas, las líneas rojas
definen a los proyectos tradicionales y las azules los
ágiles.
Visibilidad (visibilidad/tiempo)
En los proyectos tradicio-

nales, durante las fases ini-
ciales del proyecto se tiene
mucho contacto con el clien-
te para entender lo que ne-
cesita, después ya dejan de
tener contacto para crear la
solución que se decidió en
las fases iniciales y que sólo
se muestra al final del todo
cuando está terminada. En la gestión ágil, se le quiere dar
valor al cliente cuanto antes en iteraciones en las que se
reciben feedbacks por eso se ve que hay oscilaciones.
14
AGILE DEVELOPMENT
Valor de Negocio (valor de negocio/tiempo) Adaptabilidad (adaptabilidad al cambio/tiempo)
En relación con el valor La adaptabilidad que per-

de negocio se consigue mite la gestión de los
mucho antes con la en- proyectos con métodos
trega temprana de pro- agiles, nos permite ir
ducto funcionando. En el seleccionando en cada
caso de modelo tradicio- momento lo que es más
nal, hasta que no ha pa- importante o que aporta
sado por todas las fases, más valor al cliente. Por
reducción de requisitos, eso, la linea azul se man-
análisis, diseño, imple- tiene arriba permitiendo
mentación y pruebas, no se puede usar el producto y, más adaptabilidad durante el tiempo. Al contrario, los
por tanto, no da ningún valor de negocio. modelos tradiciones no nos permiten esta adaptación,
ya que nos ceñimos a un camino decidido desde el
Riesgo (Riesgo del proyecto/tiempo) principio y del cual es complicado cambiar.
El riesgo se va minimi- ROI (Retorno de la inversión/tiempo del proyec-
zando muy deprisa en los to)
métodos ágiles porque
enseguida se valida si lo Al poder hacer entregas
que se está haciendo es de producto funcionando
lo que el cliente necesita, en iteraciones más tem-
por eso la línea azul des- pranas, se puede decir en
ciende enseguida después un punto que el producto
de las primeras iteracio- ya cumple las caracterís-
nes. En cambio, en los ticas mínimas para poder
modelos tradicionales, como se aprecia se mantiene sobrevivir en el mercado
el riesgo hasta la entrega, ya que no tiene todo inte- o cubrir las expectativas
grado funcionando hasta el último momento, agrupan- de los clientes. Con lo
do ahí todo el riesgo. que se podría empezar a tener ingresos con él. En
cambio, en los modelos tradicionales lo que ocurre
es que no es comercializable o utilizable hasta que
se entrega, lugar donde termina la primera línea roja.
Ahí es el punto donde se puede empezar a vender
(segunda línea roja). Por eso, los métodos agiles per-
miten llegar antes al ROI.
15
estrategias
estrategias es-
rategias
estrategias es-
estra-
estrategias es-
estrategias
estrategias estra-
estrategias
SCRUM
04
4.1 FRAMEWORK SCRUM

Scrum es un marco de trabajo que lo que pretende es
ayudar a los equipos a poder abarcar y abordar proyecto
complejos, intentando maximizar la entrega de valor.
Es un framework creado por Jeff Sutherland y Ken

Schwaber. Y se caracteriza por que es sencillo de en-
tender, pero complejo de dominar. Este marco de trabajo
está formado por una serie varios procesos y prácticas
que lo que se enfocan en las transparencia, inspección
y adaptación.
- T
ransparencia: los apartados más importantes del
proceso tienen que estar disponibles y visibles para
todos los que son responsables del resultado. Cen-
trándonos en la comprensión de los mismos, mediante
la compartición de un mismo lenguaje.
- Inspección: el equipo ha de revisar y comprobar los

elementos o artefactos de Scrum y poder así detectar
los riesgos o problemas no deseados en la realización
del proyecto. Es importante que la haga el equipo ya
que son los más expertos en el proyecto.
- Adaptación: en el caso de la detección de algún ries-

go o problema, haciendo que el resultado haga posible
la no validez del proyecto, o su desviación, el equipo
deberá hacer el ajuste adecuado, y hacerlo cuanto an-
tes.
16
AGILE DEVELOPMENT
Scrum realiza un conjunto de eventos que fomentan bles para poder sacar el trabajo que van a realizar.
la inspección y adaptación, que son la planificación, Y son auto organizados, no necesitan a nadie que les
el Scrum diario, la revisión y la retrospectiva. diga lo que tienen que hacer, ellos mismos saben cuál
es la mejor opción para realizar el proyecto.
Scrum está divido en tres grandes partes, roles o
perfiles que conforman el equipo Scrum, los eventos El Dueño de Producto (Product Owner)
que nos van a ayudar a hacer esa inspección y adap-
tación. Y un conjunto de herramientas o artefactos Su responsabilidad máxima es realizar un
que nos ayudarán a organizar el trabajo, pendiente, en proyecto que maximice el valor para su
proceso o terminado. negocio. Para poder hacer esto, necesita
tener una visión adecuada de su negocio,
SCRUM estar alineado con su modelo de negocio y
minimizar los riesgos que pueda afrontar el proyecto.
Roles
Dentro de sus deberes y obligaciones están:
Product Owner (Dueño del producto)
- Es el responsable de añadir los elementos nece-
Development Team (Equipo de desarrollo) sarios a la lista de acciones a realizar para el
producto. Añadir elementos a la Pila de Producto.
Scrum Master
- Priorizar la Pila de Producto, centrándose en los
Eventos
objetivos más importantes y que le generen más
El Sprint valor a su organización.
Sprint Planning (La planificación del Sprint) - Encargarse de que el equipo siempre se centre
en las tareas más prioritarias o que más valor
Daily Scrum (Scrum Diario) aportan, haciendo fácil la comprensión, acceso y
transparencia de las tareas que tiene que realizar
Sprint Review (Revisión del Sprint) el equipo de desarrollo.
Sprint Retrospective (Retrospectiva del Sprint) - Es el responsable de qué trabajo es el que va a

realizar el equipo de desarrollo, con lo que tiene
Artefactos que asegurarse de la comprensión de la Pila de
Producto, o poder estar ahí para solventar las du-
Product Backlog (Pila de producto)
das que tenga el equipo en cualquier momento.
Sprint Backlog (Pila del Sprint)
- El dueño del producto debe ser una persona com-
Increment (Incremento) prometido, única y con poder de decisión.
Los riesgos de los dueños de producto son:
- Que no tenga una dedicación completa. En muchas

4.2 ROLES SCRUM ocasiones no le liberan tiempo para poder hacer
las tareas relacionadas con su puesto.
En Scrum se define como equipo Scrum al confor-
mado por tres roles diferentes: el dueño del producto, - Que no sea la persona decisora, que sean muchas
el equipo de desarrollo y el Scrum Master. personas o que no tenga poder. En última instancia
no es el que toma las decisiones, las toma un
Estos equipos tienen las características de que son, comité, un conjunto de gente externa al proyecto
multidisciplinares, tiene todas las habilidades posi-
17
o varios dueños de producto. Esto hace que las

decisiones sean costosas de tomar o que incluso
sean contradictorias y afecten a la fluidez del pro-
yecto o directamente sea un riesgo grave.
- Que sea un proxy. En vez de ser la persona deci-

sora, es un mero intermediario, haciendo que las
comunicaciones no sean fluidas y que, además,
puedan llevar a error, por la típica situación del
teléfono escacharrado.
- Que no sea cercano al equipo. Si el dueño del

producto no es accesible o está distante al equi-
po de desarrollo, no podrá solventar las dudas o
aclaraciones que tenga que hacer sobre la Pila de
Producto y al final el equipo no trabajará sobre lo
que más valor aporta o directamente hará cosas
equivocadas.
Ejercicio Product Owner
Para validar cómo de bien lo está haciendo el dueño de producto, en cada iteración haz que responda a este
cuestionario:
Check List del Dueño de Producto1
Visión del producto
Tengo una visión de producto (creada con clientes, usuarios finales e inversores, cuando es posible).
Puedo responder preguntas sobre la visión del producto y el modelo de negocios de una manera concisa
y motivadora.
Tengo un eslogan corto para la visión del producto, por ejemplo, 1,000 canciones en el bolsillo (iPod en
2001), para comunicar la esencia y el valor del lanzamiento del producto.
Stakeholders
Entiendo las necesidades de mis grupos de interés (por ejemplo, clientes, usuarios finales e inversores).
Me comunico regularmente con mis grupos de interés para entender sus necesidades y gestionar sus
expectativas.
Puedo responder a preguntas sobre cómo cada ítem acumulado del producto generará valor para las
partes interesadas.
1. Por Lekman: https://lekman.fi/productownerchecklist
18
AGILE DEVELOPMENT
Me motiva trabajar como Dueño de Producto y asegurarme de que tengo el mandato y la confianza de
los interesados.
Mis pronósticos para los interesados se basan en la velocidad o el rendimiento medido del equipo de
desarrollo.
Pila de Producto
Tengo una Pila de Producto.
Tengo el mandato de tomar decisiones sobre la Pila de Producto.
Actualizo la Pila de Producto al menos antes de cada reunión de planificación de Sprints.
Los elementos de la Pila de Producto se ordenan (según el valor, el riesgo, las estimaciones de trabajo,
las dependencias, etc).
Los elementos de la Pila de Producto están claramente expresados y son más detallados hacia la parte
superior.
La Pila de Producto está disponible para todos los miembros del equipo de Scrum.
Regularmente refino la Pila de Producto para hacer que la parte superior sea procesable para la próxima
reunión de planificación de Sprint (o entregas).
El equipo de Scrum decide cómo y cuándo se realiza el refinamiento.
Equipo de desarrollo
Estoy disponible para mis desarrolladores durante el Sprint para aclarar los requisitos.
Protejo a mi equipo de desarrollo de cualquier persona que intente cambiar los elementos atrasados del
producto del Sprint.
Solo hay un Dueño de Producto que elige los elementos de la Pila de Producto y los refina con el equipo
de desarrollo. De lo contrario, los desarrolladores no saben a quién escuchar.
Motivo a mi equipo de desarrollo describiendo ocasionalmente mi visión del producto, incluidos los be-
neficios e impactos planificados de la próxima versión o incremento del producto.
Motivo y entreno a mis desarrolladores involucrándolos por escrito y analizando las historias de los
usuarios, cuando es posible (reduciendo así mi propio trabajo).
Confío en las capacidades de desarrollo de mi equipo Scrum. De lo contrario, intentaré generar confianza
ofreciéndoles capacitación, reclutamiento, mejor comunicación, cambios de personal, etc.
Mi equipo de Scrum confía en mi dominio comercial y el conocimiento del usuario final. De lo contrario,
intentaré generar confianza mejorando la comprensión de mi negocio y el del equipo Scrum, así como la
comprensión del usuario final.
Tengo una comprensión similar de la definición de terminado con el equipo de Scrum.
19
Scrum Master
Tengo una buena comprensión y confianza con mi Scrum Master. Si no, trabajo junto con mi Scrum Master
para mejorar nuestra cooperación.
Eventos de Scrum
Participo en las reuniones de planificación de Sprints para seleccionar los ítems pendientes del producto
con el equipo.
Participo en las reuniones de revisión de Sprints, ofrezco y obtengo comentarios constructivos y verifico
cuáles de los elementos atrasados de la Pila del Sprint cumplen con sus criterios de aceptación únicos
y la definición general de Listo.
Participo en reuniones retrospectivas para observar y mejorar mi propio trabajo como Dueño de un
Producto.
Trabajo con mi equipo de desarrollo incluso a diario, cuando es necesario, para aclarar los requisitos,
trabajar en el diseño y optimizar el resultado del Sprint.
He programado eventos de Sprint con Scrum Master (por ejemplo, como eventos de calendario repeti-
tivos).
Mi puntaje actual del Dueño del Producto es _________ / 30 puntos
El equipo de desarrollo Un punto importante es que puede haber componen-

tes del equipo con habilidades especiales, pero la
Es el conjunto de profesionales es- responsabilidad de realizar las tareas de la Pila de
pecializados que van a realizar las Sprint recae sobre todo en el equipo de desarrollo,
tareas más prioritarias de la Pila de no sobre individualidades del equipo. Son todos res-
Producto que generen mayor valor al ponsables.
Dueño de Producto y que las entre-
garán en el siguiente incremento de El tamaño de un equipo de desarrollo tiene que ser
producto, al final de cada iteración. de entre 3 y 9 personas, donde menos de tres puede
afectar a la productividad y a tener todos los perfiles
Los equipos de desarrollo tienen que auto organizarse necesarios para realizar el incremento, y más de tres
y auto gestionarse para conseguir llegar al objetivo tiene el problema de la comunicación y la gestión se
planteado en la iteración. hace más compleja.
Deben de ser auto organizados, nadie tiene que darles Los problemas que se pueden encontrar los equipos
las instrucciones para su organización, ellos mismos de desarrollo son, por ejemplo, estos:
son los responsables en llevar a cabo las tareas se-
leccionadas en la Pila del Sprint. Sin tener roles es- - Que se les fuerce a seleccionar un conjunto dema-
pecíficos, ni sub equipos y teniendo todos los perfiles siado grande de elementos de la Pila de Producto
y habilidades necesarias para poder llevar a cabo las para realizar en la iteración sin dejarles decidir a
tareas que identifican en la iteración. ellos.
20
AGILE DEVELOPMENT
- Que dentro del equipo de desarrollo haya indivi- Scrum Master

dualismos que sólo quieran responsabilizarse de
su parte y no del objetivo del equipo en la itera- Es como un coach de gimnasio, es el
ción. responsable de que los clientes usen
bien las herramientas para que no se
- Que el equipo de desarrollo priorice y organice la hagan daño. En este caso, el Scrum
Pila de Producto en vez de hacerlo en Dueño de Master es el responsable de que
Producto. Scrum se aplique correctamente,
haciendo que todo el equipo lo entienda y lo adopte.
- Que en vez de tomar ellos las decisiones de cómo
hacer las cosas vengan impuestas por el Dueño de Dentro de la organización tiene que ayudar a la adap-
Producto. tación de Scrum y ayudar a planificación de la imple-
mentación de Scrum, transmitiendo el conocimiento
- Que el equipo cuando tenga dudas no las pregunte del framework entre los empleados.
el Dueño de Producto y hagan ellos suposiciones
de lo que se quiere. Es el responsable de eliminar bloqueos que tenga
el equipo para dejar que este se centre en crear la
- No poner foco en la calidad y no cumplir la defini- solución adecuada, siendo una especie de líder sier-
ción de terminado. vo en función del equipo, incluso ayudando en las
interacciones o los eventos del Equipo Scrum para
maximizar el valor creado por el equipo. Al fin y al
cabo, es el encargado de la velar por adaptación a
Scrum del equipo y la organización.
El Scrum Master ayuda al Dueño de Producto con

la gestión de la Pila de Producto, controlando que
cree los elementos que la conforman de manera clara
y concisa, para la fácil comprensión por parte del
equipo. También se centra en ayudarle a organizar y
facilitar los eventos, si así se lo requiere.
También se tiene que centrar en asistir al Dueño de

Producto para que entienda qué es la gestión ágil de
proyectos.
21
Ejercicio de verificación del buen Scrum Master2

Reuniones (Facilitar reuniones para el equipo. Esto incluye)
Ayuda el Scrum Master a Preparar las reuniones.
Ayuda el Scrum Master a Moderar las reuniones.
Ayuda el Scrum Master a Post-procesar la información de las reuniones.
Realizar retrospectivas, que son especiales, por consiguiente, las cuento separadamente.
Dinámicas de equipo
Realizar coaching a los miembros del equipo (por ejemplo, coaching 1a1).
Ayuda a mediar en los conflictos.
Ayudar al equipo en la toma de decisiones.
Ayuda para fomentar la auto-organización del equipo.
Mediar en el conflicto de objetivos entre el equipo de desarrollo (alta calidad técnica) y el Dueño de
Producto (más funcionalidad).
Aprendizaje
Continuar aprendiendo todo lo relativo a Agile (por ejemplo, visitar grupos de comunidades, atender a
conferencias, leer libros, escribir blogs).
Asesorar a los miembros del equipo en todo lo relacionado con Agile.
Ayudar al equipo a crear radiadores de información.
Dar feedback al equipo.
Fomentar el uso de prácticas de ingeniería ágiles dentro del equipo de desarrollo (esto es un enorme
trabajo para invertir el tiempo de un Scrum Master, incluyendo, por ejemplo, publicación/entregas auto-
máticas, entrega continua, TDD, y muchos más).
Desafiar al equipo con nuevas ideas sobre Agile Management.
Colaborar constantemente con otros Scrum Master en la organización (por ejemplo, a través de la co-
munidad de práctica).
Producto
Ayudar a escribir o dividir historias de usuario o elementos de la Pila de Producto o de la Pila del Sprint.
Ayudar a escribir o adaptar la visión del producto.
Ayudar a ordenar los elementos de la pila de producto.
2. Lista creada por Bernd Schiffer.
22
AGILE DEVELOPMENT
Ayudar con la planificación del Sprint. Estar familiarizado con el trabajo del equipo (por ejemplo, el
producto).
Visión general
Juntar a la gente que debería hablarse entre ellos.
Estar en contacto con los Stakeholders regularmente.
Ayudar al equipo a informar a gestión.
Ayudar a fortalecer la comunidad ágil dentro de la organización.
Organizar eventos de intercambio como Open Spaces o World Cafes para el equipo, Stakeholders y el
resto de la organización.
Compartir ideas y análisis en la compañía (micro-blogging, blogging, conferencias internas).
Ser la persona de contacto para todos en el equipo y los Stakeholders en todo lo concerniente a Agile.
Dar oportunidades de aprendizaje a la gente en la organización (por ejemplo, charlas o talleres) y permi-
tirles aprender conceptos Agile importantes como, por ejemplo, la deuda técnica.
Cambio
Ayudar al equipo a eliminar impedimentos.
Sugerir nuevas métricas para el equipo como catalizadores del cambio.
Espejo
Reflejar los valores ágiles y de Scrum al equipo.
Recordar al equipo sus acuerdos (por ejemplo, políticas).
Ayudar al equipo a mejorar constantemente sus procesos.
Reflejar los problemas al equipo a través de la observación desde fuera.
Ayudar a que el equipo se haga preguntas abiertas.
Comprobar los modelos que usa el equipo (por ejemplo, la Pila del Sprint, métricas, etc.) y mostrarles las
diferencias entre el modelo y el mundo real.
Varios
Ayudar al equipo a mantener el foco (por ejemplo, actuando como un buffer entre las distracciones ex-
ternas y el equipo).
Ayudar al equipo a mantener sus herramientas Scrum (paneles, pilas de acciones, gráficas, backlogs,…)
Ayudar al equipo y al dueño de producto para encontrar la Definición de terminado (DoD).
Ayudar al equipo y al dueño de producto para encontrar la Definición de preparado (DoR).
23
4.3 EVENTOS SCRUM Planificación del Sprint
En general, los eventos en Scrum tienen una locali-

zación dentro de la iteración que indica cuándo se
deben llevar a cabo, y tiene una limitación de tiempo
que indica cuándo empieza y cuándo termina.
Los eventos son accesibles por todos. Pero siempre,

están focalizados para algunos miembros específicos
del equipo Scrum.
El Sprint
Es el primer evento que ocurre en el Sprint y tie-

ne una duración de 2 horas por semana de Sprint.
Esta reunión está enfocada para el equipo Scrum. Se
necesitan como elementos básicos para poder reali-
zarla la Pila de Producto priorizada y gestionada por
el Dueño de Producto, teniendo los elementos más
prioritarios listos, estudiados y clarificados para su
fácil comprensión.
En este evento se pretende establecer el trabajo a

realizar en el Sprint. El equipo Scrum ha de responder
a dos preguntas:
Es la iteración que llevarán a cabo en el equipo. Es - ¿Qué es lo que puede entregar como próximo in-
el espacio de tiempo que tienen para la entrega del cremento de producto a realizar en el Sprint que
incremento de producto. Debe limitarse en tiempo, acaba de comenzar? y
siendo de un mes o menos. Esta temporalidad debe
ser consistente, y en ella tiene contenidos los demás - ¿Qué trabajo tiene que hacer para conseguir entre-
eventos. Daily Scrum, Planificación del Sprint, Revi- gar ese incremento?
sión del Sprint y Retrospectiva. La siguiente iteración En la reunión, el equipo de desarrollo hace una es-
empieza justo después de que termine la iteración timación del trabajo que pueden realizar a lo largo
anterior. del siguiente Sprint y el Dueño de Producto les da
No hay Sprints específicos, para hacer tareas de ca- el objetivo esperado y los elementos de la Pila de
lidad o para solventar incidencias. Los Sprints deben Producto que interesan para llegar al objetivo. Entre
tener un objetivo principal puesto por el Dueño de todos se discuten las dudas y se facilita la com-
Producto y este debe permanecer estable. El alcance prensión de los elementos de la Pila de Producto
del Sprint puede renegociarse con el Dueño del Pro- seleccionados. El equipo de desarrollo seleccionará
ducto y el Equipo de Desarrollo a medida que se va el conjunto de elementos que consideren oportuno de
aprendiendo más sobre las tareas. la Pila de Producto. Y entre todos se especificará el
objetivo del Sprint.
Un Sprint sólo es cancelable por el Dueño de Pro-
ducto, y sólo ocurrirá cuando este observe que el Con el objetivo claro, el equipo tiene que estudiar los
objetivo del Sprint está obsoleto. elementos seleccionados para la consecución de ese
24
AGILE DEVELOPMENT
objetivo, para detallar las acciones o tareas que tiene - ¿He detectado algún impedimento que ponga en
que realizar para conseguir completarlos. Si surgiera riesgo que el equipo de desarrollo llegue a conse-
alguna duda se debería consultar con el Dueño de guir el objetivo del Sprint?
Producto.
Problemas que pueden ocurrir en una Daily:
El conjunto de elementos seleccionados de la Pila
de Producto por el equipo para ser realizados en el 1. Ir al detalle de lo realizado el día anterior, ex-
Sprint conforman la Pila del Sprint. Y desde el mo- plicando incluso cómo se ha realizado, esto no
mento de su selección son responsabilidad de todo el es necesario, ya que además de consume mucho
equipo de desarrollo. tiempo, basta con explicar lo hecho para ayudar al
equipo a llegar al objetivo.
Scrum Diario
2. Llegar tarde a la Daily. Es importante mantener
la Daily siempre en el mismo sitio a la misma
hora, por temas de hábitos. Hay que evitar retra-
sos, distrae a la gente.
3. Describir un impedimento o bloqueo al detalle

y discutir la solución durante la Daily. La Daily
es para sincronizarse, dar visibilidad y transparen-
cia, no para solventar los impedimentos. Esto se
hace después de la Daily.
4. Que una persona consuma mucho tiempo. El

equipo debe auto organizarse y gestionarse para
saberse dividir el tiempo que tiene la Daily y que
hablen todos. Esto también incluye que la Daily se
Es un evento de una duración máxima de 15 minu-
extienda, cosa que no debe ocurrir. Si esto ocurre,
tos en la que los miembros del equipo de desarrollo
lo que estamos es haciendo reuniones de segui-
tienen para coordinarse y verificar su estado para la
miento detalladas y este no es el propósito.
consecución del objetivo del Sprint.
Mitos de la Daily:
Para conseguir esto se proponen tres preguntas, que
al final servirán como plantilla para conseguir de- - Se cree que la Daily tiene que ser de pie. Esto
tectar tres cosas, el avance actual, el deseado y los tiene la base que las reuniones de pie son más
posibles problemas para la consecución de objetivo. cortas. Esto es cierto, pero no es un requisito para
Es la manera que tiene el equipo de ver el avance la Daily, sino que dure 15 minutos, y para eso el
para conseguir el objetivo del Sprint. equipo de desarrollo es responsable de su control.
El responsable de que este evento se cumpla es el - Tiene que estar presente el Scrum Master. No,
Scrum Master. Pero es una reunión del equipo de esta reunión no es una reunión de control por par-
desarrollo para el equipo de desarrollo: te del Scrum Master al equipo, es una reunión de
coordinación, para poder inspeccionar y adaptar al
- ¿Qué es lo que he hecho desde el último Scrum
equipo de desarrollo, para el objetivo del Sprint.
Diario para ayudar al equipo de desarrollo a con-
No es necesario que este el Scrum Master, y tam-
seguir el objetivo del Sprint?
poco si está se le tiene que tratar como si se le
- ¿Qué es lo que voy a hacer hasta el próximo estuviera haciendo un reporte.
Scrum Diario para ayudar al equipo de desarrollo
a conseguir el objetivo del Sprint?
25
Revisión del Sprint muestran las soluciones.
Es el momento en el que el Dueño de Producto co-

menta el estado de la Pila de Producto y proyecto,
las fechas de finalización probables y, entre todos, se
conversa sobre qué hacer a continuación en función
de la información aportada por los participantes.
Con toda esta información el Dueño de Producto ac-

tualiza la Pila de Producto para que el equipo pueda
focalizarse en el objetivo que más valor aporte.
Problemas de la Revisión:
Un problema común es que se vuelva una reunión

para echar las culpas los unos a los otros. No se trata
de eso, sino de una reunión para poder ver qué es
Este evento tiene una duración de una hora por se- lo siguiente que se tiene que hacer en función de lo
mana de Sprint. Es uno de los eventos que ocurren que se tiene. Y ver qué se ha realizado en el Sprint
antes de terminar la iteración o Sprint. En este even- anterior.
to el Equipo Scrum muestra el incremento de pro-
ducto a los Stakeholders o personas interesadas en Otro problema es que el Dueño de Producto no quiera
el proyecto que ha convocado el Dueño de Producto. colaborar en la Revisión, el problema que no toma
Este incremento de producto estará formado por las responsabilidad del proyecto a nivel interno de su
tareas que se han realizado en el Sprint centradas organización.
en el Objetivo del Sprint propuesto por el Dueño de
Producto. Estas deben cumplir con la Definición de No se debe enseñar trabajo no terminado, porque no
Terminado que haya definido el equipo. habrá cumplido con los estándares de calidad que
se haya definido el equipo. Hay que esperar a que
Se trata de una reunión informal, no una reunión de la tarea cumpla la Definición de Terminado para ser
seguimiento, en la que se muestra el incremento con potencialmente puesta en producción.
el objetivo de obtener feedbacks o comentarios por
los Stakeholders. Retrospectiva del Sprint
Es responsabilidad del Scrum Master que este evento

se lleve a cabo y tiene las siguientes características
principales.
A la reunión podrá asistir el Equipo Scrum, así como

cualquier interesado en el proyecto que considere el
Dueño de Producto que puede aportar.
En la reunión, el Dueño de Producto será el responsa-

ble de enseñar a los convocados qué se ha terminado
y qué no se ha terminado en el Sprint. Es el momento Es un evento que debe tener una duración de 45
en el cual el equipo de desarrollo indica qué es lo que minutos por semana de Sprint. Es una reunión que se
se ha realizado en el Sprint y enseña el incremento realiza para poder mejorar el Equipo Scrum, por lo
de producto. Se comentan los bloqueos o impedi- que deben estar convocados el Scrum Master, Equipo
mentos encontrados, y si se han podido solventar se de Desarrollo y Dueño de Producto.
26
AGILE DEVELOPMENT
Es el último evento que ocurre antes de terminar el la ayuda del Equipo de Desarrollo. El Equipo Scrum
Sprint. Es responsabilidad del Scrum Master que se decide cuándo se lleva a cabo.
lleve a cabo.
Recordad que la Pila de Producto está ordenada
En esta reunión de mejora del equipo, se tiene que por prioridad, siendo lo que más arriba se encuen-
hacer la inspección de cómo lo hace el Equipo Scrum tra los elementos más importantes. Los elementos
como equipo. Para eso hay que inspeccionar cómo más prioritarios son los que antes deben añadirse al
fue el Sprint que termina, en personas, relaciones, incremento de producto. Los elementos en las posi-
procesos y herramientas. ciones más prioritarias serán los que se abarcarán en
próximos Sprints, por ello son los que más detalle
Se deben identificar lo que ha salido bien para seguir han de tener.
haciéndolo así, identificar que tiene puntos de mejora
y plantear soluciones o posibles actividades para me- La Pila del Sprint
jorar en esos aspectos. Una vez identificado, se han
de poner acciones para conseguir mejorarlo. Es la selección de los ele-
mentos más prioritarios o en
Un consejo en este aspecto es poner métricas para deferencia situados en la par-
poder conocer el índice de mejora. Revisando el ín- te más alta de la Pila de Pro-
dice antes y después del siguiente Sprint se podrá ducto, que el Equipo de Desa-
identificar el flujo. rrollo ha seleccionado con el
propósito de llevarlas a cabo
y añadirlas al incremento del
producto para conseguir cubrir
4.4 ARTEFACTOS SCRUM el objetivo del Sprint.
Son las herramientas con las que trabaja el equipo Es la predicción realizada por el equipo de desarrollo
para mantener la información de lo que tiene que de los elementos de la pila de producto que formarán
hacer, lo que está haciendo y lo que ha hecho de parte del próximo incremento.
manera sencilla.
El equipo es el dueño y auto-gestiona la Pila del
La Pila de Producto Sprint. Se encarga de estudiar los elementos y se
auto organiza para realizarlos. Hace visible y trans-
Es la lista ordenada de todo parente el estado del mismo.
lo que se tiene que abarcar
para que el producto o so- Solo el equipo de desarrollo puede cambiar su pila
luciones se considere ter- del Sprint durante el Sprint.
minada. Es la única fuente
de requisitos. Esta pila Incremento de producto
evoluciona a lo largo del
tiempo para adaptarse a lo Está compuesto por todos
que más valor da. los elementos de la Pila de
Producto que se han reali-
La persona responsable de zado durante el Sprint ac-
la Pila de Producto es el tual y que se añade a todos
Dueño de Producto, que será el que permita añadir los elementos ya termi-
o añada los elementos en la Pila. Esta pila se ha de nados con anterioridad en
refinar, este refinamiento es el momento en el que previos Sprints. Además,
se organiza y detallan los elementos de la pila. Es un estos elementos tendrán
proceso que ha de hacer el Dueño del Producto con que haber cumplido con la
27
definición de terminada propuesta por el equipo. 4.5 MÉTRICAS

En el incremento no entran tareas que no estén ter- Dentro de las métricas más importantes destacan la
minadas. Y es decisión del Dueño de Producto su Velocidad del Equipo y la Gráfica de Quemado.
puesta en producción.
La Gráfica de Quemado o Burndown Chart, mues-
tra el progreso del Sprint. Donde se pueden ver el
volumen de puntos historia, medida que se les suele
4.4 DEFINICIÓN DE TERMINADO poner a los elementos de la pila de producto en el
evento de planificación para indicar el esfuerzo que
Es el conjunto de normas, o procesos, o acciones
se necesita realizar para terminarlo, pendientes de
que se deben realizar para considerar que una tarea
entregar por el equipo, respecto al tiempo que tienen
o elemento de la Pila de Producto tiene la calidad
en el Sprint para hacerlo.
necesaria para considerarse Terminada.
En esta gráfica, el eje de ordenadas muestra el tiem-
Son un conjunto de convenciones o acciones que de-
po que queda del Sprint y el de abscisas muestra
fine el equipo de desarrollo durante el evento de pla-
los puntos historia. La línea roja muestra el número
nificación en función de los elementos seleccionados
de puntos historias pendientes de entregar. La línea
para realizar en el Sprint.
gris muestra la situación ideal. Y las zonas grises
Para que un elemento sobre el que ha trabajado el muestran los días no laborales o fines de semana.
equipo durante el Sprint se considere terminado habrá Hay situaciones en la que el equipo ha detectado que
tenido el equipo realizar lo expuesto en la definición alguna tarea tiene otra que no estaba contemplada y
para poder añadir este elemento al incremento de las añaden con su estimación, esos son los picos de
producto que se le entregará al Dueño del producto. subida de la gráfica roja.
Arriba, ejemplo de Gráfica de Quemado.
28
AGILE DEVELOPMENT
La Velocidad del Equipo es el ratio al cual el equipo

entrega elementos de la pila de producto. Conciendo
la velocidad del equipo se puede saber cuánto valor
se ha entregado hasta la fecha. Se puede estimar
cuándo se podrán entregar ciertos elementos de la
pila de producto y cuántos puntos historia se pueden
entregar para una fecha.
Esta medida se puede calcular de manera sencilla,

son el número de puntos historia, el conjunto del vo-
lumen de esfuerzo que puede cumplir un equipo de
desarrollo, por Sprint.
Una manera manual de hacerlo sería como en la fi-

gura de la derecha:
Gestionado por una herramienta como Jira de Atlassian sería algo así:
Donde las barras grises indican la estimación de puntos que indicó el equipo que iba a sacar y la verde los que
consiguió de hecho sacar al final del Sprint.
29
La Gráfica de Valor también es interesante como

métrica a seguir en los proyectos Scrum.
Es una gráfica parecida a la de quemado, pero acu-

mulativa incremental, en la que se muestra a lo largo
del proyecto el volumen de puntos historia entrega-
dos. Es una gráfica en la que en el eje de ordenadas
se muestran los Sprints y en el de abscisas se mues-
tran en número acumulado Sprint a Sprint de puntos
historias sacados. Lo que se indica con esta gráfica
el valor total entregado con todo el trabajo realizado.
30
AGILE DEVELOPMENT
Check List básico para el marco de trabajo Scrum3
Scrum Core
Entregar software funcionando y probando cada mes o menos.
Entregar lo que da valor a negocio o más.
El proceso se mejora de manera constante.
El Dueño de Producto está definido claramente.
El Dueño de Producto tiene el conocimiento para priorizar.
El Dueño de Producto tiene contacto directo con el equipo de desarrollo.
El Dueño de Producto tiene contacto directo con los interesados (Stakeholders).
El Dueño de Producto habla con una voz (en caso de que sea el Dueño un equipo).
El equipo tiene una Pila de Sprint.
La Pila es altamente visible.
La Pila se actualiza diariamente.
La Pila del Sprint es propiedad única del equipo de desarrollo.
El Scrum Diario ocurre de manera constante y a la misma hora.
Participa todo el equipo en el Scrum Diario.
En el Scrum Diario se mencionan los problemas o impedimentos.
La revisión ocurre al final de cada Sprint.
En la revisión se muestra software funcionando y probado.
En la revisión se recibe retroalimentación de interesados, Stakeholders y el dueño de producto.
Tiene una definición de terminado “DoD”.
La Definición de Terminado es alcanzable dentro de cada iteración.
El equipo respeta la Definición de Terminado.
La retrospectiva ocurre al final de cada Sprint.
En la retrospectiva de definen propuestas concretas de mejora.
Se implementa alguna de las propuestas de mejora de la retrospectiva.

3. Lista creada por Henrik Kniberg.
31
estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrategias es-e
trategias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estra-tr
tegias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrate-tr
gias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrategiase
estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrategiastr
te
g
e
Participan en la retrospectiva el Equipo Scrum (Equipo de Desarrollo, Dueño de Producto y Scrum Master). tr
El Dueño de Producto tiene una Pila de Producto.
te
g
Se priorizan los elementos de la Pila por el valor de negocio que le ve el Dueño de producto. e
Se estiman los elementos. tr
te
Es el equipo de desarrollo el que quiere hacer las estimaciones.
g
Los elementos de la Pila de Producto son lo suficientemente pequeños para poder ser abordados en un
Sprint.
El Dueño de Producto entiende el propósito de todos los elementos de la Pila de Producto.
Tienen reuniones de planificación del Sprint.
Participa el Dueño de Producto para ser consultado en la planificación.
El Dueño de Producto lleva la Pila de Producto actualizada a la planificación.
Participa el equipo completo en la planificación.
El resultado es el plan del Sprint o la Pila del Sprint.
El equipo completo cree que el plan es alcanzable.
El Dueño de producto está satisfecho con las prioridades y el objetivo del Sprint obtenido de la plani-
ficación.
Son las iteraciones o Sprints de tiempos fijos menores de un mes.
La longitud del Sprint es de 4 semanas o menos.
El Sprint siempre dura lo mismo.
El Sprint siempre termina a tiempo.
El equipo no es interrumpido o controlado por externos.
El equipo normalmente entrega lo que se comprometió a hacer en la planificación.
El equipo de desarrollo se sienta junto.
El equipo de desarrollo es de máximo 9 personas y mínimo de 3.
32
estrategias
estrategias es-
rategias
estrategias es-
estra-
estrategias es-
estrategias
estrategias estrategias AGILE
estrategias
estrategias DEVELOPMENT
estrategias estra-
estrategias
PASOS PARA TU PRIMER
EQUIPO/PROYECTO SCRUM
05
Organización quiere crear un proyecto con Scrum
Dentro de la organización se decide hacer un proyec-

to utilizando Scrum. Lo primero, una vez asimilados los
principios y valores, se ha de seleccionar al que será el
Dueño de Producto. Responsable del proyecto.
Creación de la Pila de Producto
El Dueño de producto con los Stakeholders crea la pri-

mera versión de la pila de Producto.
El Dueño de Producto debe juntarse con los Stakeholders,

o todas las personas involucradas para, estando alineado
con el modelo de negocio de su organización, cree los
primeros elementos de la pila de producto.
Selección del equipo de desarrollo, Scrum Master y

duración del Sprint
El Dueño de Producto selecciona al equipo de desarrollo.

Una vez seleccionado, estos tienen que revisar que tiene
los componentes necesarios para poder trabajar en el
proyecto. También se encarga de seleccionar al Scrum
Master. En este momento el equipo con el Scrum Master
y el Dueño de Producto deciden la duración que va a
tener el Sprint.
33
estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrategias es-e
trategias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estra-tr
tegias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrate-tr
gias estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrategiase
estrategias estrategias estrategias estrategias estrategias estrategias estrategias estrategiastr
te
g
e
Empieza el primer Sprint terminados. El equipo explica qué es lo que han hecho tr
y qué impedimentos se han encontrado. Los Stakehol- te
Con el equipo Scrum ya montado debe empezar el ders dan sus comentarios sobre el incremento para
primer Sprint. Empieza con la primera planificación. que el Dueño de Producto pueda priorizar.
g
Deben ir seleccionando los elementos más impor- e
tantes de la pila de producto para estudiarlas y es- Hacer grooming o actualización de la Pila de tr
timarlas. Al terminar tiene que definir cuál va a ser Producto
su Definición de Terminado y la Definición de Listo. te
La definición de listo sirve para ver que una tarea se Una tarea importante que se ha de realizar antes de g
puede empezar a trabajar en ella porque tiene todos que se acabe el Sprint es después de haber recibido
los requisitos necesarios para ello. los feedback o comentarios por partes de los Stake-
holders o personas interesadas en la revisión, se ha
Empieza el trabajo del Sprint de actualizar la Pila de Producto. El Scrum Master
ha de ayudar al Dueño de producto en esta tarea,
En el proceso del Sprint, se han de hacer las re- revisando que los elementos que están generan el
uniones de Scrum Diarias para coordinar al equipo y valor de negocio esperado, re-priorizar y las más
poder identificar impedimentos. El equipo de desa- prioritarias analizarlas a mayor nivel para que sean
rrollo tiene que autogestionarse para realizar las ta- lo suficientemente claras. Así hasta el principio del
reas asociadas a los elementos seleccionado para el siguiente Sprint.
Sprint y que van a cumplir con el objetivo del dueño
de producto. Deben actualizar su panel o herramienta Hacer la retrospectiva del Sprint
donde gestionen las tareas.
Se ha de revisar cómo lo ha hecho el equipo Scrum,
Preparar la revisión del Sprint para eso haremos una reunión de retrospectiva. En
esta reunión debemos ponernos en situación con los
Cuando el Sprint está a punto de terminar se tiene datos, vemos qué ha ido bien, para poder seguir ha-
que preparar la revisión del incremento de produc- ciéndolo bien o incluso mejorarlo. Qué ha ido mal
to que va incluir todos los elementos terminados. El para poder aprender y mejorar en esos aspectos. Y
Dueño de Producto tiene que estar informado para en qué punto principal queremos mejorar con alguna
poder ser él el que lleve la reunión. El Dueño de Pro- de las acciones que va a llevar a cabo el equipo para
ducto tiene que convocar a todas las personas que conseguirlo.
deben acudir para la revisión del incremento.
Si ha habido alguna retrospectiva previa antes se tie-
Hacer la revisión del Sprint ne que revisar cómo han ido las acciones propuestas.
Se ha de revisar el incremento de producto. Se mues- Vuelta a empezar al Sprint
tra sólo los elementos de la pila del Sprint que estén
Volvemos a empezar en el punto 4.
34
estrategias
estrategias es-
rategias
estrategias es-
estra-
estrategias es-
estrategias
estrategias estrategias AGILE
estrategias
estrategias DEVELOPMENT
estrategias estra-
estrategias
REFERENCIAS
06
Guía de Scrum - Scrum.org – scrumguide.com – Ken

Schwaber y Jeff Sutherland - Octubre 2017:
http://www.scrumguides.org/docs/scrumguide/
v2017/2017-Scrum-Guide-US.pdf
The Unofficial Scrum Checklist - Henrik Kniberg:
https://www.crisp.se/wpcontent/uploads/2012/05/
Scrum-checklist.pdf
42 Tasks for a Scrum Master’s Job – Bernd Schiffer:
http://agiletrail.com/2011/11/14/42-tasks-for-a-
scrum-masters-job/
An Example Checklist Product Owner - Lare Lekman:
https://scrumwell.files.wordpress.com/2013/09/pro-
duct-owner-checklist-november-2013.pdf
Versión One – The Benefits of Agile Software Develop-

ment:
https://www.versionone.com/agile-101/agile-software-
development-benefits/
Manifiesto Ágil – Varios autores:
http://agilemanifesto.org/iso/es/manifesto.html
35

Agile Development Espanol

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Development Espanol

Uploaded by

Copyright:

Available Formats

MANUAL

DIRECCIÓN Centros Europeos de Empresas Innovadoras de la Comunidad Valenciana

Este manual ha sido elaborado por Aday Francisco Guerra Escohotado de

DISEÑO Debase Estudio Gráfico

MAQUETACIÓN Selket Comunicación

Este Manual se ha editado gracias al apoyo prestado por el IVACE (Instituto

Esta iniciativa está promovida y financiada por la Generalitat Valenciana,

3. GESTIÓN ÁGIL VS GESTIÓN TRADICIONAL 14

5. PASOS PARA TU PRIMER EQUIPO/PROYECTO SCRUM 33

Con este manual se pretende ayudar a cualquier persona

Por eso, a lo largo de estas páginas, se explicará cómo

Aparte de todo lo anterior, se ofrece un proceso paso a paso

Espero que disfrutéis este manual tanto como yo he dis-

2.1 EL MANIFIESTO ÁGIL

Mucha gente cree que este manifiesto fue la base para

Para poner en común estos descubrimientos, se decidie-

Aunque no pensaban que podría salir algo realmente im-

Es importante acordarse de ser flexibles e intentar

logía y no podemos forzar a que lo que se definió en Ejercicio de Valores

Para que esto funcione bien, lo que tiene que haber

Valor 4. Respuesta ante el cambio sobre seguir

En proyectos del dominio del conocimiento, sabemos

En vez de intentar forzar las acciones para cumplir

Esto en ningún momento quiere decir que no se nece-

que hace que el agilismo quiera centrarse en lo que Ejercicio de Principio

Un punto importante es la constante mejora que pro-

La mejor manera es mejorar de manera periódica y

En las siguientes gráficas vamos a entender la compa-

En los proyectos tradicio-

Valor de Negocio (valor de negocio/tiempo) Adaptabilidad (adaptabilidad al cambio/tiempo)

En relación con el valor La adaptabilidad que per-

4.1 FRAMEWORK SCRUM

Es un framework creado por Jeff Sutherland y Ken

- Inspección: el equipo ha de revisar y comprobar los

- Adaptación: en el caso de la detección de algún ries-

Sprint Retrospective (Retrospectiva del Sprint) - Es el responsable de qué trabajo es el que va a

Los riesgos de los dueños de producto son:

- Que no tenga una dedicación completa. En muchas

o varios dueños de producto. Esto hace que las

- Que sea un proxy. En vez de ser la persona deci-

- Que no sea cercano al equipo. Si el dueño del

Ejercicio Product Owner

Check List del Dueño de Producto1

Visión del producto

1. Por Lekman: https://lekman.ﬁ/productownerchecklist

Tengo una Pila de Producto.

Tengo el mandato de tomar decisiones sobre la Pila de Producto.

Actualizo la Pila de Producto al menos antes de cada reunión de planificación de Sprints.

El equipo de Scrum decide cómo y cuándo se realiza el refinamiento.

Tengo una comprensión similar de la definición de terminado con el equipo de Scrum.

Mi puntaje actual del Dueño del Producto es _________ / 30 puntos

El equipo de desarrollo Un punto importante es que puede haber componen-

- Que dentro del equipo de desarrollo haya indivi- Scrum Master

El Scrum Master ayuda al Dueño de Producto con

También se tiene que centrar en asistir al Dueño de

Ejercicio de verificación del buen Scrum Master2

Ayuda el Scrum Master a Preparar las reuniones.

Ayuda el Scrum Master a Moderar las reuniones.

Ayuda el Scrum Master a Post-procesar la información de las reuniones.

Ayuda a mediar en los conflictos.

Ayudar al equipo en la toma de decisiones.

Ayuda para fomentar la auto-organización del equipo.

Asesorar a los miembros del equipo en todo lo relacionado con Agile.

Ayudar al equipo a crear radiadores de información.

DIRECCIÓN Centros Europeos de Empresas Innovadoras de la Comunidad Valenciana

Este manual ha sido elaborado por Aday Francisco Guerra Escohotado de

Este Manual se ha editado gracias al apoyo prestado por el IVACE (Instituto

3. GESTIÓN ÁGIL VS GESTIÓN TRADICIONAL 14

2.1 EL MANIFIESTO ÁGIL

4.1 FRAMEWORK SCRUM

- Inspección: el equipo ha de revisar y comprobar los

- Adaptación: en el caso de la detección de algún ries-