Introducción al Marco de Trabajo Scrum

Introducción al Marco de TrabajoIntroducción al Marco de Trabajo
SCRUMSCRUM

AgendaAgenda
Marco de Trabajo SCRUM
Introducción al Marco de Trabajo Scrum:Introducción al Marco de Trabajo Scrum:
(a) Introducir a los participantes en el mundo del Desarrollo Ágil (Agile)
(b) Presentar los principios y prácticas para la gestión ágil y evolutiva
de proyectos, a través del marco de trabajo SCRUM: roles,
artefactos y eventos.
ContenidosContenidos:
● Metodologías Ágiles de Desarrollo de Software:
● Metodologías Ágiles vs. Tradicionales
● Marco de Trabajo Scrum

Introducción
A pesar del carácter estratégico de los sistemas
informáticos, para garantizar el cumplimiento de la Misión,
Visión, y Objetivos de cualquier organización pública o
privada, frecuentemente la gestión de los proyectos de
desarrollo de software, se ve afectada por diversas
problemáticas como las siguientes:
● No se adaptan a los cambios.
● Calidad insuficiente y muy variable.
● Proyectos que exceden sus tiempos y costos.

Introducción
Con base en lo anterior se ha llegado a un acuerdo de lo que
significa un proyecto de software exitoso, en tres
dimensiones:
• A tiempo.
• En presupuesto.
• Cumpliendo el alcance definido (incluye adaptabilidad a los
cambios y calidad).

Metodologías Ágiles de Desarrollo de
Software: Principios
● Durante el transcurso de los años 90 el ambiente
cambiante y turbulento era cada vez más la regla que la
excepción. Por lo tanto surgió la necesidad de desarrollar
metodologías livianas y maniobrables que pudieran
operar en ese ambiente turbulento. Estas metodologías
son conocidas colectivamente hoy en día como
“metodologías ágiles”.
● Se entiende como Desarrollo ágil de Software a un
paradigma de Desarrollo de Software basado en
procesos ágiles.

Software: Principios
● Lo ágil se define como la habilidad de responder de
forma versátil al cambio para maximizar los beneficios.
● Las metodologías ágiles varían en su forma de
responder al cambio, pero en general comparten las
siguientes características:
– Los individuos y sus interacciones son más importantes que los
– procesos y las herramientas.
– El software que funciona es más importante que la documentación
exhaustiva.
– La colaboración con el cliente en lugar de la negociación de Contratos.
– La respuesta al cambio en lugar de aferrarse a un plan.

Software: Alianza Ágil
● En una reunión celebrada en febrero de 2001 en Utha
(EEUU), con la participación de un grupo de 17
expertos de la industria del software, nace el término
“ágil” aplicado al desarrollo de software.
● Su objetivo fue esbozar los valores y principios que
debían permitir a los equipos desarrollar software
rápidamente y respondiendo a los cambios que
pueden surgir a lo largo del proyecto.
● Se pretendía ofrecer una alternativa a los procesos de
desarrollo de software tradicionales, caracterizados
por ser rígidos y dirigidos por la documentación que se
genera en cada una de las actividades desarrolladas.

Software: Alianza Ágil
● Tras esta reunión se creó “The Alliance”, una
organización dedicada a promover los conceptos
relacionados con el desarrollo ágil de software y ayudar a
las organizaciones para que los adopten.
● El punto de partida fue el Manifiesto Ágil, un documento
que resume la filosofía ágil.

Software: El Manifiesto Ágil
● Individuos e interacciones sobre procesos y
herramientas
● Software que funciona sobre documentación
exhaustiva
● Colaboración con el cliente sobre negociación de
contratos
● Responder ante el cambio sobre seguimiento de un
plan

