| Desarrollo de software |
|---|
Scrum es un marco que utiliza una mentalidad ágil para desarrollar, entregar y mantener productos complejos, [1] con un énfasis inicial en el desarrollo de software , aunque se ha utilizado en otros campos como investigación, ventas, marketing y tecnologías avanzadas. [2] Está diseñado para equipos de diez miembros o menos, que dividen su trabajo en objetivos que se pueden completar dentro de iteraciones encuadradas en el tiempo, llamadas sprints., no más de un mes y más comúnmente dos semanas. El equipo Scrum evalúa el progreso en reuniones diarias de 15 minutos o menos, llamadas scrums diarios. Al final del sprint, el equipo lleva a cabo dos reuniones más: la revisión del sprint, que demuestra el trabajo realizado a las partes interesadas para obtener comentarios, y la retrospectiva del sprint, que permite al equipo reflexionar y mejorar.
Nombre [ editar ]
El término de desarrollo de software scrum se utilizó por primera vez en un artículo de 1986 titulado "El nuevo juego de desarrollo de nuevos productos" de Hirotaka Takeuchi e Ikujiro Nonaka . [3] El artículo fue publicado en la edición de enero de 1986 de Harvard Business Review. El término se toma prestado del rugby , donde un scrum es una formación de jugadores. El término scrum fue elegido por los autores del artículo porque enfatiza el trabajo en equipo. [4]
En ocasiones, Scrum se ve escrito en mayúsculas, como SCRUM . [5] Si bien la palabra en sí no es un acrónimo , su estilo en mayúsculas probablemente proviene de un artículo anterior de Ken Schwaber [6] que usaba SCRUM en mayúscula en su título. [7] [8]
Si bien se ha permitido que la marca registrada del término Scrum caduque, se considera que pertenece a la comunidad en general y no a un individuo. [9]
Muchos de los términos utilizados en Scrum se escriben normalmente con mayúsculas iniciales (por ejemplo, Scrum Master , Daily Scrum ). Sin embargo, para mantener un tono enciclopédico, este artículo utiliza mayúsculas y minúsculas para estos términos (por ejemplo, scrum master , scrum diario ), a menos que sean marcas reconocidas (como Certified Scrum Master y Professional Scrum Master ).
Ideas clave [ editar ]
Scrum es un marco liviano, iterativo e incremental para administrar trabajos complejos. [10] [11] El marco desafía los supuestos del enfoque secuencial tradicional para el desarrollo de productos, y permite que los equipos se autoorganicen fomentando la ubicación conjunta física o la colaboración estrecha en línea de todos los miembros del equipo, así como el día a día cara a cara. Enfrentar la comunicación entre todos los miembros del equipo y disciplinas involucradas.
Un principio clave de Scrum es el doble reconocimiento de que los clientes cambiarán el alcance de lo que se desea (a menudo llamado volatilidad de requisitos [12] ) y que habrá desafíos impredecibles, para los cuales un enfoque predictivo o planificado no es adecuado. Estos cambios provienen de una variedad de fuentes, pero entender por qué es irrelevante: el cambio simplemente debe aceptarse, adoptarse y analizarse para obtener beneficios.
Como tal, Scrum adopta un enfoque empírico basado en la evidencia : acepta que el problema no puede entenderse o definirse completamente desde el principio y, en cambio, se centra en cómo maximizar la capacidad del equipo para entregar rápidamente, responder a los requisitos emergentes y adaptarse a la evolución. tecnologías y cambios en las condiciones del mercado.
Historia [ editar ]
Hirotaka Takeuchi e Ikujiro Nonaka introdujeron el término scrum en el contexto del desarrollo de productos en su artículo de 1986 de Harvard Business Review , 'The New New New Product Development Game'. [13] Takeuchi y Nonaka luego argumentaron en The Knowledge Creating Company [14] que es una forma de "creación de conocimiento organizacional, [...] especialmente bueno para generar innovación de manera continua, incremental y en espiral".
Los autores describieron un nuevo enfoque para el desarrollo de productos comerciales que aumentaría la velocidad y la flexibilidad, basándose en estudios de casos de empresas manufactureras en las industrias automotriz, fotocopiadora e impresora . [13] Llamaron a esto el enfoque holístico o de rugby , ya que todo el proceso lo realiza un equipo multifuncional en múltiples fases superpuestas, en las que el equipo "intenta recorrer la distancia como una unidad, pasando el balón de un lado a otro". . [13] (En el fútbol de rugby , se usa un scrum para reiniciar el juego, ya que los delanteros de cada equipo se entrelazan con la cabeza hacia abajo e intentan tomar posesión del balón. [15])
El marco de Scrum se basó en la investigación de Schwaber con Tunde Babatunde en la Estación de Investigación DuPont y la Universidad de Delaware. Tunde advirtió que los intentos de desarrollar productos complejos, como el software, que no se basaban en el empirismo, estaban condenados a mayores riesgos y tasas de fracaso a medida que cambian las condiciones y los supuestos iniciales. El empirismo, utilizando frecuentes inspecciones y adaptaciones, con flexibilidad y transparencia, es el enfoque más adecuado.
A principios de la década de 1990, Ken Schwaber utilizó lo que se convertiría en Scrum en su empresa, Advanced Development Methods; mientras que Jeff Sutherland , John Scumniotales y Jeff McKenna desarrollaron un enfoque similar en Easel Corporation, refiriéndose a él usando la palabra scrum. [dieciséis]
Sutherland y Schwaber trabajaron juntos para integrar sus ideas en un solo marco, Scrum. Probaron Scrum y lo mejoraron continuamente, lo que llevó a su artículo de 1995, contribuciones al Manifiesto Agile [17] en 2001, y la difusión y uso mundial de Scrum desde 2002.
En 1995, Sutherland y Schwaber presentaron conjuntamente un documento que describía el marco de Scrum en el Taller de Implementación y Diseño de Objetos de Negocios que se llevó a cabo como parte de Programación Orientada a Objetos, Sistemas, Lenguajes y Aplicaciones '95 (OOPSLA '95) en Austin, Texas. [18] Durante los años siguientes, Schwaber y Sutherland colaboraron para combinar este material, con su experiencia y buenas prácticas en evolución, para desarrollar lo que se conoció como Scrum. [19]
En 2001, Schwaber trabajó con Mike Beedle para describir el método en el libro, Desarrollo de software ágil con Scrum . [20] El enfoque de Scrum para planificar y gestionar el desarrollo de productos implica llevar la autoridad para la toma de decisiones al nivel de las propiedades y certezas de la operación. [7]
En 2002, Schwaber junto con otros fundaron la Scrum Alliance [21] y establecieron la serie de acreditación Certified Scrum . Schwaber dejó la Scrum Alliance a finales de 2009 y fundó Scrum.org [22], que supervisa la serie paralela de acreditación Professional Scrum . [23]
Desde 2009, Schwaber y Sutherland han publicado y actualizado un documento público llamado The Scrum Guide [19] . Se ha revisado 6 veces, siendo la versión actual noviembre de 2020.
Equipo Scrum [ editar ]
 | Es posible que esta sección contenga investigaciones originales . ( Abril de 2019 ) ( Obtenga información sobre cómo y cuándo eliminar este mensaje de plantilla ) |
