Scrum Manager - convocatoria

programada
Informacin e instrucciones del
curso

INFORMACIN E
INSTRUCCIONES DEL CURSO
OBJETIVO
Adquirir un conocimiento amplio de Scrum: Partiendo del origen del modelo y los
principios que lo hacen funcionar, el curso ensea con detalle, a travs de
lecciones guiadas y realizacin de prcticas, los componentes y las reglas que
constituyen el marco tcnico de scrum, junto con las razones y consideraciones
necesarias para trabajar con Scrum.
Una vez conocidas, el curso muestra la forma de evolucionar una implantacin
estndar de scrum a implementaciones ms pragmticas y fluidas.

Introduccin.
Descripcin de Scrum y de los elementos que lo componen.

Pila del producto (product backlog).

Planificacin del sprint (reunin).

Pila del sprint (sprint backlog).

El incremento.

Reunin de seguimiento diario.

Roles y responsabillidades para la ejecucin del proyecto.

Reunin de revisin del sprint.

Mtrica, estimaciones y velocidad.

Las unidades.

Grfico de avance (burn down).

Grfico de producto (burn up).

Estimacin de pquer.

Kanban y Lean. Origen y principios.

Trabajando con tableros kanban: conceptos.

Trabajando con tableros kanban: operativa.

Kanban Box.

Muda, Mura y Muri. Consejos para ajustar el flujo de tareas

Metodologas de gestin de proyectos, vistas desde su mapa de

coordenadas

Incremento iterativo e incremento continuo.

Conceptos y patrones de gestin de proyectos.

Personas, procesos y tecnologa

Responsabilidades de Scrum a nivel de gestin.

AL TERMINAR EL CURSO
Se conoce el marco tcnico de Scrum con el nivel propio de un curso de
capacitacin para el rol de Scrum Master.
Adems se conocen tambin los criterios y principios necesarios para desarrollar
implementaciones de scrum pragmticas, optimizadas para proyectos y equipos
concretos, y con un alcance de agilidad global en la organizacin, ms all del
simple mbito de la gestin de proyectos.
Al terminar el curso dispondr de la base de conocimiento de scrum necesaria
para:

Trabajo en equipos scrum.

Gestin en organizaciones que emplean scrum.

Propietario o responsable de producto.

Gestin de equipos y proyectos con scrum.

Implementacin y mejora del modelo.

Seguimiento y autogestin en equipos de scrum.

EVALUACIN Y ACREDITACIN
El rea de evaluacin y acreditacin es de acceso voluntario para los alumnos
matriculados en el curso.
La realizacin correcta acumula 150 puntos de autoridad acadmica (PDAs) Scrum
Manager.

OPERATIVA
El objetivo del curso es conocer y comprender los contenidos que estn disponibles
tanto en las lecciones del rea "Lecciones" y en el libro del curso, que se
encuentra disponible en la seccin "Documentacin".
El libro del curso resulta til para su consulta off-line, pero es recomendable hacer
el seguimiento de las lecciones.
Las lecciones en lnea incluyen preguntas para reforzar el aprendizaje y comprobar
su comprensin.
Para acceder a una leccin es necesario haber completado la anterior.
El formato e-learning permite dedicar el tiempo y momento del da ms apropiado
para cada uno; y para que resulte compatible con casi cualquier actividad, el
calendario se ha estimado con bastante holgura, suponiendo una dedicacin de
tiempo medio inferior a una hora diaria. Por supuesto se puede realizar en menos
das, con un ritmo ms rpido.
Cualquier consulta o tema de discusin lo puedes plantear en el foro en el rea de
comunicacin.
Para acreditar el aprendizaje de los contenidos de este curso, puedes realizar las
pruebas que estarn disponibles los tres ltimos das, y si las apruebas podrs
sumar 150 puntos de autoridad a la acreditacin acadmica de Scrum Manager
(PDAs)

