Melé

La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la versión revisada el 2 de septiembre de 2022; las comprobaciones requieren 27 ediciones .

Melé
Sitio oficial	scrum.org
Archivos multimedia en Wikimedia Commons

Scrum ( /skrʌm/ [1] ; scrum “  scrum”) es un marco ligero que ayuda a las personas, los equipos y las organizaciones a crear valor a través de soluciones adaptables a problemas complejos [2] .

Scrum se puede utilizar no solo en el campo del desarrollo de software, sino también en otras industrias manufactureras [3] .

Además de gestionar proyectos de desarrollo de software, los equipos de soporte de software también pueden utilizar Scrum como un enfoque para la gestión y el mantenimiento del desarrollo de software.

Se debe hacer una distinción entre Scrum [4] y Agile [5] .

Historia

Las fuentes principales de la metodología Scrum fueron: el sistema de producción de Toyota y el ciclo OODA (bucle OODA, o el bucle OODA, o el bucle Boyd) del concepto de utilizar la aviación militar, que incluye cuatro componentes: observar ("observar") , orientar ("orientar"), decidir ("decidir"), actuar ("actuar"). [6]

El enfoque en sí fue descrito por primera vez por Hirotaka Takeuchi e Ikujiro Nonaka en The New Product Development Game (Harvard Business Review, enero-febrero de 1986). Señalaron que los proyectos dirigidos por pequeños equipos multidisciplinarios tienden a producir sistemáticamente mejores resultados, y lo explicaron como el "enfoque de rugby".

En 1991, DeGrace y Stahl, en su libro Unholy Problems, Righteous Solutions, [7] se refirieron a este enfoque como scrum , un término deportivo acuñado en un artículo de Takeuchi y Nonaka. Ken Schwaber utilizó el enfoque que trajo Scrum a su empresa principios de la década de 1990 . La metodología Scrum se presentó por primera vez al público en general documentada, claramente definida y descrita conjuntamente por Schwaber y Jeff Sutherland [6] en OOPSLA'95 [8] en Austin . K. Schwaber y D. Sutherland trabajaron juntos durante los siguientes años para procesar y describir toda su experiencia y mejores prácticas para la industria en un todo, en la metodología que hoy se conoce como Scrum.

Schwaber unió fuerzas con Mike Beadle en 2001 para describir el método en detalle en Agile Software Development with Scrum [9] .

En 2002, Schwaber fundó Scrum Alliance [10] con otros y creó una serie de acreditaciones Scrum certificadas. Schwaber dejó Scrum Alliance a fines de 2009 y fundó Scrum.org . Archivado el 10 de diciembre de 2019 en Wayback Machine , que organiza la serie de acreditaciones simultáneas de Professional Scrum [11] .

Desde 2009, un documento público llamado The Scrum Guide [12] ha definido oficialmente Scrum. Ha sido revisado más de 5 veces. En 2018, Schwaber y la comunidad Scrum.org, junto con los líderes de la comunidad Kanban, publicaron la Guía Kanban para equipos Scrum [13] .

Definiciones

melé

Scrum (eng. "scrum" - un término del rugby, denota el estado inicial de los equipos antes de lanzar la pelota) - el conjunto mínimo requerido de eventos, artefactos, roles sobre los que se construye el proceso de desarrollo de Scrum, lo que permite períodos cortos fijos de tiempo, denominados sprints ( sprints ), para brindar al usuario final un producto funcional con nuevas oportunidades de negocio para las cuales se determina la máxima prioridad. La metodología se basa en las ideas expresadas en el artículo de Taekuchi y Nonaka " The New New Product development Game ", así como en el trabajo en equipo, similar a cómo en el rugby un equipo trabaja en conjunto para lograr un objetivo común. El equipo determina las oportunidades de implementación en el siguiente sprint al comienzo del sprint en la reunión de planificación del sprint . Para estimar la próxima cantidad de trabajo en el sprint, se utilizan con mayor frecuencia estimaciones relativas y la práctica del póquer de planificación (Planning Poker).

Al final del sprint, el equipo Scrum se reúne en una reunión de revisión del sprint (Revisión del sprint, el antiguo nombre de Demostración) con el cliente y le presenta un incremento de producto comercial (una versión del producto con un conjunto completo de funcionalidades que puede ya se entregó al cliente y al usuario para su uso), lo que logró hacer en un sprint. El objetivo de Sprint Review es obtener comentarios del cliente para comprender qué debe enfatizarse en el futuro y cuál debe ser el próximo incremento del producto comercial.

Una duración de sprint corta estrictamente fijada (de 1 a 4 semanas) reduce los riesgos y permite obtener rápidamente comentarios del cliente para ajustar la visión del producto.

Carrera

Sprint [14]  es un período de tiempo suficiente para completar un conjunto planificado de operaciones Scrum, cuyo propósito es crear un incremento de un producto comercial. Fijado rígidamente en el tiempo. La duración de un sprint es de 1 a 4 semanas. Cuanto más corto es el sprint, más flexible es el proceso de desarrollo, los lanzamientos salen con mayor frecuencia, la retroalimentación del cliente llega más rápido, se dedica menos tiempo a trabajar en la dirección equivocada, pero se dedica mucho tiempo a reuniones de planificación de sprint, retrospectivas . Por otro lado, con sprints más largos, el equipo Scrum reduce el costo de las reuniones, demostraciones de productos, etc. Los diferentes equipos eligen la duración del sprint de acuerdo con las especificaciones de su trabajo, equipos multifuncionales y requisitos, a menudo por prueba y error. Para estimar la cantidad de trabajo en un sprint, puede usar una estimación preliminar, medida en puntos de historia. Una estimación preliminar de la duración del sprint se registra en la cartera del proyecto ( pila del producto ; ver más abajo).

Artefactos de Scrum

Gráfico de evolución

Un gráfico que muestra la cantidad de trabajo realizado y la cantidad de trabajo restante en relación con el tiempo para desarrollar un proyecto se denomina gráfico de quemado.

Estos gráficos deben actualizarse diariamente para mostrar el progreso y los costos en tiempo real en el trabajo en el sprint y el proyecto, disponibles para todos los miembros del equipo Scrum: Scrum Master y Product Owner.

El gráfico de trabajo pendiente del sprint muestra cuántas tareas se han completado y cuánto queda por hacer en el sprint actual.

Cartera de proyectos