La unidad fundamental de Scrum es un pequeño equipo de personas, que consta de un propietario de producto, un Scrum Master y desarrolladores. El equipo es autogestionario, multifuncional y se centra en un objetivo a la vez: el objetivo del producto.
Propietario del producto [ editar ]
El propietario del producto, que representa a las partes interesadas del producto y la voz del cliente (o puede representar los deseos de un comité [24] ), es responsable de obtener buenos resultados comerciales. [25] Por lo tanto, el propietario del producto es responsable de la acumulación de productos y de maximizar el valor que ofrece el equipo. [24] El propietario del producto define el producto en términos de resultados centrados en el cliente (por lo general, pero no se limita a, historias de usuarios ), los agrega a la cartera de pedidos del producto y los prioriza en función de la importancia y las dependencias. [26]Un equipo de scrum debe tener solo un propietario de producto (aunque un propietario de producto podría apoyar a más de un equipo) [27] y se recomienda encarecidamente no combinar este rol con el rol de maestro de scrum. El propietario del producto debe centrarse en el lado comercial del desarrollo del producto y dedicar la mayor parte del tiempo a comunicarse con las partes interesadas y el equipo. El propietario del producto no dicta cómo el equipo llega a una solución técnica, sino que busca el consenso entre los miembros del equipo. [28] [29] [30] [se necesita una mejor fuente ]Esta función es crucial y requiere una comprensión profunda de ambas partes: la empresa y los ingenieros (desarrolladores) del equipo scrum. Por lo tanto, un buen propietario de producto debe poder comunicar lo que necesita la empresa, preguntar por qué lo necesita (porque puede haber mejores formas de lograrlo) y transmitir el mensaje a todas las partes interesadas, incluidos los desarrolladores, utilizando un lenguaje técnico, según sea necesario. El propietario del producto utiliza las herramientas empíricas de Scrum para gestionar trabajos altamente complejos mientras controla el riesgo y logra valor.
La comunicación es una responsabilidad fundamental del propietario del producto. La capacidad de transmitir prioridades y empatizar con los miembros del equipo y las partes interesadas es vital para orientar el desarrollo de productos en la dirección correcta. El rol del propietario del producto cierra la brecha de comunicación entre el equipo y sus partes interesadas, sirviendo como un representante de las partes interesadas para el equipo y como un representante del equipo para la comunidad de partes interesadas en general. [31] [32]
Como cara del equipo para las partes interesadas, las siguientes son algunas de las tareas de comunicación del propietario del producto a las partes interesadas: [33]
- Definir y anunciar lanzamientos.
- Comunicar la entrega y el estado del producto.
- Comparta el progreso durante las reuniones de gobierno.
- Comparta RIDA importantes (riesgos, impedimentos, dependencias y suposiciones) con las partes interesadas.
- Negociar prioridades, alcance, financiamiento y cronograma.
- Asegúrese de que la acumulación de productos sea visible, transparente y clara.
La empatía es un atributo clave que debe tener el propietario de un producto: la capacidad de ponerse en el lugar de los demás. Un propietario de producto conversa con diferentes partes interesadas con una variedad de antecedentes, roles laborales y objetivos, y debe poder apreciar estos diferentes puntos de vista. Para ser eficaz, es aconsejable que el propietario de un producto conozca el nivel de detalle que necesita la audiencia. Los desarrolladores necesitan comentarios y especificaciones exhaustivos para poder construir un producto a la altura de las expectativas, mientras que un patrocinador ejecutivo puede necesitar solo resúmenes del progreso. Proporcionar más información de la necesaria puede perder el interés de las partes interesadas y perder tiempo. Los propietarios de productos experimentados prefieren un medio de comunicación directo. [27]
La capacidad de un propietario de producto para comunicarse de manera efectiva también se mejora al ser hábil en técnicas que identifican las necesidades de las partes interesadas, negocian prioridades entre los intereses de las partes interesadas y colaboran con los desarrolladores para garantizar la implementación efectiva de los requisitos.
Desarrolladores [ editar ]
Los desarrolladores realizan todo el trabajo necesario para generar incrementos de valor en cada sprint. [26]
El término desarrolladores [19] se refiere a cualquier persona que desempeñe un papel en el desarrollo y soporte del sistema o producto, y puede incluir investigadores, arquitectos, diseñadores, especialistas en datos, estadísticos, analistas, ingenieros, programadores y probadores, entre otros. [34] Sin embargo, debido a la confusión que puede surgir cuando algunas personas sienten que el término "desarrollador" no se les aplica, a menudo se las conoce como miembros del equipo .
El equipo se autoorganiza. Si bien ningún trabajo debe llegar al equipo excepto a través del propietario del producto, y se espera que el scrum master proteja al equipo de las distracciones, se alienta al equipo a interactuar directamente con los clientes y / o partes interesadas para obtener la máxima comprensión e inmediatez de la retroalimentación. [26]
Scrum master [ editar ]
Scrum es facilitado por un scrum master, quien es responsable de eliminar los impedimentos a la capacidad del equipo para cumplir los objetivos y los entregables del producto. [35] El scrum master no es un líder de equipo o gerente de proyecto tradicional , sino que actúa como una barrera entre el equipo y cualquier influencia que lo distraiga. El scrum master se asegura de que el marco de scrum sea seguido al entrenar al equipo en la teoría y los conceptos de scrum, a menudo facilitando sesiones clave, y anima al equipo a crecer y mejorar. También se ha referido al rol como un facilitador de equipo o un líder-servidor para reforzar estas perspectivas duales.
Las responsabilidades principales de un scrum master incluyen (pero no se limitan a): [36]
- Ayudar al propietario del producto a mantener la acumulación del producto de una manera que garantice que el trabajo necesario se comprenda bien para que el equipo pueda progresar continuamente.
- Ayudar al equipo a determinar la definición de terminado para el producto, con aportes de las partes interesadas clave.
- Entrenar al equipo, dentro de los principios de Scrum, con el fin de ofrecer características de alta calidad para su producto [37]
- Educar a las partes interesadas clave y al resto de la organización sobre los principios de Scrum (y posiblemente Agile)
- Ayudar al equipo de scrum a evitar o eliminar impedimentos para su progreso, ya sean internos o externos al equipo.
- Promover la autoorganización y la funcionalidad cruzada dentro del equipo.
- Facilitar eventos de equipo para asegurar un progreso regular
El scrum master ayuda a las personas y organizaciones a adoptar un pensamiento empírico y esbelto, dejando atrás esperanzas de certeza y previsibilidad.
Una de las diferencias entre el rol de scrum master y el de un director de proyecto es que este último puede tener responsabilidades de gestión de personas y el scrum master no. Un scrum master proporciona una cantidad limitada de dirección, ya que se espera que el equipo esté empoderado y se organice a sí mismo. [38] Scrum no reconoce formalmente el rol de gerente de proyecto, ya que las tendencias tradicionales de comando y control causarían dificultades. [39]
Flujo de trabajo [ editar ]
Sprint [ editar ]
Un sprint (también conocido como iteración o caja de tiempo ) es la unidad básica de desarrollo en Scrum. El sprint es un esfuerzo cronometrado ; es decir, la duración se acuerda y fija de antemano para cada sprint y normalmente es de una semana a un mes, siendo las dos semanas lo más habitual. [7]
Cada sprint comienza con un evento de planificación de sprint en el que se elabora un objetivo de sprint y surge un backlog de sprint, que contiene el trabajo previsto para el próximo sprint. Cada sprint termina con dos eventos:
- una revisión de sprint (progreso mostrado a las partes interesadas)
- una retrospectiva de sprints (identificar lecciones y mejoras para los próximos sprints). [dieciséis]
Scrum enfatiza resultados valiosos y útiles al final del sprint que realmente está terminado. En el caso del software, esto probablemente incluye que los productos estén completamente integrados, probados y documentados, y potencialmente liberables. [39]
Planificación de Sprint [ editar ]
Al comienzo de un sprint, el equipo de scrum realiza un evento de planificación de sprint para:
- Acuerde el objetivo del sprint, una breve descripción de lo que prevén entregar al final del sprint, según las prioridades establecidas por el propietario del producto.
- Seleccionar elementos de la cartera de productos que contribuyan a este objetivo
- Forme una acumulación de sprints discutiendo y acordando mutuamente qué elementos deben realizarse durante ese sprint
La duración máxima de la planificación del sprint es de ocho horas para un sprint de 4 semanas. [19] A medida que se elabora el trabajo detallado, algunos elementos de la cartera de productos pueden dividirse o devolverse a la cartera de productos si el equipo cree que no pueden completar ese trabajo en un solo sprint.
Scrum diario [ editar ]
Cada día durante un sprint, los desarrolladores realizan un scrum diario (a veces realizado de pie ) con pautas específicas: [40] [7]
Todos los desarrolladores vienen preparados. El scrum diario:
- se centra en inspeccionar el progreso hacia la meta del sprint
- debe suceder a la misma hora y en el mismo lugar todos los días
- está limitado (en una caja de tiempo ) a quince minutos
- se lleva a cabo como el equipo decida
- puede incluir otros, aunque solo los desarrolladores deben hablar.
- puede ser facilitado por el Scrum Master
- puede identificar impedimentos para el progreso (p. ej., escollo, riesgo, problema, dependencia retardada, suposición que ha demostrado ser infundada) [41]
- no incluye discusiones
- NO es un "informe de estado" ni un medio para actualizar gráficos de progreso
No debe haber discusiones detalladas durante el scrum diario. Una vez terminada, los miembros individuales pueden discutir los problemas en detalle, lo que a menudo se conoce como una "sesión de grupo" o una "fiesta posterior". [42] Los bloqueadores identificados deben discutirse colectivamente fuera del scrum diario con miras a trabajar hacia una resolución.
Cuando el equipo no ve el valor de este evento, es responsabilidad del scrum master determinar por qué [43] y educar al equipo y a las partes interesadas sobre los principios de Scrum, [37] o alentar al equipo a diseñar su propio método de mantenimiento. el equipo completamente informado del progreso del sprint.
Revisión de Sprint [ editar ]
Realizado al final de un sprint, el equipo:
- presenta el trabajo completado a las partes interesadas (también conocido como la demostración )
- colabora con las partes interesadas en temas como:
- invitar a recibir comentarios sobre el incremento de producto completado
- discutir el impacto del trabajo incompleto (planeado o no)
- recibir sugerencias para el próximo trabajo (orientación sobre en qué trabajar a continuación)
Los Product Owners deberían ver este evento como una valiosa oportunidad para revisar y refinar la acumulación de productos con las partes interesadas.
Directrices para revisiones de sprint:
- No se debe demostrar el trabajo incompleto; aunque se debe presentar a las partes interesadas los incrementos de producto que recibirán, pero también pueden solicitar ver el trabajo en progreso si es necesario. Sin embargo, el equipo solo debe estar preparado para mostrar lo que se ha hecho.
- La duración recomendada es de dos horas para un sprint de dos semanas (proporcional para otras duraciones de sprint). [19]
Sprint retrospectiva [ editar ]
En la retrospectiva del sprint, el equipo:
- reflexiona sobre el sprint pasado
- identifica y acuerda acciones de mejora continua del proceso
Directrices para las retrospectivas de sprints: [ cita requerida ]
- Tres áreas sugeridas para considerar en las retrospectivas de sprint son:
- ¿Qué salió bien durante el sprint?
- ¿Qué no salió bien?
- ¿Qué podríamos hacer de manera diferente en el próximo sprint?
- La duración recomendada es de una hora y media para un sprint de dos semanas (proporcional para otras duraciones del sprint).
El scrum master puede facilitar este evento, pero su presencia no se considera obligatoria.
Refinamiento de la cartera de pedidos [ editar ]
Aunque originalmente no era una práctica central de Scrum, el refinamiento del backlog (antes llamado grooming ) se agregó a la Scrum Guide y se adoptó como una forma de administrar la calidad de los elementos del backlog de productos que ingresan a un sprint. Es el proceso continuo de revisión y modificación / actualización / reorden de los elementos de la cartera de productos a la luz de la nueva información.
Las razones para modificar la acumulación y los elementos incluidos pueden incluir:
- Los elementos más grandes se pueden dividir en varios más pequeños
- Los criterios de aceptación pueden aclararse
- Las dependencias pueden identificarse e investigarse
- Un artículo puede requerir más descubrimiento y análisis.
- Es posible que las prioridades hayan cambiado; los rendimientos esperados ahora serán diferentes
El refinamiento significa que los elementos se preparan y ordenan adecuadamente de una manera que los hace claros y ejecutables para los desarrolladores para la planificación del sprint.
La acumulación también puede incluir deuda técnica (también conocida como deuda de diseño o deuda de código). Este es un concepto en el desarrollo de software que refleja el costo implícito de reprocesamiento adicional causado por elegir una solución fácil ahora en lugar de utilizar un enfoque mejor que tomaría más tiempo.
Se recomienda invertir hasta el 10 por ciento de la capacidad de sprint de un equipo. [19] tras el refinamiento de la cartera de pedidos. Los equipos más maduros no verán esto como un evento definido programado, sino como una actividad ad-hoc que forma parte del flujo de trabajo natural, refinando y ajustando la acumulación de productos cuando sea necesario.
Cancelar un sprint [ editar ]
El propietario del producto puede cancelar un sprint si es necesario, [19] y puede hacerlo con comentarios de otros (desarrolladores, scrum master o administración). Por ejemplo, las circunstancias externas recientes pueden negar el valor del objetivo del sprint, por lo que no tiene sentido continuar.
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.
Artefactos [ editar ]
Esta sección necesita citas adicionales para su verificación . ( Marzo de 2013 ) ( Obtenga información sobre cómo y cuándo eliminar este mensaje de plantilla ) |
Pila de productos [ editar ]
La cartera de productos es un desglose del trabajo por hacer y contiene una lista ordenada de los requisitos del producto que el equipo mantiene para un producto . Los formatos comunes para los elementos de la lista de trabajos pendientes incluyen historias de usuarios y casos de uso . [39] Estos requisitos definen características , corrección de errores , requisitos no funcionales , etc., lo que sea que proporcione un producto viable. El propietario del producto prioriza los elementos de la cartera de productos (PBI) en función de consideraciones como el riesgo, el valor comercial, las dependencias, el tamaño y la fecha necesaria.
La cartera de productos es "lo que se necesita, ordenado cuando se necesita" y es visible para todos, pero solo se puede cambiar con el consentimiento del propietario del producto, quien es responsable de administrar y mantener los elementos de la cartera de productos.
La cartera de productos contiene la evaluación del valor comercial del propietario del producto y puede incluir la evaluación del esfuerzo o la complejidad del equipo, a menudo, pero no siempre, indicada en los puntos de la historia utilizando la escala de Fibonacci redondeada . Estas estimaciones ayudan al propietario del producto a medir la línea de tiempo y pueden influir en el pedido de elementos de la cartera de productos; por ejemplo, para dos características con el mismo valor comercial, el propietario del producto puede programar una entrega más temprana del trabajo con el menor esfuerzo de desarrollo (porque el retorno de la inversión es mayor) o el que tiene un mayor esfuerzo de desarrollo (porque es más complejo o más riesgoso). , y quieren eliminar ese riesgo antes). [44]
La cartera de productos y el valor comercial de cada elemento de la cartera de productos es responsabilidad del propietario del producto. El esfuerzo para entregar cada artículo puede estimarse en puntos de historia o tiempo. Al estimar en puntos de la historia, el equipo reduce la dependencia de los desarrolladores individuales; esto es útil especialmente para equipos dinámicos donde los desarrolladores a menudo se asignan a otro trabajo después de la entrega del sprint. Por ejemplo, si una historia de usuario se estima en 5 en esfuerzo (usando la secuencia de Fibonacci), sigue siendo 5 independientemente de cuántos desarrolladores estén trabajando en ella.
Los puntos de la historia definen el esfuerzo en una caja de tiempo, por lo que no cambian con el tiempo. Por ejemplo, en una hora una persona puede caminar, correr o trepar, pero el esfuerzo realizado es claramente diferente. La progresión de la brecha entre los términos en la secuencia de Fibonacci alienta al equipo a entregar estimaciones cuidadosamente consideradas. Las estimaciones de 1, 2 o 3 implican esfuerzos similares (siendo 1 trivial), pero si el equipo estima un 8 o 13 (o más), el impacto tanto en la entrega como en el presupuesto puede ser significativo. El valor de usar puntos de historia es que el equipo puede reutilizarlos comparando trabajos similares de sprints anteriores, pero debe reconocerse que las estimaciones son relativas a ese equipo. Por ejemplo, una estimación de 5 para un equipo podría ser 2 para otro compuesto por desarrolladores más experimentados con mayor capacidad.
Cada equipo debe tener un propietario de producto, aunque en muchos casos un propietario de producto podría trabajar con más de un equipo. [27] El propietario del producto es responsable de maximizar el valor del producto. El propietario del producto recopila comentarios y comentarios de muchas personas y es presionado por muchas personas, pero en última instancia, tiene la decisión final sobre lo que se construye.
La cartera de productos:
- Captura solicitudes para modificar un producto, incluidas funciones nuevas, reemplazo de funciones antiguas, eliminación de funciones y solución de problemas.
- Garantiza que los desarrolladores tengan un trabajo que maximice el beneficio comercial del producto.
Por lo general, todo el equipo trabaja en conjunto para refinar la acumulación de productos, que evoluciona a medida que surge nueva información sobre el producto y sus clientes, por lo que los sprints posteriores pueden abordar nuevos trabajos.
Gestión [ editar ]
Una cartera de productos, en su forma más simple, es simplemente una lista de elementos en los que trabajar. Tener reglas bien establecidas sobre cómo se agrega, elimina y ordena el trabajo ayuda a todo el equipo a tomar mejores decisiones sobre cómo cambiar el producto. [45]
El propietario del producto da prioridad a los elementos de la cartera de productos en función de los que se necesitan más pronto. Los desarrolladores, influenciados por el objetivo del sprint, eligen elementos para el próximo sprint, moviendo esos elementos del backlog de productos al backlog del sprint, que es la lista de elementos que construirán. Conceptualmente, el objetivo del sprint está influenciado por elementos de alta prioridad en la parte superior de la lista, pero no es inusual ver a los desarrolladores tomar algunos elementos de menor prioridad si queda tiempo dentro del sprint para acomodar más trabajo.
Los elementos de alta prioridad (en la parte superior de la lista de trabajos pendientes) deben desglosarse en más detalles que sean adecuados para que trabajen los desarrolladores. Cuanto más abajo esté el trabajo pendiente, menos detalles serán los elementos. Como lo expresaron Schwaber y Beedle, "cuanto menor sea la prioridad, menos detalles hasta que apenas se pueda distinguir el elemento de la lista de trabajos pendientes". [7]
A medida que el equipo trabaja en el trabajo pendiente, se debe asumir que el cambio ocurre fuera de su entorno: el equipo puede aprender sobre nuevas oportunidades de mercado para aprovechar, las amenazas de la competencia que surgen y los comentarios de los clientes que pueden cambiar la forma en que se diseñó el producto. trabajar. Todas estas nuevas ideas tienden a hacer que el equipo adapte el trabajo pendiente para incorporar nuevos conocimientos. Esto es parte de la mentalidad fundamental de un equipo ágil. El mundo cambia, la acumulación de trabajos pendientes nunca se acaba. [46]
Cartera de Sprint [ editar ]
El backlog del sprint es el subconjunto de elementos del backlog del producto que los desarrolladores deben abordar en el próximo sprint. [47] Los desarrolladores llenarán esta acumulación hasta que sientan que tienen suficiente trabajo para completar el sprint, utilizando el rendimiento anterior para evaluar la capacidad para el próximo sprint, usando esto como una guía de cuánto 'esfuerzo' pueden completar.
El trabajo en el backlog del sprint nunca se asigna (o empuja) a los desarrolladores; los miembros del equipo realizan el trabajo según sea necesario de acuerdo con la prioridad de la acumulación y sus propias habilidades y capacidad. Esto promueve la autoorganización de los desarrolladores.
El backlog del Sprint es propiedad de los desarrolladores, y todos los estimados incluidos son proporcionados por los desarrolladores. Aunque no es parte de Scrum, algunos equipos utilizan un tablero que lo acompaña para visualizar el estado del trabajo en el sprint actual: Tareas pendientes, acciones, finalizadas.
Incremento [ editar ]
El incremento es la salida potencialmente liberable del sprint que cumple con el objetivo del sprint. Está formado por todos los elementos del backlog de sprints completados, integrados con el trabajo de todos los sprints anteriores. El incremento debe ser completo, de acuerdo con la definición de hecho (DoD) del equipo scrum , en pleno funcionamiento y en condiciones de uso, independientemente de si el propietario del producto decide implementarlo y usarlo.
Extensiones [ editar ]
Los siguientes artefactos y técnicas se pueden usar para ayudar a las personas a usar Scrum. [19]
Gráfico de evolución [ editar ]
A menudo se utiliza en Scrum (pero no es parte de Scrum), un gráfico de evolución es un gráfico que se muestra públicamente que muestra el trabajo restante. [48] Actualizado todos los días, proporciona visualizaciones rápidas para referencia. El eje horizontal del gráfico de quema 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 desarrollo 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.
No debe confundirse con una tabla de valor ganado .
Publicar gráfico de quemado [ editar ]
El gráfico de quemado de lanzamientos es una forma para que el equipo proporcione visibilidad y realice un seguimiento del progreso hacia un lanzamiento. Actualizado al final de cada sprint, muestra el progreso hacia la entrega de un alcance de pronóstico. El eje horizontal del gráfico de quemado de lanzamientos muestra los sprints en un lanzamiento, mientras que el eje vertical muestra la cantidad de trabajo completado al final de cada sprint (que generalmente representa puntos de historia acumulados de trabajo completado). El progreso se traza como una línea que crece hasta encontrarse con una línea horizontal que representa el alcance del pronóstico; a menudo se muestra con un pronóstico, basado en el progreso hasta la fecha, que indica cuánto alcance podría completarse para una fecha de lanzamiento determinada o cuántos sprints se necesitarán para completar el alcance dado.
La tabla de quemado de versiones facilita ver cuánto trabajo se ha completado, cuánto trabajo se ha agregado o eliminado (si la línea horizontal del osciloscopio se mueve) y cuánto trabajo queda por hacer.
Definición de listo (DoR) [ editar ]
Los criterios de inicio para determinar si las especificaciones y las entradas están configuradas lo suficiente para iniciar el elemento de trabajo.
Definición de hecho (DoD) [ editar ]
Los criterios de salida para determinar si el trabajo en el elemento de la lista de trabajos pendientes del sprint está completo, por ejemplo: el Departamento de Defensa requiere que todas las pruebas de regresión sean exitosas. La definición de hecho puede variar de un equipo a otro, pero debe ser coherente dentro de un equipo. [49]
Velocidad [ editar ]
El esfuerzo total del que es capaz un equipo en un sprint. El número se obtiene 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, es decir, cuánto trabajo pueden lograr.
Spike [ editar ]
Un período encuadrado en el tiempo que se utiliza para investigar un concepto o crear un prototipo simple. Los picos se pueden planificar para que tengan lugar entre sprints o, para equipos más grandes, se puede aceptar un pico como uno de los muchos objetivos de entrega del sprint. Los picos a menudo se introducen antes de la entrega de elementos de la cartera de productos grandes o complejos para asegurar el presupuesto, ampliar el conocimiento o producir una prueba de concepto. La duración y el (los) objetivo (s) de un ataque son acordados por el equipo antes del inicio. A diferencia de los compromisos de sprint, los picos pueden ofrecer o no una funcionalidad tangible, que se puede enviar y que es valiosa. Por ejemplo, el objetivo de un pico podría ser llegar con éxito a una decisión sobre un curso de acción. El pico termina cuando se acaba el tiempo, no necesariamente cuando se ha cumplido el objetivo. [50]
Bala trazadora [ editar ]
También llamado pico de dron, una bala trazadora es un pico con la arquitectura actual, el conjunto de tecnología actual, el conjunto actual de mejores prácticas que dan como resultado un código de calidad de producción. Puede que sea una implementación muy limitada de la funcionalidad, pero no es un código desechable. Es de calidad de producción y el resto de las iteraciones pueden basarse en este código. El nombre tiene orígenes militares como munición que hace visible el camino de la bala, permitiendo correcciones. A menudo, estas implementaciones son un "disparo rápido" a través de todas las capas de una aplicación, como conectar el campo de entrada de un solo formulario al back-end, para demostrar que las capas se conectan como se esperaba. [51]
Limitaciones [ editar ]
Los beneficios de Scrum pueden ser más difíciles de lograr cuando: [52] [53]
- Equipos cuyos miembros están dispersos geográficamente o a tiempo parcial : en Scrum, los desarrolladores deben tener una interacción cercana y continua, idealmente trabajando juntos en el mismo espacio la mayor parte del tiempo. Si bien las recientes mejoras en la tecnología han reducido el impacto de estas barreras (por ejemplo, poder colaborar en una pizarra digital), el manifiesto Agile afirma que la mejor comunicación es cara a cara. [54]
- Equipos cuyos miembros tienen habilidades muy especializadas : en Scrum, los desarrolladores deben tener habilidades en forma de T , lo que les permite trabajar en tareas fuera de su especialización. Esto se puede fomentar con un buen liderazgo de Scrum. Si bien los miembros del equipo con habilidades muy específicas pueden contribuir bien y lo hacen, se les debe alentar a aprender más y colaborar con otras disciplinas.
- Productos con muchas dependencias externas : en Scrum, dividir el desarrollo de productos en sprints cortos requiere una planificación cuidadosa; Las dependencias externas, como las pruebas de aceptación del usuario o la coordinación con otros equipos, pueden provocar retrasos y el fracaso de los sprints individuales.
- Productos maduros o heredados o con control de calidad regulado : en Scrum, los incrementos de productos deben desarrollarse y probarse por completo en un solo sprint; Los productos que necesitan grandes cantidades de pruebas de regresión o pruebas de seguridad (por ejemplo, dispositivos médicos o control de vehículos) para cada lanzamiento son menos adecuados para sprints cortos que para lanzamientos en cascada más largos .
Herramientas para la implementación [ editar ]
Al igual que otros métodos ágiles, la adopción efectiva de Scrum se puede respaldar a través de una amplia gama de herramientas.
Muchas empresas utilizan herramientas universales, como hojas de cálculo, para crear y mantener una acumulación de sprints. También hay paquetes de software patentados y de código abierto que utilizan la terminología de Scrum para el desarrollo de productos o admiten múltiples enfoques de desarrollo de productos, incluido Scrum.
Otras organizaciones implementan Scrum sin herramientas de software y mantienen sus artefactos en forma impresa como papel, pizarras y notas adhesivas. [55]
Valores de Scrum [ editar ]
Scrum es un enfoque empírico impulsado por la retroalimentación que, como todo control de procesos empíricos, se basa en los tres pilares de transparencia, inspección y adaptación. Todo el trabajo dentro del marco de Scrum debe ser visible para los responsables del resultado: el proceso, el flujo de trabajo, el progreso, etc. Para hacer que estas cosas sean visibles, los equipos de scrum deben inspeccionar con frecuencia el producto que se está desarrollando y qué tan bien está el equipo. trabajando. Con inspecciones frecuentes, el equipo puede detectar cuando su trabajo se desvía fuera de los límites aceptables y adaptar su proceso o el producto en desarrollo. [26]
Estos tres pilares requieren confianza y apertura en el equipo, lo que permiten los siguientes cinco valores de Scrum: [19]
- Compromiso: los miembros del equipo se comprometen individualmente a lograr los objetivos de su equipo, en todos y cada uno de los sprints .
- Coraje: los miembros del equipo saben que tienen el coraje de superar los conflictos y los desafíos juntos para poder hacer lo correcto.
- Enfoque: los miembros del equipo se enfocan exclusivamente en los objetivos de su equipo y la acumulación de sprints; no debería haber ningún trabajo que no sea a través de su trabajo atrasado.
- Apertura: los miembros del equipo y sus partes interesadas acuerdan ser transparentes sobre su trabajo y cualquier desafío que enfrenten.
- Respeto: Los miembros del equipo se respetan entre sí para ser técnicamente capaces y trabajar con buenas intenciones.
Adaptaciones [ editar ]
La hibridación de Scrum con otras metodologías de desarrollo de software es común ya que Scrum no cubre todo el ciclo de vida del desarrollo de productos ; por lo tanto, las organizaciones encuentran la necesidad de agregar procesos adicionales para crear una implementación más completa. Por ejemplo, al inicio del desarrollo del producto, las organizaciones comúnmente agregan orientación de proceso sobre el caso de negocios, recopilación y priorización de requisitos, diseño inicial de alto nivel y previsión de presupuesto y cronograma. [56]
Varios autores y comunidades de personas que usan 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 metodológicas como "patrones", por analogía con los patrones de diseño en arquitectura y software. [57] [58]
Scrumban [ editar ]
Scrumban es un modelo de producción de software basado en Scrum y Kanban . 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 tiempo limitado del marco de Scrum pueden percibirse como de menor beneficio, aunque los eventos diarios de Scrum y otras prácticas aún se pueden aplicar, según el equipo y la situación en cuestión. La visualización de las etapas de trabajo y las limitaciones para el trabajo no terminado y los defectos simultáneos son familiares en el modelo Kanban. Usando estos métodos, el flujo de trabajo del equipoestá dirigido de una manera que permite un tiempo mínimo de finalización para cada elemento de trabajo o error de programación y, por otro lado, garantiza que cada miembro del equipo esté constantemente empleado. [59]
Para ilustrar cada etapa del trabajo, los equipos que trabajan en el mismo espacio suelen utilizar notas adhesivas o una gran pizarra. [60] En el caso de equipos descentralizados, se puede utilizar software de ilustración de escenario como Assembla , Jira o Agilo .
Las principales diferencias entre Scrum y Kanban es que en Scrum el trabajo se divide en sprints que duran una cantidad fija de tiempo, mientras que en Kanban el flujo de trabajo es continuo. Esto es visible en las tablas de la etapa de trabajo, que en Scrum se vacían después de cada sprint, mientras que en Kanban todas las tareas se marcan en la misma tabla. Scrum se enfoca en equipos con conocimientos multifacéticos, mientras que Kanban hace posible los equipos funcionales y especializados. [59]
Scrum de scrums [ editar ]
El scrum de scrums es una técnica para operar Scrum a escala, para varios equipos que trabajan en el mismo producto, lo que les permite discutir el progreso en sus interdependencias, enfocándose en cómo coordinar la entrega de software, [61] especialmente en áreas de superposición e integración. Dependiendo de la cadencia (tiempo) del scrum de scrums, el scrum diario relevante para cada equipo de scrum finaliza designando a un miembro como embajador para participar en el scrum de scrums con embajadores de otros equipos. Dependiendo del contexto, los embajadores pueden ser colaboradores técnicos o el scrum master de cada equipo. [61]
En lugar de simplemente una actualización de progreso, el scrum de los scrums debe centrarse en cómo los equipos están trabajando colectivamente para resolver, mitigar o aceptar cualquier riesgo, impedimento, dependencia y suposición (RIDA) que se haya identificado. El scrum de scrums rastrea estos RIDA a través de una acumulación propia, como un tablero de riesgo (a veces conocido como tablero de ROAM después de las iniciales de resuelto, poseído, aceptado y mitigado), [62] que generalmente conduce a una mayor coordinación y colaboración entre equipos. [61]
Esto debería ser similar a un scrum diario, con cada embajador respondiendo las siguientes cuatro preguntas: [63]
- ¿Qué riesgos, impedimentos, dependencias o suposiciones ha resuelto su equipo desde la última vez que nos reunimos?
- ¿Qué riesgos, impedimentos, dependencias o suposiciones resolverá su equipo antes de que nos volvamos a reunir?
- ¿Existen nuevos riesgos, impedimentos, dependencias o suposiciones que ralenticen a su equipo o se interpongan en su camino?
- ¿Está a punto de introducir un nuevo riesgo, impedimento, dependencia o suposición que se interpondrá en el camino de otro equipo?
Como comentó Jeff Sutherland , [61]
Dado que originalmente definí Scrum of Scrums (Ken Schwaber estaba en IDX trabajando conmigo), definitivamente puedo decir que Scrum of Scrums no es un 'meta Scrum'. El Scrum de Scrums como lo he usado es responsable de entregar el software de trabajo de todos los equipos a la Definición de Terminado al final del sprint, o para lanzamientos durante el sprint. PatientKeeper entregado a producción cuatro veces por Sprint. Ancestry.com entrega a producción 220 veces por Sprint de dos semanas. Hubspot ofrece software en vivo de 100 a 300 veces al día. El Scrum of Scrums Master es responsable de hacer que esto funcione. Entonces, Scrum of Scrums es un mecanismo de entrega operativo.
Scrum a gran escala [ editar ]
Scrum a gran escala (LeSS) es un marco de desarrollo de productos que extiende Scrum con reglas y pautas de escala sin perder los propósitos originales de Scrum.
Hay dos niveles en el marco: el primer nivel LeSS está diseñado para hasta ocho equipos; el segundo nivel, conocido como 'LeSS Huge', introduce elementos de escala adicionales para el desarrollo con hasta cientos de desarrolladores. "Scaling Scrum comienza con la comprensión y la capacidad de adoptar Scrum de un solo equipo real estándar. Scrum a gran escala requiere examinar el propósito de los elementos de Scrum de un solo equipo y descubrir cómo alcanzar el mismo propósito mientras se mantiene dentro de las limitaciones del Scrum estándar reglas." [64]
Bas Vodde y Craig Larman desarrollaron el marco de LeSS a partir de sus experiencias de trabajo con el desarrollo de productos a gran escala, especialmente en las industrias de telecomunicaciones y finanzas. Evolucionó tomando Scrum y probando muchos experimentos diferentes para descubrir qué funciona. En 2013, los experimentos se solidificaron en las reglas del marco de LeSS. [65] La intención de LeSS es "descalcificar" la complejidad de la organización, disolviendo soluciones organizativas complejas innecesarias y resolviéndolas de formas más simples. Menos roles, menos gestión, menos estructuras organizativas. [66]
Críticas [ editar ]
Se ha informado que los eventos de Scrum están dañando la productividad y desperdiciando tiempo que podría emplearse mejor en tareas productivas reales. [67] [68]
Las prácticas de Scrum, cuando no se implementan correctamente en el espíritu del Manifiesto Ágil , tienden a convertirse en una forma de microgestión . [69]
Scrum también asume que la cantidad de esfuerzo requerido para completar ciertas tareas se puede cuantificar con precisión usando métricas, aunque la mayoría de las veces esto puede ser bastante impredecible . [70]
Ver también [ editar ]
- Pruebas ágiles
- Entrega ágil disciplinada
- Equipos de alto rendimiento
- Desarrollo de software esbelto
- Gestión de proyectos
- Scrumedge
- Proceso unificado
Referencias [ editar ]
- ^ Schwaber, Ken; Sutherland, Jeff (noviembre de 2017), The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game , consultado el 13 de mayo de 2020
- ^ "Lecciones aprendidas: uso de Scrum en equipos no técnicos" . Alianza ágil . Consultado el 8 de abril de 2019 .
- ^ https://agilix.nl/resources/TheNewNewProductDevelopmentGame.pdf
- ^ "Scrum, ¿qué hay en un nombre? - DZone Agile" . dzone.com .
- ^ "¿Debería escribirse" SCRUM "en mayúsculas?" . stackoverflow.com . Consultado el 10 de enero de 2017 .
- ^ Schwaber, Ken. "Scrum.org Ken Schwaber" . Cite journal requires
|journal=(help) - ↑ a b c d e Schwaber, Ken (1 de febrero de 2004). Gestión ágil de proyectos con Scrum . Microsoft Press . ISBN 978-0-7356-1993-7.
- ^ Schwaber, Ken (2004). "Proceso de desarrollo SCRUM" (PDF) . Métodos de desarrollo avanzados .
- ^ Johnson, Hillary Louise (13 de enero de 2011). "ScrumMaster vs Scrum Master: ¿Qué opinas?" . agilelearninglabs.com . Consultado el 10 de mayo de 2017 .
- ^ "¿Qué es Scrum?" . ¿Qué es Scrum? Un marco ágil para completar proyectos complejos: Scrum Alliance . Scrum Alliance . Consultado el 24 de febrero de 2016 .
- ^ Verheyen, Gunther (21 de marzo de 2013). "Scrum: Framework, no metodología" . Gunther Verheyen . Gunther Verheyen . Consultado el 24 de febrero de 2016 .
- ^ J. Henry y S. Henry. Evaluación cuantitativa del proceso de mantenimiento de software y volatilidad de requisitos. En Proc. de la Conferencia ACM sobre Ciencias de la Computación, páginas 346–351, 1993.
- ^ a b c Takeuchi, Hirotaka; Nonaka, Ikujiro (1 de enero de 1986). "El nuevo juego de desarrollo de nuevos productos" . Harvard Business Review . Consultado el 9 de junio de 2010 .
Moviendo el Scrum hacia abajo
- ^ La empresa creadora de conocimiento . Prensa de la Universidad de Oxford. 1995. p. 3. ISBN 9780199762330. Consultado el 12 de marzo de 2013 .
- ^ "Scrum" . Diccionario Lexico UK . Prensa de la Universidad de Oxford .
- ↑ a b 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 .
- ^ "Manifiesto para el desarrollo de software ágil" . Consultado el 17 de octubre de 2019 .
- ^ Sutherland, Jeffrey Victor ; Schwaber, Ken (1995). Diseño e implementación de objetos de negocio: Actas del taller OOPSLA '95 . Universidad de Michigan . pag. 118. ISBN 978-3-540-76096-2.
- ^ a b c d e f g h i Ken Schwaber ; Jeff Sutherland . "La Guía Scrum" . Scrum.org . Consultado el 27 de octubre de 2017 .
- ^ Schwaber, Ken ; Beedle, Mike (2002). Desarrollo de software ágil con Scrum . Prentice Hall. ISBN 978-0-13-067634-4.
- ^ Maximini, Dominik (8 de enero de 2015). La cultura Scrum: Introducción de métodos ágiles en organizaciones . Gestión para Profesionales. Cham: Springer (publicado en 2015). pag. 26. ISBN 9783319118277. 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ó Scrum Alliance, con el objetivo de proporcionar capacitación y certificación Scrum en todo el mundo.
- ^ "Inicio" . Scrum.org . Consultado el 6 de enero de 2020 .
- ^ Partogi, Joshua (7 de julio de 2013). "Certified Scrum Master vs Professional Scrum Master" . Instituto Lean Agile . Consultado el 10 de mayo de 2017 .
- ^ a b McGreal, Don; Jocham, Ralph (4 de junio de 2018). El propietario del producto profesional: aprovechar Scrum como una ventaja competitiva . Addison-Wesley Professional. ISBN 9780134686653.
- ^ Rubin, Kenneth (2013), Scrum esencial. Una guía práctica para el proceso ágil más popular , Addison-Wesley, p. 173, ISBN 978-0-13-704329-3
- ↑ a b c d Morris, David (2017). Scrum: un marco ideal para proyectos ágiles . En sencillos pasos. págs. 178-179. ISBN 9781840787313. OCLC 951453155 .
- ^ a b c Cohn, Mike. Tener éxito con Agile: Desarrollo de software con Scrum. Upper Saddle River, Nueva Jersey: Addison-Wesley, 2010.
- ^ "La guía de Scrum" (PDF) .
- ^ La guía de Scrum . http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf . pag. 6.CS1 maint: location (link)
- ^ "El papel del propietario del producto" . Scrum Alliance . Consultado el 26 de mayo de 2018 .
- ^ Pichler, Roman (11 de marzo de 2010). Gestión ágil de productos con Scrum: creación de productos que aman a los clientes . Addison-Wesley Professional. ISBN 978-0-321-68413-4.
- ^ Ambler, Scott. "El rol del propietario del producto: un representante de las partes interesadas para equipos ágiles" . agilemodeling.com . Consultado el 22 de julio de 2016 .
[...] en la práctica, se demuestra que hay dos aspectos críticos para este rol: primero como representante de las partes interesadas dentro del equipo de desarrollo y segundo como representante del equipo del proyecto para la comunidad de partes interesadas en su conjunto.
- ^ "El papel del propietario del producto" . Preparación para la prueba Scrum Master . Consultado el 3 de febrero de 2017 .
- ^ Rad, Nader K .; Turley, Frank (2018). Material didáctico de Agile Scrum Foundation, segunda edición . 's-Hertogenbosch, Países Bajos: Van Haren. pag. 26. ISBN 9789401802796.
- ^ Carroll, N, O'Connor, M. y Edison, H. (2018). La identificación y clasificación de impedimentos para el flujo de software, Conferencia de las Américas sobre sistemas de información (AMCIS 2018), 16 al 18 de agosto, Nueva Orleans, Luisiana, EE. UU.
- ^ "Core Scrum" . Scrum Alliance . Consultado el 25 de enero de 2015 .
- ^ a b Drongelen, Mike van; Dennis, Adam; Garabedian, Richard; González, Alberto; Krishnaswamy, Aravind (2017). Desarrollo de aplicaciones móviles ajustadas: aplique metodologías de puesta en marcha ajustadas para desarrollar aplicaciones exitosas de iOS y Android . Birmingham, Reino Unido: Packt Publishing Ltd. p. 43. ISBN 9781786467041.
- ^ Cobb, Charles G. (2015). The Project Manager's Guide to Mastering Agile: Principles and Practices for a Adaptive Approach . Hoboken, Nueva Jersey: John Wiley & Sons. pag. 37. ISBN 9781118991046.
- ^ a b c 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)" . InfoQ.
- ^ "¿Qué es un Scrum diario?" . Scrum.org . Consultado el 6 de enero de 2020 .
- ^ Little, Joe (17 de enero de 2011). "Gestión de impedimentos" . Consorcio Ágil. Cite journal requires
|journal=(help) - ^ Flewelling, Paul (2018). El manual del desarrollador ágil: Obtenga más valor de su desarrollo de software: obtenga lo mejor de la metodología Agile . Birmingham, Reino Unido: Packt Publishing Ltd. p. 91. ISBN 9781787280205.
- ^ 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. pag. 126. ISBN 9781484222768.
- ^ Higgins, Tony (31 de marzo de 2009). "Requisitos de autoría en un mundo ágil" . BA Times.
- ^ "La cartera de productos: su lista de tareas pendientes definitiva" . Atlassian . Consultado el 20 de julio de 2016 .
- ^ Pichler, Roman. Gestión ágil de productos con Scrum: creación de productos que aman a los clientes . Upper Saddle River, Nueva Jersey: Addison-Wesley, 2010. [se necesita cotización para verificar ]
- ^ Russ J. Martinelli; Dragan Z. Milosevic (5 de enero de 2016). Caja de herramientas de gestión de proyectos: herramientas y técnicas para el director de proyectos en ejercicio . Wiley. pag. 304. ISBN 978-1-118-97320-2.
- ^ Charles G. Cobb (27 de enero de 2015). The Project Manager's Guide to Mastering Agile: Principles and Practices for a Adaptive Approach . John Wiley e hijos. pag. 378. ISBN 978-1-118-99104-6.
- ^ Ken Schwaber, Gestión ágil de proyectos con Scrum , p.55
- ^ "Crear una solución de picos" . Programación extrema.
- ^ Sterling, Chris (22 de octubre de 2007). "Investigación, picos, balas trazadoras, ¡Dios mío!" . Volviéndose ágil . Consultado el 23 de octubre de 2016 .
- ^ Turk, Dan; Francia, 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 .
- ^ "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 .
- ^ Kent Beck ; James Grenning; Robert C. Martin ; Mike Beedle; Jim Highsmith ; Steve Mellor ; Arie van Bennekum; Andrew Hunt ; Ken Schwaber ; Alistair Cockburn ; Ron Jeffries ; Jeff Sutherland ; Ward Cunningham ; Jon Kern; Dave Thomas ; Martin Fowler ; Brian Marick (2001). "Principios detrás del Manifiesto Ágil" . Alianza ágil . Consultado el 7 de agosto de 2017 .
- ^ Dubakov, Michael (2008). "Herramientas ágiles. Lo bueno, lo malo y lo feo" (PDF) . Consultado el 30 de agosto de 2010 .
- ^ 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.a Conferencia Internacional de Ciencias de Sistemas de Hawái (HICSS) de 2018, del 3 al 6 de enero de 2018 .
- ^ Bjørnvig, Gertrud; Coplien, Jim (21 de junio de 2008). "Scrum como patrones organizacionales" . Gertrude & Cope.
- ^ "Comunidad de patrones de Scrum" . ScrumPLoP.org . Consultado el 22 de julio de 2016 .
- ^ a b Kniberg, Henrik; Skarin, Mattias (21 de diciembre de 2009). "Kanban y Scrum: aprovechar al máximo ambos" (PDF) . InfoQ . Consultado el 22 de julio de 2016 .
- ^ Ladas, Corey (27 de octubre de 2007). "scrum-ban" . Ingeniería de software ajustada . Consultado el 13 de septiembre de 2012 .
- ^ a b c d "Scrum de Scrums" . Alianza ágil. 17 de diciembre de 2015.
- ^ "Gestión de riesgos: cómo evitar que los riesgos arruinen sus proyectos". . Kelly Waters.
- ^ "Scrum de Scrums" . Preparación para la prueba Scrum Master . Consultado el 29 de mayo de 2015 .
- ^ Larman; scrumyear = 2013. "Scaling Agile Development (Crosstalk journal, noviembre / diciembre de 2013)" (PDF) .
- ^ "Scrum a gran escala (LeSS)" . 2014.
- ^ Grgic (2015). "Organización de descalcificación con LeSS (Blog)" .
- ^ Jenson, John (8 de marzo de 2019). "Reuniones: el asesino de la productividad para los desarrolladores" . TandemSeven: la empresa de innovación de experiencias . Consultado el 5 de junio de 2020 .
- ^ Materias, negocios (4 de diciembre de 2019). "No a todos los desarrolladores les gusta Agile, y aquí hay 5 razones por las que" . Asuntos comerciales . Consultado el 5 de junio de 2020 .
- ^ en, Isaak Tsalicoglou. "Cómo pasar de Agile a la microgestión | Hacker Noon" . hackernoon.com . Consultado el 5 de junio de 2020 .
- ^ Cagle, Kurt. "El fin de lo ágil" . Forbes . Consultado el 5 de junio de 2020 .
Lectura adicional [ editar ]
- Vacaniti, Daniel (febrero de 2018). "La guía Kanban para equipos Scrum" (PDF) . scrum.org . Consultado el 12 de marzo de 2018 .
- Sutherland, Jeff; Schwaber, Ken (2013). "Guías de Scrum" . ScrumGuides.org . Consultado el 26 de julio de 2017 .
- Verheyen, Gunther (2013). Scrum: una guía de bolsillo (un compañero de viaje inteligente) ISBN 978-9087537203 .
- Münch, Jürgen; Armbrust, Ove; Soto, Martín; Kowalczyk, Martin (2012). Definición y Gestión de Procesos de Software . ISBN 978-3-642-24291-5.
- Deemer, Pete; Benefield, Gabrielle; Larman, Craig; Vodde, Bas (2009). "El Scrum Primer" . Consultado el 1 de junio de 2009 .
- Janoff, NS; Rising, L. (2000). "El proceso de desarrollo de software Scrum para equipos pequeños" (PDF) . Consultado el 26 de febrero de 2015 .
Enlaces externos [ editar ]
 | Wikimedia Commons tiene medios relacionados con Scrum (desarrollo) . |
- Biblioteca Scrum de Agile Alliance
- Una descripción del proceso Scrum por el proyecto Eclipse Process Framework (EPF)
| vtmiIngeniería de software | |||||||
|---|---|---|---|---|---|---|---|
| Campos |
| ||||||
| Conceptos |
| ||||||
| Orientaciones |
| ||||||
| Modelos |
| ||||||
| Campos relacionados |
| ||||||
| |||||||
Categoría
Los comunes