Machine Translated by Google

Machine Translated by Google

EL SCRUM

ESTRUCTURA

LIBRO DE ENTRENAMIENTO

TERCERA EDICION

POR EL INSTITUTO INTERNACIONAL SCRUM™

www.scrum-institute.org

© COPYRIGHT INSTITUTO INTERNACIONAL SCRUM™

Machine Translated by Google

Dedicación

A todos los estudiantes del International Scrum Institute™, gracias por inspirarnos,
mantenernos enfocados y asegurarnos de que hacemos todo lo posible para
ayudarlos a crecer en su carrera con sus habilidades y conocimientos.

Sin usted, su compromiso y su leal apoyo, International Scrum Institute™ no podría

llegar a donde está hoy.
Machine Translated by Google

TABLA DE CONTENIDO CLICABLE

BIENVENIDO
7 ................................................ .................................................... .......................

ACERCA DEL INSTITUTO INTERNACIONAL SCRUM™ 10 ........................................... ......................

¿Qué es Scrum? 13 .................................................. .................................................... .........

MANIFIESTO ÁGIL 17 ............................................... . ............................................................. ... .......

autoorganización 18 .............................................. .................................................... .......

inspeccionar y adaptar 19 ............................................... .................................................... .......

cinco valores clave del marco scrum 20 ........................................... .....................

Introducción a Scrum: un ejemplo del mundo real (estudio de caso) 25 ...............................

TRES ELEMENTOS DE CAOS Y FRUSTRACIÓN ANTE EL MARCO SCRUM 30 .......

frustración #1. Tuvimos que planificar todo nuestro proyecto antes de comprender de qué se trataba el

proyecto 32 .................................. .................................................... .....

Machine Translated by Google

frustración #2. Falta de compromiso, gestión del cambio y trabajo conjunto Discípulos entre
diferentes equipos 36 .................................... ........................

frustración #3. Decisiones autocráticas anuladas Decisiones democráticas 40 ...........

¿Qué hace que Scrum Framework tenga éxito? 42 .................................................. .......

Roles de Scrum: el equipo Scrum 44 ........................................... .............................................

El rol de Scrum Master 51 ............................................... ..........................................................

EL ROL DEL PROPIETARIO DEL PRODUCTO Scrum 55 .................................. .....................................

EL ROL DEL MIEMBRO DEL EQUIPO SCRUM 57 ........................................... .............................................

¿Cómo funciona Scrum Framework sin un Project Manager? 58 ................

Historias de usuarios de Scrum 59 ............................................... .................................................... .....

Estimaciones de esfuerzo de Scrum – Planning Poker® 60 ........................................... ...........

Definición de Listo (DoD) 63 ........................................... ....................................................

La acumulación de productos Scrum 64 ............................................... .............................................

La acumulación de Sprint 70 ............................................... .................................................... .....

¿Qué es un Sprint? 72 .................................................. .................................................... ......

Machine Translated by Google

Diagrama de desarrollo de Scrum 74 ............................................... ..........................................................

Sprint Burndown ChaRT (informe de Sprint Burndown) 77 ....................................... .....

Reunión de planificación de Sprint 78 ............................................... .............................................................

Reunión diaria de Scrum / Reunión diaria de pie 80 ........................................... ..............

Reunión de revisión del sprint 82 ............................................... ....................................................

Reunión retrospectiva del Sprint 83 ............................................... .....................................

REUNIÓN DE PREPARACIÓN DE SCRUM (REFINAMIENTO DEL BACKLOG) 84 ........................................... ..........

MARCO Scaled Scrum (Proyectos Distribuidos y Grandes Scrum) 85 ......................

MARCO Scaled Scrum (Coordinación y Planificación de Equipos Múltiples) 97 ..................

Planificación de lanzamiento de Scrum 102 ............................................... ............................................

PRÓXIMOS PASOS 106 ............................................... .................................................... ..................

Gracias 112 ............................................... .................................................... ..................

Machine Translated by Google
BIENVENIDOS
¡Hola! Mi nombre es Yeliz.
En primer lugar, muchas gracias por obtener su copia de
The Scrum Framework. Me encanta que te tomes el tiempo
de leerlo.
Quiero compartir brevemente con usted la historia de fondo de
por qué queríamos escribir este libro para usted y cómo puede
aprovecharlo al máximo.
En el contexto de nuestros programas de capacitación y
certificación de Scrum, realizamos una investigación exhaustiva
en el espacio educativo de Scrum.
La conclusión fue: ¡Fallamos en encontrar un solo libro de
estudio confiable, que sinceramente pudiéramos recomendar
a nuestros estudiantes!
Encuestamos y hablamos con nuestros estudiantes exitosos que
aprobaron con éxito sus exámenes de certificación Scrum, y
descubrimos una información notable e indiscutible.
Casi ninguno de los libros de Scrum en el mercado los ayudó a
aprender Scrum y a tener un comienzo sin problemas para
implementar y obtener ganancias con Scrum Framework.
Terminaron literalmente con cero retorno de la inversión. Tanto
para sus objetivos profesionales como individuos como para las
metas financieras de sus organizaciones.
Un número significativo de libros Scrum en el mercado afirman
que cubren todos los detalles del proceso Scrum. Sin embargo,
lo que no están diciendo es que: No tienen una estructura lógica,
al grano y digerible, y contenidos comprobados y comprobados.
¡Así que estos libros no pudieron ayudar a nuestros estudiantes
a comprender y, lo que es más importante, a amar Scrum!
En resumen, para eliminar este importante impedimento en
el espacio de aprendizaje de Scrum, asumimos la
responsabilidad de escribir para usted The Scrum Framework
y lo pusimos a su servicio.
7
Machine Translated by Google
Estamos absolutamente seguros de que The Scrum
Framework lo hará competente en el proceso Scrum
y su uso práctico en su carrera y negocios.
Por lo tanto, tendrá una oportunidad sin precedentes
de amar Scrum y seguir aprovechando los beneficios
tangibles de ser un profesional de Scrum que sabe
cómo debería funcionar Scrum.
¡Tome un café para disfrutar y un poco de papel
para tomar sus notas, y pase un tiempo tranquilo
para leer The Scrum Framework!
Posteriormente, tendrá una gran comprensión del
dominio Scrum y estará preparado para aprobar sus
exámenes de certificación Scrum.
¡Estará listo para ofrecer excelentes productos y
servicios a sus clientes y empleadores y construir su
brillante carrera y futuro!
Ya me parece que eres una persona interesada en
agregar nuevas habilidades a tu caja de herramientas.
De lo contrario, no estarías leyendo estas oraciones
hoy.
Estoy encantado de que nos esté dando su tiempo y
atención para aprender Scrum. Permítanme
asegurarles que nunca tomaremos esta responsabilidad
a la ligera. Es nuestro deber, obligación y, al mismo
tiempo, un placer acompañarlo en su viaje para
aprender Scrum.
Puedes contar conmigo siempre que necesites
ayuda. ¡Estaré siempre complacido de atenderte y
servirte!
¡Muchas gracias de nuevo por su confianza en
nuestros servicios y por participar hoy en el trabajo
de The Scrum Frame !
Yeliz Obergfell
Vicepresidenta - Experiencia estudiantil
International Scrum Institute™
https://www.scrum-institute.org
8
Machine Translated by Google

Registre su programa de certificación

Scrum https://bit.ly/2LNv7xW

9
Machine Translated by Google
ACERCA DEL INSTITUTO INTERNACIONAL SCRUM™
International Scrum Institute™ es un instituto
independiente. Ayudamos a organizaciones y
profesionales a obtener la certificación con programas
de certificación Scrum válidos y de renombre mundial y
a demostrar su competencia en el dominio Scrum.
Capacitamos a los profesionales de todo el mundo para
que construyan sus carreras y a las organizaciones para
que creen y vendan sus productos y servicios
sobresalientes que encantarán a sus clientes.
Sus renombrados programas de certificación Scrum
han demostrado su reconocimiento mundial al ser
la elección de más de 594 000 profesionales de
Scrum en 143 países.
El término "Scrum" fue utilizado y publicado por primera
vez por Harvard Business Review en enero de 1986.
Hirotaka Takeuchi e Ikujiro Nonaka acuñaron el término
"Scrum" con su artículo: The New New Product
Development Game. Entonces, el proceso Scrum
inicialmente estaba destinado a ser un marco abierto de
gestión de proyectos.
Sin embargo, las cosas no funcionaron así. El proceso
Scrum ha sido fuertemente comercializado.
Lo peor de todo es que Scrum ha sido sutilmente
dogmatizado, por lo que ha comenzado a contradecir
su propio espíritu de "inspeccionar y adaptar", del cual
aprenderá más adelante en este libro. Los profesionales
y las organizaciones han desperdiciado enormes
cantidades de capacitación, certificación y luego tarifas
de recertificación para obtener literalmente cero retorno
de la inversión.
Antes de que se estableciera el International Scrum
Institute™ para usted, solía haber desafíos
apremiantes para los profesionales de Scrum como
usted.
No poseía una alternativa razonable para obtener sus
certificaciones Scrum y demostrar su competencia en el
dominio Scrum. Los profesionales de Scrum tuvieron
que pagar costosas tarifas por los programas de
certificación de Scrum impulsados por las ganancias de
una vía de otras entidades de certificación. Además,
tenían que pagar altos precios por la formación en el aula, recurren
10
Machine Translated by Google
renovaciones de certificación y varias suscripciones y
membresías recurrentes adicionales.
International Scrum Institute™ tiene como objetivo
eliminar estas barreras establecidas frente a los
profesionales de Scrum en los mercados desarrollados y
emergentes. Estamos aquí para evitar que pague tarifas
irrazonables por la capacitación en el aula de Scrum y los
programas de certificación de Scrum antes de que
certifique su conocimiento en Scrum.
International Scrum Institute™ ofrece diez importantes
programas de certificación Scrum en línea. Estos programas
han sido diseñados por nuestro consorcio de renombrados
líderes empresariales y de personas, entrenadores, mentores,
expertos y autoridades de las principales industrias.
Aquí hay una descripción general de nuestros programas de
certificación Scrum que hemos creado para usted:
• Certificación acreditada Scrum Master™
• Certificado acreditado Scrum Product Owner
ción™
• Certificado acreditado Scaled Scrum Expert
ción™
• Liderazgo Agile Scrum (Ejecutivo) Accredited
Certification™
• Certificación acreditada de Scrum Trainer™
• Certificación acreditada de Scrum Coach™
• Certificado acreditado de miembro del equipo Scrum
ción™
• Certificación Scrum para Web Developer™
• Certificación Scrum para desarrollo de aplicaciones móviles
por™
• Certificación Scrum para Java Developer™
Además, no dude en consultar los artículos que se especifican
a continuación para saber por qué nos desempeñamos y le
servimos mucho mejor que nuestros competidores.
• Destacado en LinkedIn con cientos de Me gusta:
Certificación Scrum Master de forma económica: Plan
paso a paso
• ¡8 razones por las que International Scrum Institute™ le
sirve mucho mejor que sus competidores!
11
Machine Translated by Google

Certificación Scrum Master de forma económica: plan paso a paso

Destacado en LinkedIn https://bit.ly/31R5wd2

12
Machine Translated by Google
¿Qué es Scrum?
¿Qué es Scrum? Bueno, sin complicar demasiado las
cosas, el marco Scrum se puede definir de la siguiente
manera:
Scrum es un proceso iterativo de ingeniería de software
para desarrollar y entregar software.
Aunque el software es el enfoque principal del marco
Scrum, el proceso iterativo y ágil de Scrum puede aplicarse
y ya se está aplicando también fuera de la industria del
software.
La mayoría de las personas en la industria de TI creen
que el término "Scrum" se acuñó a principios de la década
de 2000 como una pista paralela de las tendencias
emergentes de desarrollo y entrega de software ágil. ¡Esa
es una pieza de información incorrecta!
El término "Scrum" fue utilizado y publicado por primera
vez por Harvard Business Review en enero de 1986.
Hirotaka Takeuchi e Ikujiro Nonaka acuñaron el
término "Scrum" con su artículo: The New New Product
Development Game. (Sí, dos Noticias)
¡Debería echar un vistazo a "El nuevo juego de desarrollo
de nuevos productos" para ver cómo comenzó todo lo
relacionado con Scrum!
Scrum se puede utilizar en todo tipo de proyectos de
desarrollo de software. Desarrollar y entregar paquetes de
software completos o solo algunos módulos de sistemas
más grandes, tanto para productos como para servicios
de clientes internos y externos.
Scrum Framework es un proceso ligero. Se enfoca en
aumentar la productividad de los equipos mientras
reduce los desperdicios y las actividades redundantes.
Scrum define algunas pautas generales con algunas
reglas, roles, artefactos y eventos. Sin embargo, todos
estos componentes son críticos, sirven para propósitos
específicos y son esenciales para el uso exitoso del marco
Scrum.
13
Machine Translated by Google
Descripción general del marco Scrum
Los componentes principales del framework Scrum
son:
• Tres roles de Scrum: el producto Scrum
Propietario, el Equipo Scrum y el Scrum
Maestro.
• Cinco eventos de Scrum (rituales de Scrum) o ceremonias:
reunión de preparación de Scrum (refinamiento de la cartera
de pedidos), reunión de planificación de Sprint, reunión diaria
de Scrum, reunión de revisión de Sprint y reunión retrospectiva
de Sprint.
• Product Backlog (Scrum Backlog) o Scrum Product
Backlog: Un artefacto que se utiliza para gestionar y priorizar
todos los requisitos conocidos de un proyecto Scrum.
• Sprints: Ciclos de actividades de trabajo para desarrollar
incrementos de servicios o productos de software entregables.
• Sprint Backlog: un artefacto para realizar un seguimiento de
los requisitos comprometidos por los equipos Scrum para un
Sprint determinado.
14
Machine Translated by Google
La autoorganización y la colaboración incondicional
son elementos críticos del marco Scrum. Los Equipos
Scrum ya no requieren un gerente de proyecto en el
sentido clásico. Con el marco Scrum, Scrum Master y
Scrum Product Owner comparten el rol y las
responsabilidades de un gerente de proyecto típico.
No obstante, nunca se permite que un Scrum Master o
un Producto Scrum anulen la capacidad democrática de
toma de decisiones de un Equipo Scrum. Por ejemplo,
solo los miembros del equipo de Scrum pueden confirmar
conjuntamente cuáles de los elementos del Backlog
altamente priorizados entregarán en un Sprint como un
incremento de software.
Otro elemento central del marco Scrum es la mejora
continua que habilitamos con "inspeccionar y
adaptar". Un Equipo Scrum monitorea, inspecciona y
evalúa continuamente sus artefactos y su uso del marco
Scrum para adaptarlos y optimizarlos.
Estos esfuerzos continuos de optimización maximizan
la calidad, la eficiencia, la satisfacción del cliente y, por
lo tanto, minimizan los desperdicios y los riesgos
generales del proyecto.
El marco Scrum entiende que es probable que los
requisitos cambien y no se conocen por completo,
especialmente al comienzo de los proyectos.
Cada proyecto tiene incógnitas desconocidas.
A veces unos pocos, a veces muchos. El marco
Scrum nos ayuda a aceptar que podemos descubrir y
lidiar con estas incógnitas desconocidas solo mientras
ejecutamos nuestros proyectos.
El Equipo Scrum primero ajusta y granulariza los
requisitos de menor nivel o baja prioridad antes de
implementarlos. Durante Scrum Grooming (refinamiento
de backlog) y reuniones de planificación de Sprint. La
apertura al cambio, la optimización continua y el
aprendizaje de los errores se están convirtiendo en
elementos integrales de todo el ciclo de vida de la
ingeniería de software.
Otro pilar del marco Scrum es la transparencia y la
comunicación directa.
El propietario del producto Scrum trabaja en estrecha
colaboración con el equipo Scrum para identificar y
priorizar los requisitos. Estos requisitos se escriben
como historias de usuario y se almacenan en el Producto Scrum.
15
Machine Translated by Google
Reserva. Scrum Product Backlog consiste en todas las
tareas que deben implementarse para entregar un sistema
de software que funcione con éxito.
Un Equipo Scrum está facultado para seleccionar las
historias de usuario con las que confían para entregar
dentro de las 2 a 4 semanas de Sprints. Debido a que el
Equipo Scrum se compromete con sus propios objetivos,
los miembros del equipo se sienten más comprometidos y
saben que sus opiniones son escuchadas. Esta inclusión
de los miembros del equipo Scrum en el flujo natural y la
planificación de los proyectos de software aumenta la
moral del equipo y, posteriormente, aumenta el rendimiento
del equipo.
Los Scrum Masters poseen otro papel vital en Scrum
Framework, ya que trabajan como líderes de servicio
para y con su Scrum.
equipos
Los Scrum Masters son facilitadores capacitados para
garantizar el funcionamiento impecable de sus Equipos Scrum.
A veces son maestros negociadores para proteger a sus
Scrum Teams de interrupciones y prioridades ficticias de
sus partes interesadas. Otras veces son maestros
comunicadores para eliminar
o prevenir impedimentos conocidos o anticipados antes de
que estos impedimentos lleven a sus equipos a callejones
sin salida. Para nombrar solo algunas de las
responsabilidades de los Scrum Masters. Cubriremos más
sobre los deberes de varios roles de Scrum más adelante.
Scrum Framework, en su forma pura, es más adecuado
para proyectos altamente independientes, de un
equipo, greenfield o brownfield.
Sin embargo, el sentido común práctico de los profesionales
de Scrum no se quedó ahí. Con la introducción de roles y
anexos adicionales como "Jefe de Scrum Product Owner"
y "Scaled Scrum", también se puede usar dentro de
diferentes configuraciones de proyectos, incluidas
configuraciones de proyectos distribuidos geográficamente
y de varios equipos. Cubriremos más sobre esto también.
¡Por ahora estad atentos y seguid disfrutando de la
conferencia!
dieciséis
Machine Translated by Google
Manifiesto ágil
Cuando la industria de TI habla sobre el marco Scrum, a
menudo también escuchamos el término "Agile Scrum" en
la misma línea que "Scrum". Nos llevó a algunos de
nosotros en la industria a pensar y buscar diferencias entre
los términos "Agile Scrum" y "Scrum".
Aquí hay buenas noticias para ti. Los términos "Agile
Scrum" y "Scrum" se refieren a lo mismo. Ambos se
refieren al proceso de ingeniería de software Scrum.
Entonces, ¿por qué a veces usamos la palabra "Ágil"
delante de "Scrum"?
Es porque el marco Scrum adoptó e incorporó por completo
el Manifiesto Ágil (Manifiesto para el desarrollo ágil de
software) en su proceso central, principios y filosofía
subyacente.
Eso nos lleva a comprender mejor el manifiesto ágil y los
valores del proceso scrum antes de profundizar en los
aspectos técnicos del proceso scrum.
Valores del manifiesto ágil:
• Individuos e interacciones sobre procesos y
herramientas, • Software de trabajo sobre
documentación completa, • Colaboración del cliente
sobre contrato
negociación,
• Responder al cambio sobre seguir un plan.
Si bien los factores del lado derecho aún poseen valores
significativos, el manifiesto ágil aprecia y prioriza más
los factores del lado izquierdo.
Los elementos favorecidos por el manifiesto ágil han
sido cuidadosamente probados y elegidos para:
• Servir mejor a los clientes y partes interesadas y
crear valor para ellos con el software, • Mejorar
la profesión del software
independientemente de su función, título y nivel
profesional.
17
Machine Translated by Google

autoorganización La autoorganización requiere conformidad y confianza en los

procesos conjuntos de toma de decisiones.

El equipo scrum se organiza solo. Los miembros del equipo Ese proceso de toma de decisiones en el marco de scrum
Scrum deciden por consenso las tareas que deben ejecutar incluye, entre otros, la planificación, la estimación, la
para cumplir los objetivos de un sprint. Un equipo implementación, la presentación de informes y la revisión del
autoorganizado no requiere un gerente o un líder de equipo. trabajo del que el equipo scrum es responsable conjuntamente.

