SCRUM
SCRUM
SCRUM
industrias.
Historia
Este modelo fue identificado y definido por Ikujiro Nonaka y Takeuchi a principios de los
80, al analizar cómo desarrollaban los nuevos productos las principales empresas de
manufactura tecnológica: Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M y Hewlett-
Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986)..23
Características de Scrum
Scrum es un marco de trabajo que define un conjunto de eventos, prácticas y roles, 4 y que
puede tomarse como conjunto base para definir el proceso de producción que usará un
equipo de trabajo o dentro de un proyecto.5
Los roles principales en Scrum son el Scrum Master, que procura facilitar la aplicación de
Scrum y gestionar cambios, el Product Owner, que representa a los stakeholders
(interesados externos o internos), y el Team (equipo) que ejecuta el desarrollo y demás
elementos relacionados con él.
Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el
equipo y debe ser lo más corta posible), el equipo crea un incremento de software
potencialmente entregable (utilizable). El conjunto de características que forma parte de
cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel
priorizados que definen el trabajo a realizar (PBI, Product Backlog Item). Los elementos
del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint
Planning. Durante esta reunión, el Product Owner identifica los elementos del Product
Backlog que quiere ver completados y los da a conocer al equipo. Entonces, el equipo
conversa con el Product Owner buscando la claridad y magnitud adecuadas (Cumpliendo el
INVEST) para luego determinar la cantidad de ese trabajo que puede comprometerse a
completar durante el siguiente sprint.6 Durante el sprint, nadie puede cambiar el Sprint
Backlog, lo que significa que los requisitos están congelados durante el sprint.7
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van
desde notas amarillas "post-it" y pizarras hasta paquetes de software; requiere muy
poco esfuerzo para comenzarse a utilizar. Así, si se utiliza una pizarra con notas
autoadhesivas cualquier miembro del equipo podrá ver tres columnas: trabajo pendiente
("backlog"), tareas en curso ("in progress") y hecho ("done"). De un solo vistazo, una
persona puede ver en qué están trabajando los demás en un momento determinado.8
Roles en Scrum
Roles Principales
Roles Auxiliares
Los roles auxiliares en los "equipos Scrums" son aquellos que no tienen un rol formal y no
se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en
cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el
proceso a los usuarios, expertos del negocio y otros interesados ("pandemoldes"). Es
importante que esa gente participe y entregue retroalimentación con respecto a la salida del
proceso a fin de revisar y planear cada sprint.
Registra y prioriza los requisitos desde el punto del vista del cliente. Empieza con una
visión inicial del producto y crece y evoluciona durante el desarrollo del producto. Los
requisitos suelen denominarse "historias de usuario"
Registro de los requisitos desde el punto de vista de los desarrolladores. Es la lista de tareas
que se deben realizar durante un sprint para lograr el incremento previsto.
Incremento
Flujo de trabajo
Sprint
Al final de cada sprint, el equipo deberá presentar los avances logrados, y el resultado
obtenido es un producto que, potencialmente, se puede entregar al cliente.6
Así mismo, se recomienda no agregar objetivos al sprint o sprint backlog a menos que su
falta amenace al éxito del proyecto. La constancia permite la concentración y mejora la
productividad del equipo de trabajo.
El tiempo mínimo de un Sprint es de una (1) semana y el máximo es de cuatro (4) semanas.
Planificación de sprint
También llamado Daily Standup. Cada día durante la iteración, tiene lugar una reunión de
estado del proyecto. Su objetivo es que los miembros del equipo se mantengan actualizados
unos a otros sobre el trabajo de cada uno desde el último standup, qué problemas han
encontrado o prevén encontrar, y qué planean hacer.6
Revisión de sprint
Al final de un sprint, el equipo realiza dos eventos: la revisión del sprint y la retrospectiva
del sprint.6
Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los
miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de
la retrospectiva es realizar una mejora continua de la implementación de Scrum. La
duración de la retrospectiva es, como máximo, de tres horas para Sprints de un mes.
Consideración de Riesgos
El riesgo se define como un evento incierto o una serie de eventos que pueden afectar los
objetivos de un proyecto y pudieran contribuir a su éxito o fracaso. Los riesgos con un
potencial de impacto positivo en el proyecto se denominan “oportunidades”, mientras que
las “amenazas” son riesgos que pudieran afectar negativamente a un proyecto. La gestión
de riesgos debe hacerse proactivamente y es un proceso iterativo que debe empezar al inicio
del proyecto y continuar durante toda vida. El proceso de gestión de riesgos debe seguir
algunos pasos estandarizados para garantizar que los riesgos sean identificados, evaluados y
se establezcan las medidas para actuar en consecuencia.
Es necesario identificar, evaluar y responder a los riesgos basándose principalmente en dos
factores: la probabilidad de ocurrencia y el impacto probable en caso de que ocurra. Los
riesgos de alta probabilidad y con un alto índice de impacto deben ser abordados antes de
aquellos con una calificación más baja. En general, una vez que se detecta un riesgo, es
importante comprender los aspectos básicos del riesgo respecto a las posibles causas, el
área de la incertidumbre y los efectos potenciales si se produce el riesgo.9
La gestión de riesgos se compone de los siguientes cinco pasos que deben llevarse a cabo
en forma iterativa durante el proyecto:
1. Identificación de riesgos: Utilizar diversas técnicas para identificar todos los riesgos
potenciales.
4. Mitigación de riesgos: Desarrollar una estrategia adecuada para hacer frente a un riesgo.
Beneficios de Scrum
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.10
Documentos
Product backlog
El product backlog se trata como un documento de alto nivel para todo el proyecto. Es el
conjunto de todos los requisitos de proyecto, el cual contiene descripciones genéricas de
funcionalidades deseables, priorizadas según su retorno sobre la inversión (ROI) .
Representa el qué va a ser construido en su totalidad. Es abierto y solo puede ser
modificado por el product owner. Contiene estimaciones realizadas a grandes rasgos, 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 (KEV) 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 menor tiempo de desarrollo tendrá probablemente más prioridad, debido a que
su ROI será más alto.
Sprint backlog
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.
Definition of Done
El Definition of Done es un documento con una serie de criterios comunes para determinar
cuando una tarea está completamente hecha.
Definition of ready
Este debe ser una lista de requerimientos necesarios para iniciar el desarrollo de una
Historia de Usuario o un Incremento, por lo general estos requerimientos dependen de
actores externos al Scrum Team.
Véase también
Agilmática
Arquitectura orientada a servicios
Back office
Ciclo de vida del producto
Desarrollo ágil de software
Desarrollo de software
Kanban
Lean software development
Referencias
«Qué es SCRUM». Proyectos Ágiles. 4 de agosto de 2008. Consultado el 8 de abril de
2019.
«Archived copy». Archivado desde el original el 9 de febrero de 2021. Consultado el
7 de abril de 2021.
"The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro
Nonaka (1986)
«¿Qué es Scrum?». Consultado el 11 de marzo de 2021.
«Scrum tools» (en inglés). Consultado el 11 de marzo de 2021.
Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January
2004, 163pp, ISBN 0-7356-1993-X
Métodos Ágiles. Scrum, Kanban, Lean, Carmen Lasa, Rafael de las Heras, Alonso
Álvarez, Anaya, 2017, 400pp, ISBN 978-8441538887
Leader Summaries (ed.). «Resumen del libro Scrum, de Jeff Sutherland». Consultado
el 25 de enero de 2016.
Guía de los Fundamentos de Scrum (Guía del SBOK). VMEdu. 2022. ISBN 978-0-
9899252-0-4.