¿Debo usar scrum para grandes proyectos? [cerrado]

He estado trabajando como programador en un proyecto diseñado para software genérico para estaciones de servicio (que se redistribuirá para muchos clientes) durante 18 meses. El proyecto es grande. Hoy tenemos alrededor de 150 mesas. No hemos utilizado un approuch específico, no fue bien administrado.

La tabla de personas tiene hoy alrededor de 70 columnas, pero hace 15 meses tenía alrededor de 30 columnas. Estos nuevos campos surgieron para integrarse con otros módulos como ventas, finanzas y contabilidad. También se crearon muchos campos y luego se eliminaron.

Como resultado, tuvimos muchas refactorizaciones y modificaciones. El proyecto nunca se prepara porque siempre surgen nuevos requisitos.

Aquí está mi duda: si hubiéramos utilizado un enfoque habitual de especificación, tendríamos entrevistas, un documento de requisitos, diagramas de actividad, secuencia y clase, por lo que sabríamos desde el principio que la tabla "persona" necesitaría 70 campos, entonces había evitado muchas refactorizaciones.

¿Podría Scrum ayudar en este proyecto? Tengo la sensación de que en este caso el scrum también terminaría en una gran refactorización.

Solo soy un programador, no un gerente de proyecto. Me pregunto cómo debería haberse hecho: con scrum o con un gran diseño por adelantado.

Editar

Solo para complementar el final de esta historia. Ocho meses después hice esta pregunta, después de poner el proyecto en producción en algunos "clientes de prueba", el proyecto fracasó oficialmente. El propietario del producto decidió abandonar el proyecto. Se hizo difícil solucionar problemas y se produjeron muchos problemas de rendimiento.

Parece que te abres camino en un proceso de desarrollo incontrolado para crear un sistema de desarrollo interminable. Esto también ocurre en sistemas ágiles.

El problema raíz es la falta de requisitos, y aunque parece que su solución es utilizar una metodología ágil para solucionar esto (ya que ágil está diseñado en torno a los requisitos cambiantes), no resolvería el problema.

Incluso los métodos ágiles requieren un punto de partida bastante firme. Responden bien a los requisitos cambiantes, pero son tan inútiles como cualquier otra metodología si comienzas sin requisitos. Aún debe tener un plan al que se dirija antes de comenzar. Agile ayuda cuando ese objetivo se desvía, no te ayuda a definir ese objetivo.

Ahora es cierto que un diseño frontal fijo es demasiado rígido si no sabe exactamente lo que está construyendo.

Por lo tanto, creo que tendrá que pasar de su metodología actual de 'caos' a algo más organizado y tendrá que implementar una buena cantidad de diseño y planificación. Puede intentar hacer esto de una vez con una metodología pesada, o puede ser más flexible con una ágil. Lo que no puede hacer es esperar ninguna metodología para corregir su falta de planificación inicial.

Por cierto, Kanban suena más apropiado para sus necesidades. Scrum funciona mejor con pequeños equipos y proyectos. Kanban puede trabajar con proyectos más grandes, pero también funciona con un enfoque de rendimiento de trabajo, por lo que los cambios de diseño son continuos y no se agrupan en sprints. Creo que tendrías más éxito con eso.

18 meses, 150 mesas y todavía no en producción? Suena como una marcha de la muerte para mí. La única manera de solucionar esto, si hay alguna posibilidad de guardar esto ahora, es reducir drásticamente el alcance de su proyecto, al menos para su primer lanzamiento de producción. Lo que necesita es una planificación de lanzamiento adecuada, objetivos pequeños y alcanzables y llevar el sistema al usuario final lo antes posible.

Y cuando tenga su primer lanzamiento en producción, con solo una décima parte de los requisitos implementados, tendrá que extenderlo paso a paso en el siguiente bloque de requisitos, lo que provocará una "refactorización". También recibirá comentarios, lo que significa la corrección de errores y los requisitos modificados, lo que también provocará una refactorización.

Ahora a su pregunta: ¿ayudará Scrum? Tal vez tal vez no. Scrum es una herramienta para soportar el desarrollo iterativo y los requisitos cambiantes, y enfocarse primero en las cosas importantes. Otros métodos "ágiles" también hacen esto, y un proceso no tan formalizado podría manejar eso también. Pero mientras trates de poner en producción un monstruo como este en un "big bang", no importa si usas un desarrollo "ágil" o "inicial", ambos fracasarán.

Entonces, antes de pensar en Scrum, primero reconsidere sus objetivos y su estrategia de lanzamiento, y luego verifique si Scrum es la herramienta adecuada para eso, y no al revés.

Si no puede administrar los requisitos y no tiene personas capaces de implementar los requisitos adecuadamente, SCRUM no lo ayudará (mucho), y ese parece ser el verdadero problema que enfrenta.
SCRUM puede ayudarlo a lidiar mejor con los requisitos cambiantes que los sistemas de gestión de proyectos más estáticos, pero no es el santo grial lo que mágicamente hará que todo funcione. De hecho, a menos que su gente esté a bordo, dispuesta y capaz de trabajar con SCRUM, y también lo esté el resto de la organización, puede empeorar las cosas.

Si tiene una tabla que ha crecido tanto para encajar en cosas para vincular con otros sistemas, postulo que el diseño de su base de datos es muy defectuoso, por ejemplo. Ninguna cantidad de SCRUM mejorará el diseño de su base de datos sin que usted incluya personas que sean buenas en el diseño de la base de datos en su equipo y que no tengan miedo de esos cambios de diseño y los cambios que causarán en el resto de su sistema.

Tenga en cuenta que cuando escribí esta respuesta, no me di cuenta de que el sistema aún no estaba en producción.

De la forma en que describe su producto, no creo que su problema inmediato sea el de gestionar los requisitos ni su proceso de desarrollo. Es el de la arquitectura de su sistema.

Has logrado crear un monolito, y uno bastante grande. 150 tablas es mucho para un sistema *. En particular, mencionas que tienes 40 nuevos campos durante los últimos 15 meses solo para integrarte a sistemas externos. Consideraría seriamente dividir su sistema en varios servicios autónomos, probablemente comenzando con servicios para la integración a sistemas externos, pero luego identificando áreas comerciales separadas implementadas en su monolito, y luego tal vez divida esas preocupaciones en servicios separados.

Si logra dividir este monolito en bases de código mantenibles por separado, también puede dividir a sus desarrolladores en equipos más pequeños con responsabilidades bien definidas en áreas específicas de su negocio, y puede hacer que muchos equipos ágiles más pequeños mantengan su propia base de código, en lugar de hackear en la misma base de código.

En cuanto a por qué ha llegado a tal arquitectura, la causa raíz de su problema, puede haber muchas respuestas. Tal vez esté enraizado en su proceso de desarrollo, tal vez todos sus desarrolladores solo tengan experiencia con software transaccional consistente, o tal vez sea una consecuencia de cómo está estructurada su organización (usted es víctima de la Ley de Conway ). Creo que hay una buena posibilidad de que sea una combinación de los dos últimos.

No creo que implementar scrum, o ser mejores en la gestión de requisitos ayudará a resolver su problema inmediato, ni la causa raíz. Ajustar la arquitectura para la complejidad de su sistema lo hará, y abordar la causa raíz de por qué ha creado tal sistema.

* Algunos probablemente argumentarán que pueden mantener un sistema con 150 tablas, o que han mantenido sistemas mucho más grandes, pero creo que la mayoría de los desarrolladores considerarán esto como una gran cantidad de tablas para un sistema.