La autoorganización en el marco de scrum es muy

disciplinada.

Sprint Backlog, Sprint Burndown Chart y Daily Scrum

Meetings los cuales aprenderá más sobre ellos más adelante
en este material construyen la base de la autoorganización.

Organizar el trabajo por sí mismos requiere para la mayoría

de los equipos una fase de aprendizaje. Scrum masters
competentes que poseen certificaciones de scrum master
ayudan a sus equipos de scrum a sobresalir rápidamente con
la autoorganización.

La autoorganización también incluye la capacidad de trabajar ¿Sí? ¡Entonces necesitas formar un equipo que pueda
juntos a pesar de las diferentes opiniones y posibles conflictos autoorganizar su propio trabajo!
entre varios miembros del equipo Scrum.

18
Machine Translated by Google
inspeccionar y adaptar
Scrum Inspect and Adapt es un concepto sencillo de
comprender, pero el más difícil de implementar y dominar
adecuadamente.
Las empresas finalmente han confirmado que ninguno
de sus gerentes de proyecto puede prever completamente
el panorama general de los sistemas complejos. No
pudieron hacer una planificación confiable de extremo a
extremo. Era evidente para ellos que necesitaban probar
algo diferente.
Junto con la manufactura esbelta (también conocida como
movimiento esbelto), las empresas necesitaban desarrollar
un proceso para potenciarlas estratégicamente. Necesitaban
un procedimiento operativo estándar que les ayudara a
aprender y fijar sus cursos de acción mientras ejecutaban sus
proyectos e incluso operaciones.
Ese fue el nacimiento de Toyota Improvement Kata, que hoy
llamamos "Inspeccionar y adaptar" mientras hablamos sobre
el marco de desarrollo y entrega de software scrum.
Según "Scrum Inspeccionar y Adaptar":
• Paso 1. Inspeccionar: hacemos todo lo posible para
comprender el estado actual del proyecto con nuestro nivel
actual de conocimiento y comprensión al respecto. • Paso
2. Adaptar: definimos una dirección y una visión sobre los
próximos pasos de nuestro proyecto y luego elaboramos
una estrategia y ejecutamos nuestra visión. • Paso 3.
Aprender: Observamos cuidadosamente, aprendemos y
enseñamos unos a otros mientras lo hacemos. Registramos
continuamente lo que funciona y lo que no funciona
mientras hacemos nuestro trabajo. • Paso 4. Reiniciar:
Comience de nuevo desde el Paso 1.
Tenga en cuenta que los cuatro pasos descritos anteriormente
son análogos, pero no se limitan a los siguientes rituales
Scrum (eventos Scrum).
• Paso 1. Inspeccionar es análogo a las reuniones de
revisión de Sprint y las reuniones retrospectivas de Sprint.
• Paso 2. Adapt es análogo a Sprint Planning Meetings y
Backlog Refinement Meetings. • Paso 3. Learn es análogo
a Daily Scrum Meetings. • Paso 4. Reiniciar es análogo al
cierre de un sprint y al inicio de un nuevo sprint.
19
Machine Translated by Google
cinco valores clave del
marco scrum
Ya hemos mencionado que el marco Scrum no es solo
un proceso de ingeniería de software. También tiene
un sólido conjunto de principios subyacentes.
De hecho, la mayoría de los negocios profesionales
pueden aplicar y utilizar estos principios.
No es suficiente obtener una certificación de scrum
para tener un gran éxito con el scrum. Debe poseer
una comprensión firme de los valores de Scrum para
tener éxito con el marco Scrum.
De modo que va a entregar un gran trabajo y un
software fantástico que les encantará a sus clientes
y empleadores. Permítame ahora contarle más acerca
de esos principios del proceso scrum.
Valor #1 de Scrum. Coraje
Hay momentos en que hacer lo correcto para servir los
mejores valores y beneficios para nuestros clientes no
es lo más fácil. En esos momentos, el Scrum Master,
el propietario del producto Scrum y los miembros del
equipo Scrum deben recordar su deber y obligación.
Eso es para construir los mejores productos y servicios
posibles en su dominio particular de tecnología de
información y negocios. Para ser mejor que mediocre,
un equipo scrum tarde o temprano debe enfrentar
decisiones difíciles que no harán felices a todos en
su ecosistema particular de partes interesadas.
Para lidiar con esto, todos los miembros del equipo
Scrum deben recordar lo que aprendieron durante su
capacitación de certificación Scrum.
Deben recordar ser valientes y deben dominar para
decidir y actuar con valentía.
20
Machine Translated by Google
Valor Scrum #2. Enfoque
Con el marco Scrum, cuando escuche el enfoque de valor,
debe pensar en dos cosas:
• Identificación del trabajo correcto: ¿Qué tareas son
necesarias para cumplir los objetivos de mi sprint?
¿Qué es esencial para desarrollar los mejores productos
y servicios de software para mis clientes de modo que
estén satisfechos con mi trabajo? • Priorización: en
qué tareas debería estar trabajando
¿En el siguiente?
En cada momento, hay una pregunta crítica que todo el
equipo de scrum, incluido el maestro de scrum y el
propietario del producto, debe responder.
Esta pregunta es: "¿Cuáles son las cosas más
importantes que deberíamos estar haciendo en este
momento para cumplir con las razones por las que un
empleador nos contrató en primer lugar?"
El marco Scrum tiene varios eventos incorporados (rituales)
para garantizar la priorización razonable de
historias de usuario y tareas. De acuerdo con el proceso
scrum, la priorización de las historias de usuario y sus
tareas asociadas debe tener una prioridad continua.
Así que nos aseguramos de que el equipo Scrum trabaje
en las cosas correctas en el orden correcto.
Algunas de las ceremonias integradas de scrum
(eventos de scrum) para priorizar nuestro trabajo y
ajustar nuestro enfoque son:
• Scrum Grooming (Refinamiento de Backlog)
Reunión: la reunión de preparación se centra
únicamente en la priorización de la cartera de productos
para prepararla antes de la próxima reunión de
planificación de Sprint. • Reunión de Planificación de
Sprint: Estas reuniones nos ayudan a ver las
dependencias y el orden correcto de trabajo para
entregar nuestras historias de usuario. • Reunión diaria
de Scrum: la reunión diaria de Scrum (Daily Stand-Up)
nos ayuda a establecer el tono de un próximo día de
trabajo. Debemos dirigir nuestro enfoque hacia donde
más se requiere. • Reunión de revisión de Sprint: la
reunión de revisión de Sprint nos muestra indirectamente dónde es
21
Machine Translated by Google
El equipo Scrum debe canalizar para tener revisiones
más exitosas en el futuro.
• Reunión retrospectiva de Sprint: estas reuniones
ayudan al equipo Scrum a priorizar qué aspectos de su
proceso de ingeniería deben mejorarse primero.
Aquí, en esta sección, cubrí los rituales de scrum solo
desde el punto de vista del enfoque. Puede encontrar una
explicación más detallada sobre las ceremonias de scrum
más adelante en este material.
Habiendo leído todo esto, debe ser evidente para usted
ahora cuán esenciales son la priorización y el enfoque
para el marco de Scrum.
Valor Scrum #3. Compromiso
Sin el compromiso del scrum master, el propietario del
producto scrum y el equipo scrum, no hay posibilidad de
obtener resultados sobresalientes con el software.
En el mundo del proceso de desarrollo de software scrum,
la mayoría de las personas traducen el valor del
compromiso como el acuerdo y el confinamiento de los
objetivos de los entregables de sprint dados.
Aunque esto tiene mucho sentido, esa comprensión no
es perfecta. Cada vez que escuche la palabra
"compromiso" en el contexto de los valores de scrum;
lo que debes recordar es la palabra: "obsesión".
Para tener éxito en la ingeniería de software y, en la vida
y los negocios, debe obsesionarse con sus objetivos.
Entonces, en el contexto del proceso scrum, debe
obsesionarse con crear un software maravilloso para
que sus clientes resuelvan sus problemas.
¿Por qué son tan importantes el compromiso y la obsesión
asociada con los objetivos de Scrum?
Porque sin la obsesión con la misión del equipo de
construir y entregar un software asombroso, cada vez que
el equipo Scrum encuentre un impedimento no trivial, su
trabajo se ralentizará y se estancará.
22
Machine Translated by Google
Luego, el maestro de scrum y el equipo de scrum
comenzarán a crear explicaciones para justificar y
legitimar al propietario del producto de scrum por
qué no pueden cumplir los objetivos del sprint. Las
excusas no deberían tener más espacio en su equipo
si su objetivo es convertirse en un equipo scrum mejor
que el promedio.
Solo con un nivel de dedicación enormemente alto, es
relativamente más cómodo y satisfactorio resolver los
problemas de nuestros clientes y ayudarlos y generar
valor para ellos con el software.
Valor Scrum #4. Respeto
Independientemente de su edad, género, raza,
creencia, experiencia, competencia, opiniones y
desempeño laboral, todos los miembros de un equipo
scrum deben respetarse y contar con los demás.
Este respeto no solo está confinado dentro de los
límites del equipo scrum. Además, todas las partes
interesadas internas o externas de TI y de negocios
que interactúan con el equipo Scrum son totalmente
respetadas y bienvenidas por un equipo Scrum.
Los miembros del equipo con experiencia deben
prestar atención para no invalidar la voluntad de la
contribución de los miembros del equipo con
menos experiencia.
Es particularmente crucial recibir y responder
adecuadamente a las opiniones opuestas con las que
la mayoría del grupo no está de acuerdo.
Valor Scrum #5. Franqueza
La "apertura" del valor de scrum suele ser uno de los
principales diferenciadores entre un equipo de scrum
promedio y uno de alto rendimiento. Sería útil si
asemejara la capacidad de apertura de un equipo
Scrum a la gran capacidad de un conjunto de personas
de mente abierta.
Son creativos, innovadores, intelectuales, honestos,
directos y humildes. En el proceso de ingeniería y
entrega de software Scrum, no hay ninguna
opinión, decisión o acción inapropiada.
23
Machine Translated by Google

La única condición es que deben ser transparentes
y deben aspirar a contribuir a la misión conjunta
del equipo scrum.
No significa que cada decisión y acción
necesariamente deba acelerar los resultados del
equipo Scrum, y deberían dar como resultado
historias de éxito sustanciales.
Gracias a los valores de apertura y coraje, el grupo
de desarrollo de software Scrum no tiene miedo de
cometer errores. Ven sus errores y resultados
menos que óptimos como oportunidades vitales
para mejorar significativamente su productividad
general y la calidad del trabajo.

Coraje, Enfoque, Compromiso, Respeto, Apertura

son los valores vitales de Scrum que siempre tiene en cuenta.

24
Machine Translated by Google
Introducción a Scrum - Un Real
Ejemplo mundial (estudio de caso)
Antes de comenzar el primer sprint
Alex trabaja como Scrum Product Owner de un
nuevo proyecto de desarrollo de software. Una de
sus primeras tareas es evaluar y descubrir los
requisitos para entregar el valor comercial que busca sutienda.
Necesita asegurarse de que su cliente obtenga el
software correcto para lograr resultados
comerciales tangibles. Escribe los casos de uso
esenciales y los analiza con los arquitectos, los
representantes de los clientes y otras partes
interesadas de las unidades de negocio y de TI.
Después de reunir los requisitos y los casos de uso
de alto nivel, los escribe en el Scrum Product
Backlog e inicia una sesión de estimación y
priorización con el Equipo Scrum. Como resultado
de esta sesión, todos los elementos en el Scrum
Product Backlog obtienen una estimación
aproximada inicial y una prioridad.
Durante esas sesiones, Anna, Scrum Master, se
asegura de que todos hablen el mismo idioma.
Entonces, el propietario del producto Scrum, los
miembros del equipo Scrum y sus partes interesadas
están alineados con los objetivos anticipados.
Por lo tanto, tienen una comprensión adecuada de
conceptos potencialmente nuevos para ellos,
como Caso de uso, Backlog, Sprint, etc. Y lo más
importante, el proceso de desarrollo y entrega del
software Scrum se aplica correctamente en la
cliente.
Ahora, Alex, el Product Owner de Scrum, comienza
a desglosar los requisitos de alto nivel en el primer
borrador de historias de usuario más detalladas. Con
esta lista, llama a la primera reunión de planificación
de Sprint.
Sprint 1 - Día 0
Durante la reunión de planificación de Sprint, Alex
presenta los elementos de Scrum Product Backlog
desde la prioridad más alta hasta la más baja. El
Equipo Scrum pregunta y aclara preguntas abiertas.
Para cada artículo, el equipo discute si tienen suficiente
25
Machine Translated by Google
la capacidad y los conocimientos necesarios para desarrollarla
y entregarla. El Equipo Scrum debe asegurarse de que todos
los recursos humanos y técnicos necesarios estén listos
antes del inicio del Sprint. Necesitan confirmar que se
cumplan todos los requisitos previos y las dependencias, lo
que podría ser fundamental para entregar con éxito ciertas
características del software.
Durante la reunión de planificación de Sprint (What-Part),
el Equipo Scrum se compromete a completar las historias de
usuario 1, 2, 3, 6, 7 y 8 hasta el final del Sprint.
Por lo tanto, estas historias de usuario ahora se mueven del
Scrum Product Backlog al Sprint Backlog.
Las historias de usuario 4 y 5 no se pueden lograr en este
Sprint, ya que aún no se cuenta con la infraestructura técnica
necesaria.
Después de la parte qué de la reunión de planificación del
Sprint, Anna, Scrum Master, llama al equipo Scrum para
profundizar en cómo el equipo va a implementar las
historias de usuario comprometidas (parte cómo). Las
tareas emergentes durante la parte del cómo de la reunión de
planificación del Sprint se anotan en las tarjetas y el equipo
las almacena en el Sprint Backlog. Ahora todos los miembros
del Equipo Scrum están listos para seleccionar una tarea para
comenzar a trabajar.
Sprint 1 - Día 1
Por la mañana, todo el equipo se reúne para su Daily Scrum
Meeting. Todos dan una declaración breve y concisa sobre
lo que han hecho hasta ahora, actualizan las estimaciones
del trabajo restante en las tarjetas del Sprint Backlog. Todos
dicen lo que planean hacer hoy y revelan si hay algún
impedimento que les impida procesar alguna tarea.
Hoy, uno de los miembros del Equipo Scrum, Melinda, informa
al Equipo Scrum que tiene un problema con la licencia del
entorno de desarrollo de software integrado que está utilizando.
Anna, la Scrum Master, verifica si otros miembros del equipo
tienen el mismo problema y confirma que se ocupará de este
impedimento después de la reunión. Después de unos 15
minutos de esta reunión diaria de Scrum, todos vuelven al
trabajo.
26
Machine Translated by Google
Después de esta reunión, Anna actualiza el Sprint
Burndown Chart para visualizar el progreso del
trabajo durante este Sprint. Luego llama al
proveedor del software, solicita la licencia faltante
y se la entrega a Melinda.
Introducción a Scrum
Un ejemplo del mundo real (estudio de
caso) en varias fases y sprints de Scrum
Carrera 1 - Día 2
Por la mañana, todo el equipo se reúne nuevamente
para su Daily Scrum Meeting. Por la tarde, un
miembro del Scrum Team, James, tiene dudas
sobre el resultado esperado de una de las historias
de usuario. Llama a Alex, propietario del producto
Scrum, y discuten esta historia de usuario para
asegurarse de que James la entienda correctamente.
Después de que Alex se informa y confía en cómo
proceder con esta historia de usuario, continúa
trabajando en su implementación.
Sprint 1- Día 6
El día comienza de nuevo con el Daily Scrum
Meeting del equipo. Anna, la Scrum Master, nota
esta mañana que la reunión tiende a durar más de
15 minutos. Los miembros del Equipo Scrum están
participando en una discusión sobre la optimización
de algunas consultas de bases de datos. Anna le
recuerda al equipo que las reuniones diarias de
Scrum no están destinadas a hacer el trabajo,
sino a alinear formalmente al equipo sobre
27
Machine Translated by Google
el trabajo y ponerlos en la misma página.
Después de la reunión diaria de Scrum, Alex (Propietario
del producto) le informa a Anna (Scrum Master) que el
cliente planteó varios requisitos nuevos que podrían afectar
el Sprint en curso y los Sprints posteriores. Anna le recuerda
cortésmente a Alex que el Equipo Scrum no puede
cumplir con estos requisitos durante el Sprint actual,
ya que el equipo ya se comprometió con el alcance
(historias de usuarios) de este Sprint. Y, sin embargo,
Anna convoca una reunión de refinamiento de tareas
pendientes para la tarde para que Alex pueda informar al
equipo sobre estos nuevos requisitos.
Durante esta reunión, el grupo ayuda a Alex a descubrir
dónde encajan estas historias de usuarios en el plan
de desarrollo general del software, su desglose inicial
de tareas, estimaciones y prioridades.
Sprint 1 - Día 10
Finalmente, ese es el último día de este primer Sprint.
Anna, Scrum Master, invita al equipo Scrum a la reunión
de revisión de Sprint. El equipo ha preparado un servidor
que no es de producción con la última versión del
incremento de software que se puede enviar que crearon.
Alex, el propietario del producto Scrum, y el Sr. Rich, una
de las partes interesadas del cliente, se sientan frente a
una instancia de una interfaz gráfica de usuario de este
software. Validan si la implementación cumple con las
expectativas y si el equipo documentó adecuadamente los
detalles sobre el nivel actual de aplicación.
Al final de la Reunión de Revisión del Sprint, Alex concluye:
• El equipo entregó las historias de usuario 1, 2, 6 y 7 como
comprometido y esperado.
• El equipo no pudo terminar la historia de usuario 3 a
tiempo y no demostraron esta historia de usuario en
absoluto. Entonces, las tareas restantes de esta historia
de usuario se trasladan a este próximo Sprint.
28
Machine Translated by Google

• La historia de usuario 8 no cumplió con algunos de los la tarea de incorporar a un arquitecto de sistemas para que
criterios de definición de hecho (DoD). Esta historia de entrene y guíe al equipo al comienzo del próximo Sprint.
usuario se mueve al siguiente Sprint, por lo que el equipo
puede definir y completar las tareas asociadas para
satisfacer el DoD de esta historia de usuario más adelante.
Sprint 2 - Día 1
Alex, el propietario del producto Scrum, y el Sr. Rich, la
parte interesada del cliente, informan brevemente al
Alex, el propietario del producto Scrum, continúa agregando
equipo Scrum sobre los próximos cambios y desafíos
nuevos requisitos a la cartera de productos Scrum en
sobre los requisitos del software y la dirección de la
función de sus reuniones recientes con los clientes. Además,
estrategia general sobre este software. El Sr. Rich
mejora la forma en que articuló el DoD de la historia de
agradece al Equipo Scrum por sus esfuerzos y compromiso
y sale de la sala. usuario 8, de modo que el Equipo Scrum pueda visualizar
mejor el resultado esperado de esta historia de usuario.

Luego, Alex invita al equipo a la reunión de planificación del

Después de completar la reunión de planificación de Sprint,
Sprint para el Sprint 2. El equipo Scrum discute y se
el equipo Scrum se reúne para la reunión retrospectiva
compromete con las historias de los usuarios con la guía de
de Sprint. Durante esta reunión, discuten qué salió bien
Anna, Scrum Master y, posteriormente, comienza el segundo
durante el Sprint y qué se podría mejorar, de modo que la
Sprint.
probabilidad de compromisos fallidos como sucedió con las
historias de usuario 3 y 8 se reduzca en los próximos
Sprints. Uno de los obstáculos identificados en la reunión
retrospectiva de Sprint es que el equipo no sabe lo suficiente
sobre la arquitectura general del sistema. Anna, la Scrum
Master, toma el relevo