El registro de deseos del proyecto (project backlog) contiene una lista de requisitos de funcionalidad, ordenados por importancia y, en consecuencia, el orden de implementación. Los elementos de este registro se denominan historias de usuario ( user stories ) o elementos de backlog ( elementos de backlog ). El backlog del proyecto está abierto para que lo editen todos los participantes en el proceso Scrum. La persona responsable de mantener el backlog del proyecto es el propietario del producto Scrum.

Sprint backlog

Sprint Wishlist (Sprint Backlog): contiene la funcionalidad seleccionada por el propietario del producto de la lista de espera del proyecto. Todas las funciones se dividen en tareas, cada una de las cuales es evaluada por el equipo Scrum. En la reunión de planificación de Sprint , el equipo utiliza el método de póquer de planificación para estimar la cantidad de trabajo que debe realizarse para completar el Sprint [15] .

Tablero Scrum

El Tablero Scrum es una herramienta para mostrar abiertamente el estado del trabajo en curso del Equipo Scrum. El tablero de Scrum consta de tres columnas: "to do" ( to-do ), "in progress" ( en proceso ), "done" ( hecho ).

El Scrum Board contiene todo el alcance del Sprint Backlog que el equipo ha seleccionado en Sprint Planning para implementarlo en el sprint actual. Por lo general, las tarjetas de tareas comerciales se colocan en el tablero de arriba a abajo en orden descendente de prioridad (arriba: la más importante, abajo: la menos importante). Es una buena práctica descomponer las tareas comerciales en trabajo específico (técnico, organizacional y otros) que el equipo debe realizar para implementar la tarea comercial.

Las tareas comerciales y las tarjetas de trabajo específicas se mueven de una columna a otra de acuerdo con la forma en que el equipo las toma para su ejecución (En progreso) y las completa (Terminado). Para proporcionar visibilidad sobre el progreso del trabajo del equipo, se muestra la "disminución del trabajo" por día en el gráfico Burndown.

La mayoría de las veces, al comienzo del trabajo, los equipos usan tableros con rotafolios dibujados en hojas, mientras que los nombres de los trabajos se escriben en pegatinas adhesivas y se pegan al tablero. A medida que avanza la reunión, el equipo mueve físicamente las notas adhesivas de una columna a otra.

También se utilizan a menudo placas electrónicas, con mecanismos similares implementados en ellas. Por ejemplo, Atlassian Jira , Trello o kaiten [16] .

Meta de Sprint

Es una breve descripción del objetivo comercial del sprint. Como artefacto, el objetivo del sprint ayuda al equipo a tomar decisiones comerciales informadas. Este artefacto es necesario para que el equipo del proyecto tome una decisión independiente al buscar formas alternativas de resolver un problema empresarial.

Incremento del producto

Un incremento de producto es una pieza lista para usar de un producto que debe implementarse al final de un sprint. El equipo de revisión de Sprint (demostración) demuestra el incremento del producto al Scrum Master, al propietario del producto, a los clientes y a otras partes interesadas [4] para recibir comentarios de ellos y decidir sobre la dirección futura del desarrollo del producto [17] .

Historia de usuario

La funcionalidad comercial requerida que se agrega a la cartera de proyectos a menudo se denomina historia de usuario. A menudo, la estructura de la historia es: "Como usuario <tipo de usuario>, quiero realizar <acción> para obtener <resultado>". Esta estructura es conveniente porque es clara tanto para los desarrolladores como para los clientes.

Estimación del esfuerzo requerido para completar una historia de usuario (tareas de sprint)

En el libro [6] , Sutherland describió el siguiente método eficaz, utilizado por él y confirmado por la experiencia, para evaluar la intensidad de trabajo de realizar tareas de sprint en algunas unidades de intensidad de trabajo: horas-hombre y similares.

La evaluación de tareas la realizan los desarrolladores del proyecto junto con el Scrum Master y el Product Owner. El método correcto para estimar tareas es el póquer de planificación . Se muestra que tal evaluación de la mano de obra es mucho más precisa que las evaluaciones realizadas por otras personas.

Cada desarrollador debe dar su propia valoración de la complejidad de la tarea, independiente de los demás, utilizando números de la serie de Fibonacci (1, 2, 3, 5, 8, 13, 20, 40, 100). En lugar de los números 21, 34, 55, se usan los números 20, 40, 100. Las estimaciones se pueden registrar en hojas de papel, o se pueden usar tarjetas especiales para esto (ver planificación de póquer ) y deben abrirse al mismo tiempo . Esta organización de la evaluación evita el efecto de anclaje .

Si todos los valores elegidos por los desarrolladores se encuentran dentro de un intervalo de no más de tres números de Fibonacci consecutivos, entonces la estimación promedio de todos los desarrolladores del grupo se utiliza como evaluación final de la tarea por parte del grupo. Si los puntajes elegidos caen fuera de este intervalo, entonces los desarrolladores con los valores más altos y más bajos deben explicar las razones de su elección, luego de lo cual se repiten las rondas de evaluación hasta que el conjunto de estimaciones se encuentre dentro del intervalo de tres números de Fibonacci consecutivos. Como muestra la práctica, si se utiliza la variante con el promedio de las estimaciones que se encuentran en el intervalo mayor que tres números de Fibonacci consecutivos para formar la estimación final de la complejidad de la tarea, entonces el resultado resulta ser mucho menos preciso.

Aunque inicialmente las tareas y, en consecuencia, las historias y el proyecto en su conjunto, se estiman en una determinada unidad de trabajo, estas estimaciones se utilizan posteriormente como trabajo relativo como puntos (puntos) para determinar la velocidad (productividad) de el equipo Scrum (Velocity). ).

Obviamente, la metodología anterior para evaluar la intensidad de trabajo de las tareas individuales y el proyecto en su conjunto se puede utilizar no solo en Scrum, sino también en otros métodos de implementación de proyectos.

Definición de Listo (DoD)

Criterios que determinan la disponibilidad de un elemento del backlog del usuario.

Velocidad del equipo Scrum (Velocidad)

El número total de puntos anotados por el equipo Scrum en el sprint anterior. Esta métrica ayuda al equipo a comprender cuántas historias puede completar en un sprint.

Roles en el proceso Scrum