Metodologías Ágiles vs. Tradicionales
Metodologías Ágiles Metodologías Tradicionales
La planificación del trabajo sólo
comprende el ciclo en el que se está
trabajando (normalmente 30 días).
Trabajo y gestión guiada por un plan
general del proyecto que comprende
todo su ciclo de desarrollo.
Descubrimiento progresivo de
requisitos, e incorporación de cambios
en cualquier iteración del desarrollo.
Conocimiento detallado de los
requisitos antes de comenzar el
diseño del proyecto.
“Refactorización” de código como
modelo de trabajo compatible con el
punto anterior
“Hacerlo bien a la primera”. Evitar la
re-codificación y el re-trabajo que
supone una pérdida de eficiencia
Comunicación directa entre los
integrantes del equipo (incluido
cliente).
Comunicación formal según el plan de
comunicación del proyecto.
Equipos auto-gestionados. Gestión de equipos centralizada
No existe contrato tradicional Existe un contrato prefijado.
El cliente es parte del equipo de
desarrollo.
El cliente interactúa con el equipo de
desarrollo mediante reuniones.
Pocos artefactos y roles Más artefactos y roles
Menos énfasis en la arquitectura del
software.
La arquitectura del software es
esencial y se expresa mediante
modelos.

Metodologías Ágiles vs. Tradicionales

SCRUM: Introducción
La palabra SCRUM
procede del vocabulario
del rugby y significa
melé; es decir, que los
compañeros del equipo
se amontonan, forman
una piña y empujan
todos en la misma
dirección.

● SCRUM es un modelo de desarrollo ágil caracterizado por:
– Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y
ejecución completa del producto.
– Basar la calidad del resultado más en el conocimiento tácito de las personas en
equipos auto-organizados, que en la calidad de los procesos empleados.
– Solapamiento de las diferentes fases del desarrollo, en lugar de realizarlas una tras
otra en un ciclo secuencial o de cascada.
– Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios
de los 80, al analizar cómo desarrollaban los nuevos productos las principales empresas
de manufactura tecnológica: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y
Hewlett Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986)
● SCRUM está pensado en un desarrollo de software en un proceso iterativo e incremental es
decir nos va a dar las pautas para gestionar a las personas que realizaran el trabajo.
● Reduce al máximo la burocracia y actividades no orientadas a producir software que funcione
y produce resultados en periodos muy breves de tiempo (cada 30 días), por medio de
iteraciones o Sprints.
● Ideal para proyectos con un rápido cambio de requerimientos.

● Los principales atributos de SCRUM son:
– Un enfoque orientado a que los equipos desarrollen sistemas y
productos de manera iterativa e incremental cuando los
requerimientos cambian de manera rápida.
– Un proceso que controla el caos de conflictos de intereses y
necesidades
– Una manera de mejorar las comunicaciones y maximizar la
cooperación
– Una manera de maximizar la productividad
– Escalable a múltiples proyectos y toda la organización
– Una forma que todos se sientan bien con su trabajo, entendiendo
que cada uno con sus contribuciones hizo lo mejor que podía hacer
– SCRUM está basado en el control empírico de procesos. Se utiliza
cuando la capacidad de predicción es vaga, la incertidumbre alta o
el proceso es demasiado complejo para ser modelado y definido.

Marco de Trabajo SCRUM
Contexto
Sólo abarca
prácticas de gestión
sin entrar en las
prácticas de
desarrollo.
Delega completamente en
el equipo la responsabilidad
de decidir la mejor manera
de trabajar para ser lo más
productivos posibles y, le
da gran protagonismo a las
reuniones que realicen a lo
largo del proyecto.
Sus raíces teóricas
están en las teorías
de la
auto-organización.

Marco de Trabajo SCRUM :
Componentes

Roles de SCRUM
● Responsable de la Pila de Producto y su correcta priorización
● Prioriza funcionalidades
● Puede cambiar la funcionalidad y prioridades para cada sprint (pero no
durante el mismo)
● Acepta o rechaza los resultados del sprint
● Responsabilidad del producto
● El PO aporta la visión general que el cliente ha transmitido, y desglosa
las historias de usuario en tareas.
Dueño del Producto / Product Owner (PO)