29
Machine Translated by Google
TRES ELEMENTOS DEL CAOS Y
FRUSTRACIÓN ANTES DEL SCRUM
ESTRUCTURA
Para comprender mejor el impacto del marco Scrum en
nuestras prácticas y negocios de ingeniería de software,
tiene sentido echar un vistazo a un día en la vida (o un
proyecto de software en la vida).
Por lo tanto, me encantaría hablar brevemente sobre un
proyecto de software del pasado antes de que adoptáramos
el marco de trabajo de desarrollo y entrega de software
Scrum en nuestras organizaciones.
Unos días antes de escribir estas líneas, almorzamos con
uno de mis excompañeros con los que trabajábamos juntos
hace casi 20 años.
Este caballero, Marcus tiene su certificación de maestro
scrum y certificación de propietario de producto scrum
del Instituto Internacional Scrum ™. Actualmente trabaja
como scrum master para una de las casas de software
líderes en el dominio de software de gestión de proyectos
ágiles.
Como maestro de scrum, Marcus ahora está a cargo de
operar un equipo de scrum ágil cuyos miembros del
equipo de scrum se encuentran en ubicaciones
distribuidas geográficamente en todo el mundo.
Durante nuestro almuerzo, Marcus admitió que hay muchos
desafíos típicos con los equipos ágiles de scrum distribuidos.
Algunos de los problemas que mencionó específicamente
relacionados con la configuración de su proyecto de
software son:
• Diferencias en los estilos de trabajo entre scrum
miembros del
equipo, • diferencias de zona
horaria, • inadaptados
culturales y • restricciones de idioma.
A pesar de estas dificultades, Marcus agregó que
ejecutar un proyecto de software con el proceso ágil
Scrum es más divertido, productivo y enriquecedor que
la forma en que solíamos trabajar hace 20 años. En
comparación con los días en que solíamos trabajar sin
desarrollo de software scrum y procesos de entrega de
software scrum.
30
Machine Translated by Google

La declaración de Marcus fue de hecho un gran
testimonio del crédito del marco Scrum de un gerente,
Scrum Master y Product Owner muy competente y
experimentado.
¡Gracias, Marcos!
Luego le explicamos uno de nuestros proyectos de software
anteriores antes de que nos reuniéramos con el marco
Scrum. Estoy seguro de que muchos scrum masters
asemejarían esta experiencia a sus proyectos anteriores
antes de obtener sus certificaciones de scrum master.
cantidades masivas de investigación y desarrollo (I+D)
para construir un sistema de hardware y software totalmente
funcional.
Recuerde que estos son días antes de que tuviéramos el
producto mínimo viable (MVP) concepto para experimentar,
crear, aprender y volver a experimentar.
Sin scrum, crear una infraestructura tan sofisticada que
constituía numerosos elementos de hardware y software
fue un verdadero desafío.

Aquí hay tres contratiempos significativos que solíamos

A fines de la década de 1990, éramos parte de un grupo de tener sin ningún maestro de scrum y cualquier persona que
ingeniería de software para construir una infraestructura posea una certificación de maestro de scrum en nuestros
de clave pública basada en tarjetas inteligentes. Las equipos.
tarjetas inteligentes protegían de forma segura las claves
privadas de los miembros de la infraestructura, las claves
públicas asociadas y sus certificaciones envolventes se
distribuían abiertamente (como implica el nombre público).

En el pasado, este era en sí mismo un proyecto de TI

relativamente complejo que requería múltiples equipos de
ingeniería de hardware e ingeniería de software
interdependientes. Tuvimos que hacer

31
Machine Translated by Google
frustración #1. Tuvimos que planificar todo
nuestro proyecto antes de entender de qué
se trataba el proyecto
Sin scrum, nuestros equipos habían creado y entregado
productos de software y hardware completamente
incorrectos que no cumplían con las demandas de
nuestro cliente.
Tuvimos momentos en nuestra vida profesional en los que
algunas empresas de terceros impusieron cómo se suponía
que debíamos construir nuestros productos de software o
servicios de software.
Modelo de madurez de la capacidad (CMM), Norma ISO
9001:2008 y otros derivados intentaron ayudar a nuestras
empresas a garantizar que construimos nuestro software
correcto de la manera correcta.
El éxito que solían tener no forma parte de este libro. Este
libro estaba destinado a centrarse en el proceso de scrum
y los méritos del scrum.
marco en lugar de criticar procedimientos casi extinguidos.
Sin embargo, debo agregar que estos marcos de
mejora de procesos antes del marco de ingeniería
de software Scrum recomendaban un enfoque
por etapas. Aconsejaron un enfoque de ingeniería
de software por etapas que llamamos Modelo
de ingeniería de software en cascada.
Con el modelo de cascada, se suponía que cada proyecto
de software debía comenzar con un análisis de requisitos,
donde nuestro objetivo era comprender lo que nuestro
cliente necesitaba y quería.
Luego, diseñamos estos requisitos, los implementamos,
los probamos (verificamos) y los mantuvimos en nuestros
entornos de producción de software. Finalmente, llegamos
al final del ciclo de vida de la ingeniería de software.
Sin embargo, ¡la realidad no fue así!
32
Machine Translated by Google

La Metodología Waterfall vs El Marco Scrum

33
Machine Translated by Google

Los estudios han demostrado que en más del 80% de

los proyectos de software investigados y fallidos, el uso
de la Metodología Waterfall fue uno de los factores
críticos del fracaso. ¿Pero por qué?

Como se muestra en el lado izquierdo, cuando se

implementa la Metodología Waterfall, existe una cadena
secuencial estricta de las diferentes fases del proyecto.
Una fase previa tiene que ser completada antes de
comenzar la siguiente fase. Regresar es, en la mayoría
de los casos, doloroso, costoso, frustrante para el equipo
y requiere mucho tiempo.

El cronograma del proyecto se planifica desde el principio.

Fases en el software Classic Waterfall Un producto liberable se entrega solo al final de la línea
de tiempo del proyecto. Si una fase se retrasa, todas las
modelo de desarrollo
demás fases también se retrasan.

Para evitar esto, los directores de proyecto de la

Los efectos adversos de los retrasos imprevistos
Metodología Waterfall suelen tratar de anticipar todas
ocurridos durante una fase particular del modelo de
las posibilidades de antemano. Eso significa que en una
ingeniería de software en cascada eran inevitables
de las primeras fases del proyecto, intentan definir todos
para las siguientes fases de ingeniería de software.
los requisitos de la forma más detallada y completa
posible. Sin embargo, la definición de requisitos en una
etapa inicial de un proyecto suele ser complicada y, por
lo tanto, muchos requisitos

34
Machine Translated by Google
cambiar (o debería cambiar) a lo largo del proyecto.
Los estudios han demostrado que en proyectos más
extensos y complejos, alrededor del 60% de los
requisitos iniciales cambian a lo largo del curso de los
proyectos. Otros requisitos se implementan según lo
definido, pero algunos de ellos no son realmente
necesarios para el cliente. Por lo tanto, esas
implementaciones consumen tiempo y dinero que
podrían haber sido mejor utilizados para implementar
funcionalidades con un mayor valor agregado para sus clientes.
La separación en diferentes fases del proyecto obliga
a los directores de proyecto a estimar cada fase por
separado. El problema es que la mayoría de estas
fases no suelen estar separadas. Están trabajando
juntos y en paralelo.
Por ejemplo, ningún ser humano razonable puede
suponer que la fase de desarrollo terminó antes de
que comenzara la fase de prueba. Y, sin embargo, así
es precisamente y desafortunadamente cómo solía
funcionar la Metodología Waterfall.
La Metodología Waterfall para el desarrollo de software
se puede utilizar para implementar proyectos pequeños
y sencillos. Pero para proyectos más grandes y
complejos, este enfoque es muy arriesgado, si no
una locura. A menudo es más costoso y siempre
menos eficiente que el marco de desarrollo y entrega
de software Scrum.
Esta era la vida antes del marco Scrum.
Enviar nuestro software de un lado a otro entre varios
equipos, sin la guía de profesionales con las
habilidades de Scrum, hizo que nuestro trabajo
fuera burocrático, complejo e improductivo.
Finalmente, no fue solo el producto el que sufrió,
sino que también la moral de los empleados y el
compromiso con nuestra misión organizacional
se vieron afectados por completo.
35
Machine Translated by Google
frustración #2. Falta de
compromiso, gestión del cambio y
trabajo conjunto Discípulos entre
diferentes equipos
La debilidad más importante de los marcos de mejora de
procesos utilizados antes de Scrum era que: Se centraban
principalmente en las demandas de liderazgo de la
organización en beneficio propio.
Algunas de estas demandas son la supervisión, el cumplimiento
y la previsibilidad. No había ningún enfoque en servir bien
a los clientes y aumentar la moral de los empleados en
absoluto.
Por lo tanto, los miembros de los equipos de administración de
software y otras partes interesadas internas y externas
intentaron tener una fecha límite fija para los proyectos de
entrega de software y monitorear fácilmente el progreso de las
fases de ingeniería de software.
Penalizaban a su gente si algo estaba fuera de la pista
planeada, y esperaban
solucionar problemas emergentes antes de la fecha
programada de finalización del proyecto.
Además, los silos independientes realizaron fases de ingeniería
de software completamente separadas. Como ejemplo, el
equipo de desarrollo era completamente independiente de un
equipo de prueba (verificación) de software. La mayoría de las
personas que supuestamente trabajarían para la misma misión
comercial ni siquiera se conocían por sus nombres.
¿Tiene alguna idea sobre el motivo de esta mentalidad de silo
en nuestras organizaciones en lugar de centrarse en las
misiones comerciales y la madurez profesional (comercial) de
los empleados?
La razón es simplemente la gestión matricial.
La gestión matricial es una estructura organizativa de gestión
y de empleados, y ha estado presente en nuestras empresas
desde la década de 1970. A primera vista, la idea diferenciadora
detrás de una organización matricial o gestión matricial parece
inteligente.
El Liderazgo crea una estructura organizativa al reunir a
empleados con tipos similares de funciones y técnicas.
36
Machine Translated by Google

El modelo de entrega de proyectos en

cascada en una organización matricial

37
Machine Translated by Google
conjuntos de habilidades en los mismos o, en el mejor de los casos,
silos vecinos.
En el pasado, era muy popular ver el llamado "Centro
de Competencias" en nuestras empresas donde cada
centro de competencia representaba un silo
independiente y autónomo.
Un silo para desarrolladores de C++, otro silo para
administradores de bases de datos y otro silo de
control de calidad completamente separado en
supervisión y sigue y sigue. ¡Ve y fíjate!
El mayor desafío con la estructura organizativa
matricial fue que: para entregar un proyecto de software
sin el marco Scrum y los maestros Scrum, los gerentes
de proyecto tuvieron que tomar prestados empleados
de los silos temporalmente.
Estos empleados ni siquiera se posicionaron físicamente
con sus equipos de proyecto, pero aun así se ubicaron
en las salas de su particular centro de competencia.
estas.
Al finalizar los proyectos, estos equipos de proyectos
temporales se disolvieron y los participantes del proyecto
pasaron a sus próximas asignaciones para servir en
otros proyectos.
Por lo tanto, los valores comerciales objetivo de estos
proyectos de software en curso nunca han sido la
máxima prioridad para estos silos independientes.
Tienden a ver su trabajo como casillas de
verificación que marcaron para un proyecto aquí y
otro proyecto allá.
El liderazgo y el modelo organizacional matricial
no les enseñaron cómo los profesionales deben
comprometer su negocio para mejorar el resultado
final, incluidas las ventas, los ingresos y las ganancias.
Un artículo de McKinsey Quarterly escrito por McKinsey
& Company también ha ilustrado claramente esta
ilusión de optimización de costos más allá de la
organización matricial.
Gartner ha estimado que las organizaciones de todo el
mundo han gastado anualmente 600 mil millones de
dólares para recuperar sus sistemas de TI. de
trabajos de mantenimiento no programados y defectos.
38
Machine Translated by Google

Ahora tomemos un breve momento para visualizar
cómo se desarrolló la gestión de cambios y el manejo
de impedimentos de los proyectos de software. Cómo
se desarrollaron en una configuración de proyecto con el
modelo en cascada, con la organización matricial y sin el
proceso scrum.
Por último, pero no menos importante, debido a que
los silos no contaban con un mecanismo para procesar,
corregir y aprender de sus errores, seguían repitiendo
los mismos errores.
Además, siguieron aumentando el monto de la deuda
técnica mientras ellos pasivamente intentaban lidiar con
sus problemas.

Sí. Estás bien.

La gerencia y los empleados trataron la gestión de cambios,
los impedimentos y el manejo de errores como si fueran
malas excepciones que no deberían haber ocurrido en
primer lugar.

Por lo tanto, los cambios en un proyecto de software han

sido sinónimo de retrasos. Por lo general, creaban un
efecto dominó de retrasos en cascada.
Los equipos requerían alguien a quien culpar y señalar
con el dedo por los defectos e impedimentos.

39
Machine Translated by Google

todo el ciclo de vida de la ingeniería de software desde la

frustración #3. Decisiones
concepción del software hasta sus operaciones.
autocráticas anuladas Decisiones
Cuanto más remota se alejaba una decisión de los centros
democráticas de trabajo (equipos) a los que afectaba, más difícil era dar
una decisión correcta de misión crítica.

Steve Jobs dijo una vez:

"No tiene sentido contratar a personas inteligentes y
decirles qué hacer. Contratamos a personas
inteligentes para que nos digan qué hacer".
Los juicios de los líderes solían ser impulsivos, no bien
pensados, en su mayoría tardíos y tentativos, pero a
veces incluso demasiado temprano.

Estas decisiones autocráticas impuestos desde arriba

Sin embargo, esto es exactamente lo contrario de cómo
hacían que los empleados se sintieran infravalorados.
solía operar la mayoría de los líderes principales para
tomar decisiones antes de la era scrum. Obstaculizaron por completo la capacidad de sus
organizaciones para encontrar soluciones creativas e
innovadoras para manejar los desafíos competitivos
Antes de que tuviéramos el proceso Scrum en nuestras
relacionados con el software y los negocios.
organizaciones, las decisiones autocráticas de los
líderes anulaban la inteligencia combinada de sus
equipos. Además, desanimaron a los equipos de ingeniería de
software de dar su opinión en los momentos en que
se les pide que contribuyan con decisiones.
Ellos invalidaron la capacidad de toma de decisiones
democráticas de los grupos que estaban a cargo de
hacer los trabajos reales que abarcaron el
Fue una breve descripción general de cómo solíamos
desarrollar y entregar nuestros servicios de software y

40
Machine Translated by Google

productos de servicio antes de que adoptáramos el Ahora echemos un vistazo a cómo solucionamos estos
marco Scrum en nuestras organizaciones. elementos de caos y frustración con la ayuda del proceso
scrum.

41
Machine Translated by Google
¿Qué hace que Scrum
Framework tenga éxito?
Scrum Framework cambia el
triángulo clásico de la gestión de
proyectos.
Las organizaciones ya no necesitan sacrificar tiempo,
presupuesto o calidad. Ahora está surgiendo el nuevo
triángulo entre el presupuesto, el tiempo y la
funcionalidad. Y ninguno de estos elementos de éxito
del proyecto tiene que estar en peligro.
Triángulo de Gestión de Proyectos
De acuerdo con el marco Scrum, la calidad ya no es
opcional. Para ofrecer lo que los clientes están pagando
para hacer prosperar sus negocios, los Equipos Scrum
se esfuerzan por proporcionar el mejor software posible
que puedan construir juntos.
En el marco de Scrum, los factores que definen
cuándo se completa una función y cuándo cumple
con los estándares de calidad requeridos se
establecen mediante la definición de hecho (DoD).
Los DoD especifican el resultado esperado en términos
de requisitos funcionales y no funcionales, diseño,
codificación, pruebas unitarias, validaciones del usuario
final, documentación, etc. Los DoD se definen en los
niveles de las historias de usuario y las tareas. Los DoD
de historias de usuario se enfocan en los requisitos
funcionales y no funcionales del cliente, mientras que
los DoD de tareas se enfocan en las actividades de
trabajo deseadas de los miembros del Equipo Scrum.
El equipo Scrum no puede cerrar las historias de usuario
y, obviamente, las tareas que no cumplen con sus DoD.
Scrum Product Owner y el Scrum Team definen las
historias de los usuarios y sus tareas a través de:
42
Machine Translated by Google
el curso del proceso de ingeniería de software Scrum de manera
incremental.
Este desarrollo incremental permite que el equipo se mantenga
adaptable y ajuste sus próximas mejores acciones de manera
controlada sin los costos adicionales y los riesgos de poner en
peligro gran parte del trabajo anterior.
El Equipo Scrum crea un incremento de producto de software
potencialmente entregable hasta el final de cada Sprint. El equipo
demuestra y discute estos incrementos con el propietario del producto
Scrum y las partes interesadas del cliente para obtener e incorporar
sus comentarios hacia los próximos pasos de su proyecto.
Esta flexibilidad se aplica no solo a la entrega de software, sino
también a los procesos operativos. Así, el Framework Scrum permite
la optimización del uso de los recursos (humanos, tiempo,
presupuesto, materiales) y la minimización de los desperdicios.
Los estudios han demostrado que Scrum tiene los siguientes efectos
positivos en la práctica:
• Implementaciones de código más frecuentes, •
Tiempo de entrega más rápido desde el compromiso hasta la implementación
código,
• Tiempo promedio más rápido para recuperarse del tiempo de
inactividad, • Menor tasa de fallas en el cambio, • Mejor calidad
del producto, • Costos reducidos o idénticos en comparación con
los anteriores
Implementación de Scrum,
• Productividad y rendimiento mejorados, • Código
mejorado y confiabilidad operativa, • Rendimiento
organizacional mejorado y
satisfacción del cliente,
• Mejora de la penetración de mercado, cuota de mercado,
y la rentabilidad de las organizaciones, •
Mejora del crecimiento de la capitalización de mercado, •
Mejora de la motivación de los empleados.
Introducir y adoptar Scrum Framework no es trivial. Y, sin embargo,
el enfoque adaptativo e iterativo de Scrum Framework maneja esta
carga inicial y se adapta mejor a los requisitos comerciales y del
cliente en constante cambio.
Por lo tanto, Scrum Framework es, en la mayoría de los casos,
una mejor alternativa a las metodologías clásicas de ingeniería
de software.
43
Machine Translated by Google
Roles Scrum - El Equipo Scrum
Scrum Framework reconoce tres roles:
• El propietario del
producto, • El miembro del
equipo Scrum, • El Scrum Master.
Además de otros programas que ofrece a sus estudiantes
de todo el mundo, International Scrum Institute™ ofrece
tres programas principales de capacitación y certificación
para estos tres roles.
Estos programas son: Scrum Product Owner Accredited
Certification™ (SPOAC™), Scrum Team Member
Accredited Certifica tion™ (STMAC™), y Scrum Master
Accredited Certification™ (SMAC™).
Una organización de scrum adecuada debe poseer
adecuadamente personas de estos tres conjuntos de habilidades.estrechamente, colaboran y trabajan juntos, pueden
Eso es particularmente esencial para tener éxito con el
marco de desarrollo de software Scrum.
Ninguno de estos roles es prescindible o reemplazable.
No son combinables con los otros roles y funciones
de scrum.
Cada propietario de producto Scrum normalmente trabaja
junto con un equipo Scrum. Cada Scrum Team tiene su
propio Scrum Master, y cada Scrum Master se preocupa
y trabaja con un solo Scrum Team.
No subestime la importancia de comprender el propósito y
la función de estos roles y emplearlos con los talentos
adecuados.
Muchas veces observamos que la causa raíz de las
dificultades de un equipo scrum se debe a que estos roles
no se entienden o no emplean a las personas adecuadas.
Cada uno de estos roles tiene un conjunto definido de
responsabilidades. Solo si los propietarios de estos roles
cumplen con estas responsabilidades, interactúan
terminar un proyecto Scrum con éxito.
44
Machine Translated by Google

