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

8

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?

Giorgio
fuente
1
Eso de "obtener un documento de especificación de requisitos y hay que volver seis meses después con el software en funcionamiento" es un mito. Incluso cuando crea algo así como un compilador para un lenguaje formalmente definido (donde los requisitos funcionales parecen ser realmente claros y fijos), tiene que decidir y priorizar las cosas a implementar, hay requisitos no funcionales que deben discutirse con el usuario , y tiene varios grados de libertad, uno tiene que decidir cómo resolver las cosas. Por lo tanto, un enfoque ágil tiene sentido incluso para este tipo de proyectos.
Doc Brown
"Por lo tanto, un enfoque ágil tiene sentido incluso para este tipo de proyectos": aunque ágil puede ser más flexible, otros métodos también lo son. Puede haber otros métodos que sean lo suficientemente flexibles, y ágil es demasiado flexible para ciertos proyectos. Solo lluvia de ideas aquí.
Giorgio
2
"Eso" obtiene un documento de especificación de requisitos y tiene que volver seis meses después con el software en funcionamiento "lo que es un mito": no lo creo. Si bien puede cambiar rápidamente la etiqueta de un botón en una página web porque los clientes han cambiado de opinión después de mirarlo, no puede cambiar tan fácilmente una parte crítica de un software de aviónica que controla una parte móvil de un avión. Tal vez se necesiten cambios tardíos, pero me pregunto si un método ágil es la forma correcta de administrarlos, o si necesita una iteración más compleja de otro método (por ejemplo, el modelo V).
Giorgio

Respuestas:

5

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.

Ryathal
fuente
¿Hay alguna información sobre cuándo un proyecto se considera demasiado grande para hacerse con SCRUM? Considere, por ejemplo, un proyecto de 18 meses para un equipo de 15 personas: tal equipo se beneficiaría de SCRUM u otro modelo como el modelo V también sería adecuado. La razón por la que pregunto es que durante 18 meses los requisitos y la implementación tienen tiempo suficiente para madurar y estabilizarse, y tal vez la flexibilidad proporcionada por SCRUM no sea realmente necesaria. Más bien, aquí es adecuado un enfoque más a mediano y largo plazo. ¿Hay alguna literatura sobre esto?
Giorgio
El tiempo del proyecto de @Giorgio realmente no importa, pero 15 personas son suficientes para que te beneficies haciendo múltiples grupos scrum, pero todavía está en el rango manejable para SCRUM. cuando la gestión de la comunicación comienza a convertirse en un trabajo a tiempo completo para su equipo, es hora de comenzar a mirar un modelo V
Ryathal
1
¿En serio? Estábamos usando un modelo V antes y cambiamos a SCRUM. En realidad, tenemos la sensación de que nos hemos vuelto más lentos exactamente por esta razón: demasiada contabilidad.
Giorgio
@Giorgio eso sería cierto para cualquier cambio, te sentirás más lento al principio porque es nuevo, como Pierre 303 dijo que tienes una mejor idea después de algunos sprints.
Ryathal
1
@Giorgio: eso es cierto, muchas metodologías "ágiles" son más pesadas que los procesos pesados ​​que se supone que deben reemplazar. Obviamente, esto significa que están equivocados: se supone que ágil es ligero y libre, y parece caótico para los extraños. Significa que su equipo tiene que ser muy organizado y disciplinado, pero eso generalmente es un beneficio. Prueba Crystal de Alistair Cockburn (uno de los fundadores de Agile).
gbjbaanb
8

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.

Tom Morgan
fuente
¿Su propia opinión es compartida por los proponentes de SCRUM, es decir, por los autores que han codificado y promovido SCRUM?
Giorgio
Sí, Cheryl Hammond ( blog.bsktcase.com ), una consultora de ALM con Northwest Cadence, dijo recientemente en una charla titulada "A Scrum Masters Day In The Life: The New Visual Studio". Puedes verlo aquí: msevents.microsoft.com/CUI/…
Tom Morgan
5

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.

Mahmoud Hossam
fuente
1

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.

gbjbaanb
fuente
La forma en que somos ágiles en nuestro equipo es permitir que el cliente establezca una prioridad en las historias (de la más importante a la menos importante), estimamos las historias de los usuarios utilizando cartas de póker y planificamos tantas historias como podamos implementar hasta la fecha límite. Si resultamos ser más rápidos, programamos más historias, de acuerdo con lo que viene a continuación en la lista de prioridades.
Giorgio
Leí su respuesta nuevamente después de unos meses y en realidad es realmente esclarecedora. +1
Giorgio