PARTICIPACIN ACTIVA
Desde Scrum Manager hacemos lo posible para que este curso resulte lo ms
enriquecedor posible, pero no olvides que el principal valor de una formacin on
line no est tanto en la plataforma o el material, sino en la participacin y debate.
En el conocimiento que se genera de la conversacin.
Somos conscientes de que esta formacin de e-learning se compagina con
jornadas de trabajo, y el tiempo es limitado; pero en la medida de lo posible, os
animamos a participar en el foro de preguntas y discusiones en clase y en el del
curso preguntando las dudas que tengis, y aportando a las dudas planteadas por
otros.

Gracias!

AREAS DEL CURSO E INSTRUCCIONES

Una vez matriculado en el curso (http://www.scrummanager.net/oks) puedes
acceder a las secciones que lo componen:

rea de comunicacin
Se encuentra:

"Novedades": Es el tabln de anuncios y novedades del curso.

"Foro del curso": salo para plantear las consultas o dudas sobre cualquier
tema o aspecto del curso, as como para responder o debatir con las preguntas
del profesor o de otros compaeros.

Al estar matriculado en el curso, ests suscrito por defecto a los mensajes de estos
foros, lo que quiere decir que recibirs por correo las notificaciones de los temas
que se vayan abriendo.
Si no fuera as, por favor revisa la configuracin del filtro de correo no deseado, por
si los estuviera bloqueando.

Lecciones
En esta seccin est el contenido de formacin, dividido en lecciones, que incluyen
preguntas de confirmacin al final de cada una.

Para pasar a una leccin es necesario haber respondido las preguntas de

revisin de la leccin anterior.
Cada leccin se puede repetir hasta un mximo de 6 veces

El calendario previsto para el curso prev un ritmo de estudio de una leccin al da,
y el tiempo mximo de dedicacin para cada una no debera exceder de un cuarto
de hora o veinte minutos.
Los contenidos de las lecciones los puedes consultar tambin en el texto de
apuntes disponible en el rea de documentacin.

Documentacin
Aqu dispones del libro con el temario del curso.

Prcticas.
En esta seccin iremos realizando diversas prcticas a lo largo del curso.

Evaluacin
Realizando el examen de evaluacin puedes comprobar y acreditar el
aprovechamiento del curso, y es de ejecucin voluntaria.
Si realizas el examen y obtienes la calificacin de 8 o ms (sobre 10) obtendrs la
acreditacin de 150 PDAs de Scrum Manager.
Informacin sobre la acreditacin de este curso para los participantes
que hayan realizado otros cursos de Scrum Manager en un periodo
inferior a dos aos.
1.- De igual forma que el conocimiento que no se practica ni actualiza se va
perdiendo, el nivel de acreditacin de Scrum Manager se mantiene durante el
primer ao, y luego se va reduciendo un 20% anual.
2.- Para mantener el nivel de acreditacin al da se puede realizar de nuevo un
curso o examen, una vez transcurridos 2 aos desde la ltima vez que se realiz.
Al repetir un curso o examen los puntos obtenidos son los proporcionales para
recuperar el nivel perdido. De esta forma la repeticin del examen:

En menos de dos aos -> no incrementa la autoridad registrada.

En menos de 5 aos (y ms de dos) -> incrementa la autoridad en el 50%
de la puntuacin fijada para ese curso.

Si se hizo el curso hace ms de 5 aos se contabiliza toda la puntuacin de

autoridad del curso.

Preguntas frecuentes sobre formacin.

Referencias e informacin
adicional
A lo largo del curso iremos publicando en este rea artculos y documentacin para
ampliar los conceptos que vayamos viendo.
ltima modificacin: sbado, 30 de enero de 2016, 15:55

Hola a todos!
Algunos ya habris hecho el examen y espero que tambin aprobado :-)
Como sabris, si aprobis el examen estaris "acreditados" en el nivel de
conocimiento del curso. Hay una diferencia entre "acreditacin" y "certificacin",
en la primera Scrum Manager no ha podido verificar la identidad de la persona
registrada, y se basa por tanto en la buena fe de su titular, y en la segunda, al
pasar por un examen presencial, la identidad queda verificada. En la pgina sobre
certificaciones podis encontrar ms informacin al respecto.
A quines interese certificarse informaros que el examen de certificacin puede
realizarse presencialmente concertando fecha y hora en un centro examinador
Scrum Manager(*), o con supervisin web (prueba monitorizada audiovisualmente
con webcam) concertando con los centros examinadores que ofrecen esta
modalidad.
Si sois un grupo tenemos examinadores que podramos enviar a vuestra empresa.
Si queris ms informacin como cuidad, convocatorias, precio, etc. podis
dirigiros al contacto del centro o a m. Me podis preguntar o bien a travs del foro
estos ltimos das o por email a alexander.menzinsky@scrummanager.net.
Y a quin quisiera certificarse en Madrid y hacerlo conmigo puede contactarme en
alexander.menzinsky@estratecno.es. En Estratecno empezamos una hora antes del
examen para hacer un repaso para asentar los conceptos clave y resolver las
dudas que podis tener.
Atencin!!! El examen de certificacin abarca el curso troncal de Scrum
Manager, aunque sea recomendable, no es necesario haber cursado el curso online, siempre encontraris los apuntes del curso en nuestro Body of Knowledge.
Encantado de haberos tenido de alumnos y desearos mucha suerte,