Roles y partes interesadas de Scrum

45
Machine Translated by Google

El equipo Scrum

Dentro del Marco Scrum, los Equipos Scrum

dedicados hacen todo el trabajo entregado a los
clientes comerciales. Un Equipo Scrum es una
colección de personas que trabajan juntas para
proporcionar los incrementos de producto solicitados y comprometidos.

Para trabajar con eficacia, es esencial que un Scrum

Equipo que todos dentro del equipo:

• Adopta los valores de Scrum Framework, como

Coraje, Enfoque, Compromiso, Respeto y Apertura,
• Se adhiere a las mismas normas y reglas, •
Sigue el objetivo común, que los conecta con los
resultados de TI y de negocios.
Al configurar un nuevo equipo Scrum, siempre debe
tener en cuenta que ningún equipo nuevo ofrecerá
el mayor rendimiento posible desde el principio.
Después de configurar el equipo, tiene que pasar
por ciertas fases como se describe en el Modelo
Tuckman: Formar, Asaltar, Normar, Interpretar.
Etapas de desarrollo de equipos de Tuckman
El tiempo que tarda el equipo Scrum en llegar a la
fase de ejecución varía de un equipo a otro.
Contratar buenos jugadores de baloncesto para el
mismo club no hará un buen equipo de baloncesto
tan pronto como comiencen a jugar juntos. Primero
necesitan aprender y adaptar sus estilos de juego,
sus fortalezas y debilidades para ayudarse
mutuamente y tocar en armonía. Los equipos Scrum
no son tan diferentes. Por lo tanto, es vital tener en
cuenta que por lo general toma alrededor de 3 a 5 Sprints hast

46
Machine Translated by Google
El equipo se vuelve lo suficientemente maduro para entregar sus
resultados de manera efectiva y predecible.
Características de un Equipo Scrum
Los Equipos Scrum tienen las siguientes características:
• Los miembros del equipo comparten las mismas normas y
normas,
• El equipo Scrum como un todo es responsable de
la entrega, • El
Equipo Scrum está empoderado, • El Equipo
Scrum está trabajando de la manera más autónoma posible, • El
Equipo Scrum se autoorganiza, • Las habilidades dentro del Equipo
Scrum están equilibradas, • Un Equipo Scrum central es pequeño y
no tiene sub
equipos,
• Los miembros del Equipo Scrum están dedicados a
sus equipos con el 100% de su capacidad, •
Los miembros del Scrum Team están ubicados en el mismo lugar e
idealmente comparten la misma habitación.
Reglas y Normas
El entorno, el negocio, la TI y el ecosistema geográfico de los Equipos
Scrum definen de manera invisible algunas de las normas que siguen
los equipos. Y, sin embargo, para convertirse en un Scrum Team
verdaderamente exitoso, se deben desarrollar y aplicar explícitamente
algunas reglas y normas durante la fase de normalización.
Estos estándares comunes son esenciales y no se puede enfatizar lo
suficiente para ofrecer una jugabilidad fluida, TI y resultados
comerciales. De lo contrario, los miembros del Equipo Scrum tendrían
que alternar continuamente entre diferentes sistemas de valores y
conjuntos de reglas, y perderían su valioso tiempo. Algunos ejemplos
de tales normas y reglas son:
• El objetivo, el alcance, la duración, la ubicación, los participantes y
los resultados de Scrum Rituals (Eventos), • El nivel requerido de
detalles para escribir una Definición de hechos (DoD) clara, concisa e
inequívoca, • Pautas para priorizar y estimar usuarios
historias y tareas,
• Directrices, procedimientos y el nivel de detalle
para crear documentos vivos,
47
Machine Translated by Google
• Herramientas para usar y herramientas para no usar (recuerde,
a veces menos es más), •
Estándares de codificación, •
Herramientas y pautas para construir/realizar manual/
pruebas automatizadas y garantizar la calidad,
• El proceso para resolver errores, • El proceso
para manejar solicitudes de cambio, • El proceso para
prepararse para demostraciones de incremento de producto
durante las reuniones de revisión de Sprint,
• El proceso para manejar los resultados de cada Scrum Ritual
(Evento), • Frecuencia, profundidad y duración de las
Reuniones de Refinamiento del Backlog.
Responsabilidad
El Equipo Scrum en su conjunto es responsable de entregar las
historias de los usuarios comprometidos a tiempo y con la mayor
calidad posible.
Un buen resultado o un fracaso nunca se atribuye a un solo
miembro del equipo, sino siempre al resultado del Equipo Scrum.
Empoderamiento y autoorganización
El Equipo Scrum debe estar facultado para definir
• Lo que el equipo se compromete a entregar al final
del Sprint, •
Cómo se romperán las historias de usuarios comprometidas
abajo en tareas,
• Quién realizará una tarea específica y en qué
orden en que se ejecutan las tareas.
Solo si el Equipo Scrum está facultado para decidir estas y otras
decisiones internas similares, los miembros del equipo trabajarán
con mayor rendimiento y motivación por el interés de sus clientes
interesados.
conjunto equilibrado de habilidades
Cada Individuo dentro del Equipo Scrum seguramente tendrá
habilidades especializadas, enfoque y preferencia personal de
intereses. Sin embargo, para lograr el mejor rendimiento posible,
su Scrum Team necesita tener un conjunto equilibrado de
48
Machine Translated by Google
habilidades. Solo entonces, el Equipo Scrum podrá hacer frente
a los desafíos comerciales y de TI en constante cambio, y podrá
actuar de la manera más autónoma posible.
Eso significa que un equipo Scrum debe ser multidisciplinario
(diseñadores, desarrolladores, probadores, arquitectos, etc.)
desde el principio. Por otro lado, esto también significa que cada
miembro del equipo debe aprender un poco de la especialización
de los demás.
Por ejemplo, para poder terminar una historia de usuario
comprometida hasta el final del Sprint, un desarrollador debe
escribir y ejecutar pruebas voluntariamente y consultar al
probador cuando sea necesario.
Los roles de los miembros del Equipo Scrum no están
compartimentados como el arquitecto, el desarrollador, el
evaluador, etc. Todos comparten el mismo título, "Miembro del
equipo Scrum", independientemente de sus competencias
personales básicas.
Tamaño del Equipo Scrum
Los equipos Scrum son pequeños. El tamaño ideal es de 7 +/- 2
personas.
Tenga en cuenta que si el Equipo Scrum contiene más de nueve
miembros, su equipo probablemente sufrirá debido a la
sobrecarga excesiva de alineación y comunicación. Y, sin
embargo, no hay una respuesta única para todos. Sus Equipos
Scrum aún pueden funcionar productivamente incluso si tienen
menos de cinco o más de nueve miembros.
La única forma de averiguarlo es probar, aprender y adaptarse.
Si descubre que un equipo de 13 personas no puede
desempeñarse lo suficientemente bien, entonces estos equipos
Scrum deben dividirse en dos equipos. Estos equipos Scrum
deben alinearse estrechamente y correlacionar sus objetivos e
historias de usuarios. Además de eso, trabajan de forma
independiente.
49
Machine Translated by Google

Colocación • Deben actualizar el estado y los esfuerzos de trabajo

restantes para sus tareas para permitir la creación de un
Para minimizar la sobrecarga de comunicación innecesaria, Sprint Burndown Diagram.
cada equipo Scrum debe estar ubicado en el mismo lugar.
Si el trabajo tiene que distribuirse en varias ubicaciones
geográficas, es necesario crear equipos Scrum
independientes. Estos equipos necesitan alinear y
correlacionar sus objetivos e historias de usuarios.

Responsabilidades del Equipo Scrum

El Equipo Scrum tiene responsabilidades específicas que
deben cumplir:

• Deben desglosar las historias de usuario, crear tareas,

definir prioridades y estimaciones, y autoorganizar la
implementación. En otras palabras, tienen que crear,
procesar y entregar el Sprint Backlog. Aprender Scrum puede ser un desafío.
Pero no te preocupes por eso. ¡Construimos
• Deben realizar Scrum Meetings Diarios. • Deben nuestros productos para ayudarlo y servirle!
asegurarse de que, al final del Sprint, se entregue y
demuestre un incremento de producto potencialmente
entregable.

50
Machine Translated by Google
El rol de Scrum Master
El Scrum Master sirve a todos los participantes de un
Proyecto Scrum y a las partes interesadas externas
para comprender y aplicar correctamente el trabajo del
Marco Scrum.
Él o ella apoya al Equipo Scrum para ejecutar el Marco
Scrum con éxito y contribuye a mejorar su productividad y
rendimiento de forma continua.
El rol del Scrum Master es establecer el Proceso Scrum
en su organización, la nueva forma de pensar y actuar.
Además, el Scrum Master actúa como agente de cambio.
Él o ella entrena al equipo para desarrollar nuevas normas
y estándares de equipo. El Scrum Master tiene su escritorio
en algún lugar muy cerca del resto del equipo Scrum.
Las tareas esenciales de un Scrum Master son:
• Establecer el Marco Scrum en su
ecosistema empresarial y de TI,
• Actuar como agente de cambio y apoyar la adaptación de
los procesos existentes para maximizar la productividad
del Scrum Team.
• Entrenar al Equipo Scrum para comprender y vivir los
valores del Marco Scrum, • Asegurar una colaboración
estrecha y eficiente entre el propietario del producto Scrum
y el
Scrum Team, •
Para eliminar los impedimentos que impiden la continuidad
del trabajo,
• Liderar el progreso del trabajo sirviendo, •
Moderar los Scrum Rituals (Scrum Events). • Proteger al
Equipo Scrum de interferencias e interrupciones externas
mientras el equipo realiza el trabajo que se comprometió
originalmente para un Sprint.
51
Machine Translated by Google

Aprenda Scrum fácilmente y demuestre oficialmente sus conocimientos

52
Machine Translated by Google

Para hacer este trabajo de manera efectiva, un Scrum la dirección suele imponer quién será el Scrum Master.
Master debe poseer habilidades inteligentes de Para obtener la confianza necesaria, el Scrum Master no
moderación y entrenamiento. Él o ella necesita ser un debe tener ninguna responsabilidad de gestión de línea por
aprendiz continuo para inspirar a otros a aprender, encima de los miembros del Equipo Scrum. De lo contrario,
cambiar y crecer. la comunicación abierta en el Equipo Scrum y la propiedad
conjunta del trabajo y la capacidad de toma de decisiones
Para saber más sobre las funciones de Scrum Master del Equipo Scrum pueden verse afectadas.
como facilitador, le recomiendo que eche un vistazo a este
artículo: Si tuviera 5 minutos para explicar Scrum Master
como facilitador.
Protegiendo al Equipo Scrum,
El Scrum Master es parte del Equipo Scrum y actúa como
Eliminación de impedimentos
un líder de servicio para el Equipo Scrum. Al principio, este
será un trabajo de tiempo completo, por lo que el Scrum
Master no podrá contribuir directamente a los resultados Un trabajo esencial del Scrum Master es salvaguardar al
Equipo Scrum de un falso sentido de urgencia. La gerencia
del Sprint. Sin embargo, después de algunos Sprints,
de línea y el propietario del producto Scrum a menudo
mientras el Equipo Scrum se acerca a la fase de Ejecución
intentan agregar historias de usuarios no planificadas al
del modelo Tuckman, la carga de trabajo inicial como
moderador y entrenador se reducirá. Entonces, el Scrum Sprint Backlog mientras el equipo se enfoca en el trabajo
de un Sprint planificado.
Master podría contribuir activamente a los objetivos del
Sprint.
Sin embargo, uno de los aspectos críticos de Scrum
Framework es que todas las historias de usuarios se
Dado que debe haber confianza entre el Scrum Master y
conocen y confirman solo durante las reuniones de
los miembros del Equipo Scrum, siempre puede ser una
planificación de Sprint. No se puede obligar al Equipo
buena idea que el Equipo Scrum elija a su Scrum Master.
Scrum a hacerse cargo de nuevas historias de usuario. El trabajo del S
Sin embargo, en realidad,

53
Machine Translated by Google

Master debe asegurarse de que hasta la próxima reunión de Scrum Master como agente de cambio
planificación de Sprint, estas nuevas historias de usuario se
almacenen en Scrum Product Backlog. Uno de los pilares del trabajo de Scrum Framework es la
mejora continua a través de Inspect & Adapt.
Alternativamente, si el Sprint en curso no tiene ningún sentido
comercial o técnico para continuar, se puede cancelar y se
puede planificar un nuevo Sprint. El Scrum Master organiza y modera la reunión retrospectiva
de Scrum, y su trabajo es facilitar, controlar y medir el cambio
de las deficiencias identificadas.
Los miembros del Equipo Scrum solo deben concentrarse en
brindar valor al cliente mediante la creación de incrementos
de productos potencialmente entregables. El Scrum Master
ayuda eliminando los impedimentos que bloquean o ralentizan
Facilitación de Scrum Rituals (Eventos)
el progreso del trabajo.

El Marco Scrum define varias reuniones que deben ser

Ejemplos de eliminación de impedimentos podrían ser:
organizadas y facilitadas por el
Maestro Scrum:
• Para organizar apoyo, recursos, • Para
encontrar el conocimiento que falta, y •
• Scrum Grooming (Refinamiento de Backlog)
Para hacer trabajo práctico para ayudar a los miembros del
equipo Scrum. Reuniones,
• Reuniones de planificación de
Sprint, • Reuniones Scrum diarias,
• Reuniones de revisión de Sprint y •
Reuniones retrospectivas de Sprint

54
Machine Translated by Google

EL ROL DEL PROPIETARIO DEL PRODUCTO Scrum ciclo de vida del proyecto. A nadie más se le permite imponer
al Equipo Scrum que trabaje para un conjunto diferente de
prioridades.
El propietario del producto Scrum es un rol central dentro
del marco Scrum. Ese rol unifica las tareas de gestión de
Las tareas esenciales de un propietario de un producto Scrum son:
productos y proyectos, y también está firmemente integrado
con el desarrollo y la entrega de software.
• Gestionar y aclarar los requisitos del proyecto, • Guiar las
liberaciones y garantizar el rendimiento de
inversión (ROI),
El rol del propietario del producto es mucho más amplio que los
• Trabajar en estrecha colaboración con el Equipo Scrum y
roles tradicionales de gestión de proyectos, gestión de permitirle entregar el trabajo correcto a tiempo. • Gestionar a
programas o gestión de productos.
las partes interesadas y sus expectativas.
ciones,
Él o ella representa a los clientes finales y/u otras partes
• Gestionar el Scrum Product Backlog.
interesadas y es responsable de maximizar el valor del producto
al garantizar que el Equipo Scrum entregue el trabajo correcto
El propietario del producto Scrum puede delegar ciertas
en el momento correcto. El propietario del producto Scrum
actividades (como el mantenimiento físico de Scrum Product
decide los requisitos de software proporcionados para una
Backlog). Sin embargo, él o ella todavía es dueño de la
versión de software específica y cuándo se lanzará el software.
responsabilidad de sus tareas.
Ella representa las demandas funcionales y no funcionales de
los usuarios finales.

Gestión de la cartera de productos

Eso significa que el propietario del producto Scrum tiene que
El propietario del producto Scrum es la única persona a la que
trabajar muy de cerca con el equipo Scrum y coordina sus
se le permite poseer los contenidos de la cartera de pedidos
actividades durante todo el proceso.
del producto Scrum. Eso significa que él o ella necesita:

55
Machine Translated by Google
• Crear, mantener y describir claramente las historias de
usuarios en Scrum Product Backlog, • Priorizar las
historias de usuarios para lograr los objetivos comerciales
y cumplir la misión del producto de software,
• Asegúrese de que el Equipo Scrum comprenda e
implemente correctamente las historias de usuario en el
Scrum Product Backlog.
Gestión de la liberación
El propietario del producto Scrum es responsable de
alcanzar los objetivos del proyecto. Él o ella crea y mantiene
el plan de lanzamiento y decide sobre las entregas, las
funciones del usuario final y el orden en que deben
entregarse. Los propietarios de productos Scrum a menudo
también administran los costos y el presupuesto de los
equipos Scrum. Colaboran con los miembros del Equipo
Scrum para ajustar, priorizar y estimar las historias de los
usuarios.
Gestión de los interesados
Las partes interesadas externas no deben presentar sus
demandas directamente a los miembros del Equipo Scrum.
En cambio, el propietario del producto Scrum debe recopilar
y evaluar las funcionalidades requeridas con las partes
interesadas (por ejemplo, con clientes internos,
representantes de clientes externos o usuarios finales).
El propietario del producto Scrum combina, filtra e
inicialmente prioriza estas historias de usuario antes de
discutirlas con el equipo Scrum.
Colaboración con el equipo Scrum Para un proyecto
exitoso, el propietario del producto Scrum y el equipo
Scrum deben trabajar muy de cerca. El propietario del
producto Scrum es responsable de garantizar que los
miembros del equipo Scrum estén informados y alineados
con respecto a los objetivos del software que están creando.
Durante las reuniones de revisión de Sprint, el propietario
del producto Scrum es responsable de inspeccionar,
aceptar o rechazar los entregables del equipo Scrum.
56
Machine Translated by Google

EL ROL DEL MIEMBRO DEL EQUIPO SCRUM Independientemente de sus coordenadas anteriores en la
organización, los miembros de un equipo Scrum pertenecen a su
proyecto Scrum particular.
Los miembros del equipo Scrum implementan el software.
Ellos deciden conjuntamente la cantidad de requisitos que sin duda
Ahora su trabajo es construir el mejor software posible para
pueden entregar durante un incremento de producto en particular
cumplir con los requisitos del propietario del producto Scrum.
llamado "Sprint".

Las características de los equipos scrum son:

Un equipo de scrum de alto rendimiento tiene la mayoría de las
habilidades de ingeniería de software típicamente en él. Los
• Empoderados y autónomos, •
desarrolladores de software, los arquitectos, los evaluadores, los Multifuncionales, • Autoorganizados y
administradores de bases de datos y los miembros del equipo de
pequeños, • Participantes a tiempo completo,
todos los demás roles trabajan juntos.
• Trabajando en la misma sala, • Uno para
todos, todos para uno.
Construyen y entregan conjuntamente un excelente software
que su cliente está pagando.

Los miembros del equipo Scrum ya no pertenecen a un silo Es un excelente momento para recordar que los miembros del
funcional de una organización matricial. Los desarrolladores ya no
Equipo Scrum siguen los valores de Scrum de manera persistente.
pertenecen a los centros de competencia de desarrollo de software,
y los probadores ya no pertenecen al centro de competencia de
• Coraje •
pruebas de software, y así sucesivamente. Enfoque •
Compromiso

• Respeto •
Apertura

57
Machine Translated by Google

¿Cómo funciona Scrum obtener se puede hacer mucho más cómodo, rápido
y mejor si una persona es responsable de la
Framework sin un Project Manager? ejecución, el control y la documentación de esas
actividades. De lo contrario, siempre existiría una
tensión constante entre el Scrum Product Owner
En un proyecto tradicional, típicamente, un Product
(no responsable del proyecto) y el Project
Manager define los requisitos. Luego, el Product
Manager (no responsable de la ejecución del
Manager delega la realización a un Project Manager.
trabajo).
Posteriormente, el Project Manager coordina todas
las actividades necesarias para cumplir con los
El objetivo de cualquier proceso confiable debe ser
requisitos del proyecto.
evitar este conflicto potencial que afecta la
administración funcional y táctica del trabajo que
Scrum Framework no define un rol de "Gerente
realiza el Equipo Scrum. Y eso es precisamente lo
de Proyecto" en el sentido clásico.
que Scrum Framework pretende lograr. Por lo tanto,
las responsabilidades típicas de los Gerentes de
Y, sin embargo, las tareas de este rol aún son
Proyecto y los Gerentes de Producto se fusionan
necesarias para entregar un proyecto con éxito.
en el rol de Propietario de Producto Scrum.
Dentro del Marco Scrum, las responsabilidades de
un Project Manager se distribuyen entre las funciones
del Scrum Product Owner y el Scrum Master.
Sin embargo, el Scrum Master asume algunas
responsabilidades de un Project Manager tradicional.
La definición del rol y responsabilidades del Scrum
Entre sus funciones se encuentran el seguimiento
Product Owner tiene en cuenta los posibles conflictos
de las tareas en Sprints y facilitar la resolución
que puedan surgir entre el Product Owner y el Project
de impedimentos. Dado que él o ella es parte del
Manager. Decisiones sobre funcionalidad,
Equipo Scrum, es mucho más fácil y mucho más
planificación de lanzamientos y brotes
eficiente manejar tales actividades directamente en el equipo.

