Documentos de Académico
Documentos de Profesional
Documentos de Cultura
También se le conoce como una estructura en la que las personas pueden abordar complejos problemas
adaptativos, siendo a la vez productivas y creativas para entregar productos finales de gran valor. Scrum
también incorpora varios elementos, como que es ligero y fácil de entender. Eso sí, es difícil de dominar.
La estructura está compuesta de Equipos Scrum que llevan a cabo una serie de funciones, tienen diferentes
utensilios y eventos y siguen una serie de reglas. Cada parte de la estructura tiene un propósito, que
trabaja hacia el éxito de Scrum.
Scrum es el nombre con el que se denomina a los marcos de desarrollo ágiles caracterizados por:
Introducción.
La metodología Scrum es tendencia en la gestión de proyectos. Si trabajas en un sector en el que el nivel
de incertidumbre es alto y tu trabajo ágil, quizás tengas que aplicar Scrum para gestionar tus proyectos.
El sector del desarrollo de software es el principal representante de este tipo de metodología ágil. Se trata
de planificar tus proyectos en pequeños bloques o Sprint, e ir revisando y mejorando el anterior. Y es el
propio término Scrum proviene del mundo del rugby. Te lo contamos a continuación.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que
aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos
complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco
definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.
Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita,
cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se
necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación
alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere
trabajar utilizando un proceso especializado en el desarrollo de producto.
Entre las principales características de la metodología Scrum, desataca que es un desarrollo incremental
en lugar de la clásica planificación del desarrollo completo de un producto o servicio. Sus equipos de
trabajo se caracterizan por ser auto-organizados. Y se centra en el producto final, en la calidad del mismo.
Historia
El término Scrum (traducido del inglés como melé) fue acuñado y definido por Ikujiro Nonaka e Hirotaka
Takeuchi en los años 80, cuando las principales empresas de desarrollo tecnológica empezaban a dominar
el mercado y a definir conductas de trabajo. Ambos publicaron en 1986 en la Harvard Business Review
este artículo “El nuevo juego para el desarrollo de productos”. Así abrieron una caja que durante los
próximos años ha evolucionado y se ha extendido por muchos sectores, no sólo el tecnológico.
El avance de las formaciones de las melés en partidos de rugby, inspiró a Nonaka y Takeuchi para bautizar
una nueva forma de trabajar que ya venía dándose en muchas empresas tecnológicas como Honda, Canon
y Fuji-Xerox.
La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son:
Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados.
Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog),
Incremento.
Reuniones:
Planificación del sprint, Revisión diaria, Revisión del sprint.
Sprint
Por tanto, Scrum busca cómo optimizar la predictibilidad y controlar el riesgo utilizando un método
Iterativo e Incremental. Para que esto suceda, hay tres pilares que se deben implementar. Estos son la
Transparencia, la Inspección y la Adaptación.
Transparencia
Hay partes de este proceso que necesitan ser visibles para aquellos responsables de los resultados. Esto
requiere definiciones estándar de todos los aspectos para asegurarse de que hay un entendimiento común
de todas las observaciones. Considera estos ejemplos: –
Inspección
Aquellos que usan Scrum necesitan inspeccionar periódicamente los instrumentos Scrum y el progreso del
Objetivo en el Sprint. Esto asegura que puedan detectar variaciones no deseadas a tiempo. Las
inspecciones deben llevarse a cabo de vez en cuando, de manera que no se interrumpa el trabajo en
progreso.
Adaptación
Después de una inspección, puede revelarse que uno o más aspectos del proceso se ha desviado de los
límites aceptables. Esto significa que el producto final podría no ser aceptable y que es necesario hacer
algún ajuste en el proceso o el material que se está usando. Cuanto antes ocurra, mejor, de manera que
se eviten más desviaciones.
Fundamentos de Scrum
Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar
de equipos altamente productivos.
Características
Características principales
Entre las características principales del SCRUM podemos mencionar:
Gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptación,
retorno de inversión, mitigación de riesgos, productividad y calidad, alineamiento entre cliente y
equipo, por último, equipo motivado.
Se hace uso de equipos auto-dirigidos y auto-organizados.
Se realiza a diario una reunión de Scrum, que es una reunión de avance diaria que no dura más
de 15 minutos con el objetivo de obtener realimentación sobre las tareas del equipo y los
obstáculos que se presentan.
Scrum permite la creación de equipos auto organizados impulsando la co-localización de todos los
miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas
involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden
cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que
los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y
planificada.
Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser
completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de
entregar rápidamente y responder a requisitos emergentes.
Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco
esfuerzo para comenzarse a utilizar.
Cada uno de estos puntos mencionados hacen que el Scrum sea utilizado de manera regular en un
conjunto de buenas prácticas para el trabajo en equipo y de esa manera obtener resultados posibles.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas
amarillas "post-it" y pizarras hasta paquetes de software.
Roles SCRUM
Roles principales
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como
punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.
Tres miembros componen el Equipo Scrum básico, y son el Product Owner, el Equipo de Desarrollo y el
Scrum Master. Se espera que estos equipos se auto-organicen y sean multifuncionales. Cuando se auto-
organizan, pueden elegir la mejor manera de finalizar el trabajo y no tener en cuenta la orientación que
puedan dar personas que no sean del equipo.
El Product Owner
Cuando se trata de maximizar el valor del producto y el trabajo del Equipo de Desarrollo, es el Product
Owner el responsable de ello. Esto varía según los Equipos Scrum y las personas del equipo. El Product
Owner tiene la responsabilidad de gestionar el Backlog del Producto. Esta gestión incluye:
Para garantizar que el Product Owner tiene éxito, todas las personas de la organización deben respetar
sus decisiones, que son visibles en el contenido y orden del Backlog de Producto. No hay nadie capaz de
ordenar al Equipo de Desarrollo trabajar con requisitos distintos, y el Equipo de Desarrollo también tiene
sus acciones limitadas bajo las instrucciones de otra persona.
El Equipo de Desarrollo
Es un equipo formado por profesionales que trabajan para entregar un Incremento de producto
“Finalizado” que se pueda lanzar al final de cada Sprint. Solo los miembros de este equipo pueden crear
el Incremento.
La organización asegura que el Equipo de Desarrollo está empoderado para organizar y gestionar su
trabajo. La sinergia que ocurre, como resultado, optimizará la eficiencia y efectividad del Equipo de
Desarrollo. Estos equipos tienen las siguientes características:
El Equipo de Desarrollo se compone de muchas personas, siendo tres el número óptimo. Esto asegura
que se mantienen ágiles y son un lo suficientemente grandes para finalizar todo el trabajo que se debe
hacer en un Sprint.
Si el equipo tiene menos de tres miembros, la interacción puede verse reducida, lo que significa que se
tendrá menor productividad. Además, los Equipos de Desarrollo pequeños pueden ver restringidas sus
capacidades durante el Sprint, significando que podrían no ser capaces de entregar un Incremento
potencialmente liberable.
Los equipos grandes, como aquellos con más de nueve miembros, necesitan mucha más coordinación.
Acaban generando demasiada complejidad como para gestionar un proceso empírico. Al contar al
Equipo de Desarrollo, no se cuenta al Product Owner ni al Scrum Master a no ser que también estén
realizando el trabajo del Backlog del Sprint.
El Scrum Master
El Scrum Master tiene la responsabilidad de asegurar que se ha entendido y aprobado el método Scrum.
Trabajan con el Equipo Scrum, por lo que pueden adherirse a la teoría, prácticas y reglas de Scrum. El
Scrum Master es esencialmente el líder-ayudante del Equipo Scrum.
El Scrum Master ayuda a las personas que no están en el Equipo Scrum a entender cuáles de sus
interacciones con el Equipo Scrum son útiles y cuáles no.
Administradores (Managers)
Son los responsables de establecer el entorno para el desarrollo del proyecto.
Reuniones en Scrum
Daily Scrum
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup".
El scrum tiene unas guías específicas:
La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
Scrum de Scrum
Cada día normalmente después del “Daily Scrum”
La agenda será la misma como del Daily Scrum, además de las siguientes cuatro preguntas:
Al final del ciclo Sprint, dos reuniones se llevarán a cabo: la “Reunión de Revisión del Sprint” y la
“Retrospectiva del Sprint”
Documentos
Product backlog
El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas
de todos los requerimientos, funcionalidades deseables, etc. priorizadas según su retorno sobre la
inversión (ROI). Es el qué va a ser construido. Es abierto y cualquiera puede modificarlo. Contiene
estimaciones grosso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido.
Esta estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de
las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera
menos tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto.
Sprint backlog
El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los
requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración
superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser rota en mayor detalle. Las tareas en el
sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca
oportuno.
Burn down
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog
del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos
los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea
descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde
el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha
terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se
añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se
modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.
Ventajas y desventajas
Ventajas
Flexibilidad a cambios: Gran capacidad de reacción ante los cambiantes requerimientos
generados por las necesidades del cliente o la evolución del mercado. El marco de trabajo está
diseñado para adecuarse a las nuevas exigencias que implican proyectos complejos.
Reducción del Time to Market: El cliente puede empezar a utilizar las características más
importantes del proyecto antes de que esté completamente terminado.
Mayor calidad del software: El trabajo metódico y la necesidad de obtener una versión de
trabajo funcional después de cada iteración, ayuda a la obtención de un software de alta calidad.
Mayor productividad: Se logra, entre otras razones, debido a la eliminación de la burocracia y la
motivación del equipo proporcionado por el hecho de que pueden estructurarse de manera
autónoma.
Maximiza el retorno de la inversión (ROI): Creación de software solamente con las prestaciones
que contribuyen a un mayor valor de negocio gracias a la priorización por retorno de inversión.
Predicciones de tiempos: A través de este marco de trabajo se conoce la velocidad media del
equipo por sprint, con lo que es posible estimar de manera fácil cuando se podrá hacer uso de
una determinada funcionalidad que todavía está en el Backlog.
Reducción de riesgos: El hecho de desarrollar, en primer lugar, las funcionalidades de mayor
valor y de saber la velocidad a la que el equipo avanza en el proyecto, permite despejar riesgos
efectivamente de manera anticipada.
Entregables en tiempo y forma, puedes ir enviando entregables al cliente mientras vas atacando
los objetivos más sencillos, eso te hace ganar tiempo para atacar los objetivos más complejos.
El ScrumMaster tiene el conocimiento necesario para lograr el objetivo primario y secundario
por lo cual puede ir controlando el proyecto y delegando roles.
Cada persona sabe que es lo que tiene que hacer y no es necesario estar reorganizando una y
otra vez los Tracks de cada persona.
Se involucra desde un principio y se da un rol a todos los stakeholders (personas que van a
participar en el proyecto incluyendo cliente final, QA, Testers, etc.)
Desventajas
Algunos miembros de tu equipo pueden saltar pasos importantes en el camino rápido para llegar
al “sprint” final.
El cliente siempre va a esperar los informes con la fecha exacta, y muchas veces los va a pedir
antes, cuando capaz no pudiste avanzar en nada.
Demasiadas Reuniones para poco avance, a veces es muy cansado y estresante reunirse
demasiadas veces por el mismo tema, algunos van perdiendo el interés en el proyecto.
Si una persona renuncia o hay algún cambio es complicado remplazar ese rol ya que es la
persona que se lleva el conocimiento específico y afecta a todo el proyecto.
No es aplicable a grandes escalas o cuando el sector IT es variado.
Dificultad de aplicación en grandes proyectos.
Plantea un problema si el desarrollo está restringido por una fecha de entrega y un precio de
entrega cerrados por contrato.
Supone que el equipo está muy formado y motivado.
Etapas o fases
El desarrollo se realiza de forma iterativa e incremental. Cada iteración, denominada Sprint, tiene una
duración preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versión del software
con nuevas prestaciones listas para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya
construida y se añaden nuevas prestaciones priorizándose siempre aquellas que aporten mayor valor de
negocio.
Product Backlog:
Conjunto de requisitos denominados historias descritos en un lenguaje no técnico y priorizados por valor
de negocio, o lo que es lo mismo, por retorno de inversión considerando su beneficio y coste. Los
requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares.
Sprint Planning:
Reunión durante la cual el Product Owner presenta las historias del backlog por orden de prioridad. El
equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint, para en
una segunda parte de la reunión, decidir y organizar cómo lo va a conseguir.
A destacar que el objetivo del Sprint puede ser un hito en el objetivo más amplio de la hoja de ruta
(roadmap) del producto.
Sprint
Iteración de duración prefijada durante la cual el equipo trabaja para convertir las historias del Product
Backlog a las que se ha comprometido, en una nueva versión del software totalmente operativo.
Cuando un Sprint es demasiado largo, la definición de lo que se está construyendo puede cambiar, puede
aumentar la complejidad y puede aumentar el riesgo. Los Sprints permiten previsibilidad al garantizar la
inspección y la adaptación de los avances hacia una meta de por lo menos cada mes de calendario.
Sprint Backlog
Lista de las tareas necesarias para llevar a cabo las historias del sprint.
El equipo de desarrollo utiliza el Scrum Diario para evaluar el progreso hacia la meta del Sprint y evaluar
la tendencia del progreso en finalizar el trabajo en el Sprint Backlog. Cada día, el equipo de desarrollo debe
ser capaz de explicar al dueño del producto y al Scrum Master como van a trabajar juntos como un equipo
auto-organizado para lograr el objetivo y crear el incremento previsto en el resto del Sprint.
Demo y retrospectiva
Reunión que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas
mediante una demonstración del producto. Posteriormente, en la retrospectiva, el equipo analiza qué se
hizo bien, qué procesos serían mejorables y discute acerca de cómo perfeccionarlos. El propósito de la
retrospectiva de Sprint es:
Revisar cómo fue el último Sprint en lo que respecta a las personas, relaciones, procesos y
herramientas;
Identificar y ordenar los temas principales que salieron bien y las potenciales mejoras, y
Crear un plan para la implementación de mejoras con respecto a cómo el Equipo Scrum hace su
trabajo.
Valores SCRUM
Hay muchos valores que el Equipo Scrum debe encarnar. Estos son el coraje, el compromiso, la
sinceridad, el respeto Estos valores son básicos para erigir los pilares del método Scrum y conseguir
confianza con todas las personas envueltas en él.
Los miembros del Equipo Scrum aprenden y exploran estos valores al trabajar en eventos y roles de
Scrum. Para que el método Scrum tenga éxito, es necesario que los miembros del equipo sean
competentes en estas cinco características.
Así lo hacen:
Tienen el coraje para hacer lo que es correcto y abordar los problemas graves
Se comprometen a alcanzar los objetivos del equipo
Los inversores y el equipo acuerdan hablar abiertamente sobre el trabajo y las dificultades
que tiene el mismo
Se respetan los unos a los otros y confían en que son independientes y capaces
Se centran en el trabajo del Sprint y los objetivos del equipo
Ejemplos de uso
La metodología Scrum se puede aplicar a muchos sectores, sin embargo, aún no se puede adaptar
adecuadamente a otros como los procesos de fabricación de productos o el mundo de la construcción.
Conclusiones
Las metodologías son aplicables solo en cierta medida, es bueno seguir las buenas prácticas y tratar de
planificar el mejor escenario, o ir combinándolas con otras más evolucionadas como es la Metodología
RUP Agile, pero por más mejorada que este, siempre vas a tener Stoppers y Semáforos Amarillos y Rojos,
y es que no hay una receta del éxito especifica de un proyecto, porque hay variables no controlables, sino
más bien lo veo como una herramienta que nos sirve para ir mejorando el proceso del proyecto, aplicar
metodologías(Ágiles, Espirales, Prototipadas, etc.) en pequeños grupos controlables es lo ideal y por lo
que hemos visto ha dado resultados.