Alexander
(*) Actualmente disponibles en Espaa.

Introduccin
El entorno de trabajo de las empresas del conocimiento se parece muy poco al que
origin la gestin de proyectos predictiva. Ahora se necesitan estrategias para el
lanzamiento de productos orientadas a la entrega temprana de resultados
tangibles, y a la respuesta gil y flexible, necesaria para trabajar en mercados de
evolucin rpida.
Ahora se construye el producto mientras se modifican y aparecen nuevos
requisitos. El cliente parte de una visin medianamente clara, pero el nivel de
innovacin que requiere, y la velocidad a la que se mueve su sector de negocio, no
le permiten predecir con detalle cmo ser el resultado final.
Quiz ya no hay productos finales, sino productos en continua evolucin y
mejora.
La gestin de proyectos gil no se formula sobre la necesidad de
anticipacin, sino sobre la de adaptacin continua.

El Manifiesto gil

En marzo de 2001, 17 crticos de los modelos de produccin basados en procesos,

convocados por Kent Beck, que haba publicado un par de aos antes el libro en el
que explicaba la nueva metodologa Extreme Programming (Beck, 2000) se
reunieron en Salt Lake City para discutir sobre el desarrollo de software. En la
reunin se acu el trmino Mtodos giles para definir a aquellos que estaban

surgiendo como alternativa a las metodologas formales: CMM-SW, (precursor de

CMMI) PMI, SPICE (proyecto inicial de ISO 15504), a las que consideraban
excesivamente pesadas y rgidas por su carcter normativo y fuerte dependencia
de planificaciones detalladas, previas al desarrollo.
Los integrantes de la reunin resumieron en cuatro postulados lo que ha quedado
denominado como Manifiesto gil, que son los valores sobre los que se asientan
estos mtodos.
Hasta 2005, entre los defensores de los modelos de procesos y los de modelos
giles fueron frecuentes las posturas radicales, ms ocupadas en descalificar al
otro, que en estudiar sus mtodos y conocerlos para mejorar los propios

Los cuatro valores del Manifiesto gil

Estamos poniendo al descubierto mejores mtodos para desarrollar
software, hacindolo y ayudando a otros a que lo hagan.
Con este trabajo hemos llegado a valorar:

A los individuos y su interaccin, por encima de los procesos y las

herramientas.
El software que funciona, por encima de la documentacin
exhaustiva.
La colaboracin con el cliente, por encima de la negociacin
contractual.

La respuesta al cambio, por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos ms los de

la izquierda.

Los 12 principios del Manifiesto gil.

El manifiesto gil, tras los cuatro postulados anteriores de, en los que se
fundamenta, desarrolla 12 principios, que definen la agilidad en proyectos de
software, con independencia de la metodologa o prcticas giles que se empleen.
Ellos son:
1.

Nuestra principal prioridad es satisfacer al cliente a travs de la entrega