58
Machine Translated by Google
Historias de usuarios de Scrum
Las entradas en Scrum Product Backlog a menudo
se escriben en forma de Historias de usuario. Una
historia de usuario cuenta una breve historia sobre
los requisitos de alguien mientras usa el producto
de software que estamos construyendo.
Tiene un nombre, una narración breve y criterios de
aceptación para que la historia se cuente como completa.
La ventaja de las historias de usuario es que se enfocan
precisamente en lo que el usuario necesita y quiere sin
entrar en detalles sobre cómo lograrlo. Cómo lograrlos
será el trabajo del equipo Scrum en una etapa posterior,
Hay diferentes recomendaciones sobre cómo definir las
historias de usuario. Una plantilla bien conocida y
confiable es:
Como [actor], [quiero|debo] [actuar] para que [logre]
O en una versión más corta:
Como [actor], [quiero|debo] [logro]
El actor es el propietario de la historia de usuario.
Eso suele ser un usuario, pero es recomendable ser
más específico. Mediante el uso de actores particulares,
como un administrador, un cliente registrado, un visitante
no autenticado, etc., las historias de los usuarios se
vuelven distintivas. Por lo tanto, establecen los requisitos
en un contexto adecuado que todos puedan entender.
La Acción es lo que el Actor quiere hacer. Si es un
requisito obligatorio, se puede anteponer como debe.
De lo contrario, tiene el prefijo querer.
El Logro es lo que el Actor quiere lograr al realizar
la Acción. Ese es el resultado comercial previsto por el
Actor o un componente técnico funcional que emerge
una vez que se completa la Acción.
59
Machine Translated by Google
Estimaciones de esfuerzo de Scrum –
Planificación Poker®
Todas las historias de usuarios dentro de Scrum Product
Backlog deben estimarse para permitir que Scrum Product
Owner las priorice y planifique los lanzamientos. Eso
significa que el propietario del producto Scrum necesita una
evaluación confiable de cuánto llevará la entrega de cada
historia de usuario.
Sin embargo, se recomienda que el Scrum Product Owner no
interfiera con las estimaciones que realiza el Scrum Team.
Entonces, el equipo Scrum entrega sus estimaciones sin sentir
ninguna presión por parte del propietario del producto Scrum.
Una historia de usuario de ejemplo
El Marco Scrum en sí mismo no prescribe una forma para que
los Equipos Scrum estimen su trabajo.
Los equipos que confían en Scrum Framework no entregan sus
estimaciones de historias de usuarios basadas en unidades de
tiempo o persona-día. En su lugar, brindan sus estimaciones
mediante el uso de métricas más abstractas para comparar
y calificar el esfuerzo requerido para entregar las historias
de los usuarios.
Los métodos de estimación comunes incluyen:
• Tallas numéricas (del 1 al 10), • Tallas
de camisetas (XS, S, M, L, XL, XXL, XXXL) o • la
secuencia de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21,
34, etc.)
60
Machine Translated by Google
Los miembros del equipo Scrum deben compartir un
entendimiento común y un consenso de la unidad de estimación
que utilizan para que todos los miembros del equipo se sientan
y actúen cómodos con ella.
Planificación Poker® / Scrum Poker
Un método comúnmente utilizado para el proceso de
estimación es jugar a Planning Poker® (también llamado
Scrum Poker).
Al usar Planning Poker®, la influencia de la prueba social entre
los miembros del Equipo Scrum es mínima. Por lo tanto, el
Equipo Scrum produce resultados de estimación más precisos.
Lo que necesitas para jugar el juego de Planning Poker® es
sencillo:
• La lista de características a estimar • Barajas
de cartas numeradas.
Una baraja típica tiene cartas que muestran la secuencia de
Fibonacci, incluido un cero: 0, 1, 2, 3, 5, 8, 13, 21,
34, 55, 89. También son posibles otras progresiones similares.
La razón para usar la secuencia de Fibonacci es reflejar la
incertidumbre al estimar elementos más grandes. Sería una
pérdida de tiempo discutir si una historia de usuario debe tener
un tamaño de 19, 20 o 21. Y, sin embargo, es relativamente
más fácil decidir si la historia de usuario se ajusta mejor
al tamaño 13 o 21.
Una estimación alta podría significar que los miembros del
Equipo Scrum aún no han entendido muy bien la historia del
usuario. Por lo tanto, pueden intentar asegurar capacidad
adicional para contingencias antes de comprometerse con
esta historia de usuario. Alternativamente, eso también podría
significar que la historia de usuario debe dividirse en varias
historias de usuario más pequeñas. Los equipos de Scrum
generalmente pueden estimar historias de usuarios más
pequeñas y claras con mayor confianza.
Finalmente, el Scrum Team juega Planning Poker® siguiendo
los siguientes pasos:
• El Product Owner de Scrum presenta la historia a estimar.
El Equipo Scrum hace preguntas y el Product Owner de
Scrum articula la historia del usuario con más detalle. Si el
Equipo Scrum tiene que evaluar muchas historias de
usuarios,
61
Machine Translated by Google

las estimaciones se pueden dividir en un cuadro de tiempo de Planning Poker® es una marca registrada de Mountain Goat
manera que el Equipo Scrum no dedique más de unos minutos Software, LLC.
a cada historia de usuario. Si el equipo aún no puede estimar
una historia de usuario en un período de tiempo determinado,
esta podría ser una señal a la que el propietario del producto
Scrum debe prestar atención. Esta señal indica que el requisito
del usuario final o la historia del usuario o ambos no son lo
suficientemente claros, por lo que deben reescribirse.

• Cada miembro del Scrum Team elige en privado la tarjeta que

representa la estimación. • Después de que todos hayan
seleccionado una carta, se revelan todas las selecciones.

• A las personas con estimaciones altas y bajas se les pide que

expliquen su evaluación porque pueden haber pensado algo
que la mayoría de los miembros del Equipo Scrum no han
podido
para ver.

• Se realiza otra estimación para esta historia de usuario en

particular hasta que el equipo llega a un consenso para una
estimación.

• El Equipo Scrum repite el juego hasta que

estimar todas las historias de usuario.

62
Machine Translated by Google

Definición de Listo (DoD) solo se entregan características verdaderamente completas, no

solo en términos de funcionalidad sino también en términos de
calidad. Las normas que utiliza un Equipo Scrum para definir los
En el marco de Scrum, los factores que definen cuándo se
DoD pueden variar de un equipo a otro, pero deben ser
completa una función y cuándo cumple con los estándares
consistentes dentro de un Equipo Scrum determinado.
de calidad requeridos se establecen mediante la definición
de hecho (DoD).

Por lo general, hay diferentes DoD en varios niveles:

Como se aclaró anteriormente en este material, los DoD
especifican el resultado esperado en términos de requisitos
• DoD para un proyecto/producto (en los objetivos del proyecto)
funcionales y no funcionales, diseño, codificación, pruebas
• DoD para una versión (en los objetivos de la versión) • DoD
unitarias, validaciones del usuario final, documentación, etc. Los
para un sprint (en los objetivos del sprint) • DoD para una historia
DoD se definen en los niveles de las historias de usuario y las
de usuario (en la historia de usuario) • DoD para Tareas (En la
tareas.
tarea)

Los DoD de historias de usuario se enfocan en los requisitos

Una cosa más esencial a tener en cuenta aquí es que un DoD
funcionales y no funcionales del cliente, mientras que los
no es estático ni indiscutible.
DoD de tareas se enfocan en las actividades de trabajo
Durante el curso de un proyecto, un lanzamiento o un sprint,
deseadas de los miembros del Equipo Scrum.
cualquier miembro del equipo de Scrum u otras partes interesadas
del negocio y de TI pueden desafiar un DoD. Siempre que los
El equipo Scrum no puede cerrar las historias de usuario y,
cambios propuestos de un DoD tengan sentido y se mencionen
obviamente, las tareas que no cumplen con sus DoD. La
para llevar el proyecto al éxito, el Scrum Team y el Scrum Product
Definición de Hecho (DoD) se usa para decidir si una Historia de
Owner deben tener la mente abierta para escuchar esas
Usuario del Sprint Backlog está completa o no. DoD es una lista
propuestas e implementarlas cuando y donde sea necesario.
de verificación completa de las actividades requeridas para
garantizar que

63
Machine Translated by Google
La cartera de productos de Scrum
Product Backlog (Scrum Backlog) o Scrum Product
Backlog es el elemento central para gestionar todos
los requisitos conocidos de un Proyecto Scrum.
Consiste en todos los requisitos del cliente y los
resultados del trabajo que se necesitan para ejecutar
y terminar un proyecto exitoso. Como requisitos,
cuenta los requisitos funcionales y no funcionales
y otras características relacionadas con la
experiencia del usuario y el diseño de la interfaz de usuario.
El Product Backlog contiene solicitudes de
características y sus historias de usuario de alto nivel. El propietario del Scrum Product Backlog es el Scrum
Estos también pueden incluir requisitos previos o
complementarios del proyecto, como la creación de
entornos de prueba y desarrollo. Además, otras
historias de usuarios requeridas para resolver errores
conocidos o reducir la deuda técnica o mejorar ciertas
características del software también tienen su lugar en
la Lista de Producto.
Cada Proyecto Scrum tiene su Product Backlog. El
propietario del producto Scrum es responsable de la
creación, el mantenimiento y el ajuste fino de un
Product Backlog. El Product Backlog no responde
ni debería responder a la pregunta de cómo se
desarrollarán y entregarán estos requisitos.
Ese es el deber del Equipo Scrum. El Equipo Scrum
decide y documenta las tareas necesarias para abordar
estos requisitos en los registros de Sprint Back. Tenga
en cuenta que Product Backlog y Sprint Backlog
son entidades físicamente separadas, aunque las
entradas en Product Backlog controlan el contenido
de Sprint Backlog.
Product Owner. El Scrum Master, el Equipo Scrum y
otras partes interesadas lo contribuyen para crear una
lista más amplia de historias de usuarios para llevar el
producto al éxito.
Trabajar con un Scrum Product Backlog no significa
que el Equipo Scrum no pueda crear y usar otros
artefactos para administrar el trabajo.
Ejemplos de artefactos adicionales podrían ser un
64
Machine Translated by Google
resumen de los diversos roles de usuario, descripciones de
flujo de trabajo, pautas de interfaz de usuario, guiones
gráficos o prototipos de interfaz de usuario. Sin embargo,
tenga en cuenta que estos artefactos no reemplazan el
Scrum Product Backlog sino que complementan y detallan
su contenido.
El Product Backlog es un documento vivo.
De manera similar a cómo el software mejora gradualmente,
el Product Backlog también crece con el tiempo. El marco
Scrum no requiere un proceso de gestión de cambios
por separado per se.
El propietario del producto Scrum crea las primeras
versiones del Product Backlog en función de su mejor
comprensión inicial del producto.
Mientras que el propietario del producto Scrum observa de
cerca cómo emerge el producto de un sprint a otro y mientras
aumenta el conocimiento sobre los requisitos del cliente, él
o ella agrega, elimina y afina los requisitos en el Product
Backlog.
El propietario del producto Scrum prioriza los requisitos
en el Product Backlog. Cuanta más prioridad tenga un
elemento en el Product Backlog, más detalles debe contener.
Entonces el scrum
El equipo puede entender fácilmente estos requisitos de
alta prioridad y crear las tareas necesarias para desarrollarlos.
Además, mediante el uso de puntos de la historia, el Equipo
Scrum estima regularmente los requisitos en el Product
Backlog. Estas estimaciones deben ajustarse y mejorarse
para las historias de usuarios de alta prioridad para que
estén listas para las reuniones de planificación de Sprint.
El propietario del producto Scrum utiliza el Scrum Product
Backlog durante las reuniones de planificación de Sprint
para presentar las historias de usuario de mayor prioridad
al equipo Scrum. Luego, el Equipo Scrum determina qué
elementos pueden completar durante el próximo Sprint.
Cada Scrum Product Backlog tiene atributos específicos
que lo diferencian de una simple lista de tareas pendientes:
• Una historia de usuario en Scrum Product Backlog siempre
agrega un valor comercial o técnico a su cliente,
propietario del negocio y usuarios finales.
sesenta y cinco
Machine Translated by Google

• Todas las historias de usuario en Scrum Product Backlog • La especificación de funciones y no

están priorizadas y ordenadas de mayor a menor prioridad. requerimientos funcionales,
• El nivel de detalles almacenados en una historia de • El resumen de desglose de alto nivel del trabajo necesario
usuario depende de su posición dentro de Scrum. para lanzar el producto de software,

Product Backlog, • • Configuración de entornos de desarrollo y demostración

Las historias de usuarios son que no sean de producción. • Reparación de defectos.
estimadas, • Scrum Product Backlog es un documento
vivo, • No hay elementos de acción o tareas de bajo nivel en
la cartera de productos de Scrum.

Las historias de usuarios agregan valor al cliente,

Negocios y Sistemas

Cada historia de usuario en Scrum Product Backlog

debe ofrecer algún valor para el cliente. Las historias de
usuarios sin ningún valor para el cliente son un puro
desperdicio de recursos y deben eliminarse. Scrum Product
Backlog puede incluir historias de usuarios para:

• La exploración de las necesidades del cliente o diversas Ejemplo de acumulación de productos de Scrum

diferentes opciones técnicas,

66
Machine Translated by Google
Algunas tareas pueden no agregar valor directo a la
funcionalidad del sistema de software y los clientes
comerciales. No obstante, deben agregar valor
aumentando la calidad, reduciendo la deuda técnica y
aumentando la mantenibilidad del producto a largo plazo.
Product Backlog es un documento
vivo
El Scrum Product Backlog es un documento vivo.
Cambia y evoluciona a lo largo de todo el curso de un
proyecto. Si es necesario, se agregan nuevas historias
de usuarios, las historias de usuarios existentes se
pueden modificar, definir con más detalle o incluso
eliminar. Los requisitos de los proyectos Scrum ya no se
congelan desde el principio como solíamos tener con la
Metodología Waterfall.
En cambio, el conjunto final de requisitos dentro de
Scrum Product Backlog se desarrolla de forma
iterativa, junto con los incrementos de software
emergentes. Eso es diferente de la ingeniería de
requisitos tradicional. Aún así, esto
La nueva forma de manejar los requisitos del cliente
permite al Equipo Scrum maximizar el valor del cliente y
minimizar el desperdicio de recursos.
Diferente nivel de detalles
Los requisitos en Scrum Product Backlog pueden tener
diferentes profundidades con sus granularidades.
Solo se deben definir con mayor detalle aquellos
requisitos que se implementarán durante los
próximos Sprints. Todas las demás historias de
usuarios deben seguir siendo de grano grueso; solo
deben procesarse "justo a tiempo" antes de que el
Equipo Scrum necesite saber más sobre ellos.
No tiene sentido invertir tiempo y recursos en la
especificación de estos requisitos, ya que algunos de
estos requisitos pueden cambiar o desaparecer hasta
que se necesiten para la implementación. El manejo
"justo a tiempo" de los requisitos es uno de los
beneficios más excelentes que ofrece Scrum
Framework para lidiar con "incógnitas desconocidas"
en sus proyectos.
67
Machine Translated by Google

Sin tareas de bajo nivel en el producto que son tomados en cuenta por el equipo.
Gracias a esta priorización, el propietario del producto
Reserva Scrum puede decidir lo que el equipo Scrum debe construir
y entregar posteriormente.
El Scrum Product Backlog no debe contener un desglose
detallado de las tareas de las historias de los usuarios. El
propietario del producto Scrum define los requisitos junto
Todas las historias de usuarios son estimadas
con los clientes comerciales y las partes interesadas antes
de llevarlos a las reuniones de refinamiento del backlog o
planificación de Sprint. El desglose detallado de tareas y la Todas las historias de usuarios dentro de Scrum Product
distribución de estas tareas entre los miembros del equipo Backlog deben estimarse de acuerdo con la norma
Scrum son responsabilidad del equipo Scrum. acordada de unidades de puntos de historia, como el
número de Fibonacci o S/M/L/XL/XXL, etc. Más adelante
en este material se ofrece más información sobre esto.
Estas estimaciones luego afectan la planificación de
capacidad de Sprints, el contenido de Sprint Backlog y los planes de la
La cartera de productos de Scrum es
Ordenado en función de la prioridad
Trabajando con el Backlog
Todas las historias de usuarios se priorizan y el Scrum
Product Backlog se ordena en función de la prioridad de
El Scrum Product Backlog necesita cuidado y atención
las historias de usuarios (de mayor a menor). El propietario
regulares. Debe administrarse con cuidado porque es la
del producto Scrum realiza la priorización con el apoyo del fuente de la verdad para comprender de qué se trata
equipo Scrum. Durante este ejercicio de priorización, el
su producto de software.
valor agregado creado para el negocio del cliente, costos,
riesgos y dependencias son los factores más comunes

68
Machine Translated by Google
Al comienzo de un proyecto, está lleno de muchas
historias de alto nivel que pueden o no ser muy relevantes
para contribuir al éxito del proyecto. Mientras el proyecto
avanza de un Sprint a otro, el Product Owner de
Scrum y el equipo aprenden más sobre el proyecto.
Posteriormente, el contenido de Scrum Product Backlog
se volverá perfectamente razonable para reflejar mejor su
producto.
Después de esta configuración inicial, el Scrum Product
Backlog debe mantenerse continuamente. El mantenimiento
de Scrum Product Backlog significa:
• A medida que se descubren nuevos requisitos, se
describen y agregan. Los requisitos existentes pueden
cambiarse o eliminarse según corresponda. • Ordenar
(priorizar) el Scrum Product Backlog. Las historias de
usuario más importantes (prioridad más alta) se mueven
a la parte superior, • Preparar las historias de usuario
de alta prioridad para las próximas reuniones de
planificación de Sprint (generalmente durante las
reuniones de refinamiento de tareas pendientes),
• (Re-)estimar las historias de usuario en el Scrum Product
Backlog (generalmente durante las Reuniones de
Refinamiento del Backlog).
El propietario del producto Scrum es responsable de
asegurarse de que el Scrum Product Backlog esté
siempre en buen estado. Y, sin embargo, mantener
Scrum Product Backlog es un proceso colaborativo.
Se debe reservar una capacidad razonable de los
miembros del Equipo Scrum para administrar el Scrum
Product Backlog durante el tiempo que necesitan pasar
durante Scrum Rituals (Eventos).
Además, tenga en cuenta que este mantenimiento
colaborativo de Scrum Product Backlog ayuda a aclarar
los requisitos y crea la aceptación del producto de software
emergente por parte de los miembros del Equipo Scrum.
69
Machine Translated by Google
La acumulación de Sprint
Sprint Backlog almacena y mantiene las historias de
usuario necesarias para entregar el incremento de
software entregable de un Sprint.
Estas historias de usuario son las que el Equipo Scrum
comprometió durante la Reunión de Planificación del Sprint.
Todas las historias de usuarios en Sprint Backlog se
estiman para permitir el monitoreo y seguimiento del trabajo.
El Sprint Backlog es un artefacto vivo, y durante el
transcurso del Sprint, los miembros del equipo Scrum
lo actualizan continuamente.
Cuando un miembro del Equipo Scrum trabaja en una
tarea, su nombre se asocia con ella. El estado de la tarea
se establece en "Tareas iniciadas" o "Trabajo en curso".
Cuando la tarea se completa de acuerdo con su Definición
de Hecho, su estado se establece en "Terminado" o
"Completado".
Se pueden agregar nuevas tareas (no nuevas historias de
usuario) al Sprint Backlog durante el Sprint. Al final
de cada día, se calcula el esfuerzo restante para entregar
el Sprint Backlog completo. Esto ayuda al equipo Scrum y
al propietario del producto Scrum a monitorear la cantidad
de trabajo restante para llevar las metas del Sprint al éxito.
El Sprint Backlog se puede mantener electrónicamente
mediante el uso de un software de gestión de proyectos
Scrum o un software de hoja de cálculo como Excel o
Google Sheet. Alternativamente, para equipos más
pequeños y nuevos, también se pueden usar tarjetas (o
post-its) pegadas en un tablero físico real.
Este último tiene algunas ventajas, como la transparencia
del trabajo y el fácil acceso para todos, incluidas las partes
interesadas. Su desventaja es que no es sostenible si el
Equipo Scrum se distribuye en varias ubicaciones.
La siguiente figura muestra un ejemplo de cómo se puede
construir un Sprint Backlog Board de este tipo. La estructura
debe adaptarse para reflejar las necesidades del proyecto
y del Equipo Scrum.
70
Machine Translated by Google

