Scrum (desarrollo de software)
Marco de gestión

Parte de una serie sobre
Desarrollo de software
Actividades principales
Paradigmas y modelos
Metodologías y marcos de trabajo
Disciplinas de apoyo
Prácticas
Herramientas
Normas y cuerpos de conocimiento
Glosarios
Esquemas
Eventos Scrum Agile, basados ​​en la Guía Scrum 2020 [1]

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]

Historia

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.

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 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]

Propietario del producto

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]

Desarrolladores

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]

Maestro Scrum

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]

Flujo de trabajo

Sprint

El marco de trabajo Scrum (PBI en la figura se refiere al elemento del backlog del producto)
El proceso scrum

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]

  • Una revisión de sprint (progreso mostrado a las partes interesadas para obtener sus comentarios)
  • Una retrospectiva del sprint (identificando lecciones y mejoras para los próximos sprints)

La duración máxima sugerida de la planificación del sprint es de ocho horas para un sprint de cuatro semanas. [13]

Scrum diario

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

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 usen los Scrum diarios de manera efectiva o, si los miembros del equipo no pueden usarlos, brindar alternativas para lograr resultados similares. [28] [29]

Eventos posteriores al sprint

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]

Refinamiento del backlog

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.

Artefactos

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.

Cartera de productos

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]

Lista de tareas pendientes del sprint

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]

Incremento

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.

Otros artefactos

Diagrama de evolución

Un gráfico de muestra de evolución de un sprint completado, que muestra el esfuerzo restante al final de cada día

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.

Gráfico de quemado de la versión

Un diagrama de evolución de muestra para un lanzamiento, que muestra el alcance completado en cada sprint (MVP = producto mínimo viable )

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.

Velocidad

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.

Limitaciones

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]

Adaptaciones

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

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 de scrums

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

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]

Crítica

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]

Véase también

