Que tal, el dia de hoy daremos respuesta a la pregunta:

¿Cuál es la mejor manera de planear y ejecutar un proyecto grande de software?

imagen de : https://www.codejobs.biz

Yo consideraría los siguientes aspectos:

El ratio o tasa de fracaso de los proyectos crece exponencialmente con el tamaño de los mismos. Por poner un ejemplo, en empresas grandes solo el 9% de los proyectos son exitosos. No es únicamente por el tamaño del software sino por la cantidad de personas, criterios y decisiones que participan.
En el Chaos Report se establecen los factores de éxito de los proyectos obtenidos en la encuesta, mismos que te pueden servir de guía:

Adoptar prácticas formales de gestión de proyectos (como las del PMI) te pueden ayudar con la mayoría de los factores enunciados. Dale mucha importancia a la gestión de los riesgos, lo que te permitirá ser proactivo y no reactivo. También a la gestión de la calidad, porque hasta el 65% del costo del proyecto se puede ir en pruebas y corrección de defectos

Tendrás el problema de estimar el tiempo y el costo, lo cual no es posible si no se conoce el tamaño y para esto requieres conocer la totalidad de los requerimientos. En mi opinión conviene invertir al inicio del proyecto en el entendimiento de todos los requerimientos (aunque cambien más adelante) ya que esto nos permitirá hacer estimaciones (usando Puntos de Función), conocer más a fondo a los usuarios y sus expectativas, identificar riesgos y planificar mejor el proyecto. Estos requerimientos se pueden establecer como línea de partida (baseline) junto con un proceso de gestión de cambios que facilitará incorporar cambios de manera ordenada

Una estrategia que te conviene definitivamente es desarrollar el proyecto de manera iterativa e incremental. De ninguna manera uses el ciclo de vida de cascada. Scrum puede servir para guiar el ciclo de vida pero es complicado adaptarlo para proyectos muy grandes (no imposible pero toma tiempo en la organización) . En todo caso, apóyate en un Scrum master

Prototipos utilizados para reducir el riesgo técnico. Por ejemplo, si va a utilizar tecnología que no se ha probado antes en la organización puedes establecer actividades para hacer pruebas técnicas desde el principio del proyecto e ir reduciendo los riesgos (y establecer alternativas si no funciona)
Prototipos de interfaz para reducir el riesgo con el usuario. Existen muchas herramientas que te permiten hacer maquetas del sistema sin necesidad de programar y esto te permite reducir el riesgo de que el usuario vea algo que ya ha sido codificado y no le guste
Prototipos de interfaz con otros sistemas o librerías. Hacerlo al inicio te permite asegurar que la conexión con otros sistemas o librerías externas funciona adecuadamente

Definir la Arquitectura de alto nivel del software, esto es, los mecanismos y componentes del más alto nivel. Esto es mejor hacerlo al inicio

Busca a los mejores programadores que puedas pagar, procúrales lo que necesitan (silencio, no interrupciones, cubículos privados, computadoras/ordenadores potentes con pantallas grandes y doble monitor) y déjalos trabajar . Minimiza las reuniones y maximiza la comunicación asíncrona con ellos. El avance y los problemas que enfrentan se pueden informar vía correo o a través de un software. Las únicas reuniones presenciales (obligatorias) son para que entiendan los requerimientos