a Sprint Backlog para lograr los objetivos del

Sprint.

Durante la Reunión de Planificación de Sprint,

todos los miembros del Equipo Scrum deben
discutir qué tareas se deben realizar y cómo se
completarán estas tareas.

Es en este punto que cada elemento del Sprint

Backlog se divide en tareas o pasos que se tomarán
para completar las historias de usuario
comprometidas. Todo esto debe comunicarse
claramente y acordarse, de modo que los miembros
Un tablero de trabajo pendiente de Sprint de muestra del Equipo Scrum tengan un consenso inequívoco
sobre lo que viene en el Sprint y lo que se necesita
para lograr sus objetivos.
Es evidente que para que un equipo Scrum funcione
de manera productiva, deben comprender la
diferencia entre un Product Backlog y un Sprint
Backlog, y cómo interactúan estos dos elementos
para ejecutar el proyecto.

Recuerda que hay una lista completa de historias

de usuarios del Product Backlog. Y ahora, se
está moviendo un pequeño subconjunto de esta lista

71
Machine Translated by Google
¿Qué es un Sprint?
En el marco de Scrum, todas las
actividades para implementar los
requisitos ocurren durante los Sprints.
Los sprints son ciclos de actividades de trabajo para
desarrollar incrementos de servicios o productos de
software entregables. Los sprints también se denominan
a veces iteraciones.
Piensas en los sprints como si fueran microproyectos.
Como implica el término "Sprint", un sprint no lleva
mucho tiempo y tiene una duración máxima de cuatro
semanas.
Los sprints siempre son cortos, normalmente entre
2 y 4 semanas. Pero dependiendo de la cantidad de
trabajo prevista de forma fiable o para los Sprints de
exploración, también es típico un Sprint de una semana
de duración. Con la aprobación del propietario del
producto Scrum, un equipo Scrum puede necesitar
un Sprint de exploración para investigar nuevas
tecnologías, crear una maqueta o una prueba de concepto. miembros del equipo Scrum también pueden pedir ayuda al Scrum
A diferencia de una carrera a pie, al final de un Sprint, el
Equipo Scrum no debería quedarse sin aliento ni energía.
En cambio, el equipo Scrum debe estar fresco y debe
comenzar con energía el próximo Sprint.
El Marco de Desarrollo y Entrega de Software Scrum no
tiene nada que hacer para crear presión y estrés para los
miembros de su equipo. Es un hecho bien conocido que
las personas se desempeñan mejor cuando pueden
trabajar concentradas, aliviadas y sin distracciones. Si se
aplica correctamente, esto es lo que Sprints nos ayuda a
lograr.
Cada Sprint comienza con una reunión de planificación
de Sprint. Durante la Reunión de Planificación de Sprint,
el Equipo Scrum decide qué y cuántos requisitos
implementará en este Sprint dado. Posteriormente, el
Equipo Scrum inicia la ejecución de actividades para
entregar los requisitos.
Daily Scrum (Reunión diaria de Scrum) ocurre todos
los días a la misma hora en el mismo lugar.
El objetivo de esta reunión es alinear a todos los
miembros del Equipo Scrum con regularidad. Los
72
Machine Translated by Google

Master para eliminar cualquier impedimento que pueda

ralentizar o bloquear el progreso de un Sprint.

El Equipo Scrum finaliza un Sprint con reuniones de

Revisión de Sprint y Retrospectiva de Sprint.
La reunión de revisión de Sprint le permite al propietario del
producto Scrum revisar y controlar los resultados del trabajo
que el equipo Scrum ha creado durante el Sprint.

Durante la reunión de retrospectiva de Sprint, el equipo

Scrum refleja la forma en que trabajan juntos, cómo usan el
marco Scrum y cómo pueden mejorar.

Entonces, el equipo Scrum toma en cuenta estos potenciales
de mejora y comentarios durante la próxima reunión de
planificación de Sprint. Los sprints permiten tales bucles
de retroalimentación durante períodos cortos con lotes
de trabajo pequeños.
Los sprints son ciclos de actividades de
trabajo para desarrollar incrementos de
servicios o productos de software entregables.

Esa es una de las razones importantes por las que el

marco Scrum ayuda a los equipos y las organizaciones
a mejorar continuamente.

73
Machine Translated by Google
Gráfico de desarrollo de Scrum
El "Scrum Burndown Chart" es una herramienta de
medición visual que muestra el trabajo completado por
Sprint frente a la tasa de finalización proyectada para la
versión actual del proyecto.
Su propósito es permitir que el propietario del producto
Scrum, el equipo Scrum y otras partes interesadas controlen
el progreso del proyecto. Entonces, el Equipo Scrum logra
entregar la solución de software solicitada dentro del
cronograma deseado.
Gráfico de evolución de Scrum simple
La velocidad/tasa de progreso de un Equipo Scrum se
llama "Velocidad". Expresa el número total de puntos
de historia completados que el Equipo Scrum entrega
por Sprint (Iteración).
Una regla esencial para evaluar y calcular la Velocidad es
que; Solo se cuentan las historias de usuario completamente
completadas que cumplen con precisión su Definición de
Listo (DoD). El cálculo de la velocidad no debe tener en
cuenta las historias de usuario parcialmente completadas.
(Por ejemplo, se realiza la codificación de una historia de
usuario, pero aún faltan sus pruebas)
Solo unos pocos Sprints después de que se forma un nuevo
Equipo Scrum, la Velocidad del equipo se puede calcular
de manera confiable. Eso ayuda al propietario del producto
Scrum a predecir mejor el rendimiento del equipo Scrum, y
puede prever qué historias de usuario puede entregar el
equipo Scrum en un Sprint determinado. Eso permitiría al
propietario del producto Scrum planificar lanzamientos de
software con mayor precisión, con menos sorpresas para
los clientes comerciales y los usuarios finales.
Como un ejemplo simple: Supongamos que la Velocidad de
su Equipo Scrum es de 50 puntos de historia por Sprint.
74
Machine Translated by Google

Y la cantidad total de trabajo restante se ha estimado

en 300 puntos de historia. Luego, puede predecir que
necesita 6 Sprints para entregar todas las historias de
usuario restantes del Product Backlog.

Sin embargo, en realidad, las historias de usuario

en Scrum Product Backlog cambiarán a lo largo del
proyecto. Se agregan nuevas historias y se modifican
o incluso eliminan otras historias.

En el Gráfico de Burndown Simple, la Velocidad del Gráfico de trabajo pendiente extendido

Equipo Scrum y el cambio del alcance no se pueden
visualizar con precisión. Para aumentar esta precisión
y visibilidad perdidas, los Equipos Scrum usan otro
tipo de diagrama, al que llamamos "Gráfico de
Burndown Extendido".
El gráfico de trabajo pendiente extendido utiliza un
gráfico de barras en lugar de un diagrama de líneas. El
tamaño de cada barra representa el número total de
historias de usuario restantes al comienzo de cada
sprint. La Velocidad del Equipo Scrum se resta de la
barra superior, mientras que los cambios del Product
Backlog se presentan en la parte inferior de la barra.
Separación de cambios de velocidad y alcance
Para obtener resultados aún más precisos con el
Burndown Chart, también podemos tener en cuenta
la tasa de cambios en el trabajo total. Llamamos a
este modelo más preciso "Gráfico de trabajo
pendiente extendido con predicción". Sin embargo,
debemos tener cuidado al usar este modelo. La
magnitud de los cambios en el Product Backlog será
relativamente mayor al principio. suelen caer y se
aproximan a cero hacia el final del proyecto.

75
Machine Translated by Google

Gráfico de trabajo pendiente extendido con predicción

76
Machine Translated by Google

Sprint Burndown ChaRT (informe esfuerzos Todos los días se suma el esfuerzo
restante que debe completarse hasta el final del
de Sprint Burndown) Sprint y se registra en este gráfico.

El Sprint Burndown Chart (Informe de Sprint Burndown)

visualiza el progreso dentro del Sprint para alcanzar
la meta del Sprint.

Permite la transparencia y los datos de progreso

procesables sobre el rendimiento real (índice de quemado)
del Equipo Scrum. Eso le permite al propietario del
producto Scrum y al equipo Scrum monitorear fácilmente
cómo va el Sprint. Gracias a esta descripción general
proporcionada por el Sprint Burndown Chart, el equipo
puede predecir si el objetivo del Sprint se puede lograr
hasta el final del Sprint a tiempo.
Informe/Gráfico de Burndown de Sprint

De lo contrario, el Scrum Master y el Equipo Scrum deben

Vale la pena recordar eso; Mientras se forma un nuevo
considerar e implementar otras medidas para acelerar la
equipo de Scrum, el rendimiento a menudo no es tan
ejecución de las tareas restantes y las historias de usuario
bueno como lo imaginó la tasa de quemado ideal. Eso
en el Sprint Backlog.
generalmente sucede debido a estimaciones incorrectas o
impedimentos imprevistos que deben eliminarse para que
el Equipo Scrum funcione a toda velocidad.
En el Sprint Burndown Chart, el Sprint inicial
Backlog define el punto de inicio para el resto

77
Machine Translated by Google
Reunión de planificación de Sprint
Durante la Reunión de Planificación de Sprint, el Equipo
Scrum crea un Sprint Backlog viable, que determina las
historias de usuario y las tareas que el equipo
implementará hasta el final de este Sprint (Incremento
de Producto).
Una reunión de planificación de Sprint consta de dos
partes, a saber, la reunión QUÉ y la reunión CÓMO.
Como lo implican esos nombres, la reunión QUÉ se enfoca
en el alcance de un Sprint, mientras que la reunión CÓMO
se enfoca en cómo se implementará este alcance.
Durante las reuniones de planificación de Sprint, la presencia
del propietario del producto Scrum es obligatoria. Para que
pueda responder preguntas del Equipo Scrum y aportar
aclaraciones sobre los requisitos y sus criterios de
aceptación.
Las partes interesadas, como los usuarios finales o
los gerentes de línea, pueden unirse a las reuniones de
planificación de Sprint como audiencias de solo lectura.
No se les permite influir en el flujo de la reunión de planificación dereunión
El objetivo del sprint
El Product Owner de Scrum define el Sprint Goal. Es una
descripción concisa y realista de lo que Sprint intentará
lograr para el negocio, los usuarios finales y los sistemas
de TI.
La capacidad del equipo
La capacidad total del Equipo Scrum puede cambiar de
Sprint a Sprint. Para hacer compromisos realistas, el
Equipo Scrum necesita conocer su capacidad para el
próximo Sprint.
El equipo necesita tener en cuenta las vacaciones, los días
festivos, el tiempo dedicado a Scrum Rituals y una pequeña
contingencia por problemas imprevistos para proponer una
capacidad razonable.
La reunión QUÉ
Una reunión de planificación de Sprint comienza con una
Sprint. de QUÉ. Requiere cierta preparación:
78
Machine Translated by Google
• El propietario del producto Scrum define el Sprint
Meta.
• Con base en este objetivo, el propietario del producto
Scrum elige las historias de usuario candidatas para el
Sprint del Scrum Product Backlog. • Estas historias de
usuario se editan y dividen en historias de usuario más
pequeñas cuando es necesario para que puedan
procesarse dentro de un Sprint. • Las historias de usuario
son estimadas y priorizadas. • El Equipo Scrum planifica
su capacidad para el
próximo Sprint.
Los deberes de varios roles de Scrum durante el transcurso
de la parte WHAT-Meeting de Sprint
Las Reuniones de Planificación son las siguientes:
• El Propietario del Producto presenta el objetivo del Sprint
y su preselección de requisitos, que deben incluirse en
el incremento del producto. • El Equipo Scrum identifica
las tareas requeridas y sus estimaciones. El papel del
equipo Scrum es decidir cuáles y cuántos requisitos
preseleccionados por el propietario del producto que
pueden cumplir con confianza en este Sprint.
• El Scrum Master modera la reunión. Ella se asegura de
que la autoorganización y la capacidad de toma de
decisiones autónoma del Equipo Scrum permanezcan
intactas.
La reunión CÓMO
El objetivo de HOW-Meeting es llenar el Sprint Backlog
identificando las tareas concretas necesarias para
implementar historias de usuarios comprometidos para el
Sprint. Estas tareas por lo general (pero no se limitan a)
incluyen actividades como análisis, diseño, desarrollo,
pruebas, empaquetado de compilación de software y
documentación.
La Reunión-CÓMO se puede realizar en una sesión
separada después de la Reunión-QUÉ, o puede seguir a la
Reunión-QUÉ sin pausa.
Después de identificar las tareas a completar, el Scrum
Team estima estas tareas. La unidad para esta estimación
puede ser horas-persona. Según estas estimaciones, el
equipo ahora tiene una línea de base sobre cuánto tiempo
les llevará entregar cada historia de usuario.
79
Machine Translated by Google

Reunión diaria de Scrum / Reunión Las reuniones diarias de Scrum están estructuradas
de la siguiente manera. Cada miembro del Scrum
diaria de pie Team responde tres preguntas.

• Reunión diaria de Scrum - Pregunta n.º 1:

La reunión diaria de Scrum es una reunión máxima
¿Qué actividades he realizado desde la última
de 15 minutos. Estas reuniones tienen lugar todos los
reunión diaria de Scrum?
días hábiles a la misma hora en el mismo lugar.

• Reunión diaria de Scrum - Pregunta n.º 2:

¿Qué actividades planeo realizar hasta la próxima
Lo mejor es realizar reuniones diarias de Scrum con
reunión diaria de Scrum? ¿Cuál es mi plan de acción?
acceso directo a Sprint Backlog y Sprint Burndown
Chart. Entonces, el equipo Scrum puede dirigir la
reunión diaria de Scrum en función de los hechos
• Reunión diaria de Scrum - Pregunta #3:
y el progreso que son visibles para todos en el
equipo. ¿Encontré o espero algún impedimento que pueda
ralentizar o bloquear el progreso de mi trabajo?

Daily Scrum Meeting tiene como objetivo apoyar la

autoorganización del Equipo Scrum e identificar
El Scrum Master tiene que moderar las reuniones
impedimentos sistemáticamente.
diarias de Scrum.
Todos los miembros del Equipo Scrum, el Scrum
Master y el Scrum Product Owner deben unirse a Daily Debe garantizar un progreso disciplinado y rápido para
que todos los miembros del equipo puedan responder
Scrums. Otras partes interesadas también pueden
estas tres preguntas en un máximo de 15 minutos.
unirse a estas reuniones, pero solo como audiencia de
solo lectura.

80
Machine Translated by Google

El objetivo de las reuniones diarias de Scrum no

incluye dar decisiones que consumen mucho tiempo
o resolver problemas.

Por otro lado, ningún problema o inquietud de ningún

miembro del Equipo Scrum debe ignorarse o socavarse
debido a la limitación de tiempo de la Reunión Scrum
diaria. Las inquietudes asociadas con historias de
usuarios específicas deben articularse, discutirse y
resolverse claramente después de la reunión con los
miembros del Equipo Scrum en relación con estas
historias de usuarios.

Para alinearse en las decisiones y resolver problemas,

el equipo Scrum puede organizar reuniones
separadas bajo demanda. Estas reuniones separadas
para enfocarse en decisiones o problemas generalmente
se llevan a cabo después de las reuniones diarias de Scrum.

El Scrum Master documenta los impedimentos

identificados y sus fechas en un registro, rotafolio o
informe separado al que puede acceder el equipo.
Nos parece muy beneficioso actualizar rápidamente el
estado de todos los impedimentos conocidos al final de
las reuniones diarias de Scrum.

81
Machine Translated by Google

Reunión de revisión de sprint equipo entregó los requisitos que se habían comprometido
durante la reunión de planificación de Sprint con precisión o no.

La Reunión de Revisión del Sprint ocurre al final del Sprint.

Independientemente de la duración del Sprint, generalmente
La reunión de revisión de Sprint permite al propietario del
toma de una a dos horas.
producto inspeccionar el estado actual del producto y adaptar
Según el tipo de software y la infraestructura disponible, las
los objetivos del Sprint posterior. Por lo tanto, las reuniones
reuniones de revisión de Sprint se llevan a cabo en una sala
de revisión de Sprint son otra forma de aplicación formal y
de reuniones, en un laboratorio o en la sala del equipo Scrum.
práctica de "inspeccionar y adaptar".

El objetivo de la reunión de revisión de Sprint es revisar el

Los participantes de la reunión de revisión de Sprint son el
incremento de productos entregables creado durante el equipo Scrum, el propietario del producto Scrum, el Scrum
Sprint y aportar transparencia al proceso de desarrollo de
Master. Opcionalmente, todas las demás partes interesadas,
productos.
como usuarios finales, clientes y representantes comerciales,
pueden unirse a las reuniones de revisión de Sprint.
Los miembros del Equipo Scrum no necesitan preparar una
presentación de Powerpoint o Keynote para mostrar en las
En las reuniones de revisión de Sprint, todos pueden
Reuniones de Revisión de Sprint. En su lugar, deberían enviar sus comentarios sobre el incremento del producto
gastar su energía en completar y demostrar con éxito el
demostrado.
resultado del Sprint, lo que llamamos el incremento del
producto entregable.
De esta manera, el equipo de Scrum tiene la oportunidad de
obtener información directa y sin filtrar de las partes interesadas
para quienes están creando el software.
El equipo Scrum demuestra los resultados de su trabajo.
El propietario del producto controla si Scrum

82
Machine Translated by Google
Reunión retrospectiva de Sprint
El objetivo de las Reuniones Retrospectivas de
Sprint es mejorar el trabajo en equipo de los
miembros del Equipo Scrum y la aplicación del
proceso Scrum.
La reunión de retrospectiva de Sprint ocurre directamente
después de la reunión de revisión de Sprint y cierra el
Sprint.
Por lo tanto, las Reuniones Retrospectivas de Sprint
conducen a un aumento en la productividad, el
desempeño de los miembros del Equipo Scrum y la
calidad del software diseñado.
La Retrospectiva de Sprint es una parte integral del
proceso de "inspeccionar y adaptar". Sin esta reunión, el
Equipo Scrum nunca podrá mejorar su rendimiento
general y no podrán concentrarse en mejorar el
desempeño del equipo.
Recuerda esto: ¡En lo que te enfocas es en lo que se
vuelve mejor!
Una reunión retrospectiva de Sprint es prácticamente
una mini autopsia para definir los potenciales de mejora
y eliminar los obstáculos relacionados con el proceso.
Algunos ejemplos de estos potenciales de mejora que
vemos con frecuencia en nuestros proyectos son:
• Adopción de prácticas ágiles de desarrollo de
software como programación extrema (XP)
o desarrollo dirigido por pruebas
(TDD), • Identificación de nuevas normas y principios
de equipo, o • Mayor disponibilidad del Producto
Scrum
Dueño.
Sin excepción, el equipo Scrum realiza reuniones
retrospectivas de Sprint al final de cada Sprint.
Solo de esta manera, estas reuniones permiten al Equipo
Scrum adaptar y mejorar sistemáticamente su uso del
proceso Scrum a las especificaciones de su proyecto.
83
Machine Translated by Google