De acuerdo con la metodología Scrum en el proceso de producción, es posible definir roles, divididos en dos grupos: "cerdos" y "gallinas". Desde 2011, las metáforas de "cerdos" y "pollos" están ausentes del manual de Scrum, ya que no existen rituales especiales para los pollos [18] . La guía Scrum tiene que ver con los cerdos. Estos términos fueron tomados de una anécdota: [6]

El cerdo camina por el camino. El pollo la mira y dice: "¡Abramos un restaurante!" El cerdo mira al pollo y responde: "Buena idea, ¿cómo quieres llamarlo?" El pollo piensa y dice: "¿Por qué no llamarlo tocino y huevos?" “Eso no servirá”, responde el cerdo, “porque entonces tendré que dedicarme por completo al proyecto y tú estarás solo parcialmente involucrado”.

Los cerdos crean el producto, mientras que las gallinas están interesadas, pero no tan interesadas, porque no les importa si el proyecto tiene éxito o no, no les afectará mucho. Se tienen en cuenta los requisitos, deseos, ideas e influencia de los pollos , pero no se permite que participen directamente en el curso del proyecto Scrum.

Roles centrales en la metodología Scrum (“Pigs”)

Los cerdos están completamente incluidos en el proyecto y en el proceso Scrum. Scrum Master: realiza reuniones (reuniones de Scrum), supervisa el cumplimiento de todos los principios de Scrum, resuelve conflictos y protege al equipo de distracciones, facilita las reuniones, es responsable de registrar, almacenar y emitir el inventario de Scrum. Este rol no implica nada más que la correcta conducción del proceso Scrum. Por lo tanto, el Scrum Master es el líder servidor equipo.

La herramienta principal del Scrum master es la maleta del facilitador , que incluye cajas de tarjetas, tarjetas cuadradas y redondas, tarjetas adhesivas, alfileres, marcadores, un cuchillo de papelería, cinta adhesiva , tarjetas de Planning Poker, imanes, tijeras, puntos de votación.

Propietario del producto Scrum: representa los intereses de los usuarios finales y otras partes interesadas en el producto .

El equipo de desarrollo (Scrum Development Team) es un equipo multifuncional de desarrolladores de proyectos, compuesto por especialistas de diferentes perfiles: probadores , arquitectos , analistas , programadores , etc. El tamaño del equipo es de 5 a 9 personas. El equipo es el único participante plenamente involucrado en el desarrollo y es responsable del resultado en su conjunto. Nadie más que el equipo de desarrollo, el maestro de scrum y el propietario del producto pueden interferir con el proceso de desarrollo durante el sprint. La funcionalidad cruzada del equipo le permite planificar los costos de implementar los requisitos comerciales de la manera más eficiente posible y entregar aplicaciones comerciales de la vida real en pleno cumplimiento de los requisitos cambiantes del cliente en poco tiempo.

El equipo Scrum es, de hecho, una imagen colectiva de un equipo que consta de un equipo de desarrollo, un maestro scrum y un propietario del producto. El equipo es completamente autosuficiente y no depende de especialistas o clientes externos.

Roles adicionales (Roles auxiliares) en la metodología Scrum ("Pollos")

• Usuarios (Usuarios)
• Las partes interesadas son las personas que inician el proyecto (clientes comerciales) y para quienes se beneficiará el proyecto Scrum. Solo están involucrados en la pelea durante la reunión de revisión de Sprint.

Historias de usuarios

Campos obligatorios

• ID  : un identificador único, un número de serie que se utiliza para identificar historias en caso de que se les cambie el nombre.
• Nombre (Nombre)  - una breve descripción de la historia. Debe ser inequívoco para que tanto los desarrolladores como el Scrum Master y el Product Owner puedan entender de qué se trata y distinguir una historia de usuario de otra.
• Importancia  - el grado de importancia de esta historia, según el propietario del producto, obtenido como resultado de las negociaciones con el cliente. Suele ser un número entero, a veces se utilizan números de Fibonacci para este fin . Cuanto mayor sea el valor, mayor será la prioridad.

• Proceso empresarial  : una breve descripción del proceso empresarial.
• Estimación inicial  : una estimación de la cantidad de trabajo realizado antes del inicio del sprint necesario para implementar la historia. Medido en puntos de historia. Aproximadamente corresponde al número de " horas-hombre ideales ".
• Cómo hacer una demostración  : una breve descripción de cómo demostrar la tarea completada al cliente, Scrum Master y Product Owner al final del sprint. Este campo puede contener el nombre (identificador) o código de la prueba automatizada para la prueba de aceptación.
• Los criterios de aceptación  son detalles significativos de la implementación de la historia, que aclaran los requisitos del propietario del producto, recopilados por todos los miembros del equipo Scrum al planificar el sprint [19] .

Campos adicionales

A veces, también se utilizan campos adicionales en la cartera de proyectos, principalmente para ayudar al propietario del producto a priorizar el producto.

• Categoría ( pista ). Por ejemplo, "panel de control" u "optimización". Con este campo, el propietario del producto puede seleccionar fácilmente todos los elementos de la categoría "optimización" y establecerlos en baja prioridad.
• Componentes ( components ): indica qué componentes (por ejemplo, base de datos, servidor, cliente) se verán afectados cuando se implemente la historia de usuario.
• El iniciador de la solicitud ( solicitante ). El propietario de un producto puede querer almacenar información sobre todos los clientes que están interesados ​​en un problema empresarial determinado. Esto es para mantenerlos actualizados sobre el progreso del trabajo durante el sprint.
• ID en el sistema de seguimiento de defectos ( ID de seguimiento de errores ): si se usa un sistema de seguimiento de errores separado durante el desarrollo , en este caso es útil almacenar enlaces a todos los errores relacionados con él en la descripción del historial.

Principales reuniones de Scrum

Las siguientes reuniones se utilizan en Scrum para lograr regularidad, control de desarrollo y, al mismo tiempo, minimizar la cantidad de reuniones que no están predefinidas en Scrum [20] .

Reunión de planificación de Sprint

Se lleva a cabo al comienzo de cada sprint.

Toda la cantidad de trabajo que debe completarse durante el sprint se planifica en esta reunión. El plan debe ser el resultado del trabajo de todos los miembros del Scrum Team.

La duración de la reunión está determinada por la duración del sprint, la experiencia del equipo y otros factores, pero no debe exceder las 8 horas. Estas líneas de tiempo son monitoreadas por el ScrumMaster.