Roles de SCRUM
●
Formación y entrenamiento de procesos
● Incorporación de Scrum en la cultura del equipo
● Garantía de cumplimiento de roles y responsabilidades
● Remueve impedimentos
● Facilitador
● Asegura que se cumpla Scrum
Scrum Master (Facilitador):

Roles de SCRUM
● Auto – gestionado
● Auto – organizado
● Multifuncional
● Transforman los requerimientos en funcionalidad en cada
incremento
Equipo Scrum (5 a 9 personas)

Roles de SCRUM: Cerdos y Gallinas
● Hay dos categorías:
– Cerdos (comprometidos con el proceso)
– Gallinas (no son parte del proceso pero hay que considerarlos).
● Un cerdo y un gallina se encuentran por la calle:

Roles de SCRUM: Cerdos y Gallinas
● Roles de cerdo: (parte del proceso)
– Scrum Master (el facilitador del Scrum, asegura y guía en
el proceso Scrum, quita escollos).
– Dueño del producto (representa la voz del cliente)
– Miembros del equipo Scrum (responsables de crear el
producto)
● Roles gallina: (no son parte del proceso)
– Usuarios (quienes utilizarán el producto)
– Stakeholders (clientes y aquellos que permiten que exista
– el proyecto)
– Gerentes (administradores de la administración)

Ciclo SCRUM
Pila de producto
-- Requisitos priorizados.
-- Listado con los requisitos
del sistema.
Selección de la
Pila de producto
(Product Backlog)
-- Funcionalidades
Pila del sprint Nueva
Funcionalidad
• Dueño del Producto
(modificar cuidando la
inversión).
• Stakeholders (usuario,
soporte técnico,
administradores, etc )

Los “Sprint” / Iteraciones
● Un Sprint es el periodo de tiempo durante el que se
desarrolla un incremento de funcionalidad y su duración
está entre 2-4 semanas.
● Dentro de cada Sprint, Scrum gestiona la evolución del
proyecto mediante reuniones breves de seguimiento
diarias en las que se revisa el trabajo realizado desde el
hito anterior y los planes para el hito siguiente.

● Durante el Sprint NO se puede modificar el trabajo que se ha acordado
en el Backlog.
● Sólo es posible cambiar el curso de un Sprint, abortándolo, y sólo lo
puede hacer el Scrum Master si decide que no es viable por alguna de
las razones siguientes:
– La tecnología acordada no funciona.
– Los circunstancias / objetivos / prioridades han cambiado.
– El equipo ha tenido interferencias.
● Se planifica en detalle el trabajo al inicio de cada Sprint asumiendo que
los objetivos no van a cambiar durante el mismo. De esta manera se
atenúa el riesgo.

Artefactos SCRUM
● El primer paso en la estimación y planificación ágil es la
creación de la Pila del Producto / Backlog, o sea la
definición del proyecto a realizar.
● La pila del producto es la lista ordenada de todo aquello
que esperan el cliente, los usuarios, y en general los
interesados.
● Constituye el listado con la estimación inicial de los
requisitos de los usuarios o propietarios del sistema para
planificar el proyecto.
● Es el inventario de funcionalidades, mejoras,
tecnología y corrección de errores que deben
incorporarse al producto a través de los sucesivos sprints
Backlog del Producto – Pila de Producto:

Artefactos SCRUM
● La pila del producto nunca se da por completada;
está en continuo crecimiento y evolución.
● Al comenzar el proyecto incluye los requisitos
inicialmente conocidos y mejor entendidos, y
evoluciona conforme avanza el desarrollo
● Gracias a su carácter dinámico, refleja aquello que el
producto necesita incorporar para adecuarse a las
circunstancias, en todo momento.
● El propietario del producto mantiene la pila ordenada por
la prioridad de los elementos, siendo los más prioritarios
los que confieren mayor valor al producto, o por
alguna razón resultan más necesarios, y determinan las
actividades de desarrollo inmediatas
Backlog del Producto – Pila de Producto:

Artefactos SCRUM
● Se denomina “preparación” (grooming) de la pila del
producto a las actividades de priorización, detalle y
estimación de los elementos que la componen.
● Es un proceso que realizan de forma puntual, en
cualquier momento, continua y colaborativa el propietario
del producto y el equipo de desarrollo.
● Otras personas aparte del Dueño de Producto pueden
añadir elementos a la Pila de Producto. No obstante, no
pueden asignarles niveles de importancia.
● No debe consumir más del 10% de la capacidad de
trabajo del equipo.
● La responsabilidad de estimar el esfuerzo previsible para
cada elemento, es de las personas del equipo que
previsiblemente harán el trabajo.
Preparación de la Pila del Producto:

Artefactos SCRUM
● Una historia de usuario (user storie) es una representación de un
requisito escrito por el usuario final en lenguaje común (se plasma lo
que el cliente quiere, como lo quiere y para que lo quiere), con el fin
de que el equipo que va a trabajar pueda comprender con claridad la
necesidad y su prioridad).
● Las historias de usuario están divididas en dos apartados
diferentes: el enunciado y los criterios de aceptación (de gran
relevancia para estimar el esfuerzo y realizar las pruebas de
validación).
● Las historias de usuario se construyen bajo un mismo esqueleto
que centra el foco de las características del producto.
● Primero se determina quién propone la historia de usuario,
● luego se describe la característica que se cubre con la historia
de usuario y
● finalmente se especifica la razón por la que dicha característica
es necesaria.
Elementos de la Pila del Producto →
Historias de Usuario:

Artefactos SCRUM
● Las Historias de Usuario deben cumplir las siguientes características:
– Independientes. Deben ser atómicas en su definición. Es decir, se
debe intentar que no dependa de otras historias para poder completarla.
– Negociables. Son entidades vivas. Deben ser ambiguas en su
enunciado para poder debatirlas, dejando su concreción a los criterios
de aceptación.
– Valoradas. Deben ser valoradas por el cliente. Para poder saber cuanto
aporta al Valor de la aplicación y junto con la estimación convertirse en
un criterio de prioridad.
– Estimables. Tener su alcance lo suficientemente definido como para
poder suponer una medida de trabajo en la que pueda ser completarla.
– Pequeñas. Para poder realizar una estimación con cierta validez y no
perder la visión de la Historia de Usuario, se recomienda que sean
mayores de dos días y menores de dos semanas.
– Verificables. Este es el gran avance de las Historias de Usuario. Que,
junto con el cliente, se acuerdan unos Criterios de Aceptación que
verifican si se ha cumplido con las funcionalidades descritas y
esperadas

Artefactos SCRUM

Artefactos SCRUM
Pila de Producto:

Artefactos SCRUM
Pila de Producto:
Listado con los requisitos del sistema.
Listado de todas las a implementar.
Es dinámico.
Mientras exista un producto, existirá la Pila del Producto
también existe.

Artefactos SCRUM
● Los criterios de aceptación, son el mecanismo por el cual se
define si una historia de usuario fue desarrollada según la
expectativa del Dueño del Producto (como representante de los
criterios del cliente) y se si puede dar como hecha (done). Su uso
aporta muchas ventajas, las que me parecen más importantes:
– Fomentan la comunicación entre Dueño del Producto y equipo
para aclarar las expectativas
– Ayudan en la estimación de la historia al imponerle límites.
– Garantizan que el trabajo realizado será lo solicitado por el
Dueño del Producto.
– Reducen las necesidad de hacer consultas al PO durante el
sprint, con la consiguiente pérdida de productividad del equipo
y del PO.
– Sirven de guía para el desarrollo de las pruebas. Deben cubrir
los casos de uso positivos o comunes (el trayecto feliz) pero
también las excepciones o “corner case”
Historias de Usuario → Criterios de Aceptación:

Artefactos SCRUM
● Un criterio de aceptación es el mecanismo por el cual se
define si una historia de usuario fue desarrollada según la
expectativa del Dueño del Producto (como representante de
los criterios del cliente) y se si puede dar como hecha.
● Ayudan al equipo de desarrollo a entender mejor cómo se
espera que el producto se comporte (expectativas claras) y
facilita la estimación de la historia.
● Sirven de guía para el desarrollo de los test. Deben cubrir los
casos de uso positivos o comunes (el trayecto feliz) pero
también las excepciones o “corner case”
● Las calidades de un criterio de aceptación eficaz se definen
bajo el método SMART. SMART significa Specific
(Especifico), Measurable (Medible), Achievable (Alcanzable),
Relevant (Relevante) y Time-bound (Temporalmente limitado).
Historias de Usuario → Criterios de Aceptación:

Artefactos SCRUM
● La pila del sprint (sprint Backlog) es la lista de las
tareas necesarias para construir las historias de usuario
que se van a realizar en un sprint.
● La construye el equipo en la reunión de planificación del
sprint, indicando para cada tarea el esfuerzo previsto para
realizarla.
● La pila del sprint descompone las historias de usuario
en unidades de tamaño adecuado para hacer seguimiento
del avance a diario, e identificar riesgos y problemas sin
necesidad de procesos de gestión complejos.
● Es también una herramienta para la comunicación visual
directa del equipo.
● Al final del sprint se busca un incremento en la
funcionalidad.
Backlog del Sprint – Pila de Sprint:

Artefactos SCRUM
● Realizada de forma conjunta por todos los miembros del
equipo.
● Cubre todas las tareas identificadas por el equipo para
conseguir el objetivo del sprint.
● Sólo el equipo la puede modificar durante el sprint.
● Las tareas demasiado grandes deben descomponerse en
otras más pequeñas.
● Es visible para todo el equipo. Idealmente en un tablero o
pared en el mismo espacio físico donde trabaja el equipo.
Pila del Sprint - Condiciones:

Artefactos SCRUM
● Son soportes habituales:
– Tablero físico o pared.
– Hoja de cálculo.
– Herramienta colaborativa o de gestión de proyectos.
● Y sobre el más adecuado a las características del proyecto, oficina
y equipo, lo apropiado es diseñar el formato más cómodo para
todos, teniendo en cuenta los siguientes criterios:
– Incluir la siguiente información: Pila del Sprint, persona
responsable de cada tarea, estado en el que se encuentra y
tiempo de trabajo que queda para completarla.
– Incluir sólo la información estrictamente necesaria.
– Debe servir de medio para registrar en cada reunión diaria del
sprint, el tiempo que le queda a cada tarea.
– Facilitar la consulta y la comunicación diaria y directa del
equipo.
Pila del Sprint – Formatos y Soporte:

Artefactos SCRUM
Backlog del Sprint – Pila de Sprint:

Artefactos SCRUM
Un Panel de Scrum, funciona como un radiador de
información, allí podemos encontrar como van esas dos
semanas de trabajo del equipo, más que como va el
proyecto, como se mencionó anteriormente lo importante no
es el proceso, son las personas y las iteraciones, de esa
forma en el Panel.
Panel de SCRUM:

Artefactos SCRUM
Gráfica de Avance (Burn-Down):
●
En esta gráfica podemos
encontrar cuando la persona
tiene que acabar cierta tarea,
la idea es visualizar cuando se
acaban las tareas.
●
Al principio se lleva un
consenso es decir un punto
son 8 horas o un día pero se
interioriza inmediatamente.

Artefactos SCRUM
Incremento:
●
El incremento es la parte de producto es la parte de producto
realizada en un sprint potencialmente entregable: terminada y
probada
●
No se deben considerar como Incremento a prototipos,
módulos o sub-módulos, ni partes pendientes de pruebas o
integración. Idealmente en Scrum:
●
Se produce un “incremento” en cada iteración.
●
Cada elemento de la pila del producto se refiere a funcionalidades
entregables, no a trabajos internos del tipo “diseño de la base de
datos”.

