Hispanopedia Wiki
Articulo de referencia

Scrum (gestión de proyectos)

Eventos Scrum Agile, basados ​​en la Guía Scrum 2020 [ 1 ] Scrum es un marco de colaboración de equipo ágil que se utiliza comúnmente en el desarrollo de software y otras indust...

Hispanopedia WikiContenido en espanolLectura gratuita

Eventos Scrum Agile, basados ​​en la Guía Scrum 2020 [ 1 ]

Scrum es un marco de colaboración de equipo ágil que se utiliza comúnmente en el desarrollo de software y otras industrias.

Scrum prescribe que los equipos dividan el trabajo en objetivos que se completan en iteraciones con plazos definidos , llamadas sprints . Cada sprint no dura más de un mes y suele durar dos semanas. El equipo Scrum evalúa el progreso en reuniones diarias de pie con plazos definidos, de hasta 15 minutos, llamadas Daily Scrums . Al final del sprint, el equipo celebra dos reuniones más: una revisión del sprint para mostrar el trabajo a las partes interesadas y recabar comentarios, y una retrospectiva interna del sprint . La persona a cargo de un equipo Scrum se suele llamar Scrum Master .

Los equipos Scrum deben ser multifuncionales y autogestionados . A diferencia de los enfoques secuenciales, Scrum es un marco iterativo e incremental para el desarrollo de productos. [ 2 ] Scrum permite la retroalimentación continua y la flexibilidad, requiriendo que los equipos se autoorganicen fomentando la ubicación física conjunta 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 el proyecto evoluciona. [ 3 ]

Historia

El uso del término scrum en el desarrollo de software proviene de un artículo de 1986 de la Harvard Business Review titulado "The New New Product Development Game" de Hirotaka Takeuchi e Ikujiro Nonaka . Basándose en estudios de caso de empresas manufactureras de las industrias automotriz, de fotocopiadoras e impresoras , los autores describieron un nuevo enfoque para el desarrollo de productos que buscaba mayor velocidad y flexibilidad. Lo denominaron el enfoque rugby , ya que el proceso implica un único equipo multifuncional que opera en múltiples fases superpuestas en las que el equipo "intenta llegar lejos como una unidad, pasándose el balón de un lado a otro". [ 4 ] Posteriormente, los autores desarrollaron el concepto de scrum en su libro The Knowledge Creating Company . [ 5 ]

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 a él con el término Scrum . [ 6 ] Posteriormente, Sutherland y Schwaber colaboraron 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, [ 7 ] y el Manifiesto para el Desarrollo Ágil de Software en 2001. [ 8 ] 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 podían fracasar cuando las condiciones iniciales cambiaban si la gestión del producto no se basaba en la práctica empírica. [ 9 ]

En 2002, Schwaber, junto con otros, fundó la Scrum Alliance y creó la serie de acreditaciones Certified Scrum . [ 10 ] Schwaber dejó la Scrum Alliance a finales de 2009 y posteriormente fundó Scrum.org, que supervisa la serie de acreditaciones Professional Scrum , que es paralela. [ 11 ] Desde 2009, Schwaber y Sutherland han publicado y actualizado un documento público llamado The Scrum Guide [ 12 ] . Ha sido revisado seis veces, y la versión más reciente se publicó en noviembre de 2020.

Equipo Scrum

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 comunica con las partes interesadas, aquellas que tienen interés en el resultado del proyecto, para comunicar las tareas y expectativas a los desarrolladores. [ 13 ] Los desarrolladores en un equipo Scrum organizan el trabajo por sí mismos, con la facilitación de un Scrum Master. [ 14 ]

propietario del producto

Cada equipo Scrum tiene un propietario de producto. [ 15 ] El propietario de producto se centra en el aspecto comercial del desarrollo del producto y dedica la mayor parte de su tiempo a comunicarse con las partes interesadas y el equipo. Su función principal es 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. [ 16 ] [ 17 ] [ 18 ] Los propietarios de producto gestionan el backlog del producto y son responsables de maximizar el valor que entrega un equipo. [ 17 ] Sin embargo, son los desarrolladores, no el propietario de producto, quienes deciden cuánto hacer en cada sprint y cómo lograrlo. [ 2 ]

Desarrolladores