La reunión de planificación de Sprint responde preguntas como:

• ¿Cuál es el objetivo de este sprint, o qué se puede hacer en este sprint?
• ¿Cómo se logrará exactamente el objetivo del sprint para obtener el incremento del producto?

La primera cuestión se decide en común. El propietario del producto analiza los objetivos que deben completarse para el sprint, teniendo en cuenta la acumulación de productos, el incremento del producto anterior, etc., agrega nuevas historias de usuarios a la acumulación y elimina las completadas. El equipo de desarrollo trata de predecir la funcionalidad que se desarrollará durante el sprint. Además, todos los miembros del Scrum Team deben comprender y evaluar conjuntamente todo el trabajo del próximo sprint.

Para planificar adecuadamente un sprint, considere lo siguiente:

• cartera de proyectos;
• Incremento del proyecto anterior;
• Potencial proyectado del equipo de desarrollo durante el sprint;
• Resultados anteriores del equipo de desarrollo.

Solo el equipo de desarrollo trabaja con la segunda pregunta. Dado que el objetivo del sprint ya se ha definido, el equipo de desarrollo debe comprender exactamente cómo se puede lograr. Deciden cómo implementarán la funcionalidad planificada para obtener un nuevo incremento de producto terminado por sprint.

El equipo de desarrollo generalmente comienza con el diseño del sistema y el trabajo necesario para convertir la acumulación de sprint en un incremento del producto. El trabajo planificado para los primeros días del sprint es más detallado, a menudo dividido en partes de un día o menos hacia el final de esa reunión. El equipo de desarrollo organiza de forma independiente el trabajo en la cartera de pedidos del sprint, tanto durante la planificación del sprint como según sea necesario durante el sprint.

Teniendo en cuenta la opinión del equipo de desarrollo, el Product Owner puede aclarar las tareas-objetivos seleccionados del backlog o formar una solución de compromiso con ellos. Si los desarrolladores deciden que hay demasiado o muy poco trabajo, ellos y el propietario del producto pueden reconsiderar las tareas-objetivos seleccionados. Además, el equipo de desarrollo puede invitar a otros expertos para que brinden asesoramiento técnico o sobre el tema.

Al final de la reunión, el equipo de desarrollo explica al propietario del producto y al Scrum Master cómo van a trabajar de forma independiente para lograr los objetivos del sprint.

Reunión diaria de Scrum

Tales reuniones son realizadas por el equipo de desarrollo, con la posible participación del propietario del producto y el Scrummaster, todos los días en el mismo lugar ya la misma hora, con una duración máxima de 15 minutos. En estas reuniones, el equipo de desarrollo planifica el trabajo para el día hábil de hoy. Estas reuniones agilizan el trabajo en equipo y aumentan la productividad mediante la revisión del trabajo realizado desde el Daily Scrum anterior y la planificación del trabajo por delante.

Estas reuniones diarias ayudan a ver cómo avanza el trabajo hacia el logro del objetivo del sprint. Aumentan la probabilidad de que el equipo de desarrollo alcance los objetivos establecidos. Durante las reuniones, el equipo de desarrollo debe comprender cómo debe organizarse para lograr los objetivos del sprint e implementar el incremento planificado.

La estructura de dichas reuniones la determina el equipo de desarrollo, si es necesario y cuando sea apropiado, la estructura de las reuniones se puede cambiar, mientras que el enfoque principal debe estar en lograr el objetivo del sprint, sin embargo, existen reglas obligatorias:

• Daily Scrum no debe durar más de 15 minutos;

• Daily Scrum se lleva a cabo todos los días hábiles, no se permite el pase de Daily Scrum;

• Ejemplos de preguntas que se pueden considerar en el Daily Scrum:

• • ¿Qué hice ayer que ayudó al equipo de desarrollo a lograr el objetivo del sprint?

• • ¿Qué haré hoy para ayudar al equipo de desarrollo a alcanzar el objetivo del sprint?

• • ¿Veo algún obstáculo que nos impida a mí o al equipo de desarrollo alcanzar el objetivo del sprint?

El equipo de desarrollo o los miembros del equipo a menudo se reúnen inmediatamente después del Daily Scrum para discusiones más profundas o para adaptar o replanificar el resto del trabajo.

El Scrum Master garantiza estas reuniones, pero el Equipo de Desarrollo es el responsable de ejecutar el Daily Scrum. El Scrum Master también entrena al equipo de desarrollo para mantener el Daily Scrum dentro de los 15 minutos y debe asegurarse de que la reunión no se interrumpa.

El propósito de dichas reuniones es mejorar las comunicaciones del equipo, reducir el número de reuniones adicionales, identificar futuros riesgos y dificultades y facilitar la toma rápida de decisiones.

Este es el principal medio para verificar el trabajo del equipo de desarrollo.

Revisión de Sprint

Realizado al final del sprint para verificar el incremento del producto y ajustar el backlog si es necesario. Durante la revisión de los resultados del sprint participan el Scrum Team y todos los stakeholders. Esta reunión informal y presentación del incremento tiene como objetivo recibir comentarios y desarrollar la cooperación.

La revisión resumida del sprint incluye los siguientes elementos:

• El propietario del producto muestra qué elementos de la cartera de pedidos se han completado y cuáles no.
• El equipo de desarrollo discute qué salió bien, qué fue difícil y cómo se resolvieron.
• El equipo de desarrollo muestra el trabajo que ha completado en el sprint y qué incremento de producto ha recibido.
• El propietario del producto analiza el estado actual de la cartera de pedidos. También predice los objetivos probables y los plazos en función del resultado logrado.
• Hay una discusión sobre lo que es más valioso hacer a continuación con base en un análisis del mercado y/o audiencia potencial.
• Revisar el cronograma, el presupuesto, las oportunidades y el mercado para complementar el backlog.

El resultado es un backlog actualizado que define objetivos para los próximos sprints. La cartera de pedidos se puede ajustar en su conjunto para satisfacer nuevas oportunidades.

Reunión retrospectiva (Sprint Retrospective)

El propósito de la reunión retrospectiva es desarrollar propuestas para mejorar el proceso (procedimientos, técnicas, operaciones) de implementación del proyecto. En el curso de un análisis retrospectivo del sprint pasado, se forma un plan para mejorar el proceso de implementación del proyecto para el próximo sprint. La reunión se lleva a cabo después de la revisión de los resultados del sprint antes de planificar el próximo sprint y no debe durar más de 3 horas. Supervisa el progreso de la reunión de Scrum Master.

