Scrum es un marco de colaboración en equipo ágil comúnmente utilizado en el desarrollo de software y otras industrias.
Scrum prescribe que los equipos dividan el trabajo en objetivos que se completarán en iteraciones con límites de tiempo , llamadas sprints . Cada sprint no dura más de un mes y, por lo general, dura dos semanas. El equipo Scrum evalúa el progreso en reuniones de pie con límites de tiempo de hasta 15 minutos, llamadas Scrums diarios . Al final del sprint, el equipo realiza dos reuniones más: una revisión del sprint para demostrar el trabajo a las partes interesadas y solicitar comentarios, y una retrospectiva interna del sprint . La persona a cargo de un equipo Scrum generalmente se denomina Scrum Master . [2]
El enfoque de Scrum para el desarrollo de productos implica llevar la autoridad de toma de decisiones a un nivel operativo. [3] A diferencia de un enfoque secuencial para el desarrollo de productos, Scrum es un marco iterativo e incremental para el desarrollo de productos. [4] Scrum permite una retroalimentación y flexibilidad continuas, lo que requiere que los equipos se autoorganicen fomentando la ubicación física o la colaboración en línea cercana y exigiendo una comunicación frecuente entre todos los miembros del equipo. El enfoque flexible de Scrum se basa en parte en la noción de volatilidad de los requisitos, es decir, que las partes interesadas cambiarán sus requisitos a medida que evolucione el proyecto. [5]
El uso del término scrum en el desarrollo de software surgió de un artículo de 1986 de la Harvard Business Review titulado "The New New Product Development Game" (El nuevo juego del desarrollo de nuevos productos) de Hirotaka Takeuchi e Ikujiro Nonaka . Basándose en estudios de casos de empresas manufactureras de las industrias automotriz, de fotocopiadoras e impresoras , los autores describieron un nuevo enfoque para el desarrollo de productos que aumenta la velocidad y la flexibilidad. Lo llamaron el enfoque del rugby , ya que el proceso implica un solo equipo multifuncional que opera en múltiples fases superpuestas en las que el equipo "intenta llegar hasta el final como una unidad, pasándose la pelota de un lado a otro". [6] Los autores desarrollaron posteriormente el scrum en su libro The Knowledge Creating Company . [7]
A principios de los años 1990, Ken Schwaber utilizó lo que se convertiría en Scrum en su empresa, Advanced Development Methods. Jeff Sutherland , John Scumniotales y Jeff McKenna desarrollaron un enfoque similar en Easel Corporation, refiriéndose al enfoque con el término Scrum . [8] Sutherland y Schwaber trabajaron más tarde juntos para integrar sus ideas en un único marco, formalmente conocido como Scrum. Schwaber y Sutherland probaron Scrum y lo mejoraron continuamente, lo que llevó a la publicación de un artículo de investigación en 1995, [9] y el Manifiesto para el Desarrollo Ágil de Software en 2001. [10] Schwaber también colaboró con Babatunde Ogunnaike en DuPont Research Station y la Universidad de Delaware para desarrollar Scrum. Ogunnaike creía que los proyectos de desarrollo de software a menudo podían fallar cuando las condiciones iniciales cambian si la gestión de productos no estaba arraigada en la práctica empírica. [3]
En 2002, Schwaber, junto con otros, fundó la Scrum Alliance y creó la serie de acreditaciones Certified Scrum . [11] Schwaber dejó la Scrum Alliance a fines de 2009 y posteriormente fundó Scrum.org, que supervisa la serie de acreditaciones paralelas Professional Scrum . [12] Desde 2009, Schwaber y Sutherland han publicado y actualizado un documento público llamado The Scrum Guide [13] . Se ha revisado seis veces; la versión más reciente se publicó en noviembre de 2020.
Un equipo Scrum se organiza en al menos tres categorías de personas: el propietario del producto, los desarrolladores y el Scrum Master. El propietario del producto se relaciona con las partes interesadas, aquellas que tienen interés en el resultado del proyecto, para comunicar tareas y expectativas a los desarrolladores. [14] Los desarrolladores en un equipo Scrum organizan el trabajo por sí mismos, con la facilitación de un Scrum Master. [15]
Cada equipo Scrum tiene un propietario de producto. [16] El propietario de producto se centra en el aspecto empresarial del desarrollo del producto y pasa la mayor parte del tiempo en contacto con las partes interesadas y el equipo. El rol está destinado principalmente a representar a las partes interesadas del producto , la voz del cliente o los deseos de un comité , y es responsable de la entrega de resultados comerciales. [17] [18] [19] [20] Los propietarios de producto administran el backlog del producto y son responsables de maximizar el valor que entrega un equipo. [18] No dictan las soluciones técnicas de un equipo, sino que pueden intentar buscar el consenso entre los miembros del equipo. [21] [22]
Como enlace principal del equipo Scrum con las partes interesadas, los propietarios de producto son responsables de comunicar anuncios, definiciones y progreso del proyecto, RIDA ( riesgos , impedimentos, dependencias y suposiciones), cambios de financiación y programación, el backlog del producto y la gobernanza del proyecto, entre otras responsabilidades. [23] [ se necesita una mejor fuente ] Los propietarios de producto también pueden cancelar un sprint si es necesario, sin el aporte de los miembros del equipo. [13]
En Scrum, el término desarrollador o miembro del equipo se refiere a cualquier persona que desempeña un papel en el desarrollo y soporte del producto y puede incluir investigadores, arquitectos , diseñadores, programadores, etc. [13] [24]
Scrum es facilitado por un Scrum Master, cuyo rol es educar y entrenar a los equipos sobre la teoría y la práctica de Scrum. [1] Los Scrum Masters tienen roles y responsabilidades diferentes a los de los líderes de equipo o gerentes de proyecto tradicionales . Algunas responsabilidades de Scrum Master incluyen entrenamiento, establecimiento de objetivos, resolución de problemas, supervisión, planificación, gestión de la cartera de proyectos y facilitación de la comunicación. [1] Por otro lado, los gerentes de proyecto tradicionales a menudo tienen responsabilidades de gestión de personas , que un Scrum Master no tiene. Los equipos Scrum no involucran a los gerentes de proyecto, a fin de maximizar la autoorganización entre los desarrolladores. [25]
Un sprint (también conocido como design sprint , iteración o timebox ) es un período fijo de tiempo en el que los miembros del equipo trabajan en un objetivo específico. Cada sprint normalmente dura entre una semana y un mes, siendo dos semanas el tiempo más común. [3] El resultado del sprint es un entregable funcional o un producto que ha recibido algún desarrollo en incrementos . Cuando un sprint finaliza de forma anormal, el siguiente paso es realizar una nueva planificación del sprint, donde se revisa el motivo de la finalización.
Cada sprint comienza con un evento de planificación del sprint en el que se define un objetivo del sprint. Las prioridades para los sprints planificados se eligen a partir del backlog. Cada sprint finaliza con dos eventos: [8]
La duración máxima sugerida de la planificación del sprint es de ocho horas para un sprint de cuatro semanas. [13]
Cada día durante un sprint, los desarrolladores realizan un scrum diario (que a menudo se lleva a cabo de pie ) con pautas específicas, y que puede ser facilitado por un Scrum Master. [3] [26] Las reuniones de Scrum diarias están destinadas a durar menos de 15 minutos, y se llevan a cabo a la misma hora y en el mismo lugar todos los días. El propósito de la reunión es anunciar el progreso realizado hacia el objetivo del sprint y los problemas que pueden estar obstaculizando el objetivo, sin entrar en ninguna discusión detallada. Una vez finalizado, los miembros individuales pueden pasar a una "sesión de trabajo" o una "fiesta posterior" para una discusión y colaboración prolongadas. [27] Los Scrum Masters son responsables de garantizar que los miembros del equipo utilicen los Scrum diarios de manera efectiva o, si los miembros del equipo no pueden usarlos, proporcionar alternativas para lograr resultados similares. [28] [29]
La revisión del sprint se lleva a cabo al final de un sprint y es una reunión en la que un equipo comparte el trabajo que ha completado con las partes interesadas y se comunica con ellas para brindarles comentarios, expectativas y planes futuros. En una revisión del sprint, se muestran a las partes interesadas los entregables completados. La duración recomendada para una revisión del sprint es de una hora por semana de sprint. [13]
Una retrospectiva de sprint es una reunión separada que permite a los miembros del equipo analizar internamente las fortalezas y debilidades del sprint, las áreas futuras de mejora y las acciones de mejora continua del proceso . [30]
El refinamiento del backlog es un proceso mediante el cual los miembros del equipo revisan y priorizan un backlog para futuros sprints. [31] Puede realizarse como una etapa separada antes del comienzo de un nuevo sprint o como un proceso continuo en el que los miembros del equipo trabajan por sí solos. El refinamiento del backlog puede incluir la división de tareas grandes en tareas más pequeñas y claras, la aclaración de los criterios de éxito y la revisión de prioridades y retornos cambiantes.
Los artefactos son un medio por el cual los equipos de Scrum gestionan el desarrollo de productos al documentar el trabajo realizado para el proyecto. Los principales artefactos de Scrum utilizados son el product backlog, el sprint backlog y el incremento.
El product backlog es un desglose del trabajo a realizar y contiene una lista ordenada de requisitos del producto (como características , correcciones de errores y requisitos no funcionales ) que el equipo mantiene para un producto . El orden de un product backlog corresponde a la urgencia de la tarea. Los formatos comunes para los elementos del backlog incluyen historias de usuario y casos de uso . [25] El product backlog también puede contener la evaluación del valor comercial del propietario del producto y la evaluación del equipo del esfuerzo o la complejidad del producto, que se pueden expresar en puntos de historia utilizando la escala redondeada de Fibonacci . Estas estimaciones intentan ayudar al propietario del producto a medir el cronograma y pueden influir en el orden de los elementos del product backlog. [32]
El propietario del producto mantiene y prioriza los elementos del backlog del producto en función de consideraciones como el riesgo, el valor comercial, las dependencias, el tamaño y el tiempo. Los elementos de alta prioridad en la parte superior del backlog se desglosan en más detalles para que los desarrolladores trabajen en ellos, mientras que las tareas que se encuentran más abajo en el backlog pueden ser más vagas. [3]
El backlog del sprint es el subconjunto de elementos del backlog del producto que los desarrolladores deben abordar en un sprint en particular. [33] Los desarrolladores completan este backlog con las tareas que consideran apropiadas para completar el sprint, utilizando el desempeño anterior para evaluar su capacidad para cada sprint. El enfoque Scrum tiene tareas en el backlog del sprint que no son asignadas a los desarrolladores por ningún individuo o líder en particular. Los miembros del equipo se autoorganizan extrayendo el trabajo según sea necesario de acuerdo con la prioridad del backlog y sus propias capacidades. [34]
Un incremento es un resultado potencialmente liberable de un sprint, que cumple con el objetivo del sprint. Está formado por todos los elementos del backlog del sprint completados, integrados con el trabajo de todos los sprints anteriores.
Un diagrama de evolución, que se utiliza a menudo en Scrum, es un gráfico que se muestra públicamente y muestra el trabajo restante. [35] Proporciona visualizaciones rápidas para referencia. El eje horizontal del diagrama de evolución muestra los días restantes, mientras que el eje vertical muestra la cantidad de trabajo restante cada día. Durante la planificación del sprint, se traza el diagrama de evolución ideal. Luego, durante el sprint, los desarrolladores actualizan el diagrama con el trabajo restante.
El gráfico de avance de la versión, que se actualiza al final de cada sprint, muestra el progreso hacia la entrega del alcance previsto. El eje horizontal del gráfico de avance de la versión muestra los sprints de una versión, mientras que el eje vertical muestra la cantidad de trabajo completado al final de cada sprint.
Algunos gerentes de proyectos creen que la capacidad total de un equipo para un sprint único se puede obtener evaluando el trabajo completado en el último sprint. La recopilación de datos históricos de " velocidad " es una guía para ayudar al equipo a comprender su capacidad.
Algunos han argumentado que los eventos de Scrum, como los Scrum diarios y las revisiones de Scrum, dañan la productividad y desperdician tiempo que podría emplearse mejor en tareas productivas reales. [36] [37] También se ha observado que Scrum plantea dificultades para los equipos de tiempo parcial o geográficamente distantes; aquellos que tienen miembros altamente especializados que estarían mejor trabajando solos o en camarillas de trabajo; y aquellos que no son adecuados para pruebas incrementales y de desarrollo . [38] [39]
Scrum se adapta con frecuencia a diferentes contextos para lograr distintos objetivos. [40] Un enfoque común para adaptar Scrum es la combinación de Scrum con otras metodologías de desarrollo de software, ya que Scrum no cubre todo el ciclo de vida del desarrollo del producto . [41] Varios profesionales de Scrum también han sugerido técnicas más detalladas sobre cómo aplicar o adaptar Scrum a problemas u organizaciones particulares. Muchos se refieren a estas técnicas como "patrones", un uso análogo a los patrones de diseño en arquitectura y software. [42] [43]
Scrumban es un modelo de producción de software basado en Scrum y Kanban . Para ilustrar cada etapa del trabajo, los equipos que trabajan en el mismo espacio suelen utilizar notas adhesivas o una pizarra grande. [44] Los modelos Kanban permiten a un equipo visualizar las etapas y limitaciones del trabajo. [45]
Scrum of scrums es una técnica para operar Scrum a escala para múltiples equipos que se coordinan en el mismo producto. Las reuniones diarias de Scrum of scrums involucran embajadores seleccionados de cada equipo individual, que pueden ser desarrolladores o Scrum Master. Como herramienta para la coordinación, Scrum of scrums permite a los equipos trabajar colectivamente en los riesgos, impedimentos, dependencias y suposiciones (RIDA) de todo el equipo, que pueden rastrearse en un backlog propio. [46] [47]
Scrum a gran escala es un marco de desarrollo de productos que escala Scrum con diversas reglas y pautas, desarrollado por Bas Vodde y Craig Larman . [48] [49] El marco tiene dos niveles: el primer nivel, diseñado para hasta ocho equipos; y el segundo nivel, conocido como "LeSS Huge", que puede acomodar el desarrollo que involucra a cientos de desarrolladores. [50]
Una revisión sistemática encontró "que Distributed Scrum no tiene ningún impacto, positivo o negativo, en el éxito general del proyecto" en el desarrollo de software distribuido. [51]
Martin Fowler , uno de los autores del Manifiesto para el Desarrollo Ágil de Software , ha criticado lo que él llama prácticas "falsamente ágiles" que "no tienen en cuenta los valores y principios ágiles", [52] y "el Complejo Industrial Ágil que impone métodos a las personas" contrarios al principio Ágil de valorar "a los individuos y las interacciones por sobre los procesos y las herramientas" [10] y permitir que los individuos que hacen el trabajo decidan cómo se hace el trabajo, cambiando los procesos para adaptarlos a sus necesidades.
En septiembre de 2016, Ron Jeffries, signatario del Manifiesto Ágil , [10] describió lo que llamó "Dark Scrum", diciendo que "Scrum puede ser muy inseguro para los programadores". [53]
Moving the Scrum Downfield
Ken Schwaber y Jeff Sutherland presentaron Scrum por primera vez en la conferencia OOPSLA en Austin, Texas, en 1995. [...] En 2001, se publicó el primer libro sobre Scrum. [...] Un año después (2002), Ken fundó la Scrum Alliance, con el objetivo de proporcionar capacitación y certificación en Scrum en todo el mundo.
[...] En la práctica, este rol tiene dos aspectos críticos: primero, como representante de las partes interesadas dentro del equipo de desarrollo y, segundo, como representante del equipo del proyecto ante la comunidad de partes interesadas en su conjunto.