PREPARACIÓN DE SCRUM (CARTERA • Actualizar las prioridades de las historias de

usuario. • Divida las historias de usuarios gigantes en historias de
REFINAMIENTO) REUNIÓN usuarios más pequeñas digeribles y priorícelas en consecuencia.

Scrum Backlog Refinement (Grooming) Las reuniones tienen

Aquí están nuestras otras sugerencias para mejorar los resultados
como objetivo mantener actualizado el Product Backlog. Por lo
de las Reuniones de Refinamiento de Backlog:
tanto, Product Backlog refleja el mejor conocimiento y comprensión
del equipo Scrum sobre el proyecto Scrum en curso.
• Garantice la participación entre equipos, lo que significa que
identifica las dependencias lo antes posible, • Dimensione las
historias de usuario correctamente, lo que significa que todas
Las reuniones de Scrum Backlog Refinement pueden realizarse bajo
las historias de usuario pueden resultar en un incremento de
demanda o de forma programada hasta dos veces por semana, 30
producto entregable dentro de un solo Sprint, • Priorice las
minutos cada sesión. El Scrum Team, el Scrum Product Owner y el
historias de usuario, lo que significa que entregue valor
Scrum Master participan en estas reuniones.
inmediato a los usuarios finales, permita ganancias rápidas y hágalos
felices, • Estime como un profesional, lo que significa que
obtendrá información práctica para una planificación de
Durante las reuniones Scrum Backlog Refinement (Grooming),
lanzamiento confiable, • Identifique las dependencias, lo que
los participantes afinan el Product Backlog con las siguientes
significa que incorporará los equipos y recursos necesarios para
acciones:
hacer su proyecto sea un éxito, • Descubrir riesgos, lo que significa
que evitará sorpresas tediosas durante las últimas etapas de su
• Agregue nuevas historias de usuario en función de los requisitos
proyecto.
recién descubiertos. • Eliminar las historias de usuario que ya no
están
requerido para el producto. •
Afinar estimaciones de historias de usuarios.

84
Machine Translated by Google
MARCO Escalado de Scrum
(Distribuido y Scrum grande
Proyectos)
El Marco Scrum, como se ha descrito hasta ahora,
funciona mejor para un solo Equipo Scrum en una
ubicación. Sin embargo, en realidad, un solo equipo
Scrum a menudo no puede implementar un proyecto por
completo, o los miembros del equipo tienen que distribuirse
en varias ubicaciones.
Como consecuencia, el número de equipos tiene que
aumentar con varios equipos distribuidos. En muchos
casos, también hemos estado observando que esos
equipos están distribuidos en lugares o continentes
geográficamente distantes.
Hay numerosas razones que motivan a las organizaciones
a distribuir sus equipos en diferentes ubicaciones:
• Razones técnicas: Algunos conocimientos para construir
componentes separados del software no están
disponibles localmente en la sede,
• Razones de experiencia: algunas capacidades
relacionadas con la ejecución de diferentes actividades
de ingeniería de software no están disponibles
localmente. Por ejemplo, la automatización de pruebas,
el diseño de la interfaz de usuario o la integración de
software interno con el software de otros proveedores
pueden requerir expertos fuera de la sede central.
• Razones relacionadas con el tamaño: el proyecto
requiere más personas para entregarlo a sus clientes
en un cronograma predefinido. Si este es el caso,
entonces la organización del proyecto necesitará más
miembros de los que posiblemente pueda caber en un
solo Equipo Scrum. Entonces, el Equipo Scrum tiene
que estar distribuido,
• Razones relacionadas con el negocio: el uso de
recursos humanos de ubicaciones de menor costo o
permitir la continuidad del trabajo mediante el uso de
ingenieros de diferentes zonas horarias podría generar
un buen caso comercial.
Dado que la comunicación es una parte integral del Marco
Scrum, todos los miembros del Equipo Scrum deben
prestar atención para superar los desafíos de trabajar en
un entorno de proyecto distribuido. Además, todos los
miembros del equipo deben tener acceso a
herramientas de comunicación,
85
Machine Translated by Google

incluidas conferencias de audio/video y herramientas para

compartir pantalla.

Estas herramientas de gestión de proyectos de uso común apoyan

a los equipos para permitir una comunicación saludable y continua.
Esos pueden incluir registros de productos atrasados, atrasos de
sprints, listas de incidentes, conocimiento/
herramientas para compartir noticias, etc.

Organización del proyecto:

Múltiples equipos

La forma más sencilla de expandir el trabajo de Scrum Framework

mientras se trabaja en una configuración de proyecto a mayor
escala es aumentar la cantidad de equipos en la misma ubicación.

Múltiples equipos en una sola ubicación

Si varios equipos necesitan trabajar juntos para implementar

un proyecto, es mejor aumentar la cantidad de equipos
En la mayoría de las organizaciones, el crecimiento progresivo es
progresivamente.
más manejable que lanzar diez nuevos equipos diferentes de una
sola vez. La mejor práctica es comenzar con un solo Equipo Scrum.
¿Qué significa esto para usted?
Después de algunos Sprints exitosos, uno o dos Equipos Scrum
adicionales pueden unirse al proyecto. Una vez que se asegure de
que estos

86
Machine Translated by Google
varios equipos Scrum funcionan bien juntos, puede
seguir agregando más equipos Scrum a su organización
de proyecto distribuida.
Aumentar el número de equipos
Hay dos formas típicas de crear nuevos
Equipos Scrum:
• Divide un Equipo Scrum existente en varios equipos
y agrega nuevos miembros del Equipo Scrum donde
y cuando sea necesario,
• Construye un nuevo equipo Scrum con ingenieros
completamente diferentes que no han participado
en el proyecto hasta el momento.
Dividir un equipo Scrum existente tiene la ventaja
de aprovechar a los miembros del equipo Scrum
que ya tienen conocimientos y que ya han
experimentado con el proyecto en curso.
Por lo tanto, esos nuevos equipos suelen ser al menos
hasta cierto punto productivos tan pronto como se
forman. El principal inconveniente de este escenario
es que el Scrum Team existente y completamente
funcional ahora se ha dividido en dos equipos. Eso
siempre podría causar algunos problemas con la
motivación de los miembros del Equipo Scrum.
Especialmente si esos cambios están ocurriendo
sin un anuncio previo y una justificación por parte
de la alta dirección, y cuando los miembros del
equipo no están mental ni técnicamente preparados.
Al agregar equipos completamente nuevos, estos
equipos ya existentes pueden continuar con sus
Sprints sin ninguna interrupción ni esfuerzo de
integración adicional. Sin embargo, llevará más tiempo
87
Machine Translated by Google

desarrollar el conocimiento y el impulso necesarios para
impulsar los equipos Scrum completamente recién
formados.
Independientemente de la decisión sobre cómo agregar
nuevos Equipos Scrum a su organización, tenga en cuenta
los siguientes principios:
Las barreras de comunicación entre las personas, las
dificultades de coordinación del trabajo y los malentendidos
de las normas del proyecto conjunto entre los equipos son
solo algunas de las muchas cuando se trata de mencionar
esta complejidad.

• Comience con una pequeña cantidad de equipos

Scrum, • Aumente la cantidad de equipos
gradualmente, • Asegure la continuidad del trabajo y la
entrega fluida de software y valor comercial durante los
tiempos de cambio y crecimiento, • Si hay problemas
significativos que obstaculicen la productividad y la
continuidad del trabajo, primero enfóquese en arreglarlos
en lugar de la expansión con nuevos Equipos Scrum.

Organización del proyecto:

Equipos distribuidos

La mayor complejidad de los equipos múltiples se

manifiesta cuando los nuevos Equipos Scrum deben
distribuirse en varias ubicaciones. Múltiples equipos en múltiples ubicaciones

88
Machine Translated by Google
Las consecuencias de no abordar estos desafíos son
graves.
Las empresas tienen que contar miles de millones de
dólares de presupuesto de TI desperdiciado debido a la
falta de sus habilidades en Liderazgo Organizacional y
experiencia en Scaled Scrum.
Hay cuatro sugerencias críticas para que pueda hacer
frente a estos desafíos:
1. Se asegura de que los nuevos miembros del Equipo
Scrum estén capacitados en el Marco Scrum como
Experto en Scaled Scrum,
2. Se asegura de que los nuevos miembros del Equipo
Scrum conozcan el proyecto de manera adecuada, de
modo que tengan una comprensión adecuada de para
qué están sirviendo. No solo desde el punto de vista
técnico sino también desde el punto de vista del valor
comercial profesional, para que puedan tomar
decisiones en su trabajo para aumentar el valor de su
contribución.
3. Te aseguras de que se establezcan las normas del
proyecto. Similar a un solo Equipo Scrum, que
tiene sus normas sobre cómo comunicarse, cómo
planificar, cómo hacer el trabajo, una organización de
equipos de proyectos múltiples también debe tener sus
normas de nivel superior. Por lo tanto, estos equipos
pueden comunicarse, planificar, operar, resolver
problemas y entregar valor al cliente y al negocio juntos.
4. Te aseguras de que los nuevos miembros del equipo
trabajen, al menos temporalmente, junto con los
miembros experimentados del proyecto. Eso podría
requerir visitas remotas al sitio y capacitación en el
trabajo. Eso está totalmente bien e incluso deseado.
Gracias a este enfoque, el conocimiento se puede
transferir sin problemas y se puede establecer un
diálogo bidireccional y personal entre personas en
diferentes equipos y ubicaciones.
Equipos virtuales
Otra opción de un Scrum Team distribuido es tener a
sus miembros repartidos en múltiples ubicaciones.
Tal equipo se llama "Virtual
Equipo".
89
Machine Translated by Google
El principal desafío aquí es garantizar una comunicación
impecable entre los miembros del equipo.
Los miembros del Equipo Scrum aún deben realizar todos los
Rituales Scrum (Eventos Scrum) para coordinar su trabajo, pero
ahora deben hacerlo mientras no todos estén presentes en la
misma sala.
Equipos virtuales
Los miembros del Equipo Scrum ubicados en la misma
ubicación aún deben trabajar juntos en la misma sala. Y, sin
embargo, ahora tienen que confiar más en el uso de
herramientas de colaboración y comunicación.
Pueden unirse a Scrum Events desde la misma sala de
reuniones para conectarse con la otra mitad del equipo virtual
a través de tecnologías de videoconferencia.
Equipo de propietarios de productos Scrum
Como hemos cubierto muchas veces en este material hasta
ahora, la comunicación regular entre el propietario del producto
Scrum y el equipo Scrum es crucial para la entrega exitosa de
un proyecto.
Necesitamos asegurarnos de que el propietario del producto
Scrum esté siempre disponible para los equipos Scrum ubicados
en diferentes ubicaciones. Por lo tanto, a menudo es
necesario que varios propietarios de productos Scrum
trabajen juntos. Idealmente, hay un propietario de producto
Scrum dedicado para cada equipo.
Los propietarios de productos Scrum deben crear un "Equipo
de propietarios de productos Scrum" dedicado para trabajar
90
Machine Translated by Google

juntos de manera efectiva. Uno de los propietarios de productos historias de usuarios específicas que requieren la atención y los
de Scrum debe ser asignado al rol de "Propietario de producto resultados de múltiples equipos de Scrum.
de Scrum en jefe".

Él o ella es responsable de garantizar que: Equipos de componentes frente a funciones

• El producto correcto está construido para satisfacer las
demandas de su cliente, • Todos los propietarios de productos
Scrum colaboran de manera eficiente
y permiten que sus equipos desarrollen el valor comercial y
técnico para sus clientes.
Al distribuir el trabajo entre diferentes equipos, podemos
hacer que los equipos sean responsables de componentes
o funciones de software específicas.
Es por eso que los llamamos "Equipo de componentes" o "Equipo
de características".

Dado que el equipo de propietarios de productos de Scrum

es responsable de la ingeniería de requisitos completa, es

Equipos de componentes
beneficioso tener otras competencias y partes interesadas
en este equipo.
Cuando se utilizan equipos de componentes, cada equipo
Estos pueden incluir a los representantes del caso comercial, las
solo es responsable de la implementación de componentes
partes interesadas relevantes, los arquitectos empresariales y los
dedicados del sistema general. Para terminar una historia de
arquitectos tecnológicos.
usuario, generalmente es necesario dividir las historias de usuario
en partes más pequeñas para implementarlas dentro de un solo
Todos los propietarios de productos Scrum deben trabajar dentro
componente. Las dependencias entre los componentes de estos
de un solo gran Backlog de productos Scrum que contenga todas
equipos de componentes hacen que la integración continua sea
las historias relevantes para el proyecto. Cada Equipo Scrum es
una parte inevitable de las entregas exitosas.
responsable de entregar algunas de estas historias de usuarios.
Y, sin embargo, todavía habrá casos de

91
Machine Translated by Google

Equipo de propietarios de productos Scrum

92
Machine Translated by Google

Por lo tanto, una función generalmente no se puede entregar
dentro de un Sprint porque su implementación depende de los
entregables de las historias de usuarios de otros equipos.
Eso da como resultado un aumento en el tamaño de los lotes
y los plazos de entrega del trabajo en curso, aún no integrado.
Eso no suena tan bien, porque Scrum Teams debe
enfocarse en entregar incrementos de software entregable
en lotes más pequeños y tiempos de entrega más cortos.
Tenga en cuenta que nuestros clientes no nos compensan
por entregar componentes, sino características con las
que ejecutarán sus negocios. Sin este enfoque incansable
en las funciones, la optimización general y la integración del
software pueden llevar más tiempo. Dado que las decisiones
de los equipos de componentes tienden a optimizar
componentes individuales, esas decisiones pueden generar
cuellos de botella invisibles para el éxito y el rendimiento de la
solución general.

La ventaja de los equipos de componentes es que facilitan la

concentración y la creación de conocimientos sobre los detalles
arquitectónicos y de diseño de componentes particulares. Eso
podría ser enormemente beneficioso para los componentes
que requieren descubrimiento e innovación.

Por otro lado, los miembros de los equipos de componentes

solo se especializan en componentes individuales de todo el
sistema. Podrían perder su vista de pájaro y la necesidad
comercial de las características.
Equipos de componentes

93
Machine Translated by Google
Equipos destacados
Los equipos de características son completamente
responsables de la implementación de las historias de
usuario tal como se especifican en la Lista de Producto.
Ya no es necesario dividir los equipos en varios componentes.
Cada equipo de funciones es responsable de ofrecer una
función completamente funcional y un valor comercial
asociado con esta función.
Equipos destacados
Los miembros de los equipos de funciones poseen
habilidades interfuncionales. Actúan tan autónomos como
sea posible para entregar rápido. La ventaja de los equipos
de funciones es que el equipo mantiene el conocimiento
del sistema y esto les facilita la integración de sus
funciones con el resto del sistema.
Sin embargo, para los equipos de funciones, puede ser más
difícil desarrollar suficiente conocimiento sobre los
componentes. Además, crear un equipo de características
autónomo que pueda entregar de forma rápida e
independiente lleva tiempo, ya que la creación de un equipo
funcional interdisciplinario no es tan fácil.
Y, sin embargo, estos son los equipos de alto rendimiento
que hacen el trabajo en la mayoría de las organizaciones,
probablemente incluida la suya.
¿Cómo elegimos los equipos de componentes
frente a los equipos de características?
En la práctica, la mayoría de las grandes organizaciones
también utilizan equipos de componentes y equipos de
funciones dedicados.
94
Machine Translated by Google

Equipos de componentes y características

95
Machine Translated by Google

El Equipo C, en el gráfico, es un Equipo Componente. • Por último, pero no menos importante, habrá muchos
Proporciona servicios de infraestructura planificados y impedimentos debido al mayor número de dependencias
bajo demanda a otros equipos que funcionan como entre los equipos y sus entregables.
Feature Teams. El equipo C no implementa
directamente las historias de usuario de extremo a
extremo per se. Cumplen con los requisitos de las Una regla importante a tener en cuenta es que el Scrum
historias de usuario comprometidas por los equipos de características.
Master debe ubicar físicamente dónde se encuentra su
equipo. De lo contrario, será casi imposible para el Scrum
Eso permite minimizar el número de personas calificadas Master:
en Feature Teams con el conocimiento de esos
componentes. • Quitar los impedimentos para su equipo, •
Establecer sus normas, y • Ayudarlos a mejorar
su uso del Scrum
Estructura.
El Scrum Master en el entorno de
proyecto distribuido La mejor práctica es tener un líder (principal)
Scrum Master para guiar el uso general de Scrum
En un entorno de proyecto distribuido, el papel del Scrum Framework en múltiples equipos.
Master es aún más esencial. En esas configuraciones de
proyecto: En otros equipos Scrum de unidad, que forman la
organización Scrum más grande, alguien también debería
• Se requerirá un esfuerzo adicional para alinear a los actuar como Scrum Master local.
equipos con los valores del Marco Scrum. • Tomará
más tiempo establecer normas (estándares) individuales
para equipos y proyectos que influyen en numerosos
equipos.

96
Machine Translated by Google
MARCO Scaled Scrum (Multi
Coordinación y planificación del equipo)
melé de melé
Después de haber visto el último capítulo de este curso,
la siguiente pregunta lógica en tu mente podría ser cómo
coordinas esos diferentes Equipos Scrum. Así que
trabajan juntos de manera eficiente.
Esa es una pregunta justa, y también hemos intentado cubrir
esta respuesta.
Scrum de las reuniones de Scrum
Scrum of Scrum Meetings se asemejan a Daily Scrum
Meetings. Y, sin embargo, aquí, durante Scrum of Scrum
Meetings, el enfoque no es el trabajo de los miembros
individuales del Equipo Scrum, sino los Equipos Scrum
mismos.
Las reuniones de Scrum of Scrum se llevan a cabo todos los
días, y también tienen un límite de tiempo (en un límite de
tiempo) de 15 minutos. Y, sin embargo, dependiendo de la
complejidad del proyecto, especialmente durante sus primeras
etapas, cuando los Equipos Scrum se están formando, estas
reuniones pueden durar de 30 a 60 minutos. Eso está
totalmente bien también.
Cada equipo envía a uno de los miembros de su equipo
Scrum (generalmente su Scrum Master local) para participar
en las reuniones de Scrum of Scrum. Y, sin embargo, los
equipos también pueden optar por rotar a su representante
diaria o semanalmente según su criterio. Cada participante
de un equipo responde las siguientes tres preguntas:
• ¿Qué hizo el equipo ayer? • ¿Qué planea
hacer el equipo hoy? • ¿Existen impedimentos que
obstaculicen o frenen el progreso del equipo?
Estas respuestas obviamente deberían cubrir las historias de
los usuarios y las interdependencias, que también afectan a
otros equipos.
97
Machine Translated by Google
El Chief Scrum Product Owner y el Lead Scrum Master
pueden moderar conjuntamente las reuniones de Scrum
of Scrum Master. Alternativamente, uno de ellos puede
hacerse cargo del deber de moderación de estas reuniones, o
pueden optar por rotar este deber entre ellos también.
Reuniones de revisión de Sprint comunes
Las Reuniones de Revisión de Sprint comunes con la
participación de todos los Equipos Scrum no son obligatorias,
pero pueden ser muy beneficiosas. Tenga en cuenta que las
Reuniones de revisión de Sprint comunes no reemplazan las
Reuniones de revisión de Sprint que el Equipo Scrum lleva a
cabo localmente.
Los participantes de las reuniones comunes de revisión de
Sprint son los delegados de los equipos Scrum y/o sus
respectivos propietarios de productos Scrum.
Los Equipos Scrum también pueden rotar a sus delegados
según sus preferencias. El líder (primario)
Scrum Master tiene la responsabilidad de moderar una
reunión común de revisión de Sprint.
Las reuniones comunes de revisión de Sprint permiten a
todos los equipos Scrum demostrar sus incrementos de
productos entregables al Chief Scrum Product Owner y a
todos los demás Scrum Product Owners.
De esta forma, las Common Sprint Review Meetings cumplen
dos propósitos:
1. Todos los equipos Scrum ahora están alineados sobre el
estado actual del proyecto general.
2. Todos los Equipos Scrum recopilan comentarios sobre su
trabajo, y ahora tienen la oportunidad de tener en cuenta
estos comentarios, mientras realizan sus próximas
reuniones de planificación de Sprint.
Retrospectivas comunes de Sprint
Al igual que las Reuniones de Revisión de Sprint Común, las
Reuniones Retrospectivas de Sprint Común no son
obligatorias, pero pueden ser muy beneficiosas.
Tenga en cuenta que las Reuniones retrospectivas comunes
de Sprint no reemplazan las Reuniones respectivas de Sprint
que el Equipo Scrum lleva a cabo localmente.
98
Machine Translated by Google