Citas

  1. ^ abc Ken Schwaber ; Jeff Sutherland . "La guía de Scrum" (PDF) . Scrum.org . Consultado el 15 de junio de 2023 .
  2. ^ "¿Qué es un Scrum Master? Todo lo que necesitas saber - Forbes Advisor". www.forbes.com . Consultado el 16 de noviembre de 2023 .
  3. ^ abcde Schwaber, Ken (1 de febrero de 2004). Gestión ágil de proyectos con Scrum . Microsoft Press . ISBN. 978-0-7356-1993-7.
  4. ^ "¿Qué es Scrum?". ¿Qué es Scrum? Un marco ágil para completar proyectos complejos – Scrum Alliance . Scrum Alliance . Consultado el 24 de febrero de 2016 .
  5. ^ J. Henry y S. Henry. Evaluación cuantitativa del proceso de mantenimiento de software y volatilidad de los requisitos. En Proc. de la Conferencia de la ACM sobre Ciencias de la Computación, páginas 346–351, 1993.
  6. ^ Takeuchi, Hirotaka; Nonaka, Ikujiro (1 de enero de 1986). "The New New Product Development Game". Harvard Business Review . Consultado el 9 de junio de 2010. Moving the Scrum Downfield
  7. ^ La empresa creadora de conocimiento. Oxford University Press. 1995. pág. 3. ISBN 978-0-19-976233-0. Recuperado el 12 de marzo de 2013 .
  8. ^ ab Sutherland, Jeff (octubre de 2004). "Desarrollo ágil: lecciones aprendidas del primer Scrum". Archivado desde el original (PDF) el 30 de junio de 2014. Consultado el 26 de septiembre de 2008 .
  9. ^ Sutherland, Jeffrey Victor ; Schwaber, Ken (1995). Diseño e implementación de objetos comerciales: actas del taller OOPSLA '95 . Universidad de Michigan . pág. 118. ISBN 978-3-540-76096-2.
  10. ^ abc "Manifiesto para el desarrollo ágil de software" . Consultado el 17 de octubre de 2019 .
  11. ^ 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-7. Consultado 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 proporcionar capacitación y certificación en Scrum en todo el mundo.
  12. ^ "Inicio". Scrum.org . Consultado el 6 de enero de 2020 .
  13. ^ ABCDE Sutherland, Jeff ; Schwaber, Ken (2013). "Guías de Scrum". ScrumGuides.org . Consultado el 15 de junio de 2023 .
  14. ^ Morris, David (2017). Scrum: un marco ideal para proyectos ágiles . En sencillos pasos. Págs. 178-179. ISBN 978-1-84078-731-3.OCLC 951453155  .
  15. ^ Cobb, Charles G. (2015). Guía del director de proyectos para dominar Agile: principios y prácticas para un enfoque adaptativo . Hoboken, NJ: John Wiley & Sons. p. 37. ISBN 978-1-118-99104-6.
  16. ^ Cohn, Mike (2010). Cómo tener éxito con Agile: desarrollo de software con Scrum . Upper Saddle River, NJ: Addison-Wesley. ISBN 978-0-321-57936-2.
  17. ^ Rubin, Kenneth (2013), Essential Scrum. Una guía práctica para el proceso ágil más popular , Addison-Wesley, pág. 173, ISBN 978-0-13-704329-3
  18. ^ ab McGreal, Don; Jocham, Ralph (4 de junio de 2018). El propietario de producto profesional: aprovechar Scrum como ventaja competitiva. Addison-Wesley Professional. ISBN 978-0-13-468665-3.
  19. ^ Pichler, Roman (11 de marzo de 2010). Gestión ágil de productos con Scrum: cómo crear productos que los clientes aman . Addison-Wesley Professional. ISBN 978-0-321-68413-4.
  20. ^ Ambler, Scott. "El rol del propietario del producto: un representante de las partes interesadas en los equipos ágiles". agilemodeling.com . Consultado el 22 de julio de 2016. [...] 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.
  21. ^ "La Guía de Scrum" (PDF) . Scrum.org. p. 6 . Consultado el 15 de junio de 2023 .
  22. ^ "El rol del Product Owner". Scrum Alliance . Consultado el 26 de mayo de 2018 .
  23. ^ "El rol del Product Owner". Preparación para el examen de Scrum Master . Consultado el 3 de febrero de 2017 .
  24. ^ 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.
  25. ^ ab 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.
  26. ^ "¿Qué es un Scrum diario?". Scrum.org . Consultado el 6 de enero de 2020 .
  27. ^ Flewelling, Paul (2018). Manual del desarrollador ágil: Obtenga más valor de su desarrollo de software: obtenga lo mejor de la metodología ágil . Birmingham, Reino Unido: Packt Publishing Ltd. p. 91. ISBN 978-1-78728-020-5.
  28. ^ McKenna, Dave (2016). El arte de Scrum: cómo los Scrum Masters unen a los equipos de desarrollo y liberan la agilidad . Aliquippa, PA: CA Press. p. 126. ISBN 978-1-4842-2276-8.
  29. ^ Drongelen, Mike van; Dennis, Adam; Garabedian, Richard; Gonzalez, Alberto; Krishnaswamy, Aravind (2017). Desarrollo de aplicaciones móviles Lean: aplique metodologías Lean startup para desarrollar aplicaciones exitosas para iOS y Android . Birmingham, Reino Unido: Packt Publishing Ltd. p. 43. ISBN 978-1-78646-704-1.
  30. ^ Rubin, Kenneth (2012), Essential Scrum. A Practical Guide to the Most Popular Agile Process , Addison-Wesley (publicado en 2013), pág. 375, ISBN 978-0-13-704329-3
  31. ^ Project Management Institute 2021, Glosario §3 Definiciones. sfn error: no target: CITEREFProject_Management_Institute2021 (help)
  32. ^ Higgins, Tony (31 de marzo de 2009). "Creación de requisitos en un mundo ágil". BA Times.
  33. ^ Russ J. Martinelli; Dragan Z. Milosevic (5 de enero de 2016). Project Management ToolBox: Tools and Techniques for the Practicing Project Manager [Caja de herramientas de gestión de proyectos: herramientas y técnicas para el director de proyectos en ejercicio]. Wiley. pág. 304. ISBN 978-1-118-97320-2.
  34. ^ Ken Schwaber ; Jeff Sutherland . "La guía de Scrum" (PDF) . Scrum.org . Consultado el 25 de mayo de 2018 .
  35. ^ Charles G. Cobb (27 de enero de 2015). Guía del director de proyectos para dominar Agile: principios y prácticas para un enfoque adaptativo. John Wiley & Sons. pág. 378. ISBN 978-1-118-99104-6.
  36. ^ Jenson, John (8 de marzo de 2019). «Reuniones: el asesino de la productividad para los desarrolladores». TandemSeven – The Experience Innovation Company . Archivado desde el original el 5 de junio de 2020. Consultado el 5 de junio de 2020 .
  37. ^ "No a todos los desarrolladores les gusta Agile, y aquí hay 5 razones por las que lo hacen". Business Matters . 4 de diciembre de 2019 . Consultado el 5 de junio de 2020 .
  38. ^ 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 .
  39. ^ "Problemas y desafíos en la implementación de Scrum" (PDF) . Revista internacional de investigación científica e ingeniería . 3 (8). Agosto de 2012. Consultado el 10 de diciembre de 2015 .
  40. ^ 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". Revista de sistemas y software . 183 : 111110. doi :10.1016/j.jss.2021.111110. ISSN  0164-1212. S2CID  240950847.
  41. ^ Hron, M.; Obwegeser, N. (enero de 2018). "Scrum en la práctica: una descripción general de las adaptaciones de Scrum" (PDF) . Actas de la 51.ª Conferencia Internacional de Hawái sobre Ciencias de Sistemas (HICSS) de 2018, del 3 al 6 de enero de 2018 .
  42. ^ Bjørnvig, Gertrud; Coplien, Jim (21 de junio de 2008). "Scrum como patrones organizativos". Gertrudis y Cope.
  43. ^ "Comunidad de patrones Scrum". ScrumPLoP.org . Consultado el 22 de julio de 2016 .
  44. ^ Ladas, Corey (27 de octubre de 2007). "scrum-ban". Ingeniería de software lean. Archivado desde el original el 23 de agosto de 2018. Consultado el 13 de septiembre de 2012 .
  45. ^ 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 .
  46. ^ "Gestión de riesgos: cómo evitar que los riesgos arruinen sus proyectos". Kelly Waters.
  47. ^ "Scrum of Scrums". Agile Alliance. 17 de diciembre de 2015. Archivado desde el original el 9 de febrero de 2014. Consultado el 17 de diciembre de 2013 .
  48. ^ "Scrum a gran escala (LeSS)". 2014.
  49. ^ Grgic (2015). "Desescalando la organización con LeSS (Blog)".
  50. ^ Larman, Craig; Bas Vodde (mayo-junio de 2013). "Escalar el desarrollo ágil" (PDF) . Crosstalk .
  51. ^ 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.
  52. ^ Fowler, Martin (25 de agosto de 2018). "El estado del software ágil en 2018". martinfowler.com . Archivado desde el original el 14 de septiembre de 2023. Consultado el 14 de septiembre de 2023 .
  53. ^ Jeffries, Ron (8 de septiembre de 2016). "Dark Scrum". ronjeffries.com . Consultado el 6 de mayo de 2024 .