Los principales objetivos de la reunión son:

• Un análisis del último sprint completado en términos de personas, procesos y herramientas involucradas.
• Identificación de las principales decisiones efectivas para mejorar el proceso de implementación del proyecto tomadas para el último sprint y búsqueda de formas de mejorarlas aún más.
• Formación de un plan de implementación, mejora del proceso de implementación del proyecto por parte del equipo Scrum.

El Scrum Master alienta al equipo a brindar sugerencias para mejorar la eficiencia del proceso de desarrollo. Durante cada retrospectiva de sprint, el equipo debe buscar y sugerir formas y medios para mejorar los procesos de trabajo.

Al final de la retrospectiva del sprint, el equipo debe identificar propuestas de mejora para implementar en el siguiente sprint. Si bien tales propuestas se pueden implementar en cualquier momento, la retrospectiva del sprint brinda la oportunidad de concentrarse en analizar las interacciones del equipo y adaptarlo a las condiciones actuales.

Cancelación de un sprint

Un sprint se puede cancelar si el objetivo del sprint no está actualizado. Solo el propietario del producto tiene derecho a cancelar un sprint [21] .

Reuniones adicionales de Scrum

Es posible que estas reuniones no sean parte del flujo de trabajo general de Scrum, pero ciertamente se llevan a cabo en algunas situaciones. Se utilizan cuando hay más de 7-11 desarrolladores, es decir, más del tamaño recomendado del equipo Scrum.

Scrum de Scrums

Si el equipo tiene más de 11 personas, entonces el equipo es más grande que el tamaño de Scrum recomendado. Scrum of Scrums [22] ha sido propuesto para extender Scrum .

Luego, el equipo se divide en varios equipos Scrum. Cada uno tiene su propio Scrum Master y Product Owner.

Los equipos realizan Daily Scrum.

Después de la reunión diaria de Scrum, hay un rally Scrum of Scrums (SoS [23] ). Esto significa lo siguiente. Se elige un representante de cada equipo. Los representantes se dividen en 5-9 personas. A cada equipo se le asigna un Chief Scrum Master [24] y un Chief Scrum Product Owner [25] de entre los Scrum Masters y Product Owners involucrados en el proyecto. Un equipo de representantes de diferentes Equipos Scrum se denomina Equipo Scrum de Scrums [26] . En esta composición, se lleva a cabo un rally permanente de 15 minutos de Scrum of Scrums (SoS) o Meta Scrum o Scaled Daily Scrum (SDS) [27] .

Ken Schwaber recomienda hacer Scrum of Scrums todos los días [28] .

Sin embargo, algunos equipos de Scrum of Scrums no lo hacen todos los días, sino 2-3 veces por semana [28] . Esto viola los principios básicos de Scrum y es un ejemplo clásico de ScrumBut [29] [30] . Esto no le permite aprovechar al máximo Scrum [31] .

Scrum of Scrums permite que múltiples Equipos Scrum discutan el trabajo, centrándose en áreas comunes y la integración mutua. El Chief Scrum Master hace cuatro preguntas a todos los miembros del equipo Scrum of Scrum [28] , las primeras tres preguntas repiten las preguntas de Daily Scrum:

• ¿Qué ha hecho cada equipo desde la reunión anterior de Scrum of Scrums para lograr el Sprint Goal?
• ¿Qué hará cada equipo para la próxima reunión diaria de Scrum de Scrums para lograr el objetivo del sprint?
• ¿Hay algún problema que impida que el equipo alcance el objetivo del sprint?
• ¿El otro equipo necesita hacer algo de las tareas de su equipo para ayudarlos a alcanzar la meta del sprint?

Con la metodología Scrum of Scrums puedes seguir aumentando el número de desarrolladores. Si Scrum de Scrums no cubre a todo el equipo, una reunión Scrum de Scrum de Scrums (Scrum-3, SoSoS) [32] , Scrum de Scrum de Scrum de Scrums (Scrum-4, SoSoS [33] ) [34] puede ser sostenido y así sucesivamente [35] . El último MetaScrum se llama Executive Meta Scrum (EMS) [36] o Executive Action Team (EAT) [37] . Este enfoque permite organizar el trabajo de 4096 personas en solo una hora [34] .

El orden del Scrum de Scrums es el mismo que el Daily Scrum [26] :

• al mismo tiempo, en el mismo lugar,
• todos pueden mirar, pero solo los "cerdos" hablan,
• el Chief Scrum Master, el Chief Scrum Product Owner y el Scrum of Scrums Team participan en el rally,
• dura exactamente 15 minutos
• todos los participantes de Scrum of Scrums se ponen de pie (Daily Standup rally).

Pedidos atrasados ​​(Grooming)

El backlog se organiza de modo que el equipo de desarrollo y el propietario del producto puedan [38] :

• Agregue, elimine, fusione o divida elementos de la cartera de productos (PBI), descomponga los elementos de la cartera en elementos de tareas de nivel de programación.
• Aclarar o dar nuevas estimaciones de la complejidad de las tareas, etc.
• Cambiar el orden de los elementos de la cartera de productos.
• Discutir y aclarar los requisitos comerciales.

Otras técnicas de escalado de Scrum

Además de la metodología clásica Scrum of Scrums (SoS), LeSS [39] [40] [41] [42] (de 2 a 8 equipos), Nexus [43] , RAGE [44] , DAD [45] , APM [46 ] ] [47] , SAFe [48] . Para proyectos muy grandes, se utiliza LeSS Huge [40] (más de 8 comandos) en lugar de LeSS . Solo los métodos SoS [49] y Nexus [50] fueron desarrollados por Sutherland y Schwaber [40] y se enseñan en los cursos de certificación CSM y PSM.

Capacitación y certificación Scrum