Los participantes de las reuniones retrospectivas comunes de gobiernan el Backlog de Producto Global Scrum. Sin embargo,
Sprint son los delegados de los equipos Scrum. sus contenidos son mantenidos por todos los propietarios de
Los Equipos Scrum pueden optar por rotar a sus delegados según productos Scrum.

su criterio.

Las reuniones retrospectivas comunes de Sprint están

dirigidas por el Scrum Master principal (principal). Estas
reuniones tienen como objetivo descubrir y actuar sobre los
potenciales de mejora sobre cómo la organización más grande
del proyecto Scrum usa el Marco Scrum.

Todos los problemas que requieran la atención y la

colaboración de múltiples Equipos Scrum para resolverlos
deben destacarse en estas reuniones. Sus caminos hacia la
resolución deben ser planificados, programados y seguidos.

Trabajos atrasados específicos del equipo

Planificación de equipos múltiples:
La cartera de productos global de Scrum
Cuando se trabaja con varios equipos, es esencial administrar
una Lista de productos Scrum global, que contiene las historias
de usuario de todos los equipos Scrum. El Chief Scrum Product
Owner podría
Cuando sea necesario, las historias de usuario del Backlog
de producto de Global Scrum se pueden dividir en historias
de usuario más específicas del equipo.
Estas historias de usuario más detalladas se mantienen en un
Backlog de Producto Scrum Local. Referencias

99
Machine Translated by Google

desde el Backlog de producto Scrum local hasta el

Backlog de producto Scrum global debe estar
presente. Estas referencias ayudarán a los
Equipos Scrum a ver qué roles juegan sus
historias de usuario en el panorama general de
su proyecto y qué tipo de valor para el cliente están entregando.

Programación de sprints

En un entorno de proyecto Scrum distribuido, hay

dos opciones sobre cómo puede elegir sincronizar el Sprints sincrónicos
trabajo de diferentes equipos Scrum.

Otra opción es utilizar Sprints asíncronos. Con

• Sprints sincrónicos •
esta opción, los Sprints no comienzan y terminan
Sprints asincrónicos
el mismo día. El uso de Sprints asincrónicos tiene la
ventaja de que no todos los Scrum Rituals de Scrum
La primera opción es usar Synchronous Sprints.
Teams individuales deben realizarse el mismo día.
Con Synchronous Sprints, todos los equipos
Por lo tanto, hace posible que el Chief Scrum Product
comienzan y terminan sus Sprints el mismo día.
Owner y otros Scrum Product Owners participen en
Sprint Planning, Sprint Review y Sprint
Los Sprints sincrónicos suelen ser el enfoque
Retrospective Events de otros Scrum Teams y
preferido, ya que facilitan relativamente la
los apoyen cuando se les solicite.
comunicación y la coordinación del Equipo Scrum.

100
Machine Translated by Google

Cuando un equipo brinda servicios a otros equipos, los Estimaciones de esfuerzo

Sprints asincrónicos brindan una ventaja adicional.
Todos los equipos Scrum dentro del entorno de proyecto
Scrum distribuido deben usar la misma unidad (números
de Fibonacci o tallas de camisa, etc.) para realizar sus
estimaciones.

Del mismo modo, el Backlog de productos de Global Scrum

también debe cumplir con las estimaciones de esta unidad
de esfuerzo acordada.

Se debe prestar especial atención a las estimaciones de los

Sprints asíncronos equipos componentes. Los equipos de componentes suelen
proporcionar servicios para las historias de usuario de los
equipos de funciones. Por lo tanto, deberían obtener el apoyo
Aquí hay un gran escenario para aclarar esto, que se y las aclaraciones necesarios durante sus propias reuniones
representó en el boceto anterior: el trabajo del Equipo A de planificación de Sprint y estimaciones.
(Equipo de proveedores) debe integrarse en los entregables
del Equipo-B (Equipo maestro). Con la ayuda de los Sprints
asíncronos, el Equipo-A puede cerrar su Sprint antes que el
Equipo-B. Entonces, el Equipo-B (Equipo Maestro) puede
elegir los entregables del Equipo-A (Equipo Proveedor) e
integrarlos en su trabajo antes de cerrar su propio Sprint.

101
Machine Translated by Google

Planificación de lanzamiento de Scrum Scrum Product Owner, cliente y partes interesadas del
negocio, • Implementación de la entrega final, que incluye
todas las demandas conocidas y solicitudes de funciones del
El objetivo de un plan de lanzamiento es visualizar la
cliente y las partes interesadas del negocio.
planificación de alto nivel para múltiples Sprints,
generalmente entre tres y doce Sprints, o los llamados
Incrementos de Producto.
Antes de crear un plan de lanzamiento, se deben tener en
cuenta los siguientes artefactos e información
Un plan de lanzamiento se convierte en la guía que refleja las cuenta:
expectativas de un Equipo Scrum sobre:

• Un Backlog de Producto Scrum priorizado y estimado,

• Qué funciones se implementarán, • En qué
• La velocidad medida del Equipo Scrum (La velocidad
orden y cuándo se implementarán estas funciones.
es estimada, o su valor debe extrapolarse de proyectos
similares anteriores si el Equipo Scrum recién se está
formando), • Criterios de éxito impuestos por los
El plan de lanzamiento también sirve como punto de
clientes tales como cronograma, alcance, recursos
referencia para monitorear y controlar el progreso de un
humanos provistos permitidos por el presupuesto del
proyecto. Un plan de lanzamiento sirve como objetivo para
proyecto).
implementaciones reales de software en sistemas de
producción de TI de dos maneras:

Dado que un Plan de lanzamiento está fuertemente

• Implementación de "Milestone Deliveries" para crear valor
asociado con el Product Backlog, el propietario del
comercial para el cliente antes de que se complete el
producto Scrum gobierna y mantiene los Planes de
proyecto. Estas entregas de hitos cubren un subconjunto lanzamiento.
de los requisitos del cliente acordados por el

102
Machine Translated by Google

Dependiendo de las demandas y prioridades de los Planificación de lanzamiento basada en funciones

clientes, se crea un plan de lanzamiento para satisfacer
uno de estos tres objetivos:
• Planificación de lanzamiento basada en
funciones • Planificación de lanzamiento basada
en fechas • Plan de lanzamiento basado en funciones y basado en fechas
Lo que sabemos: Velocidad del Equipo Scrum,
Características que queremos ofrecer.
Lo que no sabemos: ¿Cuánto tiempo necesitamos para
entregar estas funciones?

ning (El más típico)

Plan de lanzamiento para un proyecto basado en características

103
Machine Translated by Google

Para los planes de lanzamiento basados en funciones, la suma de los
puntos de la historia de usuario de las funciones solicitadas dentro de
un lanzamiento se divide por la velocidad del equipo. Eso revelará la
cantidad de Sprints necesarios para completar una Entrega de Hito o
Entrega Final del producto. Y hacemos el plan de lanzamiento en
consecuencia.
Planificación de lanzamiento basada en fechas
Lo que sabemos: la velocidad del equipo Scrum, la fecha que
queremos entregar.
Lo que no sabemos: ¿Qué características podemos entregar hasta la
fecha límite?

Plan de lanzamiento para un proyecto controlado por fecha

104
Machine Translated by Google

Para los Planes de lanzamiento basados en fechas,
multiplicamos la velocidad del equipo por la cantidad de
Sprints que tenemos hasta la fecha de lanzamiento. Eso
revelará el número total estimado de puntos de historia de
usuario que el Equipo Scrum puede entregar hasta la fecha de lanzamiento.
Y hacemos el plan de lanzamiento en consecuencia.
Basado en funciones y basado en fechas
Planificación de lanzamiento
Lo que sabemos: la velocidad del equipo Scrum, las
características que queremos entregar, la fecha en que
queremos entregar estas características.
Lo que no sabemos: ¿Puede el Equipo Scrum entregar las
características solicitadas hasta la fecha límite dada?
De lo contrario, la velocidad del Equipo Scrum debe
extenderse agregando recursos humanos adicionales al
equipo. Puede que esa no sea una opción viable ya que el
equipo Scrum ya podría tener 9 personas, que es el límite
superior del tamaño ideal de un equipo Scrum. Luego,
algunas historias de usuario del proyecto deben ser
entregadas por otro Equipo Scrum, que trabajará con el
Equipo Scrum original en paralelo.
Similar a Scrum Product Backlog, un Release Plan no es un
plan estático. Cambiará durante todo el proyecto a medida
que sepamos más sobre el proyecto. Las historias de usuario
nuevas, eliminadas, modificadas y los respectivos cambios
de sus estimaciones también influirán en los planes de
lanzamiento. Por lo tanto, el plan de lanzamiento debe
revisarse y actualizarse a intervalos regulares.

Multiplicamos la velocidad del equipo por la cantidad de

Sprints que tenemos hasta la fecha de lanzamiento. Eso
revelará el número total estimado de puntos de historia de
usuario que el Equipo Scrum puede entregar hasta la fecha
de lanzamiento. Si este número es mayor que la suma de los
puntos de características de la historia del usuario dentro de
un lanzamiento, entonces estamos a salvo.

105
Machine Translated by Google
PRÓXIMOS PASOS
Cómo garantizar su posición como
Un profesional Scrum exitoso
Siento que ahora es mi trabajo inspirarte para que
realmente implementes y ejecutes lo que has
aprendido de este material.
Afrontémoslo: la gran y vasta industria de TI no lo
acomodará con más oportunidades y más negocios sin
que tome algunos pasos iniciales serios. Lo más probable
es que la industria de TI ni siquiera sepa que existes;
hasta ahora, solo operaste como una pequeña parte de
él, o recién estás comenzando. El gobierno no lo va a
rescatar en sus días difíciles, y ciertamente no lo va a
ayudar a avanzar y conquistar su carrera profesional.
Tomarse el tiempo para tomar este libro y leerlo
sugiere que usted realmente quiere hacer algo
diferente. Por esto, lo reconozco y lo felicito. Bien
hecho por conseguir este libro. Te aplaudo por leerlo y
más aún por terminarlo. Ahora, si quieres que el mundo
te dé una ovación de pie, pon las lecciones en práctica.
Curiosamente, una de las formas más efectivas de
perfeccionar estas disciplinas es ayudar a otros a
lograr el éxito e implementar estas acciones ellos
mismos. Cuando las personas con objetivos y
motivaciones comunes se unen, tienden a aprender más
rápido y se convierten en un sistema de apoyo mutuo. Así
que reúna un grupo de personas de ideas afines y
altamente motivadas que se niegan a vivir según las
normas de los mediocres. Reúna un grupo de estudio
para leer este libro y haga una lluvia de ideas con usted.
Pida a sus compañeros de trabajo, empleados y jefes que
lean este libro en equipo. Luego, ayúdense unos a otros
a aplicar y comprometerse a usar las acciones, háganse
responsables unos a otros de estos compromisos.
mentos.
Siga ahora la página de empresa de International
Scrum Institute™ LinkedIn® para conectarse con
otros profesionales de ideas afines que pueden
empoderarlo e inspirarlo en su carrera.
106
Machine Translated by Google

Algo me dice que no eligió este libro porque se siente cómodo
o satisfecho con el lugar en el que se encuentra en su carrera.
Lo más probable es que desee cambiar o mejorar su puesto
actual. De lo contrario, no habrías terminado este libro. Por lo
tanto, ¡estaré encantado de apoyarte en tu carrera profesional!
¿Por qué debería obtener sus
certificaciones Scrum hoy?
hombres y mujeres destacados que mejoraron sus
carreras y habilidades con la ayuda del marco Scrum.
Si aún te lo preguntas, quiero asegurarte que ya no puedes
imaginar una carrera en crecimiento sin poseer una certificación
Scrum. Es independientemente de su función, título y
experiencia en el ecosistema de tecnología de la información
(TI). Ya no es necesario ser un profesional de TI para
comprender qué es Scrum, cómo funciona Scrum y obtener
una certificación Scrum.

Una certificación Scrum es el testimonio de su competencia

en el proceso de desarrollo y entrega de software Scrum.

La certificación Scrum reconoce su conocimiento calificado

demostrado y su destacada experiencia en el marco Scrum
después de una evaluación formal de prueba de opción
múltiple.

El proceso de desarrollo de software Scrum ha estado

¡Eres un profesional de cinco estrellas!
ofreciendo inmensos beneficios a millones de profesionales
¡Debe ser reconocido y compensado en
hasta el día de hoy. Por lo tanto, no hay razón para que no
consecuencia!
te unas a estos acompañamientos.

107
Machine Translated by Google
Independientemente de lo que haga para ganarse la vida,
independientemente de si es parte de un departamento
de TI o no, hay un hecho esencial e indiscutible. Sus
tareas y el valor comercial profesional que ha estado
sirviendo para su organización dependen y están
interrelacionados con la TI, el software y el proceso y
los principios ágiles de Scrum.
Además, gracias al cambio de los modelos de negocios
tradicionales hacia negocios impulsados por software
como servicio (SaaS) o el llamado movimiento de
digitalización, ya no es una decisión voluntaria para
cualquier profesional dentro o fuera del departamento de
TI obtener la certificación como profesional Scrum. Sin
embargo, hoy en día es imprescindible obtener una certificacióncomo profesional de Scrum.
Es posible que recién esté comenzando su carrera o que
sea un profesional de TI experimentado. Eso no juega un
papel. Necesitas obtener tu certificación Scrum.
Su función puede o no incluir personas y actividades de
gestión funcional. No importa también; aún necesita tener
una certificación Scrum.
Debe aprender el marco de trabajo de desarrollo de
software de Scrum y convertirse hoy en un experto
Scrum Professional al obtener su certificación Scrum.
Los pros de ser un consumado
Scrum profesional
Ahora es el momento de recapitular. Si no tuviste la
oportunidad de leer cada palabra de este libro, permíteme
desglosar mis pensamientos. Aquí están mis pensamientos
sobre los pros y los contras de obtener la certificación
Scrum.
1. Los profesionales para empleados,
autónomos, entrenadores y formadores
• Una certificación Scrum será su reconocimiento de
competencia y conocimientos actualizados en el
dominio Scrum.
• Una certificación Scrum lo ayudará a superar a su grupo
de pares que ya no se desarrollan. Y recuerda, son
muchos. Eso
108
Machine Translated by Google
lo ayudará a ser contratado para el trabajo de sus
sueños como un profesional Scrum certificado y
consumado.
• Una certificación Scrum ampliará su perspectiva y
abrirá aún más su mente para el aprendizaje continuo.
Le ayudará a obtener más responsabilidades y
fantásticas oportunidades profesionales. • Una
certificación Scrum le proporcionará un nuevo conjunto
de herramientas con el que podrá ofrecer excelentes
productos y servicios que les encantarán a sus clientes
y empleadores.
2. Las ventajas de las organizaciones y los
empleadores
• Las certificaciones Scrum reducirán los costos al
mejorar la eficiencia de sus equipos, actividades y
procesos. • Las certificaciones Scrum lo ayudarán a
ganar proyectos con sus empleados capacitados y
calificados que no podría ganar de otra manera.
• Las certificaciones Scrum mejorarán la satisfacción y el
compromiso de los empleados al alentarlos a
capacitarse y desarrollar habilidades. • Las
certificaciones Scrum mejorarán la calidad de sus
entregas, la satisfacción del cliente y, en última
instancia, el éxito y la rentabilidad de su organización.
Cosas para recordar después de ti
Conviértete en un Scrum consumado
Profesional
• Una certificación Scrum no debería detener su
aprendizaje. No olvide que obtener la certificación
como profesional de scrum es solo el primer paso. En
el espíritu de "inspeccionar y adaptar" que aprendió
del marco Scrum, sigue siendo su deber y obligación
experimentar, observar y aprender continuamente.
• No existe una solución única para todas las
organizaciones del mundo. El marco de desarrollo y
entrega de software Scrum no es una excepción a esta
regla. lo que observamos
109
Machine Translated by Google
es que: la mayoría de las organizaciones en las
que no podemos obtener el mejor rendimiento del
marco Scrum tienen una característica común.
Estas son las organizaciones que no lograron
adaptar Scrum a sus propios ecosistemas
empresariales y de TI. Por lo tanto, nuevamente
con el espíritu de "inspeccionar y adaptar", no
vea el marco Scrum como una receta 100%
garantizada para el éxito. Por favor, no subestime
su capacidad cognitiva para adaptarla a las
propias dinámicas de su negocio y TI. De hecho,
como profesional pagado, esto es lo que se
supone que debe hacer para obtener el mejor
rendimiento y resultados comerciales mediante el uso del
• Scrum no resolvió todos los problemas que
tenemos en nuestros departamentos de TI. No
deje de desarrollarse con los procesos de entrega
y desarrollo de software emergentes , como
DevOps. Para comprender mejor las fallas
conocidas del marco Scrum y cómo DevOps las
maneja, consulte este artículo principal en un
momento posterior: ¿Cuáles son las 6
diferencias PRINCIPALES entre DevOps y Scrum?
(Comparación DevOps vs Scrum)
En conclusión, una certificación Scrum es una
excelente manera de comenzar con prácticas
ágiles de desarrollo y entrega de software.
Según un estudio de Gartner "Becoming a Better
Scrum Master" publicado en 2019, hasta 2023, el
92% de las empresas en todo el mundo y el 96% de
las empresas en los Estados Unidos adoptarán
prácticas ágiles de scrum.
Por lo tanto, no habrá mejor momento que ahora
para que
• Comience
marco Scrum.
a aprender el marco Scrum y, •
Certifíquese como Scrum Professional con
tarifas muy asequibles del International Scrum
Institute™.
La única pregunta que queda es,
¿cuándo vas a empezar?
Registre su certificación Scrum >>>
110
Machine Translated by Google

Ver más reseñas >>>

111
Machine Translated by Google

Gracias
Me gustaría agradecerle nuevamente por tomarse el
tiempo de leer The Scrum Framework. Esperamos que
haya disfrutado leyendo este libro tanto como nosotros
lo habíamos hecho mientras lo escribíamos. Es nuestro
mayor placer si de alguna manera logramos ayudarlo a
construir una base sólida de Scrum para usted.

Sabemos que es un mundo muy complejo,

abrumador y superpoblado con todos los programas
de Scrum que hay en el mercado.

Y, sin embargo, logramos construir nuestros programas

de capacitación y certificación de Scrum de manera
más concreta, atractiva, útil, útil y simple que nuestra
competencia. Esta es la razón por la que creemos que
nuestros valiosos estudiantes eligen International Scrum
Institute™ en lugar de las soluciones burocráticas,
complejas, costosas y a medias de nuestros competidores.

Para registrarse y comenzar con su Scrum

Certificaciones, haga clic en Registrar programas hoy >>

Yeliz Obergfell,
Instituto Internacional Scrum™

112