En Scrum, el término desarrollador o miembro del equipo se refiere a cualquier persona que desempeñe un rol en el desarrollo y soporte del producto y puede incluir investigadores, arquitectos , diseñadores, programadores, etc. [ 12 ] [ 19 ]

Maestro Scrum

Scrum es facilitado por un Scrum Master, cuyo rol es educar y guiar a los equipos sobre la teoría y la práctica de Scrum. Los Scrum Masters tienen roles y responsabilidades diferentes a los de los líderes de equipo o los gerentes de proyecto ; los gerentes de proyecto suelen tener responsabilidades de gestión de personal , que un Scrum Master no tiene. Los equipos Scrum no involucran a gerentes de proyecto para maximizar la autoorganización entre los desarrolladores. [ 2 ]

Flujo de trabajo

Sprint

El marco de trabajo Scrum (PBI en la figura se refiere a un elemento de la lista de pendientes del producto).
El proceso scrum

Un sprint (también conocido como sprint de diseño , iteración o período de tiempo ) es un lapso fijo de tiempo durante el cual los miembros del equipo trabajan en un objetivo específico. Cada sprint suele durar entre una semana y un mes, siendo dos semanas la duración más común. El objetivo del sprint debe ser producir algo tangible y terminado, y se considera inmutable para brindar certeza al equipo. Si el objetivo debe modificarse debido a un cambio en las prioridades externas, el propietario del producto o el equipo pueden finalizar el sprint y comenzar uno nuevo con un nuevo objetivo.

Cada sprint comienza con un evento de planificación del sprint en el que se define un objetivo del sprint y se eligen las prioridades del backlog. La duración máxima sugerida para la planificación del sprint es de dos horas por cada semana del sprint. Cada sprint finaliza con una revisión del sprint , donde se muestra el progreso a las partes interesadas para obtener sus comentarios, y una retrospectiva del sprint donde el equipo identifica lecciones aprendidas y mejoras para los próximos sprints. [ 2 ]

Reunión diaria

Una reunión diaria de scrum en la sala de informática.

Cada día durante un sprint, los desarrolladores realizan una reunión diaria de scrum (a menudo de pie ) con pautas específicas, que puede ser facilitada por un scrum master. [ 2 ] Las reuniones diarias de scrum están diseñadas para 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 puedan estar obstaculizando el objetivo, sin entrar en una discusión detallada. Una vez finalizada, los miembros individuales pueden ir a una "sesión de grupos" o una "fiesta posterior" para una discusión y colaboración más extensas. [ 20 ] Los scrum masters son responsables de garantizar que los miembros del equipo utilicen los scrums diarios de manera efectiva o, si los miembros del equipo no pueden utilizarlos, proporcionar alternativas para lograr resultados similares. [ 21 ] [ 22 ]

Eventos posteriores al sprint

Al final de un sprint, la revisión del sprint es una reunión en la que el equipo comparte el trabajo realizado con las partes interesadas y se comunica con ellas sobre sus comentarios, expectativas y planes futuros. En la 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. [ 2 ]

Una retrospectiva de sprint es una reunión independiente que permite a los miembros del equipo analizar internamente las fortalezas y debilidades del sprint, las áreas de mejora futuras y las acciones de mejora continua del proceso . [ 16 ]

Refinamiento de la cartera de pendientes

El refinamiento del backlog es un proceso mediante el cual los miembros del equipo revisan y priorizan un backlog para futuros sprints. Puede realizarse como una etapa separada antes del inicio de un nuevo sprint o como un proceso continuo en el que los miembros del equipo trabajan de forma independiente. El refinamiento del backlog 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. [ 23 ] Este proceso se conocía anteriormente como "refinamiento". [ 24 ]

Artefactos

Los artefactos son una herramienta que utilizan los equipos Scrum para gestionar el desarrollo de productos, documentando el trabajo realizado para el proyecto. Existen muchos tipos de artefactos Scrum, siendo los tres más comunes: el backlog del producto, el backlog del sprint y el incremento.

cartera de productos

