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, por ejemplo, frente a los requisitos cambiantes del cliente. Otra ventaja es que la administración puede rastrear fácilmente el progreso de un proyecto.
La flexibilidad de SCRUM puede ser una ventaja p.ej 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, existen otros tipos de proyectos de software (por ejemplo, en el sector aeroespacial industria) 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 que no necesita construir prototipos y mostrárselos al cliente para obtener retroalimentación sobre los requisitos): más bien necesita un enfoque muy estructurado y sistemático, que probablemente se repita una y otra vez para cada proyecto con poco espacio para la sorpresa.
Entonces, ¿SCRUM es considerado por sus proponentes como 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?
Para Por ejemplo, recientemente miré el sitio web de una empresa que produce software para la industria aeroespacial y me di cuenta de que están utilizando el modelo V. ¿Un proponente de SCRUM diría que SCRUM es menos adecuado para este tipo de proyectos o sugeriría que esta empresa debería intentar cambiar a SCRUM?
Nota 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?
Comentarios
- Consulte stackoverflow.com / questions / 596916 / when-should-you-not-scrum y eweek.com/c/a/IT-Management/…
- Que » obtenga un documento de especificación de requisitos y tenga que regresar seis meses después con el software en funcionamiento » es un mito. Incluso cuando crea algo como un compilador para un lenguaje definido formalmente (donde los requisitos funcionales parecen ser realmente claros y fijos), tiene que decidir y priorizar las cosas a implementar, hay requisitos no funcionales que se deben discutir con el usuario , y tienes varios grados de libertad para que uno tenga que decidir cómo resolver las cosas. Por lo tanto, un enfoque ágil tiene incluso sentido para este tipo de proyectos.
- » Por lo tanto, un enfoque ágil tiene incluso sentido 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 que ágil sea demasiado flexible para ciertos proyectos. Solo haga una lluvia de ideas aquí.
- » Que » obtenga un documento de especificación de requisitos y debe regresar seis meses después con software de trabajo «, la cosa 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 verlo, 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).
Respuesta
SCRUM es una metodología de propósito general que puede funcionar bien para la mayoría de proyectos y tamaños de equipos, pero es menos útil para equipos grandes que hacen mucho proyectos. 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.
Comentarios
- ¿Hay ¿Alguna información sobre cuándo se considera que un proyecto es demasiado grande para realizarlo con SCRUM? Considere, por ejemplo, un proyecto de 18 meses para un equipo de 15 personas: ¿un equipo de este tipo se beneficiaría de SCRUM o también sería adecuado otro modelo como el modelo V La razón por la que estoy preguntando 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.Por el contrario, en este caso es adecuado un enfoque más de mediano a largo plazo. ¿Hay alguna literatura sobre esto?
- @Giorgio El tiempo del proyecto no ‘ realmente importa, pero 15 personas son suficientes para que se beneficie de hacer múltiples scrum. grupos, pero todavía está en el rango manejable para SCRUM. cuando la gestión de la comunicación comienza a convertirse en un trabajo de tiempo completo para su equipo, es hora de empezar a buscar un modelo en V
- ¿Lo dice en serio? Estábamos usando un modelo V antes y cambiamos a SCRUM. De hecho, tenemos la sensación de que ‘ nos hemos vuelto más lentos exactamente por esta razón: demasiada contabilidad.
- @Giorgio, eso sería cierto para cualquier cambio, se sentirá más lento al principio porque es nuevo, como Pierre 303 dijo que tienes una mejor idea después de algunos sprints.
- @Giorgio – eso ‘ es cierto, Muchas » ágiles » metodologías son más pesadas que los procesos pesados que ‘ se supone ¡para reemplazar! Obviamente, esto significa que ‘ están equivocados: se supone que ágil es ligero y gratuito, y parece caótico para los forasteros. Significa que su equipo tiene que ser muy organizado y disciplinado, pero eso ‘ es generalmente un beneficio. Pruebe Crystal de Alistair Cockburn (uno de los fundadores de Agile).
Respuesta
Cualquier tipo de proyecto ! Funciona bien tanto para proyectos grandes como pequeños.
La gente lo ha utilizado para planificar bodas, mudanzas, etc. Así que ni siquiera solo en proyectos de software.
Creo firmemente que hay muchas operaciones comerciales que podrían beneficiarse de un enfoque similar a Scrum.
Comentarios
- ¿Se comparte su propia opinión? por los proponentes de SCRUM, es decir, por autores que han codificado y promovido SCRUM?
- Sí, lo dijo recientemente Cheryl Hammond ( blog.bsktcase.com ), consultora de ALM con Northwest Cadence en una charla que dio titulada » A Scrum Masters Day In The Life: The New Visual Studio «. Puedes verlo aquí: msevents.microsoft.com/CUI/…
Respuesta
Tenga en cuenta que Scrum no es una metodología, sino un marco.
Scrum funcionará mejor en un c ross-funcional equipo de 5 a 9 desarrolladores trabajando 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 discutiré el tema de las funciones cruzadas aquí, pero aquí son lo que la guía oficial de Scrum dice sobre el tamaño del equipo:
Desarrollo óptimo El tamaño del equipo es lo suficientemente pequeño como para seguir siendo ágil y lo suficientemente grande para completar un trabajo importante. Menos de tres miembros del equipo de desarrollo disminuye la interacción y da como resultado ganancias de productividad menores. Los Equipos de desarrollo más pequeños pueden encontrar limitaciones de habilidades 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 los gestione un proceso empírico. Los roles de Product Owner y Scrum Master no se incluyen en este recuento a menos que también estén ejecutando el trabajo del Sprint Backlog
Un Sprint dura 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 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 más pequeños 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.
Respuesta
para empezar , piense en SCRUM como solo un conjunto de pautas para implementar prácticas ágiles. Nunca piense 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 fracasar en los proyectos que requieren una fecha de finalización fija o un costo fijo. Si bien aún puede hacer estos proyectos con métodos ágiles, la necesidad de planificar todo de antemano Determinar si es probable que alcance el objetivo no es la forma ágil habitual: en ágil, tiende a seguir trabajando hasta que se queda sin cosas que hacer o se acaba el tiempo para hacerlo. Para la mayoría de los proyectos, esto está bien ya que los requisitos cambian de todos modos durante el proyecto.
Comentarios
- La forma en que trabajamos con agilidad en nuestro equipo es permitir que el cliente establezca una prioridad en las historias (de mayor a menor importancia), estimamos las historias de usuarios usando cartas de póquer y planificamos tantas historias como podamos implementar hasta la fecha límite. Si resulta que somos más rápidos, programamos más historias, de acuerdo con lo que viene a continuación en la lista de prioridades.
- Leí su respuesta nuevamente después de unos meses y en realidad es realmente esclarecedora. +1