En Scrum, un Scrum Master calificado, un propietario de producto Scrum y un equipo Scrum juegan un papel crucial. Scrum Founders and Certified Trainers (CST®) brindan cursos de capacitación para certificar a los profesionales de Scrum. Una base obligatoria para todos son las habilidades del Scrum Master. Luego viene la especialización en Scrum Master, Scrum Product Owner y Scrum Developer (miembro del Scrum Team). Aquellos que aprueban con éxito el examen reciben certificados: Certified ScrumMaster (CSM®), Certified Scrum Product Owner (CSPO®), Certified Scrum Developer (CSD®), Professional Scrum Master (PSM™), Professional Scrum Product Owner (PSPO™) , Desarrollador Scrum Profesional (PSD™). Aquellos que deseen mejorar aún más el conocimiento y las habilidades de Scrum pueden, después de los cursos básicos CSM, CSPO de Scrum ALLIANCE y aprobar el examen sobre ellos, que tienen al menos 1 año de experiencia en su rol de Scrum, tomar Advanced Certified Scrum Master (A -CSM), Propietario de Producto Scrum Certificado Avanzado, Desarrollador Scrum Certificado Avanzado [51] . Para los desarrolladores, hay un conjunto separado de cursos relacionados con TDD , DevOps , etc. [52] . Aquellos que hayan completado los cursos CSM, CSPO, CSD, A-CSM, A-CSPO, A-CSD y hayan aprobado sus exámenes y tengan al menos 3 años de experiencia en el rol de Scrum relevante pueden tomar CSP®-SM, CSP® -Cursos PO, CSP-D® [53] . Como parte de la certificación scrum.org, los cursos también tienen varios niveles: PSM-I, PSM-II, PSM-III, PSPO-I, PSPO-II, PSPO-III [54] .

La capacitación adicional es posible con la emisión de un certificado de entrenador Scrum: Certified Scrum Trainer (CST®) o Professional Scrum Trainer (PST ™).

La certificación CST está abierta a personas con una certificación CSP-SM o CSP-PO o CSP-D y al menos 5 años de experiencia en un rol relevante de Scrum [55] .

La certificación PST reconoce a Scrum Master Trainers (PSSMT), Product Owner Trainers (PSPOT) y Development Team Trainers (PSDT) [56] [57] [58] . La admisión y certificación Train-the-Trainer (TTT) requiere:

• en PSSMT - certificado PSM III;
• en PSPOT - Certificados PSM I y PSPO I;
• en los certificados PSDT - PSM I y PSD I.

La certificación Scrum es válida por dos años. Durante estos dos años, para poder renovar el certificado para los próximos dos años, se debe reclutar un cierto número de Scrum Education Units (SEU®) [59] . Las Unidades de educación de Scrum se otorgan por completar cursos de Scrum, participar en Global Scrum Gathering℠ [60] y Regional Scrum Gathering℠ [61] , enseñar Scrum y otras actividades destinadas a mejorar sus habilidades de Scrum [59] . Dicho sistema muestra que su conocimiento de Scrum está actualizado y que siempre está listo para aplicarlo y transmitirlo a otros. Esto aumenta enormemente el valor de un certificado Scrum. Las unidades educativas Scrum se otorgan de la siguiente manera: 1 hora de capacitación Scrum (participación en una reunión, enseñanza, participación en un seminario web, etc.) equivale a 1 SEU®. La renovación de un certificado requiere:

• CSM®, CSPO®, CSD® - 20 SEU®;
• A-CSM®, A-CSPO®, A-CSD® - 30 SEU®;
• CSP®-SM, CSP®-PO, CSP-D®, CAL II-40 SEU®.

Si hay varios certificados, el número de SEU® necesarios para la renovación se calcula utilizando una calculadora especial: [62] .

No exactamente Scrum

Scrumbut

ScrumBut es el uso de sólo una parte de los principios de Scrum, manteniendo la convicción de trabajar en Scrum [29] [30] . Esto no solo le impide aprovechar al máximo Scrum [29] , sino que también degrada el rendimiento en comparación con la ausencia total de una metodología.

Los estudios han demostrado que ScrumBut reduce las ganancias anuales del 400 % al 0-35 % [31] . Al mismo tiempo, la productividad del trabajo según la "cascada" se tomó como 100% y según Scrum como 400%. Un amplio estudio de las causas y consecuencias de ScrumBut se lleva a cabo en el trabajo “ScrumBut in Professional Software Development” [63] .

Ejemplos clásicos de ScrumBut [29] :

• Dirigir Scrum Diario o Scrum de Scrums no es todos los días;
• Falta de retrospectivas;
• Sprints de más de 4 semanas;
• Falta de definición de hecho.

Se proporciona una gran cantidad de ejemplos de ScrumBut en el sitio web de Scrum Alliance, Scrum ALLIANCE® [64] .

Scrum y

Además de ScrumBut considere ScrumAnd [65] . Se considera que ScrumAnd utiliza Scrum y otras mejores prácticas. Sin embargo, puede ser difícil distinguir ScrumBut de ScrumAnd [66] . Por ejemplo, hacen la pregunta: tenemos un sprint de 6 meses, ¿es ScrumBut o ScrumAnd? Los autores de [66] atribuyen inequívocamente esto a ScrumBut y proporcionan un método para distinguir entre ScrumBut y ScrumAnd. Cabe recordar que la metodología Scrum es autosuficiente, y tanto ScrumBut como ScrumAnd conducen a una disminución de la eficiencia del proceso de desarrollo de aplicaciones empresariales. [67] .

Notas