El backlog del producto 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 backlog del producto corresponde a la urgencia de la tarea. Los formatos comunes para los elementos del backlog incluyen historias de usuario y casos de uso . [ 2 ] El backlog del producto también puede contener la evaluación del propietario del producto sobre el valor comercial y la evaluación del equipo sobre el esfuerzo o la complejidad del producto, que se puede expresar en puntos de historia utilizando la escala de Fibonacci redondeada . Estas estimaciones intentan ayudar al propietario del producto a calcular el cronograma y pueden influir en el orden de los elementos del backlog del producto. [ 25 ] Los elementos de alta prioridad en la parte superior del backlog se desglosan con más detalle para que los desarrolladores trabajen en ellos, mientras que las tareas más abajo en el backlog pueden ser más vagas. [ 2 ]

Lista de tareas pendientes del sprint

El backlog del sprint es el subconjunto de elementos del backlog del producto destinados a que los desarrolladores los aborden en un sprint en particular. [ 26 ] Los desarrolladores completan este backlog con las tareas que consideran apropiadas para 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 han sido asignadas a los desarrolladores por ninguna persona o líder en particular. Los desarrolladores se autoorganizan tomando trabajo según sea necesario de acuerdo con la prioridad del backlog y sus propias capacidades y capacidad, junto con otros factores como la oportunidad de aprendizaje. [ 2 ]

Incremento

Un incremento es un resultado potencialmente liberable de un sprint, que cumple con el objetivo del sprint y la definición de terminado. Se forma a partir de todos los elementos del backlog del sprint completados, integrados con el trabajo de todos los sprints anteriores. [ 2 ]

Otros artefactos

Gráfico de avance

Un ejemplo de gráfico de progreso para un sprint completado, que muestra el esfuerzo restante al final de cada día.

El gráfico de quemado, frecuentemente utilizado en Scrum, es un gráfico público que muestra el trabajo restante. [ 27 ] Proporciona visualizaciones rápidas para referencia. El eje horizontal del gráfico de quemado 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 quemado ideal.

Tabla de quemado

Un ejemplo de gráfico de avance para una versión, que muestra el alcance completado en cada sprint (MVP = producto mínimo viable ).

Actualizado al final de cada sprint, el gráfico de progreso de la versión muestra el avance hacia la entrega del alcance previsto. El eje horizontal del gráfico de progreso 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. [ 28 ]

Velocidad

La capacidad total de un equipo para un sprint se puede estimar evaluando el trabajo realizado en el sprint anterior. La recopilación de datos históricos de " velocidad " sirve de guía para ayudar al equipo a comprender su capacidad.

Definición de hecho

La "definición de terminado" de un equipo es una lista de verificación de lo que se debe completar para que el trabajo se considere "terminado". [ 29 ] La definición de terminado no garantiza necesariamente que el trabajo esté listo para ser lanzado, ya que hacerlo al principio del desarrollo puede no ser factible; en cambio, representa qué tan cerca puede llegar el equipo razonablemente con sus capacidades existentes. A medida que el equipo mejora, la definición de terminado debe evolucionar para alinearse con lo que se necesita para que el trabajo sea lanzado. [ 2 ]

Un término relacionado es la "definición de listo", que es una lista de verificación de lo que se debe completar antes de comenzar a trabajar en un elemento. [ 30 ]

Crítica

Algunos han argumentado que los eventos de Scrum, como las reuniones diarias de Scrum y las revisiones de Scrum, perjudican la productividad y desperdician tiempo que podría emplearse mejor en tareas realmente productivas. [ 31 ] También se ha observado que Scrum plantea dificultades para equipos a tiempo parcial o geográficamente distantes; aquellos que tienen miembros altamente especializados que estarían mejor trabajando solos o en grupos de trabajo; y aquellos que no son adecuados para pruebas incrementales y de desarrollo . [ 32 ] [ 33 ]

Una revisión sistemática encontró que "Scrum distribuido no tiene impacto, positivo o negativo, en el éxito general del proyecto" en el desarrollo de software distribuido. [ 34 ]

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 "ignoran los valores y principios de Agile" [ 35 ] y "el Complejo Industrial Ágil que impone métodos a las personas" contrario al principio de Agile de valorar "a los individuos y las interacciones por encima de los procesos y las herramientas" [ 8 ] y permitir que los individuos 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 , firmante del Manifiesto Ágil , [ 8 ] describió lo que denominó "Scrum Oscuro", afirmando que "los abusos son casi inevitables hasta que la gente realmente aprenda los principios y valores de Scrum". Se centró particularmente en la lenta adopción de la autoorganización. [ 36 ]

