Scrum es un marco ágil de colaboración en equipo comúnmente utilizado en el desarrollo de software y otras industrias.
Scrum prescribe que los equipos divida el trabajo en objetivos que deben completarse dentro de iteraciones determinadas en el tiempo , llamadas sprints. Cada sprint no dura más de un mes y normalmente dura dos semanas. El equipo de scrum evalúa el progreso en reuniones de pie con plazos definidos de hasta 15 minutos, llamadas scrums diarios. Al final del sprint, el equipo celebra 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 . A la persona a cargo de un equipo scrum se le suele llamar scrum master . [2]
El enfoque de Scrum para el desarrollo de productos implica llevar la autoridad para la 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 retroalimentación continua y flexibilidad, lo que requiere que los equipos se autoorganicen fomentando la coubicación física o la colaboración estrecha en línea, y exige comunicación frecuente entre todos los miembros del equipo. El enfoque flexible y semi-no planificado 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 proviene de un artículo de Harvard Business Review de 1986 titulado "The New New Product Development Game" de Hirotaka Takeuchi e Ikujiro Nonaka . Basándose en estudios de casos de empresas manufactureras de las industrias automotriz, fotocopiadora e impresora , los autores describieron un nuevo enfoque para el desarrollo de productos para aumentar la velocidad y la flexibilidad. A esto lo llamaron el enfoque del rugby , ya que el proceso involucra a un único equipo multifuncional que opera en múltiples fases superpuestas, en las que el equipo "intenta recorrer la distancia como una unidad, pasándose el balón de un lado a otro". [6] Más tarde, los autores desarrollaron scrum en su libro, The Knowledge Creating Company. [7]
A principios de la década de 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 juntos más tarde para integrar sus ideas en un marco único, 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 la Estación de Investigación DuPont y la Universidad. de Delaware para desarrollar Scrum. Ogunnaike creía que los proyectos de desarrollo de software a menudo podrían fallar cuando cambian las condiciones iniciales, si la gestión del producto no estaba arraigada en la práctica empírica. [3]
En 2002, Schwaber fundó junto con otros la Scrum Alliance y creó la serie de acreditaciones Certified Scrum . [11] Schwaber dejó Scrum Alliance a finales de 2009 y posteriormente fundó Scrum.org, que supervisa la serie paralela de acreditación Professional Scrum . [12] Desde 2009, Schwaber y Sutherland han publicado y actualizado un documento público llamado The Scrum Guide [13] . Ha sido revisado 6 veces, siendo la versión actual de noviembre de 2020.
Un equipo scrum está organizado en al menos tres categorías de personas: el propietario del producto, los desarrolladores y el scrum master. El propietario del producto se comunica 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 de un equipo scrum organizan el trabajo por sí mismos, con la ayuda de un scrum master. [15] Los equipos de Scrum, idealmente, deberían respetar los cinco valores de scrum: compromiso, coraje, concentración, apertura y respeto. [13]
Cada equipo scrum tiene un propietario de producto. [16] El propietario del producto se centra en el lado comercial del desarrollo del producto y pasa la mayor parte del tiempo en contacto con las partes interesadas y el equipo. El rol está destinado a representar principalmente 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 productos administran el trabajo pendiente del producto , que es esencialmente la lista de tareas pendientes en ejecución del proyecto, y son responsables de maximizar el valor que ofrece 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 productos son responsables de comunicar los anuncios, las definiciones y el progreso del proyecto, los RIDA ( riesgos , impedimentos, dependencias y suposiciones), los cambios de financiación y programación, la cartera de productos y la gobernanza del proyecto, entre otros. otras responsabilidades. [23] [ se necesita una mejor fuente ] Los propietarios de productos también pueden cancelar un sprint si es necesario, sin la participación de los miembros del equipo. [13]
En scrum, el término desarrollador o miembro del equipo se refiere a cualquier persona que desempeñe 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, cuya función 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 proyectos tradicionales . Algunas responsabilidades de scrum master incluyen entrenamiento, establecimiento de objetivos, resolución de problemas, supervisión, planificación, gestión de trabajos pendientes y facilitación de la comunicación. [1] Por otro lado, los gerentes de proyectos tradicionales a menudo tienen responsabilidades de gestión de personas , algo que un scrum master no tiene. Los equipos Scrum no involucran a los gerentes de proyecto, para maximizar la autoorganización entre los desarrolladores. [25]
Un sprint (también conocido como iteración , timebox o sprint de diseño ) es un período de tiempo fijo en el que los miembros del equipo trabajan en un objetivo específico. Cada sprint suele durar entre una semana y un mes, siendo dos semanas lo más común. [3] Por lo general, se llevan a cabo reuniones diarias para discutir el progreso del proyecto emprendido, así como las dificultades que enfrentan los miembros del equipo. 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 terminación.
Cada sprint comienza con un evento de planificación de sprint en el que se define un objetivo de sprint. Las prioridades para los sprints planificados se eligen a partir del trabajo pendiente. Cada sprint termina con dos eventos: [8]
Scrum enfatiza los resultados procesables al final de cada sprint, lo que acerca el producto desarrollado al éxito en el mercado.
Al comienzo de un sprint, el equipo scrum realiza un evento de planificación de sprint para:
La duración máxima sugerida para 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 (a menudo realizado de pie ) con pautas específicas, y que puede ser facilitado por un scrum master. [3] [26] Las reuniones de scrum diarias deben durar menos de 15 minutos y realizarse a la misma hora y 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 participar en 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 scrums diarios de forma eficaz o, si los miembros del equipo no pueden utilizarlos, de proporcionar alternativas para lograr resultados similares. [28] [29]
Realizada al final de un sprint, una revisión de sprint es una reunión en la que un equipo comparte el trabajo que han completado con las partes interesadas y se comunica con ellos sobre comentarios, expectativas y planes futuros. En una revisión de sprint, los entregables completados se muestran a las partes interesadas, a quienes también se les debe informar sobre los incrementos del producto y los trabajos en progreso. La duración recomendada para una revisión de 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, áreas futuras de mejora y acciones de mejora continua de procesos . [30]
El refinamiento del trabajo pendiente es un proceso mediante el cual los miembros del equipo revisan y priorizan un trabajo pendiente 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í mismos. El refinamiento del trabajo pendiente puede incluir la división de tareas grandes en otras más pequeñas y claras, la clarificación de los criterios de éxito y la revisión de prioridades y retornos cambiantes. Se recomienda invertir hasta el 10 por ciento de la capacidad de sprint de un equipo en el refinamiento del trabajo pendiente. [13]
Los artefactos son un medio mediante el cual los equipos scrum gestionan el desarrollo de productos documentando el trabajo realizado para el proyecto. Los principales artefactos de scrum utilizados son el trabajo pendiente del producto, el trabajo pendiente del sprint y el incremento.
El trabajo pendiente del producto es un desglose del trabajo por realizar y contiene una lista ordenada de requisitos del producto (como características , correcciones de errores , requisitos no funcionales ) que el equipo mantiene para un producto . El orden de una cartera de productos corresponde a la urgencia de la tarea. Los formatos comunes para los elementos del trabajo pendiente incluyen historias de usuarios y casos de uso . [25] La cartera de productos 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 la historia utilizando la escala redondeada de Fibonacci . Estas estimaciones ayudan al propietario del producto a evaluar el cronograma y pueden influir en el pedido de los elementos de la cartera de productos. [32]
El propietario del producto mantiene y prioriza los elementos de la cartera de productos 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 trabajo pendiente se desglosan con más detalle para que los desarrolladores trabajen en ellos, mientras que las tareas que se encuentran más abajo en el trabajo pendiente pueden ser más vagas. [3]
El sprint backlog es el subconjunto de elementos del product backlog que los desarrolladores deben abordar en un sprint particular. [33] Los desarrolladores llenan este trabajo pendiente con 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 ningún individuo o líder en particular asigna a los desarrolladores. Los miembros del equipo se autoorganizan realizando el trabajo según sea necesario de acuerdo con la prioridad del trabajo pendiente y sus propias capacidades y posibilidades. [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 incremento ideal es completo, en pleno funcionamiento y en condiciones utilizables.
Utilizado a menudo en scrum, un gráfico de evolución es un gráfico que se muestra públicamente y que muestra el trabajo restante. [35] Actualizado todos los días, proporciona visualizaciones rápidas como referencia. El eje horizontal del gráfico de avance 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 gráfico de evolución ideal. Luego, durante el sprint, los desarrolladores actualizan el gráfico con el trabajo restante para que el gráfico se actualice día a día, mostrando una comparación entre lo real y lo previsto.
Actualizado al final de cada sprint, el gráfico de avance de lanzamientos muestra el progreso hacia la entrega de un alcance de pronóstico. El eje horizontal del gráfico de avance de lanzamiento muestra los sprints en un lanzamiento, mientras que el eje vertical muestra la cantidad de trabajo completado al final de cada sprint.
Algunos gerentes de proyectos creen que el esfuerzo de capacidad total de un equipo para un solo sprint se puede derivar 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. No obstante, el concepto de velocidad ha sido controvertido entre los practicantes de scrum.
Algunos han argumentado que los eventos de scrum, como el scrum diario y la revisión de scrum, perjudican la productividad y desperdician tiempo que podría dedicarse mejor a tareas productivas reales. [36] [37] En la práctica, muchos practicantes de scrum llevan a cabo eventos, como el scrum diario, como una discusión extendida, sin cumplir con el requisito del timeboxing. [ cita necesaria ]
También se ha observado que Scrum plantea dificultades para varios tipos de equipos, incluidos aquellos que trabajan a tiempo parcial o están geográficamente distantes; que tienen miembros altamente especializados y estarían mejor trabajando solos o en camarillas de trabajo; que tienen muchas dependencias externas que interrumpen la realización de breves sprints de trabajo planificados; y que no son adecuados para pruebas incrementales y de desarrollo. [38] [39]
Scrum frecuentemente se adapta o adapta en diferentes contextos para lograr diferentes 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 de desarrollo del producto . [41] Varios practicantes 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 al diseño de patrones 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] Scrumban es especialmente adecuado para el mantenimiento de productos con elementos de trabajo frecuentes e inesperados, como defectos de producción o errores de programación. En tales casos, los sprints de scrum de tiempo limitado pueden no ser tan beneficiosos, aunque aún se pueden aplicar los eventos diarios de scrum y otras prácticas. Al mismo tiempo, los modelos kanban permiten a un equipo visualizar las etapas y limitaciones del trabajo. [45]
Scrum de scrums es una técnica para operar scrum a escala, para múltiples equipos coordinándose en el mismo producto. Las reuniones diarias de scrum-of-scrums involucran a embajadores seleccionados de cada equipo individual, que pueden ser desarrolladores o scrum master. Como herramienta de coordinación, scrum of scrums permite a los equipos trabajar colectivamente en riesgos, impedimentos, dependencias y suposiciones (RIDA) de todo el equipo, que pueden rastrearse en su propio trabajo pendiente. [46] [47]
Scrum a gran escala es un marco de desarrollo de productos que escala scrum con reglas y pautas variadas, 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 "falsas-ágiles" que "hacen caso omiso de los valores y principios ágiles" [52] y "el Complejo Industrial Ágil impone métodos a las personas". contrario al principio ágil de valorar "individuos e interacciones sobre procesos y herramientas" [10] y permitir que las personas que realizan el trabajo decidan cómo se realiza el trabajo, cambiando los procesos para adaptarlos a sus necesidades.
En septiembre de 2016, Ron Jeffries, signatario del Manifiesto Ágil, [53] publicó sobre lo que llamó "Dark Scrum" diciendo que "Scrum puede ser muy inseguro para los programadores". Ron dice que Scrum como sistema crea expectativas poco realistas y resulta en culpa en lugar de mejora. [54]
Moviendo el Scrum hacia abajo
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ó Scrum Alliance, con el objetivo de brindar capacitación y certificación Scrum en todo el mundo.
[...] en la práctica resulta que hay dos aspectos críticos en este rol: 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.