temprana y continua de software de valor.
2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al
desarrollo. Los procesos giles se doblegan al cambio como ventaja
competitiva para el cliente.

3.

Entregar con frecuencia software que funcione, en periodos de un par de

semanas hasta un par de meses, con preferencia en los periodos breves.

4.

Las personas del negocio y los desarrolladores deben trabajar juntos de

forma cotidiana a travs del proyecto.

5.

Construccin de proyectos en torno a individuos motivados, dndoles la

oportunidad y el respaldo que necesitan y procurndoles confianza para que
realicen la tarea.

6.

La forma ms eficiente y efectiva de comunicar informacin de ida y vuelta

dentro de un equipo de desarrollo es mediante la conversacin cara a cara.

7.
8.

9.

El software que funciona es la principal medida del progreso.

Los procesos giles promueven el desarrollo sostenido. Los patrocinadores,
desarrolladores y usuarios deben mantener un ritmo constante de forma
indefinida.
La atencin continua a la excelencia tcnica enaltece la agilidad.

10. La simplicidad como arte de maximizar la cantidad de trabajo que se hace,

es esencial.
11. Las mejores arquitecturas, requisitos y diseos emergen de equipos que se
autoorganizan.
12. En intervalos regulares, el equipo reflexiona sobre la forma de ser ms
efectivo y ajusta su conducta en consecuencia.

Origen de los principios de Scrum en

proyectos de software.
Scrum es un modelo de desarrollo gil caracterizado por:

Adoptar una estrategia de desarrollo incremental en lugar de tradicional de

planificacin y ejecucin completa del producto.
Confiar la calidad del resultado ms al conocimiento tcito de las personas
que trabajan en equipo, que a la calidad de los procesos empleados.
Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una
tras otra en un ciclo secuencial o de cascada.

Este modelo de desarrollo fue identificado y definido por Ikujiro Nonaka e Hirotaka
Takeuchi a principios de los 80, al analizar la forma en la que desarrollaban los

nuevos productos las principales empresas de manufactura tecnolgica: Fuji-Xerox,

Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard. Los autores del estudio
expusieron este modelo de desarrollo en el artculo que dio origen al trmino y
concepto Scrum: New New Product Development Game.

The New New Product Development Game es el ttulo del artculo publicado en
1986 por Hirotaka Takeuchi e Ikujijo Nonaka; que a su vez daba continuacin a otro
anterior de los mismos autores junto con Kenichi Imai: Managing the New Product
Development Process: How Japanese Companies Learn and Unlearn.
En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo,
con el avance en formacin de scrum de los jugadores de Rugby, a raz de lo cual
qued acuado el trmino scrum para referirse a ella.

Aunque esta forma de trabajo surgi en empresas de productos tecnolgicos, es

apropiada para proyectos con requisitos inestables y para los que requieren
rapidez y flexibilidad, situaciones frecuentes en el desarrollo de determinados
sistemas de software.
Muchas compaas han descubierto que para mantenerse en el actual mercado
competitivo necesitan algo ms que los conceptos bsicos de calidad elevada,
costes reducidos y diferenciacin. Adems de esto, tambin es necesario velocidad
y flexibilidad.
En 1981 las encuestas realizadas a 700 empresas americanas revelan que el 30%
de sus beneficios se debe a nuevos productos.
Hasta entonces, el desarrollo de nuevos productos se realizaba como una carrera
de relevos, en la que un grupo de especialistas funcionales pasaban el relevo al
siguiente.
El proyecto avanzaba secuencialmente de fase en fase: creacin del concepto,
pruebas de viabilidad, diseo del producto, diseo del proceso, desarrollo de
prototipo y produccin final.

Es un modelo de trabajo segmentado por especializacin de funciones.

La gente de marketing explora y estudia las necesidades de los clientes, para crear
el concepto del producto. Los ingenieros de investigacin y desarrollo elaboran un
diseo adecuado, los ingenieros de produccin llevan a cabo la solucin tcnica
Nonaka y Takeuchi observaron que empresas americanas y japonesas tecnolgicas,
de primera lnea, que aventajaban a sus competidores en innovacin y rapidez,
compartan pautas de trabajo comunes, ajenas al clsico patrn secuencial.
Analizaron la forma de trabajo de: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother,
3M, Xerox y Hewlett-Packard y en concreto la forma en la que abordaban el
desarrollo de 6 productos:

La fotocopiadora Fuji-Xerox FX3500. (1978)

La copiadora personal Canon PC-10 (1982)

El coche urbano de 1200cc de Honda (1981)

El ordenador personal NEC PC 8000 (1979)

La cmara Canon AE-1 (1976)

Cmara Canon Auto Boy (1979).

En estas empresas el trabajo no recorra fases a travs de diferentes equipos

especializados.
El producto emerge de la interaccin constante de un equipo de lite,
multidisciplinario que trabaja conjuntamente desde el principio hasta el final

Cul de las siguientes caractersticas detectaron Nonaka y Takeuchi en

1986 los entornos de trabajo a los que ellos llamaron Campos de Scrum?

Gestin de producto distribuida

Segmentacin del trabajo y especializacin de funciones
Un equipo nico multifuncional
Presencia de gestores de proyecto especiallizados, para garantizar las fechas
de entrega.

Aunque las prcticas observadas por Nonaka y Takeuchi surgieron en empresas de

productos tecnolgicos, en general son apropiadas para entornos que trabajan con
requisitos inestables y que requieren rapidez y flexibilidad, situaciones frecuentes
en el desarrollo de determinados sistemas de software.
En 1995 Ken Schwaber present Scrum Development Process en OOPSLA 95
(Object-Oriented Programming Systems & Applications conference) (SCRUM
Development Process), un marco de reglas para desarrollo de software, basado en
los principios de scrum, y que l haba empleado en el desarrollo de Delphi, y Jeff
Sutherland en su empresa 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)
En este curso cubre scrum tcnico, basado en la aplicacin de reglas concretas en
un marco de roles, eventos y artefactos definidos. El aprendizaje de scrum tcnico
es el primer paso aconsejable para familiarizarse con la agilidad.
Una vez iniciados en agilidad, y con el conocimiento que el propio equipo acumula
a travs de las retrospectivas, se pueden ir rompiendo las reglas y adoptar scrum
pragmtico, personalizado y ms adecuado a las propias circunstancias del propio
equipo y proyecto.

NIVELES DE SCRUM
1.- Reglas

2.- Valores

Marco de reglas para desarrollo de