Adaptaciones

Scrum se adapta con frecuencia a diferentes contextos para lograr diversos objetivos. [ 37 ] Un enfoque común para adaptar Scrum es combinarlo con otras metodologías de desarrollo de software, ya que Scrum no abarca todo el ciclo de vida del desarrollo del producto . [ 38 ] 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 al de los patrones de diseño en arquitectura y software. [ 39 ] [ 40 ]

Scrumban

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 usar notas adhesivas o una pizarra grande. Los modelos Kanban permiten a un equipo visualizar las etapas y limitaciones del trabajo. [ 41 ]

Scrum de scrums

Scrum de Scrums es una técnica para implementar Scrum a gran escala para múltiples equipos que coordinan el mismo producto. Las reuniones diarias de Scrum de Scrums involucran embajadores seleccionados de cada equipo, que pueden ser desarrolladores o Scrum Masters. Como herramienta de coordinación, Scrum de Scrums permite a los equipos trabajar colectivamente en los riesgos, impedimentos, dependencias y supuestos (RIDA) de todo el equipo, los cuales pueden ser monitoreados en su propio backlog. [ 42 ]

Scrum a gran escala

Scrum a gran escala es un sistema organizativo para el desarrollo de productos que adapta Scrum con reglas y directrices variadas, desarrollado por Bas Vodde y Craig Larman . El marco consta de dos niveles: el primero, diseñado para hasta ocho equipos; y el segundo, conocido como «LeSS Huge», que puede dar cabida a proyectos de desarrollo con cientos de desarrolladores.

Véase también