1. ↑ "scrum" traducción inglés-ruso . lingvo.abbyyonline.com. Recuperado: 4 de mayo de 2016. (indefinido)
2. ↑ Schwaber Ken, SutherlandJeff. Guía Scrum (noviembre 2020). (Ruso)
3. ↑ Copia archivada . Consultado el 19 de octubre de 2018. Archivado desde el original el 20 de octubre de 2018. (indefinido)
4. ↑ 1 2 5 herramientas clave del método SCRUM (27 de abril de 2017). Consultado el 21 de octubre de 2018. Archivado desde el original el 2 de octubre de 2019. (indefinido)
5. ↑ Agile: un enfoque ágil para la gestión de proyectos (4 de noviembre de 2016). Consultado el 21 de octubre de 2018. Archivado desde el original el 3 de octubre de 2019. (indefinido)
6. ↑ 1 2 3 4Jeff Sutherland. MELÉ. Método revolucionario de gestión de proyectos = SCRUM. El arte de hacer el doble de trabajo en la mitad de tiempo. - Mann, Ivanov y Ferber, 2016. - 288 p. - ISBN 978-5-00057-722-6 .
7. ↑ Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms Yourdon Press Computing Series, 1990 (primera edición), ISBN 0-13-590126-X
8. ↑ OPSPLA 2006 . Fecha de acceso: 26 de enero de 2010. Archivado desde el original el 25 de junio de 2010. (indefinido)
9. ↑ Schwaber, Ken; Beedle, Mike. Desarrollo ágil de software con Scrum  (neopr.) . - Prentice Hall , 2002. - ISBN 0-13-067634-9 .
10. ↑ Maximini, Domingo. La Cultura Scrum: Introducción de Métodos Ágiles en las Organizaciones. Gestión para profesionales  // Cham: Springer. - 8 de enero de 2015. Consultado el 25 de agosto de 2016.. - Pág. 26 . — ISSN 9783319118277 .
11. ↑ Partogui, Joshua. Scrum Master certificado vs Scrum Master profesional // Lean Agile Institute. — 7 de julio de 2013. Consultado el 10 de mayo de 2017.
12. ↑ Ken Schwaber; Jeff Sutherland. La guía Scrum. — Scrum.org, consultado el 27 de octubre de 2017.
13. ↑ Scrum.org presenta Scrum con el curso Kanban, permitiendo una mayor transparencia entre los equipos de desarrollo (obtenido el 2 de marzo de 2018). Consultado el 22 de mayo de 2019. Archivado desde el original el 18 de noviembre de 2018. (indefinido)
14. ↑ Sprint - imbécil; lanzar; A corto plazo.
15. ↑ Ken Schwaber. Gestión ágil de proyectos con Scrum . - Microsoft Press, 2004. - 163 p. — ISBN 073561993X .
16. ↑ Proyecto visual y gestión de equipos @ Kaiten . Consultado el 15 de marzo de 2021. Archivado desde el original el 22 de enero de 2021. (indefinido)
17. ↑ ¿Qué es Scrum-Agile para principiantes ? Consultado el 20 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido)
18. ↑ Pollos y cerdos . Consultado el 23 de julio de 2019. Archivado desde el original el 23 de enero de 2017. (indefinido)
19. ↑ Criterios de aceptación de requisitos en Agile . Devprom ALM. Consultado el 3 de abril de 2016. Archivado desde el original el 1 de abril de 2016. (indefinido)
20. ↑ Guía de Scrum | Guías Scrum . scrumguides.org. Consultado el 3 de junio de 2020. Archivado desde el original el 16 de junio de 2020. (indefinido)
21. ↑ Copia archivada . Consultado el 15 de marzo de 2021. Archivado desde el original el 14 de enero de 2021. (indefinido)
22. ↑ (PDF) Scrum of Scrums Solution para equipos de gran tamaño que utilizan la metodología Scrum . Consultado el 21 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido)
23. ↑ Scrum de Scrums (SoS) Definición | innovación _ Consultado el 21 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido)
24. ↑ Rol de un Jefe Scrum Master | Blog de estudio SCRUM . Consultado el 21 de octubre de 2018. Archivado desde el original el 25 de octubre de 2018. (indefinido)
25. ↑ Endava . Consultado el 21 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido)
26. ↑ 1 2 La reunión Scrum de Scrums - Manifiesto . Consultado el 21 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido)
27. ↑ Jeff Sutherland lanza la Guía Scrum@Scale | Blog de Henny Portman . Consultado el 21 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido)
28. ↑ 1 2 3 Artículos informativos enviados por miembros de Scrum Alliance (enlace no disponible) . Consultado el 21 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido) 
29. ↑ 1 2 3 4 ¿Qué es ScrumBut? | Scrum.org . Consultado el 21 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido)
30. ↑ 1 2 ITKaiZenClub "Scrum, pero..." o problemas típicos al implementar Scrum, 8 de febrero | DOU
31. ↑ 1 2 (PDF) Scrum+:: ¿Es "ScrumBut" o "ScrumAnd" . Consultado el 21 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido)
32. ↑ El Equipo Scrum y Scrum de Scrums . Consultado el 21 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido)
33. ↑ Organización ágil con Scrum@Scale, Vimar Spa un ejemplo real
34. ↑ 1 2 ágil en hardware militar. Cómo el SAAB Gripen se convirtió en el avión militar más rentable del mundo Archivado el 20 de octubre de 2018 en Wayback Machine / Sutherland y Joe Justice , 2017 
35. ↑ Scaling Agile Series Parte 2: Una mirada a dos de los cuatro marcos populares de escalamiento ágil: SoS y LeSS - Gorilla Logic . Consultado el 21 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido)
36. ↑ El MetaScrum Ejecutivo | AgileGenesis . Consultado el 15 de marzo de 2021. Archivado desde el original el 18 de abril de 2021. (indefinido)
37. ↑ Equipo de Acción Ejecutiva - Scrum Inc. Consultado el 15 de marzo de 2021. Archivado desde el original el 28 de febrero de 2021. (indefinido)
38. ↑ "Looking for a Backlog Comb Blog of Proactive Business (enlace no disponible) . Fecha de acceso: 8 de diciembre de 2018. Archivado el 27 de diciembre de 2018. (indefinido) 
39. ↑ Scrum a gran escala (LeSS) - Alexey Krivitsky - Agile Coach y Scrum Trainer . Consultado el 2 de noviembre de 2018. Archivado desde el original el 4 de noviembre de 2018. (indefinido)
40. ↑ 1 2 3 ¿Cómo escalar Agile? | sistemas abiertos. SGBD | Editorial "Sistemas abiertos" . Consultado el 2 de noviembre de 2018. Archivado desde el original el 4 de noviembre de 2018. (indefinido)
41. ↑ Introducción a LeSS - Scrum a gran escala (LeSS) . Consultado el 4 de noviembre de 2018. Archivado desde el original el 5 de noviembre de 2018. (indefinido)
42. ↑ LeSS - Scrum a escala - ScrumTrek Blog . Consultado el 4 de noviembre de 2018. Archivado desde el original el 5 de noviembre de 2018. (indefinido)
43. ↑ La guía Nexus | Scrum.org . Consultado el 4 de noviembre de 2018. Archivado desde el original el 5 de noviembre de 2018. (indefinido)
44. ↑ RABIA | Transformaciones ágiles escaladas | proceso | cPrimo . Consultado el 4 de noviembre de 2018. Archivado desde el original el 4 de noviembre de 2018. (indefinido)
45. ↑ Copia archivada (enlace no disponible) . Consultado el 4 de noviembre de 2018. Archivado desde el original el 5 de noviembre de 2018. (indefinido) 
46. ↑ Gestión ágil de proyectos: qué y por qué | APM . Consultado el 4 de noviembre de 2018. Archivado desde el original el 5 de noviembre de 2018. (indefinido)
47. ↑ Gestión ágil de proyectos con Scrum . Consultado el 4 de noviembre de 2018. Archivado desde el original el 5 de noviembre de 2018. (indefinido)
48. ↑ Copia archivada (enlace no disponible) . Consultado el 4 de noviembre de 2018. Archivado desde el original el 5 de noviembre de 2018. (indefinido) 
49. ↑ Scrum de Scrums | Scrum.org . Consultado el 2 de noviembre de 2018. Archivado desde el original el 4 de noviembre de 2018. (indefinido)
50. ↑ La guía Nexus | Scrum.org . Consultado el 2 de noviembre de 2018. Archivado desde el original el 5 de noviembre de 2018. (indefinido)
51. ↑ Certificación Advanced Certified ScrumMaster (A-CSM℠) . Consultado el 15 de marzo de 2021. Archivado desde el original el 17 de marzo de 2021. (indefinido)
52. ↑ Búsqueda de cursos - Scrum Alliance
53. ↑ Curso de certificación Scrum Professional ScrumMaster® (CSP-SM) certificado . Consultado el 15 de marzo de 2021. Archivado desde el original el 17 de marzo de 2021. (indefinido)
54. ↑ Certificación Scrum Master desde el hogar de Scrum . Consultado el 15 de marzo de 2021. Archivado desde el original el 3 de marzo de 2021. (indefinido)
55. ↑ Proceso de solicitud de certificación de Certified Scrum Trainer (CST) . Consultado el 19 de octubre de 2018. Archivado desde el original el 20 de octubre de 2018. (indefinido)
56. ↑ Solicitud y proceso de selección de entrenadores de PSD | Scrum.org . Consultado el 19 de octubre de 2018. Archivado desde el original el 20 de octubre de 2018. (indefinido)
57. ↑ Solicitud y proceso de selección de formadores de PSPO | Scrum.org . Consultado el 19 de octubre de 2018. Archivado desde el original el 20 de octubre de 2018. (indefinido)
58. ↑ Solicitud y proceso de selección de formadores de PSM | Scrum.org . Consultado el 19 de octubre de 2018. Archivado desde el original el 20 de octubre de 2018. (indefinido)
59. ↑ 1 2 Scrum Education Units® (SEU®) Créditos para capacitación . Consultado el 15 de marzo de 2021. Archivado desde el original el 20 de abril de 2021. (indefinido)
60. ↑ Información y patrocinio del evento Global Scrum Gathering . Consultado el 15 de marzo de 2021. Archivado desde el original el 4 de marzo de 2021. (indefinido)
61. ↑ Scrum Alliance Regional Scrum Gatherings . Consultado el 15 de marzo de 2021. Archivado desde el original el 28 de enero de 2021. (indefinido)
62. ↑ Capacitación y certificación de Agile y Scrum | Alianza Scrum . Consultado el 15 de marzo de 2021. Archivado desde el original el 21 de abril de 2021. (indefinido)
63. ↑ Copia archivada . Consultado el 21 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido)
64. ↑ Artículos informativos enviados por miembros de Scrum Alliance (enlace no disponible) . Consultado el 21 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido) 
65. ↑ La postura "ScrumAnd" (requiere pensamiento y disciplina) | Scrum.org . Consultado el 15 de marzo de 2021. Archivado desde el original el 14 de abril de 2021. (indefinido)
66. ↑ 1 2 (PDF) Scrum+:: ¿Es “ScrumBut” o “ScrumAnd” . Consultado el 21 de octubre de 2018. Archivado desde el original el 21 de octubre de 2018. (indefinido)
67. ↑ https://www.researchgate.net/publication/254048455_Scrum_Is_it_ScrumBut_or_ScrumAnd