software.
Autores: Ken Schwaber y Jeff
Sutherland
(Origen: "Scrum Development Process
OOPSLA'95" 1995)

Concepto original Scrum.

Autores: Hirotaka Takeuchi e Ikujiro
Nonaka
(Origen: "The New New Product Development
Game" 1986)

Reglas definidas

Roles

Valores giles...

Personas > procesos

Resultado > documentacin

Dueo de producto
Equipo de desarrollo

Colaboracin > negociacin

Scrum Master

Cambio > planificacin

Eventos

Sprint

Reunin de planificacin

Scrum diario

Revisin de sprint

Retrospectiva de sprint

Artefactos

Pila de producto

Pila de sprint

Incremento

... "Para avanzar

en Scrum"

Incertidumbre
Autoorganizacin

Fases de desarrollo solapadas

"Mutiaprendizaje"

Control sutil

Difusin del conocimiento

Scrum tcnico

Scrum pragmtico

Para avanzar guiados por reglas

Para avanzar en scrum, sin reglas.

Equipos autoorganizados asesorados por un

Scrum Master

Equipos autoorganizados sin Scrum Master

.
Scrum se comenz a aplicar tambin en el desarrollo de software a raz
de:
La publicacin del artculo The New New Product Development Game en 1986
La presentacin de Jeff Sutherland y Ken Schwaber como proceso en OOPSLA
95.
La publicacin de Scrum en el Manifiesto gil en 2001

El marco tcnico de scrum, por su sencillez, resulta apropiado para equipos y

organizaciones que quieren comenzar a avanzar en scrum
Est formado por un conjunto de prcticas y reglas que resultan vlidos para dar
respuesta a los siguientes principios de desarrollo gil:

Gestin evolutiva del avance, en lugar de la tradicional o predictiva.

Trabajar basando la calidad del resultado en el conocimiento tcito de las

personas, ms que en el explcito de los procesos y la tecnologa empleada.

Estrategia de desarrollo incremental a travs de iteraciones (sprints) y

revisiones.

Seguir los pasos del desarrollo gil: desde el concepto o visin general de la
necesidad del cliente, construccin sel producto de forma incremental a travs
de iteraciones breves que comprenden fases de especulacin exploracin y

revisin. Estas iteraciones (en scrum llamadas sprints) se repiten de forma

continua hasta que el cliente da por cerrada la evolucin del producto.

Se comienza con la visin general de lo que se desea obtener, y a partir de ella se

especifica y da detalle a las partes de mayor prioridad, y que se desean tener
cuanto antes.
Cada ciclo de desarrollo o iteracin (sprint) finaliza con la entrega de una parte
operativa del producto (incremento). La duracin de cada sprint puede ser desde
una, hasta seis semanas, aunque se recomienda que no excedan de un mes.
En scrum, el equipo monitoriza la evolucin de cada sprint en reuniones breves
diarias donde se revisa en conjunto el trabajo realizado por cada miembro el da
anterior, y el previsto para el da en curso. Esta reunin diaria es de tiempo
prefijado de 5 a 15 minutos mximo, se realiza de pie junto a un tablero o pizarra
con informacin de las tareas del sprint, y el trabajo pendiente en cada una. Esta
reunin se denomina reunion de pie o scrum diario y si se emplea la
terminologa inglesa: stand-up meeting, tambin: daily scrum o morning
rollcall

Gestin de la evolucin del proyecto

Scrum maneja de forma emprica la evolucin del proyecto a con las siguientes
tcticas:

Revisin de las Iteraciones

Al finalizar cada sprint se revisa funcionalmente el resultado, con todos los
implicados en el proyecto. Es por tanto la duracin del sprint, el perodo de tiempo
mximo para descubrir planteamientos errneos, mejorables o malinterpretaciones
en las funcionalidades del producto
.

Desarrollo incremental
No se trabaja con diseos o abstracciones durante toda la construccin del
producto.
El desarrollo incremental ofrece al final de cada iteracin una parte de producto
operativa, que se puede usar, inspeccionar y evaluar.
Scrum resulta adecuado en proyectos con requisitos inciertos y, o inestables.
Por qu predecir la versin definitiva de algo que va a estar evolucionando de
forma continua? scrum considera a la inestabilidad como una premisa, y adopta
tcnicas de trabajo para facilitar la evolucin sin degradar la calidad de la
arquitectura y permitir que tambin evolucione durante el desarrollo.
Durante la construccin se depura el diseo y la arquitectura, y no se cierran en
una primera fase del proyecto. Las distintas fases que el desarrollo en cascada
realiza de forma secuencial, en scrum se solapan y realizan de forma continua y
simultnea.

Autoorganizacin
Son muchos los factores impredecibles en un proyecto. La gestin predictiva
asigna al rol de gestor del proyecto la responsabilidad de su gestin y resolucin.
En scrum los equipos son autoorganizados, con un margen de maniobra suficiente
para tomar las decisiones que consideren oportunas

Colaboracin
Es un componente importante y necesario para que a travs de la
autoorganizacin se pueda gestionar con solvencia la labor que de otra forma
realizara un gestor de proyectos.
Todos los miembros del equipo colaboran de forma abierta con los dems, segn
sus capacidades y no segn su rol o su puesto.
Cul de las siguientes afirmaciones es cierta?:
Scrum es un modelo orientado a las personas.
Scrum garantiza el resultado a travs de un modelo de ingeniera de procesos.
Scrum es un mtodo de gestin de proyectos predictivo.

Comparte los principios estructurales del desarrollo gil: Gestin de riesgos, y

medicin del impacto de las modificaciones de requisitos.

Descripcin del marco y las reglas

de scrum tcnico
Scrum tcnico