Eventos: Reuniones en SCRUM
●
Reunión para Planificar el Sprint (Planning
Meeting) (Planificación):
●
Reunión Diaria (Daily Scrum) (Sincronización)
●
Reunión de Revisión del Sprint (Sprint Review
Meeting) (Revisión)
●
Retrospectiva del Sprint (Sprint Retrospective)
(Retrospectiva)

Reunión de Planificación de Sprint:

Reunión de Revisión de Sprint →
Seguimiento (Demo)
Lista de comprobación para demos de Sprint:
● Asegurarse de presentar claramente el objetivo del Sprint. Si hay personas en la
demo que no saben nada sobre tu producto, tomar un par de minutos para
describirlo.
● No perder mucho tiempo preparando la demo, especialmente en llamativas
presentaciones. Concentrase en mostrar código funcionando.
● Concentrar la preparación en hacer que la demo sea rápida en lugar de bonita.
● Mantener la demo a nivel de negocio, dejar los detalles técnicos aparte.
● Concentrarse en “qué hemos hecho” en lugar de “cómo lo hemos hecho”.
● En la medida de lo posible, dejar que la audiencia pruebe el producto por si
misma.
● No mostrar un montón de pequeños errores solucionados y funcionalidades
triviales. Mencionarlos, pero no los mostrarlos, ya que normalmente se tarda
mucho y desvía la atención de las historias más importantes.

Estimaciones en SCRUM
Las estimaciones se realizan por primera vez en la reunión
de planificación al inicio del Sprint y se revisan a diario,
registrando sus cambios en el Backlog del Sprint; esta
actividad puede ser realizada inmediatamente antes o
después del Scrum diario. Para ello se recomienda:
● Estimar el esfuerzo, en lugar de la duración.
● Estimar el esfuerzo total pendiente para terminar la tarea;
no se estima el esfuerzo consumido (Burn-Down).
● Se buscan unidades manejables, lo usual es que estén en
un mínimo de 2 horas y un máximo de 20.

Estimaciones en SCRUM: “Planning
Pocker”
●
El objetivo del planning poker (póker de planificación) es
obtener una medida de tamaño relativo de todas las historias
respecto a sí mismas
●
Se planifica con todo el equipo y una baraja de cartas llamada
Planning Poker, que sigue una seudo distribución de Fibonacci
de la siguiente forma tenemos el 1, 2, 3, 5, 8, 13, 20,40 y 100
por que Scrum quiere dar la sensación de que se realiza una
estimación
●
Al efectuar el planning poker sobre todo el backlog, da como
resultado que todas las historias han sido estimadas con muy
poco esfuerzo en una medida llamada story points o “puntos de
historia” (no en base a tiempo).

Estimaciones en SCRUM: “Planning
Pocker”

Priorización en SCRUM
●
La etapa de priorización es sencilla y depende
exclusivamente del Product Owner. Sabiendo ya el tamaño de
las historias, debe priorizarlas por valor que agreguen a a la
misión, visión y objetivos estratégicos de la organización y su
entorno.
●
La priorización se realiza balanceando el valor respecto al
costo y respecto a los riesgos de cada objetivo.
●
La prioridad puede cambiar todo el tiempo; pero el tamaño en
story points debe mantenerse fijo con la estimación original (o
sea: como regla general, no reestimar)

Reuniones en SCRUM
Su propósito, es fomentar el intercambio de comunicación, se
tratan temas como ¿qué hiciste ayer?, ¿qué vas a hacer hoy?,
¿qué impedimentos tienes?, con el fin de detectar los posibles
errores u obstáculos y para llevar actualizado el panel. Para
ello se recomienda:
●
Realizarla cada día en el mismo sitio y a la misma hora, con una
duración máxima de 15 minutos y se siguiere sea la primera
actividad del día.
●
Deben acudir todos los miembros del equipo.
●
Qué exista contacto visual entre todos los participantes y
manteniendo el foco y el orden.
Reunión Diaria / Scrum Diario:

Reunión de Revisión de Sprint:
●Análisis y revisión del incremento generado
●Constituye la presentación de resultados del equipo
Planificación
Revisión (máximo
4 horas)

Reuniones en SCRUM
● Reunión del equipo, Scrum Master, Poduct Owner (PO),
con todos los roles gallina
● Duración máxima: 4 horas (2h. recomendado)
● Objetivo: Presentar al Propietario del producto y a las
gallinas las funcionalidades implementadas.
● Presentación de producto terminado
● Todo el equipo participa
● Propuesta modificaciones en el Blacklog por PO

Reuniones en SCRUM
Lista de comprobación para demos de Sprint:
● Presentar claramente el objetivo del Sprint. Si hay personas en la demo que
no saben nada sobre tu producto, tomar un par de minutos para describirlo.
● Evitar hacer presentaciones llamativas. Concentrarse en mostrar código
funcionando.
● Concentrar la preparación en hacer que la demo sea rápida en lugar de
bonita.
● Mantener la demo a nivel de negocio, dejar los detalles técnicos aparte.
● Concentrarse en “qué hemos hecho” en lugar de “cómo lo hemos hecho”.
● En la medida de lo posible, dejar que la audiencia pruebe el producto por si
misma.
● No mostrar un montón de pequeños errores solucionados y funcionalidades
triviales. Mencionarlos, pero no los mostrarlos, ya que normalmente se tarda
mucho y desvía la atención de las historias más importantes.

Reuniones en SCRUM
Reunión de Retrospectiva de Sprint:
Buscan detectar los puntos positivos y negativos del Sprint para
generar propuestas de mejora para futuros Sprints.
● Todos los miembros del equipo responden a dos preguntas:
✔ ¿Qué cosas se realizaron con éxito en el último Sprint?
✔ ¿Qué cosas se podrían mejorar?
● El Scrum Master anota todas las respuestas.
● El equipo prioriza las mejoras posibles.
● El Scrum Master no proporciona respuestas, sino que ayuda
al equipo a encontrar la mejor forma de trabajar con Scrum.
● Las acciones de mejora localizadas que se puedan
implementar en el próximo Sprint deben introducirse en el
Backlog como elementos no funcionales.

Proceso de Desarrollo SCRUM
● Se utiliza un proceso ágil iterativo e incremental que
respeta las cinco etapas tradicionales de un proyecto que
facilitan su gestión y control; ellas son: planificación,
análisis, diseño, construcción y prueba, e implementación.
● Se definen, en forma clara, los entregables de cada etapa
y el alcance global, reflejando estos puntos en la
planificación de todas las tareas involucradas
● Este tipo de proceso de desarrollo permite hacer entregas
parciales que se van complementando según avanza el
proyecto.

Información y Recursos
● Libro Scrum Manager Guía de formación Versión 2.6 –
Julio 2016 - (http://www.scrummanager.net/bok/)
● Open Knowledge Scrum
(http://www.scrummanager.net/oks/)
● Blog
(http://www.scrummanager.net/blog/)
● Acerca de la certificación Scrum Manager®.
(http://www.scrummanager.net/certificacion)
● Preguntas frecuentes sobre cursos y exámenes Scrum
Manager® (http://www.scrummanager.net/faq-formacion-
scrum-manager)

Información y Recursos
● Twitter. (https://twitter.com/scrummanager)
● Facebook.
https://www.facebook.com/Scrum-Manager-144889095527292/
● Google+ (https://google.com/+ScrummanagerNet/)
● Pinterest (https://es.pinterest.com/scrummanager/pins/)
● Grupo profesional en LinkedIn
(http://www.linkedin.com/e/gis/855957)
● Comunidades Google +
(https://plus.google.com/communities/116174698722878580028)

Introducción al Marco de Trabajo Scrum

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Introducción al Marco de Trabajo Scrum

Similaire à Introducción al Marco de Trabajo Scrum (20)

Dernier

Dernier (9)

Introducción al Marco de Trabajo Scrum