Históricamente, mi equipo ha tenido un promedio de 40 personas durante varios años, a menudo más que eso. Tenemos un producto bastante complejo que atraviesa varios dominios problemáticos. Cambiamos de cascada a scrum y, mirando hacia atrás, debo decir que ninguno funcionó (bien). Como me dijo un PM, nuestro proyecto estaba "siempre en amarillo o rojo" (es decir, en estado de alto riesgo o seriamente retrasado).
Watefall "funcionó" porque una vez que terminamos oficialmente con el desarrollo y pasamos a las pruebas, no muchas de las características hechas oficialmente funcionaron realmente y se realizó un desarrollo efectivo durante (largas) pruebas y se corrigió tediosamente. Se podría decir que fue una especie de cascada oficial combinada con una especie de proceso iterativo subyacente.
Cambiamos a ágil/scrum (en una forma muy básica). De la sartén al fuego: ahora tenemos problemas terribles para obtener un producto lógicamente consistente. No es extraño dado que tenemos 5 sub-equipos principales (no todos ellos en una ubicación geográfica) y la ley de Conway opera. Además, el estrés repetido al final de la iteración durante varios años tiende a desgastar/agotar a las personas (sin embargo, ese es mi sentimiento subjetivo, no tengo datos sólidos para probarlo). También ha sido terrible mantener a las personas el tiempo suficiente en un lugar/subsistema del producto para que pudieran convertirse en expertos y altamente productivos en su lugar: tengo la impresión de que en este cambio constante evolucionamos hacia ser aprendices de todos los oficios y maestros de nada. En retrospectiva, no puedo decir que scrum nos haya dado ninguna ventaja definitiva (tenemos "scrum de scrums" por supuesto y no puedo detectar que haya hecho alguna diferencia). Ciertamente, la falta de un gran diseño inicial de mi punto de vista es una falla grave: el trabajo se desincroniza, se divide mal y debe rehacerse o modificarse más tarde.
Es como un punto muerto clásico del proceso de CS, simplemente se movió al nivel conceptual/de diseño: el desarrollador/subequipo A espera a que el desarrollador/subequipo B complete el diseño X en el que confía para poder completar su diseño Y, mientras que el desarrollador/subequipo B espera A para hacer su diseño Y para que él/ella pudiera hacer X.
Scrum no dice nada sobre las tareas de infraestructura aparte de "meterlo en alguna historia de usuario" (y así la infraestructura sufre). Otros 3 equipos de subtemas más pequeños (equipo de proveedor de contenido interno, externo que usa productos de los dos anteriores) para un área en particular aún no pueden ponerse de acuerdo sobre la representación y el formato de datos comunes. El seguimiento del estado real de un millón de tareas es una pesadilla. El consenso en el equipo es que scrum no nos ha brindado beneficios al tiempo que impone costos adicionales. Ciertamente no nos ha hecho prestar más atención a lo que realmente necesitan los clientes/usuarios finales.
No puedo creer que esté diciendo esto, pero para nosotros, la cascada funcionó (ligeramente) mejor que el scrum (o para ser más precisos: "no fue tan malo, aunque solo un poco menos").
Afortunadamente, algunos subsistemas son bastante ortogonales, de lo contrario no haríamos nada. Sin embargo, esto es pura casualidad: un poco más de dependencias internas entre los subsistemas (re integridad conceptual, rendimiento, etc.) y estaríamos fritos. Ser salvado por pura suerte no es prueba de una organización efectiva o sabiduría.
Desde mi punto de vista, es así: si un proyecto es pequeño (algo asimilable por una persona en su totalidad o casi) o consta de un montón de conceptos y características casi independientes, cualquier metodología funcionará. Si un proyecto es grande (una persona ni siquiera puede asimilar un subsistema completo + hay muchas dependencias internas entre los subsistemas en conceptos, diseño, lógica comercial y algoritmos), ninguna metodología funciona.
La única solución que personalmente veo sería así:
Si eso no funciona, tengo que decir que para mí mi proyecto es como un "nudo gordiano del infierno" que es básicamente irresoluble (bueno) desde mi punto de vista.
Esta información de fondo súper larga me lleva a mi pregunta: ¿existen metodologías de PM que funcionen bien en proyectos grandes ?
Entiendo que el mapa no es el camino. Seguro. Pero no puedo imaginar llegar a Alaska desde SA sin el mapa. :-) Como dicen en matemáticas, la metodología para mí es una condición necesaria, no suficiente.
Cuestiones:
Sé que la gente rechazará mi visión diciendo que "pide piloto automático/panacea", pero tiendo a pensar que A. Whitehall tiene algo de razón cuando dijo que el progreso se mide por una serie de cosas que podemos hacer sin pensar. Una metodología perfecta encajaría en cualquier equipo: solo tenga las agallas para seguir el procedimiento. Si "otros factores", los factores desconocidos, son necesarios para que el proyecto tenga éxito, ¿cuáles son esos?
Estoy empezando a pensar que todo esto es inútil. He hecho algunos cálculos de ejemplo aproximados: Imagine: n funciones, m clases (suponiendo programación OO), k características de software (confiabilidad, rendimiento en varios contextos, seguridad, costo de implementación, tasas de defectos, tiempo necesario para realizar el desarrollo, pruebas costo, tiempo de prueba, etc), o personas. Complejidad potencial: cada característica se puede dividir en p clases (p menor que m, con la suma de todas las p para todas las características == m), afecta como máximo k características y puede requerir el trabajo o la intervención de cualquier subconjunto de o personas.
Entonces, la complejidad del peor de los casos (número de combinaciones) es n*m*k*o. con 20 características, 500 clases, 10 aspectos y 40 personas que es 4000000 (4 mil). Suponiendo un generoso tiempo de lanzamiento de 18 meses, es decir 222222 (222 mil) combinaciones por mes. Supongamos que cortamos 500 (o "m") clases en 50 colecciones manejables con cada colección modificable/refactorizable internamente sin afectar a otra colección. Eso sigue siendo más de 22 mil combinaciones por mes.
No es humanamente posible rastrear tantos impactos potenciales de característica/clase/persona en k (características del software) y seleccionar las mejores combinaciones (planificar con anticipación). Alguna herramienta de inteligencia artificial dura al estilo de la ciencia ficción tendría que hacerlo. De lo contrario, solo estamos lanzando un "avemaría": tal vez funcione lo suficientemente bien en suficientes casos como para que el proyecto no se retrase. O tal vez no lo hará.
Información general para darle una mejor idea del sistema en cuestión. Esto tiene que ser una especie de "anonimizado" por razones de confidencialidad.
Afortunadamente, este es bastante simple: agentes <-> servidor, con un servidor que consta de los siguientes subsistemas principales:
(por supuesto, hay muchos subsistemas compatibles, desde la consola de configuración del servidor hasta la interfaz de usuario web y la API REST, pero no los incluyo aquí)
Implementación
Tecnologías: C, Java, SQL. Los entornos varían de cientos a decenas de miles de agentes (el entorno más grande: alrededor de 100 000 agentes).
Tamaño del código: varios miles de archivos Java organizados en aproximadamente 500 paquetes. Aproximadamente 900 KLOC en total hasta ahora (sin contar al agente). Así que no es tan grande, pero es complejo en el sentido de que involucra muchos dominios de problemas.
La agregación es la parte más compleja e intensiva en recursos de la aplicación. Usamos SQL simple para el rendimiento, pero incluso entonces la agregación no puede finalizar en 24 horas para entornos grandes (justo cuando debería comenzar la siguiente ronda de agregación, es decir, al día siguiente). Un error de cálculo puede ser algo serio, ya que fácilmente puede costarle a un cliente decenas de millones de dólares.
Siguiendo la respuesta de Tiago, el problema no es la metodología sino cómo se adapta la metodología a sus proyectos.
Basado en mi experiencia trabajando en proyectos de biodefensa para el gobierno de los EE. UU., a medida que aumenta la complejidad de un proyecto, también lo hace su necesidad de planificación inicial y supervisión exhaustiva del proyecto. Independientemente de su uso de cascada o ágil o lo que sea:
Preguntar si hay una metodología que funcione bien para un proyecto grande suena como preguntar si una ruta de mapa puede llevar a alguien desde América del Sur hasta Alaska.
¿Hay alguna (metodología o mapa)? Sí. ¿Lo hará (trabajar o viajar) por sí mismo? Definitivamente no.
Una metodología es una guía. Pero, como el mapa, son solo sugerencias de cómo llegar a algo o algún lugar, no el destino en sí.
Mencionaste Waterfall x Agile. Hay una muy buena discusión sobre este tema AQUÍ , y creo que la respuesta de Pawel es increíble (¡como siempre!). En su caso, como un gran proyecto, parece que una metodología más formal encajaría mejor (es decir, Waterfall), pero no hay una regla estricta que diga eso.
En resumen: el problema no es el mapa . El problema no es la metodología . Habiendo dicho eso, la pregunta subyacente aquí es:
¿Cuál es el problema número uno de su proyecto? O, ¿por qué tus proyectos siempre están entre ámbar/rojo?
Deberá determinar la causa raíz de los problemas de su proyecto y luego podrá evaluar cuál es la mejor metodología para adaptarse a su proyecto. No al revés.
En los comentarios, el OP elaboró sobre el entorno de su proyecto. Él dijo:
[E]l principal problema con nuestro proyecto no es que sea grande en KLOC/FP o "complejo"... El problema es que el proyecto se parece más a un "tazón de clips" que a un montón de características independientes: no puede tocar ninguna característica o problema sin afectar la mayoría de los otros aspectos, subsistemas y problemas.
Tal como lo entiendo, el problema es que las tareas, los hitos, las características y los objetivos del proyecto son tan interdependientes que cualquier cambio o desviación requiere una refactorización de todo el plan y/o cronograma del proyecto.
Entonces, este es un problema X/Y porque:
Según mi comprensión de la causa raíz, recomendaría refactorizar el plan del proyecto en lugar de rediseñar el proceso de gestión del proyecto. Específicamente:
También podría considerar tratar las fuertes dependencias entre tareas como riesgo del proyecto. Documente el riesgo de manera adecuada, informe los riesgos a la alta gerencia y permítales aceptar el riesgo o autorizar las medidas necesarias de mitigación de riesgos.
Por último, si todo lo demás falla, establezca un punto de referencia para cuando el proyecto esté tan fuera de la tolerancia que se deba recomendar su finalización. Si bien el rol del gerente de proyecto no suele ser el de autorizar la desconexión, ciertamente está dentro de su alcance identificar los límites de riesgo y gastos de capital que la organización está dispuesta a tolerar. Una vez que se conoce esa información, puede administrar esa métrica y recomendar una terminación anticipada oportuna (si la falla es inevitable) para ahorrar dinero a la empresa.
Waterfall se utiliza con éxito en los proyectos más grandes del mundo, por ejemplo, 500 personas durante 6 años a un costo de $ 21 mil millones. Estos son en su mayoría proyectos de infraestructura (puentes, túneles y ferrocarriles), proyectos aeroespaciales y de defensa (aviones y sistemas de armas) y proyectos de energía (oleoductos, plataformas de perforación)
No es la metodología la que falla, sino la implementación y las "vibras" del entorno del proyecto. Para ver un ejemplo de "vibraciones" en el entorno del proyecto, acabo de regresar de un taller que estudió el desarrollo de 3.300 millones de dólares del avión de combate FA-18 Hornet. Uno de los factores críticos de éxito mencionados en el proyecto fue crear una atmósfera de confianza y un flujo de datos precisos en el proyecto.
Necesita mirar la organización, el liderazgo y el entorno del proyecto. Esto no es un problema de metodología.
david espina
Tiago Cardoso
Todd A. Jacobs
mrkafk
mrkafk
Tiago Cardoso
mrkafk
mrkafk
Tiago Cardoso