Historia del método en cascada
El modelo en cascada es un patrón lógico a seguir: planificar, crear, probar y lanzar en secuencia. La historia del modelo en cascada proviene del artículo de Winston W. Royce de 1970 del Acta de IEEE WESCON, que gestiona el desarrollo de grandes sistemas de software. El artículo de Royce probablemente fue la primera conversación sobre el método en cascada en el desarrollo de software, aunque la palabra "cascada" no aparece en ningún lugar del artículo. El término formal se introdujo en Tom E. Bell y T.A. El artículo de Thayer de 1976 de las Actas de la 2.ª Conferencia Internacional sobre Ingeniería de Software, Requisitos de software: ¿Realmente son un problema? Sin embargo, como se ha observado en muchos lugares, el papel de Royce no alababa el método. De hecho, lo describió en términos poco detallados, lo que lo llamó deficiente e invitaba al fracaso de muchas maneras. Continuó discutiendo un enfoque más iterativo, tal vez la base de lo que se convertiría en un enfoque Agile.
El artículo de Bell y Thayer discute un cambio en el enfoque de abajo hacia arriba a un top-down en el desarrollo de requisitos de software, haciendo referencia a la adopción de este enfoque en MIL STD 490/483 (MIL STD 490 discute las prácticas de especificaciones y MIL STD 483 discute las prácticas de gestión de configuración para sistemas). El papel se ocupa principalmente de examinar los enfoques empíricamente para determinar qué funciona mejor. En última instancia, el artículo declara que "en los últimos diez años se ha adoptado más estructura y disciplina, y los profesionales han completado que un enfoque descendente es superior al enfoque ascendente del pasado". El término "cascada" se utiliza en referencia directa al papel de Winston Royce.
A pesar de los defectos descritos por Royce, el método en cascada se convirtió en un método preferido en 1985 cuando el Departamento de Defensa emite el DOD-STD-2167A, el desarrollo de sistemas de defensa. Describió el ciclo de desarrollo de software a continuación:
- Análisis de requisitos de software
- Diseño preliminar
- Diseño detallado
- Codificación y pruebas unitarias
- Componente de software informático (CSC) Integración y pruebas
- Pruebas de CSCI
El futuro afirma que "este estándar está destinado a ser dinámico y receptivo al campo de la tecnología de software que evoluciona rápidamente. Como tal, este estándar debe aplicarse selectivamente y adaptarse a las características únicas de cada programa de adquisición de software". Sin embargo, el requisito se estableció en blanco y negro y se siguió religiosamente.
El método en cascada comenzó a desaparecer de un uso popular cuando los líderes de la industria se frustraron con su inflexibilidad y desarrollaron el Manifiesto Agile. Desde entonces, cada vez más empresas han adoptado Agile, pero muchas empresas todavía se aferran a Waterfall, y por una buena razón. El método en cascada tiene sus fallas, pero también tiene sus beneficios y en el entorno adecuado, puede ser la mejor práctica.
Project Management Guide
Your one-stop shop for everything project management
Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.
Beneficios de la gestión de proyectos en cascada
Para todas las críticas del modelo en cascada, hay algunos beneficios reales para su implementación:
- Es un enfoque sencillo y sencillo.
- Es fácil desarrollar un plan para gestionar un proyecto en cascada, ya que cada fase tiene un inicio y finalización, y sabe antes de codificar lo que se debe desarrollar, cuándo se debe desarrollar, cuándo se debe realizar las pruebas, etc.
- La planificación temprana proporciona una buena base para diseñar componentes que se integren con los sistemas externos.
- Es fácil planificar los recursos para el modelo en cascada porque, de nuevo, usted sabe cuándo todo debe comenzar y terminar.
- Los clientes que quieren fechas de inicio y finalización definitivas pueden encontrar un método en cascada en cascada. Se puede decir a los clientes la fecha en que tendrán un producto en sus manos y, si el proyecto es adecuado para un enfoque en cascada, se entrega en esa fecha.
- El costo del desarrollo se puede determinar con anticipación.
- Los procedimientos detallados se pueden usar para regular todas las partes del proceso.
- El enfoque pesado del diseño del modelo en cascada obliga a un enfoque disciplinado al desarrollo y deja claras las expectativas.
- Los miembros del equipo pueden participar en otros proyectos antes de que comience o después de que finalice su fase, volviendo al proyecto según sea necesario.
- La dependencia de la documentación de diseño reduce el estrés de la rotación de desarrolladores.
- El enfoque de diseño pesado significa que los errores se pueden detectar en la fase de diseño. Hay obstáculos obvios para esto y cualquier persona que ha trabajado con el método en cascada sabe que se producen errores de diseño, pero tome un equipo experimentado y reúna un plan y a menudo obtendrá un diseño sólido que se puede ejecutar según el plan.
Inconvenientes de la gestión de proyectos en cascada
A continuación, le mostramos algunas de las principales preocupaciones y críticas del modelo en cascada:
- El tiempo para lanzar es excepcionalmente extenso para proyectos grandes. El papel de Royce era amable con el método en cascada cuando se trata de proyectos pequeños e internos, pero le resultaba bastante deficiente para proyectos más grandes y complejos. De hecho, probablemente esta es la razón principal por la que Agile se ha vuelto tan popular. Los proyectos que eran demasiado grandes se cancelaron antes de poder llegar a la finalización a través del método en cascada.
- La segunda crítica líder del modelo en cascada es que el cambio no es bienvenido. Una vez que comienzan las pruebas, es extremadamente costoso volver al desarrollo o rediseñar el proyecto. El diseño debe estar cuidadoso y escrito correctamente antes de ir demasiado lejos.
- El software funcional no aparece hasta finales del proyecto.
- Los errores escritos al principio del proyecto pueden crear grandes dolores de cabeza para el código posterior, pero nada de eso se hace evidente hasta que comienzan las pruebas, lo que hace que la reparación del código sea costosa y lleve mucho tiempo.
- No es un enfoque orientado a objetos. Los proyectos en cascada son altamente integrados. Este es otro aspecto del modelo en cascada que reduce la flexibilidad.
- No es un buen método para el mantenimiento y otros tipos de proyectos a largo plazo.
- La mano con las críticas anteriores es el hecho de que los clientes a menudo no saben lo que quieren antes de que comience el proyecto.
- Si el equipo es inexperto o entra en aguas inexploradas, aparecen obstáculos que crean peligro para el proyecto.
- Las pruebas pueden cambiarse de corto plazo para mantenerse dentro del cronograma, lo que deja que los errores se descubran por el cliente después de que se entregue el producto.
- Los eventos pueden obligar a desechar todo el proyecto. Por ejemplo, los cambios en la industria que se producen durante la fase de desarrollo podrían hacer que todo el proyecto quede obsoleto. Otro evento puede ser el descubrimiento de un defecto de diseño tan grave que todo el proyecto tiene que volver atrás para el rediseño, lo que puede ser tan costoso que el cliente rechaza el proyecto.
Comparar el método en cascada con Agile
El método en cascada se centra en la fase de diseño de un proyecto, mientras que Agile implica un tiempo mínimo en el diseño. Ambas opciones de gestión de proyectos tienen como objetivo entregar software funcional, pero los proyectos en cascada suelen entregar una publicación una o dos veces al año (o incluso menos a menudo) mientras que Agile puede entregar software funcional con frecuencia como una vez a la semana. Las entregas en cascada pueden ser grandes y requieren un largo período de pruebas y muchas empresas también utilizan clientes para proporcionar pruebas Beta. El software Agile prueba el software a medida que se construye y el desarrollador a menudo realiza las pruebas.
Una diferencia significativa entre el método en cascada y Agile es que la cascada es una metodología, pero Agile es un "movimiento" con una variedad de métodos derivados que aplican los principios y valores de Agile. Scrum, eXtreme Programming (XP), Kanban, Scrumban y una serie de otros métodos permiten las opciones del equipo de desarrollo, por lo que puede haber una mejor opción entre ellos.
Una metodología Agile es una opción superior cuando el cliente no tiene claro los requisitos o quiere participar de cerca en el proceso de desarrollo, y si los plazos son cortos y quieren una entrega rápida. El método en cascada es superior si hay dependencias complejas, pero Agile es preferible cuando las dependencias son mínimas. Agile también es mejor si la velocidad es más importante que la calidad.
Algunos inconvenientes de Agile son los siguientes:
- Requiere participación de los clientes
- Los costos y los cronogramas son inciertos
- La planificación es difícil
- Falta de claridad sobre el resultado final
- Documentación mínima
- Los miembros del equipo deben ser multifuncionales, algunos de los cuales no tienen experiencia en roles desconocidos.
- Los desarrolladores se dedican a un solo proyecto
- La corrupción del alcance es un riesgo: a medida que un proyecto da la bienvenida al cambio, puede crecer fuera de control y pasar su fecha de vencimiento.
La idea de que Agile es una desviación drástica del método en cascada no es en su totalidad verdadera. El enfoque Agile es realmente más un enfoque en cascada ajustado, un intento de abordar algunos de los inconvenientes del método en cascada en términos de resistencia a los cambios y las fechas de entrega prolongadas. La falta de flexibilidad y una alta tasa de proyectos cancelados ha causado que muchos equipos cambien del método en cascada a Agile. Sin embargo, es importante entender que Agile sigue teniendo un enfoque secuencial: solo utiliza una secuencial más corta. Agile todavía incluye algunos análisis y diseño de requisitos al principio, pero la codificación no comienza hasta que los requisitos y el diseño se completan, y no puede probar el código que no se ha escrito o entregar código que no se ha probado e integrado. Por lo tanto, Agile puede considerarse una forma más flexible y rápida de gestión de proyectos en cascada.
Consejos y prácticas recomendadas para su próximo proyecto utilizando la metodología Agile.
Descubra todo lo que hay que saber sobre la gestión de proyectos Agile y consejos que le permitirán empezar a implementar las mejores prácticas de Agile PM.
Obtenga el libro electrónico gratuito para implementar las mejores prácticas de Agile
Cuándo usar el método en cascada para la gestión de proyectos
Decidir entre el método en cascada y Agile se reduce al examen de las características del proyecto y las necesidades del cliente. En particular, preste atención a los requisitos, la meta y el objetivo del proyecto. El método en cascada suele ser una mejor opción cuando:
- Los requisitos se comprenden bien y no es probable que cambien.
- El cliente no es propenso a exigir cambios.
- El cliente prefiere no involucrarse en el desarrollo, pero quiere que se le consulte al principio y recibir un paquete de trabajo al final del proyecto. Agile funciona mejor cuando el cliente está involucrado en todas las fases (revisar el producto en cada iteración), pero los clientes en cascada solo necesitan recibir una publicación e instalarlo. (Nota: esto es una simplificación. Los clientes también deben educarse en el uso del sistema y que pueden ser un paso extenso e importante. Esto es lo mismo independientemente del método utilizado, y puede ser que educar a los usuarios una o dos veces al año en funciones nuevas para una publicación más grande es menos molesto que educar a un cliente mensual o incluso semanal en un conjunto más pequeño de funciones. Además, tenga en cuenta que los clientes que quieran participar pueden participar en un proyecto basado en cascadas. Hacer que el cliente reciba revisiones frecuentes puede distraer y puede generar solicitudes de cambio no deseadas, pero también puede mantener el proyecto enfocado en satisfacer las necesidades del cliente).
- El proyecto es pequeño.
- La velocidad de entrega no es importante.
- La entrega se debe aplicar a un sistema heredado que no sea propenso a cambiar.
- Tendrá proyectos similares en el futuro, lo que permitirá la reutilización del plan del proyecto y podrá extraer lecciones de la documentación pesada del proyecto anterior.
Una breve mirada a las principales metodologías de gestión de proyectos
La metodología en cascada es solo una de las muchas metodologías que compiten entre sí. Al tomar la decisión de implementar uno o otro, ayuda a tener una idea de lo que son. Lo siguiente es un breve vistazo a las principales metodologías de gestión de proyectos que se utilizan actualmente.
En cascada
La metodología en cascada generalmente se considera un enfoque tradicional de la gestión de proyectos. El método en cascada se basaba en la noción de todo lo que ocurre en secuencia, con una fase de un proyecto que termina antes de otro comienzo. Esto creó muchas dependencias y también dio lugar a algunas situaciones bastante desastrosas para el desarrollo de software. Los proyectos a menudo estaban atrasados y por encima del presupuesto, y en algunos casos se cancelaban por completo cuando la tecnología cambiaba demasiado rápido.
El método de ruta crítica (CPM)
El método CPM es otro método secuencial que asume que cada paso depende de la finalización del paso anterior. La fase de planificación de un proyecto de CPM consiste más en identificar las partes más intensivos de recursos del proyecto para asignar recursos y evitar cuellos de botella. La aplicación del método se realiza mediante lo siguiente:
- Identificar las tareas necesarias y definir la secuencia para completarlas.
- Definir las dependencias para las tareas necesarias.
- Determinar las relaciones que son y no son críticas entre las tareas.
- Programar el cronograma esperado para cada tarea.
- Desarrollar un plan B para rutas críticas.
El método en cascada de gestión de proyectos de cadena crítica (CCPM)
se centra en el diseño y el CPM en las tareas, pero CCPM se centra en los recursos y la asignación de recursos. CCPM se centra en los factores que pueden afectar los cronogramas, los costos, el rendimiento y el riesgo de la entrega inferior. El enfoque de CCPM es definir la cadena crítica, aplicar recursos que puedan hacer lo más bueno y, por último, introducir márgenes de tiempo a las tareas críticas para garantizar la entrega oportuna si surgen problemas.
Guía PMI PMBOK® Guía
El método de guía PMIBOK® de gestión de proyectos aplica los cinco grupos de procesos del PMI desde el texto, Una guía para el cuerpo de conocimiento de gestión de proyectos. A continuación, le mostramos una descripción general de alto nivel de estos grupos:
- Iniciar: Establezca la visión. También es el grupo de procesos en el que se selecciona el gerente de proyectos.
- Planificación: Establezca el alcance. El PMBOK describe 24 procesos en la etapa de planificación.
- Ejecución: Ponga en marcha el plan.
- Monitoreo y Control: Esto se produce durante todo el proyecto y no es una fase secuencial que espera a que finalice otra fase.
- Cierre: Se produce cuando el cliente acepta el proyecto.
Las metodologías Agile se definen como un movimiento, no una metodología, pero se han desarrollado una familia de metodologías Agile en acuerdo con los valores y principios de Agile.
Scrum
El método Scrum tiene un pequeño equipo Agile encabezado por un Scrum Master. El papel del Scrum Master es facilitar el trabajo del equipo. La planificación es mínima y se crea una lista de las tareas en las que se debe trabajar. Las tareas se trabajan en "Sprints", que suelen ser de dos a cuatro semanas. Se realizan reuniones diarias breves (llamadas Daily Scrums) para repasar las tareas del día e identificar obstáculos. Los miembros del equipo realizan todas las tareas tradicionales de un proyecto, diseñando sobre la marcha y probando a medida que completan una tarea. El objetivo del Scrum es entregar un software de trabajo. Cuando finaliza un Sprint, el siguiente comienza, con el equipo dibujando un conjunto de tareas del backlog del proyecto. Cuando se han cumplido los objetivos generales del proyecto y no hay más tareas, el proyecto está completo.
Kanban
El método Kanban es el más adecuado para proyectos de mantenimiento. El núcleo del método Kanban es el tablero Kanban, una lista de todas las tareas (también llamadas tarjetas Kanban) que se realizan continuamente y que son fácilmente visibles para todos los miembros del equipo. Cuando se dispone de un recurso (miembro del equipo), ese miembro del equipo toma una tarea del tablero y trabaja en él. Las tareas se agregan al tablero y se trabajan continuamente. No existe un principio o finalización definido para el proyecto.
Los sprints de programación extrema (XP)
Los sprints suelen durar una semana con muchas iteraciones. En XP, el cambio es la clave y los programadores XP trabajan en estrecha colaboración con las partes interesadas. XP es ideal para entornos en los que los requisitos están cambiando constantemente. Las tareas pueden sustituirse a mitad del Sprint.
El Marco de proyecto adaptativo (APF)
APF asume que los proyectos de TI varían tan ampliamente, que ningún enfoque tiene sentido. Los proyectos de TI difieren en riesgo, costo, longitud y complejidad y a menudo involucran incertidumbre en el mercado, valor empresarial, participación y objetivos del cliente. Por lo tanto, un proyecto APF comienza con el análisis de los requisitos para definir los objetivos estratégicos. El proyecto se ejecuta de forma iterativa y tras las iteraciones se realizan autoevaluaciones para mejorar el proceso. El análisis suele ser continuo, para que todo el proyecto se pueda redefinir o adaptar a medida que avanza en respuesta a los problemas de incertidumbre para mantener o aumentar el valor del negocio.
Lean
Lean está destinado a reducir el desperdicio y maximizar el valor. Los valores básicos de Lean son una mejora incremental continua y el respeto a las personas. Lean se centra en ofrecer el mayor valor al cliente, mantener el flujo, asignar el trabajo incluso y, en la mayoría de los casos, eliminar el desperdicio.
Six Sigma
Six Sigma consiste en eliminar los defectos en el desarrollo a través de procesos eficientes y mejora continua de los procesos. Una calificación de Six Sigma significa que el producto está 99.99966% libre de defectos. Cuando tiene un proceso con una calificación Six Sigma, significa que se puede esperar que cada producto entregado a través de esos productos logre el mismo resultado.
Lean Six Sigma
Lean Six Sigma intenta combinar los enfoques Lean y Six Sigma, eliminando el desperdicio para hacer que los procesos sean más eficientes y ofrecer un alto valor y bajos defectos al cliente.
Gestión de proyectos basada en procesos
En la gestión de proyectos basada en procesos, la atención se centra en alinear cada proyecto con la misión y los valores corporativos. Los proyectos se subsumen en la estrategia corporativa. Por lo tanto, se utilizan aspectos tradicionales del análisis de proyectos, como métricas, para determinar qué tan estrechamente se cumple ese objetivo.
PRINCE2
El método PRINCE2 se basa en el método PRINCE menos exitoso. El MÉTODO PRINCE no fue ampliamente adoptado porque era demasiado engorroso y fue revisado en 1996 en PRINCE2 por un comité compuesto por 150 organizaciones europeas. Si bien PRINCE estaba destinado a reducir el costo y los excesos de tiempo de TI, también se desarrolló como una metodología de gestión de proyectos para cualquier tipo de proyecto. PRINCE2 publicó una revisión importante en 2009, que hizo que el método sea más sencillo e introdujo siete principios básicos del éxito del proyecto.
La integración de métodos sostenibles (PRiSM)
PRiSM se centra en la gestión socialmente responsable de proyectos. Su intención es gestionar proyectos y reducir los impactos negativos en el medioambiente y promover proyectos socialmente beneficiosos.
La realización de beneficios
El método de realización de beneficios gira en torno al cliente. Desde el principio hasta el final, el método busca garantizar que el cliente obtenga el máximo beneficio de la entrega anterior y más allá del costo y el cronograma.
Muchos métodos de gestión de proyectos son iguales a muchas oportunidades
Hay muchos métodos en el mundo de la gestión de proyectos. La mayoría de las personas han crecido en torno a nuevos enfoques y necesidades variables que solo se han vuelto evidentes a medida que la industria de software se volvió más compleja (variedad de métodos y lenguajes) y también más fácil (mayor facilidad de redacción de código). Sin embargo, los antiguos métodos de gestión de proyectos siguen manteniendo su valor en los entornos adecuados, tal como lo demuestran las empresas que siguen desarrollando proyectos en el método en cascada. Muchos clientes todavía quieren saber cuánto costará y cuándo se hará antes de aceptar el desarrollo, y también quieren saber qué habrá en él. Sin esa información vital, ¿cómo sabría si la entrega tiene algún valor comercial?
Por qué Smartsheet es una herramienta poderosa para la gestión de proyectos en cascada
De la administración básica de tareas y de proyectos hasta la administración compleja de recursos y portafolios, Smartsheet lo ayuda a mejorar la colaboración y acelerar el trabajo. Esto lo empodera para lograr más. La plataforma Smartsheet facilita la planificación, la captura, la gestión y la creación de informes sobre el trabajo, desde cualquier lugar, lo que ayuda a su equipo a ser más eficiente y lograr más. Cree informes sobre las métricas clave y obtenga visibilidad en tiempo real acerca de trabajo gracias a informes, paneles y flujos de trabajo automatizados diseñados para ayudar a su equipo a mantenerse conectado e informado. Cuando los equipos tienen claridad sobre el trabajo en curso, pueden lograr mucho más en menos tiempo. Pruebe Smartsheet gratis hoy mismo.