Citas

  1. ↑ Ken Schwaber ; Jeff Sutherland . "La guía de Scrum" (PDF) . Scrum.org . Consultado el 15 de junio de 2023 .
  2. ^ Pete Deemer ;​​​​​​​ ​Gabrielle Benefield; Craig Larman; Bas Vodde (17 de diciembre de 2012). "The Scrum Primer: una guía ligera para la teoría y la práctica de Scrum (versión 2.0)" . InformaciónQ.
  3. ↑ J. Henry y S. Henry. Evaluación cuantitativa del proceso de mantenimiento de software y la volatilidad de los requisitos. En Actas de la Conferencia ACM sobre Ciencias de la Computación, páginas 346–351, 1993.
  4. ↑ Takeuchi, Hirotaka; Nonaka, Ikujiro (1 de enero de 1986). "El nuevo juego del desarrollo de productos" . Harvard Business Review . Recuperado el 9 de junio de 2010. Llevando el Scrum a un nuevo nivel .
  5. ↑ La empresa creadora de conocimiento . Oxford University Press. 1995. pág. 3. ISBN  978-0-19-976233-0. Consultado el 12 de marzo de 2013 .
  6. ↑ Sutherland, Jeff (octubre de 2004). "Desarrollo ágil: lecciones aprendidas del primer Scrum" . Archivado del original (PDF) el 30 de junio de 2014. Recuperado el 26 de septiembre de 2008 .
  7. ↑ Sutherland, Jeffrey Victor ; Schwaber, Ken (1995). Diseño e implementación de objetos de negocio: Actas del taller OOPSLA '95 . Universidad de Michigan . pág. 118. ISBN  978-3-540-76096-2.
  8. 1 2 3 "Manifiesto para el desarrollo ágil de software" . Consultado el 17 de octubre de 2019 .
  9. ↑ Schwaber, Ken (1 de febrero de 2004). Gestión ágil de proyectos con Scrum . Microsoft Press . ISBN 978-0-7356-1993-7.
  10. ↑ Maximini, Dominik (8 de enero de 2015). La cultura Scrum: Introducción de métodos ágiles en las organizaciones . Gestión para profesionales. Cham: Springer (publicado en 2015). pág. 26. ISBN  978-3-319-11827-7Recuperado el 25 de agosto de 2016. 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 brindar capacitación y certificación de Scrum a nivel mundial.
  11. ↑ "Inicio" . Scrum.org . Consultado el 6 de enero de 2020 .
  12. 1 2 Sutherland, Jeff ; Schwaber, Ken (2013). "Guías Scrum" . ScrumGuides.org . Recuperado el 15 de junio de 2023 .
  13. ↑ Morris, David (2017). Scrum: un marco ideal para proyectos ágiles . En Easy Steps. pp. 178–179 . ISBN  978-1-84078-731-3OCLC 951453155​​ 
  14. ↑ Cobb, Charles G. (2015). The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach . Hoboken, NJ: John Wiley & Sons. p. 37. ISBN  978-1-118-99104-6.
  15. ↑ Cohn, Mike (2010). Succeeding with Agile: Software Development Using Scrum . Upper Saddle River, NJ: Addison-Wesley. ISBN 978-0-321-57936-2.
  16. 1 2 Rubin, Kenneth (2013), Essential Scrum. A Practical Guide to the Most Popular Agile Process , Addison-Wesley, pp. 173, 375, ISBN  978-0-13-704329-3
  17. 1 2 McGreal, Don; Jocham, Ralph (4 de junio de 2018). El Product Owner Profesional: Aprovechando Scrum como Ventaja Competitiva . Addison-Wesley Professional. ISBN 978-0-13-468665-3.
  18. ↑ Pichler, Roman (11 de marzo de 2010). Gestión ágil de productos con Scrum: Creando productos que encantan a los clientes . Addison-Wesley Professional. ISBN 978-0-321-68413-4.
  19. ^ Rad, Nader K.; Turley, Frank (2018). Material didáctico Agile Scrum Foundation, segunda edición . 's-Hertogenbosch, Países Bajos: Van Haren. pag. 26.ISBN​  978-94-018-0279-6.
  20. ↑ Flewelling, Paul (2018). Manual del desarrollador ágil: Obtenga más valor de su desarrollo de software: saque el máximo provecho de la metodología ágil . Birmingham, Reino Unido: Packt Publishing Ltd. pág. 91. ISBN  978-1-78728-020-5.
  21. ↑ McKenna, Dave (2016). El arte de Scrum: cómo los Scrum Masters unen a los equipos de desarrollo y desatan la agilidad . Aliquippa, PA: CA Press. pág. 126. ISBN  978-1-4842-2276-8.
  22. ↑ Drongelen, Mike van; Dennis, Adam; Garabedian, Richard; Gonzalez, Alberto; Krishnaswamy, Aravind (2017). Desarrollo de aplicaciones móviles Lean: Aplicación de metodologías Lean Startup para desarrollar aplicaciones iOS y Android exitosas . Birmingham, Reino Unido: Packt Publishing Ltd. pág. 43. ISBN  978-1-78646-704-1.
  23. ↑ Ken Schwaber y Jeff Sutherland (18 de noviembre de 2020). "The Scrum Guide" . scrumguides.org . scrumguides.org . Consultado el 10 de enero de 2025. El refinamiento del Product Backlog es el acto de desglosar y definir aún más los elementos del Product Backlog en elementos más pequeños y precisos.
  24. ↑ Ken Schwaber y Jeff Sutherland (18 de noviembre de 2020). "Revisiones de la Guía Oficial de Scrum" . scrumguides.org . scrumguides.org . Consultado el 10 de enero de 2025. El Product Backlog se refina en lugar de limpiarse .
  25. ↑ Higgins, Tony (31 de marzo de 2009). "Creación de requisitos en un mundo ágil" . BA Times.
  26. ↑ Russ J. Martinelli; Dragan Z. Milosevic (5 de enero de 2016). Project Management ToolBox: Herramientas y técnicas para el gestor de proyectos en ejercicio . Wiley. pág. 304. ISBN  978-1-118-97320-2.
  27. ↑ Charles G. Cobb (27 de enero de 2015). Guía del director de proyecto para dominar Agile: Principios y prácticas para un enfoque adaptativo . John Wiley & Sons. pág. 378. ISBN  978-1-118-99104-6.
  28. ↑ Arafeen, Junaid; Bose, Saugata (septiembre de 2009). "Mejora del desarrollo de software mediante el modelo Scrum analizando los movimientos ascendentes y descendentes en el gráfico de avance del sprint: propuesta para mejores alternativas" . Revista internacional de tecnología de contenido digital y sus aplicaciones . 3 (3) – vía CiteSeerX.
  29. ↑ Hinshelwood, Martin (10 de enero de 2021). "Cómo empezar con una Definición de Hecho (DoD)" . Scrum.org . Consultado el 13 de junio de 2026 .
  30. ↑ "Definición de listo y diferentes formas de usarlo" . Project Management Institute . Consultado el 22 de diciembre de 2025 .
  31. ↑ "No a todos los desarrolladores les gusta la metodología ágil, y aquí hay 5 razones por las que" . Asuntos empresariales . 4 de diciembre de 2019. Consultado el 5 de junio de 2020 .
  32. ↑ Turk, Dan; France, Robert; Rumpe, Bernhard (2014) [2002]. "Limitaciones de los procesos de software ágiles". Actas de la Tercera Conferencia Internacional sobre Programación Extrema y Procesos Flexibles en Ingeniería de Software : 43–46 . arXiv : 1409.6600 .
  33. ↑ "Problemas y desafíos en la implementación de Scrum" (PDF) . Revista Internacional de Investigación Científica y de Ingeniería . 3 (8). Agosto de 2012. Recuperado el 10 de diciembre de 2015 .
  34. ↑ Santos, Ronnie de Souza; Ralph, Pablo; Arshad, Arham; Stol, Klaas-Jan (5 de octubre de 2023). "Scrum distribuido: un metaanálisis de casos" . Encuestas de Computación ACM . 56 (4): 1– 37. doi : 10.1145/3626519 . S2CID 263672588 . 
  35. ↑ Fowler, Martin (25 de agosto de 2018). "El estado del software ágil en 2018" . martinfowler.com . Archivado del original el 14 de septiembre de 2023. Recuperado el 14 de septiembre de 2023 .
  36. ↑ Jeffries, Ron (8 de septiembre de 2016). "Dark Scrum" . ronjeffries.com . Consultado el 6 de mayo de 2024 .
  37. ↑ Hron, Michal; Obwegeser, Nikolaus (1 de enero de 2022). "Por qué y cómo se está adaptando Scrum en la práctica: una revisión sistemática" . Journal of Systems and Software . 183 111110. doi : 10.1016/j.jss.2021.111110 . ISSN 0164-1212 . S2CID 240950847 .  
  38. ↑ Hron, M.; Obwegeser, N. (enero de 2018). "Scrum en la práctica: una visión general de las adaptaciones de Scrum" (PDF) . Actas de la 51.ª Conferencia Internacional de Hawái sobre Ciencias de Sistemas (HICSS), 3-6 de enero de 2018 .
  39. ↑ Bjørnvig, Gertrud; Coplien, Jim (21 de junio de 2008). "Scrum como patrones organizativos" . Gertrude & Cope. Archivado del original el 6 de noviembre de 2012.
  40. ↑ "Comunidad de patrones Scrum" . ScrumPLoP.org . Consultado el 22 de julio de 2016 .
  41. ^ Kniberg, Henrik; Skarin, Mattias (21 de diciembre de 2009). "Kanban y Scrum: aprovechar ambos al máximo" (PDF) . InfoQ . Consultado el 22 de julio de 2016 .
  42. ↑ "Scrum de Scrums" . Agile Alliance. 17 de diciembre de 2015. Archivado del original el 9 de febrero de 2014. Consultado el 17 de diciembre de 2013 .

Referencias generales y citadas

  • Janoff, NS; Rising, L. (2000). "El proceso de desarrollo de software Scrum para equipos pequeños" (PDF) . IEEE Software . 17 (4): 26–32 . doi : 10.1109/52.854065 . Archivado del original (PDF) el 6 de noviembre de 2015. Recuperado el 17 de febrero de 2022 .
  • Münch, Jürgen; Armbrust, Ove; Soto, Martín; Kowalczyk, Martín (2012). Definición y Gestión de Procesos de Software . Saltador. ISBN 978-3-642-24291-5.
  • Guía de los fundamentos de la gestión de proyectos (Guía PMBOK) (7.ª  ed.). Newtown Square, PA: Project Management Institute . 2021. ISBN 978-1-62825-664-2.
  • Vacaniti, Daniel (febrero de 2018). "La guía Kanban para equipos Scrum" (PDF) . scrum.org . Consultado el 12 de marzo de 2018 .