Véase también

• Implementación de software

Enlaces

• El libro de reglas oficial de Scrum Archivado el 9 de septiembre de 2012 en Wayback Machine .
• Descripción general de la metodología Scrum Archivado el 14 de marzo de 2016 en Wayback Machine .

Literatura

• Henrik Kniberg. Scrum y XP: notas desde el frente = Scrum y XP desde las trincheras. - C4Media, 2007. - Pág. 140. - ISBN 978-1-4303-2264-1 .
• Mike Cohn. Scrum: desarrollo de software ágil = tener éxito con Agile: desarrollo de software usando Scrum. - M. : "Williams" , 2011. - S. 576. - ISBN 978-5-8459-1731-7 .
• Jeff Sutherland. MELÉ. Método revolucionario de gestión de proyectos = SCRUM. El arte de hacer el doble de trabajo en la mitad de tiempo. - Mann, Ivanov y Ferber, 2016. - 288 p. - ISBN 978-5-00057-722-6 .
• Kenneth Rubín. Scrum esencial: una guía práctica para el proceso ágil más popular. - M. : "Williams" , 20161. - S. 544. - ISBN 978-5-8459-2052-2 .

En catálogos bibliográficos	J9U : 987007534934605171 LCCN : sh2001003039

Desarrollo de software
Proceso	Etapas de desarrollo Análisis de requerimientos Diseño Programación Pruebas Documentación
Conceptos de alto nivel	Arquitectura de software Paradigma Metodología Proceso de desarrollo Calidad
Direcciones	Programación ( orientada a aspectos ) Orientado a objetos orientado a problemas )
Metodologías de desarrollo	Ágil cuarto limpio CASO ARRIBA. RUP Abrir RAD Melé Seguro Modelo Spotify MSF PE DSDM
Modelos	Iterativo en cascada Espiral Modelo V Modelo de doble V MMC CMMI Datos modelo de función IDEF Informativo metamodelo modelo de objeto ver modelo UML
Figuras notables	Kent Beck Gradi Butch fred brooks Ward Cunningham Ole-Johan Dahl tom demarco Edsger Dijkstra donald knuth alan kay Martín Cazador antonio hoare ivar jacobson Bertrand Meyer niklaus wirth Eduardo Jordán steve mconnell james rambo barry boehm humphrey Michael A. Jackson craig larman Roberto Martín Jaime David Parnas Winston Royce