¿Para qué tipo de proyectos se considera adecuado SCRUM?

He estado usando SCRUM en tres proyectos diferentes durante los últimos cuatro años. Una de las ventajas de SCRUM parece ser su flexibilidad y adaptabilidad, p. Ej. Wrt a los requisitos cambiantes del cliente. Otra ventaja es que la administración puede seguir fácilmente el progreso de un proyecto.

La flexibilidad de SCRUM puede ser una ventaja, por ejemplo, al implementar una aplicación web, donde los requisitos cambian muy rápido y los clientes realmente entienden lo que quieren después de haber visto un prototipo.

Por otro lado, hay otros tipos de proyectos de software (por ejemplo, en la industria aeroespacial) donde los requisitos son bastante fijos: obtienes un documento de especificación de requisitos y tienes que regresar seis meses después con el software en funcionamiento y la documentación completa. Para este tipo de proyectos, dudo que se necesite la flexibilidad que ofrece SCRUM (en el sentido de que no es necesario construir prototipos y mostrarlos al cliente para obtener comentarios sobre los requisitos): más bien necesita un enfoque muy estructurado y sistemático , que probablemente se repite una y otra vez para cada proyecto con poco espacio para la sorpresa.

Entonces, ¿sus defensores consideran SCRUM una metodología de desarrollo de software de propósito general o se considera especialmente adecuado para ciertas categorías de proyectos o áreas de aplicación?

Por ejemplo, recientemente miré el sitio web de una compañía que produce software para la industria aeroespacial y noté que están usando el modelo V. ¿Podría un defensor de SCRUM decir que SCRUM es menos adecuado para este tipo de proyectos o más bien sugerir que esta compañía debería intentar cambiar a SCRUM?

Tenga en cuenta que no estoy pidiendo la opinión de los lectores de este foro, pero quiero saber cuál es la opinión establecida entre los proponentes de SCRUM: ¿SCRUM se considera de propósito general o más bien adecuado para ciertas clases de proyectos solamente? En los últimos casos, ¿para qué tipo de proyectos?

SCRUM es una metodología de propósito general que puede funcionar bien para la mayoría de los proyectos y tamaños de equipo, pero es menos útil para equipos grandes que realizan proyectos muy grandes. La gran cantidad de personas involucradas en algunos proyectos hace que cualquier metodología ágil sea extremadamente difícil o casi imposible porque se requiere una estructura más rígida para mantener el orden. La industria aeroespacial es un buen ejemplo de una industria que tiende a tener grandes proyectos donde los enfoques ágiles no siempre son factibles.

Cualquier tipo de proyecto! Funciona bien para proyectos grandes y pequeños.

La gente lo ha usado para planificar bodas, mudanzas, etc. Por lo tanto, ni siquiera los proyectos de software.

Creo firmemente que hay muchas operaciones comerciales que podrían beneficiarse de un enfoque tipo Scrum.

Tenga en cuenta que Scrum no es una metodología, sino un marco.

Scrum funcionará mejor en un equipo multifuncional de 5 a 9 desarrolladores que trabajan en un proyecto de tamaño mediano a grande (de 4 meses a varios años). Si su proyecto es más grande, puede escalar con Scrum of Scrums .

No voy a discutir el tema de las funciones cruzadas aquí, pero esto es lo que dice la Guía oficial de Scrum para el tamaño del equipo:

El tamaño óptimo del equipo de desarrollo es lo suficientemente pequeño como para ser ágil y lo suficientemente grande como para completar un trabajo significativo. Menos de tres miembros del Equipo de Desarrollo disminuyen la interacción y resultan en ganancias de productividad más pequeñas. Los equipos de desarrollo más pequeños pueden encontrar limitaciones de habilidad durante el Sprint, lo que hace que el equipo de desarrollo no pueda entregar un incremento potencialmente liberable. Tener más de nueve miembros requiere demasiada coordinación. Los grandes equipos de desarrollo generan demasiada complejidad para que un proceso empírico lo gestione. Las funciones de Propietario del producto y Scrum Master no se incluyen en este recuento, a menos que también estén ejecutando el trabajo del Backlog de Sprint

Un sprint es de aproximadamente un mes.

Los sprints están limitados a un mes calendario. Cuando el horizonte de un Sprint es demasiado largo, la definición de lo que se está construyendo puede cambiar, la complejidad puede aumentar y el riesgo puede aumentar. Los sprints permiten la previsibilidad al garantizar la inspección y la adaptación del progreso hacia una meta al menos cada mes calendario. Los sprints también limitan el riesgo a un mes calendario de costo.

Creo que no tiene sentido usar un marco basado en un proceso iterativo con proyectos de menos de 4 meses. 4 meses = 4 sprints. También debes considerar que obtienes una velocidad más precisa después de 3 sprints.

Dicho esto, yo personalmente uso una versión limitada de Scrum para proyectos más pequeños. Pero realmente no puedes llamarlo Scrum entonces. En ese caso particular, está utilizando algunos principios básicos de Scrum en su propia implementación del marco.

Para empezar, piense en SCRUM como solo un conjunto de pautas para implementar prácticas ágiles. Nunca pienses en él como un "libro sagrado" de cómo hacer proyectos. Para muchos proyectos donde se requiere un flujo constante de tareas, Kanbam es más apropiado, por ejemplo.

Los proyectos ágiles tienden a caer donde estás haciendo proyectos que requieren una fecha de finalización fija o un costo fijo. Si bien aún puede hacer estos proyectos utilizando métodos ágiles, la necesidad de planificar todo por adelantado para determinar si es probable que alcance el objetivo no es la forma ágil habitual: en el ágil tiende a seguir trabajando hasta que se quede sin cosas hacer, o quedarse sin tiempo para hacerlo. Para la mayoría de los proyectos esto está bien ya que los requisitos cambian de todos modos durante el proyecto.