Referencias generales y citadas

  • Deemer, Pete; Benefield, Gabrielle; Larman, Craig; Vodde, Bas (2009). "La introducción a Scrum" . Consultado el 1 de junio de 2009 .
  • Janoff, NS; Rising, L. (2000). "El proceso de desarrollo de software Scrum para equipos pequeños" (PDF) . Archivado desde el original (PDF) el 6 de noviembre de 2015. Consultado el 26 de febrero de 2015 .
  • 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 dirección de proyectos (Guía del PMBOK) (7.ª ed.). Newtown Square, PA: Project Management Institute. 2021. ISBN 978-1-62825-664-2.
  • Rubin, Kenneth (2013). Essential Scrum: Una guía práctica para el proceso ágil más popular . Addison-Wesley. pág. 173. ISBN 978-0-13-704329-3.
  • Vacaniti, Daniel (febrero de 2018). "La guía Kanban para equipos Scrum" (PDF) . scrum.org . Consultado el 12 de marzo de 2018 .
  • Verheyen, Gunther (2013). Scrum: una guía de bolsillo (un compañero de viaje inteligente) . ISBN 978-90-8753-720-3 . 
Wikimedia Commons tiene medios relacionados con Scrum (desarrollo) .
Wikisource tiene el texto original relacionado con este artículo:
La guía de Scrum
  • Biblioteca Scrum de Agile Alliance
  • Una descripción del proceso Scrum por parte del proyecto del marco de procesos Eclipse (EPF)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Scrum_(software_development)&oldid=1248087313"