Gestión de proyectos en cascada : hoy en día, la mayoría de los equipos de TI buscan adoptar sistemas de gestión de proyectos ágiles. Pero lo que terminan haciendo es adoptar sistemas ágiles de gestión de proyectos para sus proyectos. Esto significa una combinación de sistemas de gestión de proyectos tradicionales (llamados Sistemas de gestión de proyectos en cascada), combinados con los Principios de gestión ágil, como se detalla en el Manifiesto Ágil original.
A medida que más proyectos en todo el mundo incorporan prácticas de gestión de proyectos ágiles, ¿eso significa el final de la gestión de proyectos en cascada? ¿Acabarán todos los proyectos de TI siendo Agile Project Management?
Para comprender los diferentes modelos, incluido Agile, y utilizar el que mejor se adapte a su situación, es importante comprender primero de qué se trata el sistema tradicional de gestión de proyectos, llamado Modelo de gestión de proyectos en cascada.
El modelo de gestión de proyectos de Waterfall, llamado así por la naturaleza del proceso de flujo de trabajo, se caracteriza por lo siguiente:
- El producto final se visualiza primero con gran detalle.
- Luego, las etapas del flujo de trabajo se implementan en secuencia:
- Requerimientos y análisis
- Diseño
- Implementación
- Pruebas
- Instalación
- Mantenimiento
- El plan del proyecto debe ser infalible porque una vez que se completa una etapa de la secuencia, los desarrolladores no pueden volver a visitar el mismo sin comenzar nuevamente la planificación.
- Hay poco margen para cambios o errores y el plan del proyecto debe seguirse diligentemente.
Origen del modelo de gestión de proyectos en cascada:
En las primeras etapas de la industria de TI, no existía un modelo específico para el desarrollo de software.
Entonces, la industria adoptó el modelo de flujo de trabajo secuencial utilizado en las industrias de fabricación y construcción. Estas industrias tenían etapas de trabajo bien definidas y habían desarrollado un modelo que satisfacía su necesidad de un estricto control de costos. Entonces, el modelo de la industria del hardware se aplicó a la industria del software.
Winston W Royce presentó este modelo por primera vez en 1970, pero no utilizó el término "Gestión de proyectos en cascada". De hecho, presentó el modelo como defectuoso. La representación pictórica del modelo parecía una cascada en cascada. Thomas E. Bell y TA Thayer luego usaron el término "cascada" en su artículo de 1976, "Requisitos de software: ¿son realmente un problema?" Y el término llegó para quedarse.
Hay una serie de variantes de este modelo. Las seis fases distintas comúnmente utilizadas en el Modelo de gestión del proyecto Cascada se explican a continuación. Sin embargo, dependiendo del proyecto, se pueden combinar dos etapas juntas.
Consideremos el ejemplo de construir una escuela como un ejemplo para comprender mejor el modelo de gestión de proyectos en cascada.
-
Requisitos y fase de análisis:
Primero, tenemos que saber exactamente lo que estamos diseñando. Para esto, podríamos querer:
- Llevar a cabo discusiones detalladas con el cliente.
- Intente visualizar claramente el producto con sus detalles más mínimos.
- Analice qué componentes de hardware y software son necesarios
- Enumere los detalles que incluyen: el problema que el producto debe resolver, las restricciones del cliente, el nivel de rendimiento y la compatibilidad con los sistemas ya existentes.
- Realizar estudios de caso de un producto similar.
- Considere los requisitos de cada parte interesada
- Enumere las especificaciones en el Documento de requisitos del producto, que forma la entrada para el siguiente paso.
En nuestro ejemplo de construcción de una escuela, en este paso, enumeramos el número de aulas, el material que se utilizará para construir, las personas requeridas, la infraestructura ya existente. Además, anotaríamos lo que requiere la administración de la escuela (sala de oficina, sala de personal) y lo que requieren los estudiantes (mejores baños, áreas de juego)
-
Diseño:
En la etapa de diseño, todo lo que se ha visualizado en la primera etapa se convierte en un plano.
En proyectos de TI, esto consiste en definir:
- El hardware que se usará
- La plataforma de software que se utilizará, incluida la implementación local o en la nube
- La arquitectura del software, incluidos los diferentes componentes y módulos que se crearán.
- Entradas requeridas para que el proyecto funcione con éxito
- Salidas que pueden esperarse (idealmente, esto se sincronizará con los Requisitos detallados en la etapa anterior)
Hay dos tipos de diseño que entran en juego en un proyecto de software:
- Diseño lógico
- Diseño fisico
Diseño lógico:
Esto incluye los datos básicos y los procesos que se incluirán en el proyecto. Detalla el diseño de formularios e informes, el diseño de la interfaz y el diseño de la base de datos. Por ejemplo, para un sitio web de venta de boletos de tren, este diseño determinará cómo funcionará todo el proceso: la pantalla en la que el viajero ingresa sus detalles y cómo esos datos fluirán a la base de datos, y también qué tipo de base de datos almacenará estos detalles.
Diseño fisico:
Esto tiene que ver con el diseño de la base de datos física, los programas y procesos y los sistemas distribuidos. Esto se realiza después del diseño lógico e incluirá "cómo" se realizará el proyecto: el hardware, la plataforma en la que se desarrollará, las diversas bases de datos, pantallas y formularios que se utilizarán, etc.
-
Implementación:
- Aquí es donde tiene lugar el desarrollo real del software / sistema.
- La entrada para esta etapa son las especificaciones de diseño proporcionadas por la etapa anterior.
- El resultado es uno o más de los componentes del producto creados según las especificaciones, depurados, probados e integrados para satisfacer la arquitectura del sistema.
- Por lo general, esta etapa es atendida por el equipo de desarrollo que consiste en programadores, diseñadores de interfaces y otros especialistas y las herramientas utilizadas son compiladores, depuradores, intérpretes y editores de medios.
- Esta etapa generalmente toma el tiempo máximo y es importante realizar un seguimiento diligente de los procesos y el diseño. Los cambios en el diseño en esta etapa son difíciles en la gestión de proyectos en cascada.
- Para un proyecto grande que involucra varios equipos, se recomienda el control de versiones para realizar un seguimiento de los cambios en el árbol de códigos y volver a las instantáneas anteriores para el manejo de errores.
- En nuestro ejemplo: la construcción real del edificio utilizando mano de obra y materiales se realiza en esta etapa.
-
Pruebas:
Se pueden realizar pruebas para el producto en su conjunto o para componentes individuales. Los "casos de prueba" se pueden verificar para ver si el producto puede entregar lo prometido. Puede haber pruebas de módulos, pruebas del sistema del producto integrado y pruebas de aceptación. La prueba de aceptación implica probar el producto para detectar lagunas por el usuario final o el cliente. Los defectos se anotan para que el equipo de implementación los corrija. Una vez que se realizan las correcciones, se prepara una documentación formal del producto.
En el ejemplo, se prueba la infraestructura de la escuela, probablemente por un equipo de auditoría. En algunos casos, los maestros están invitados a entrar y usar las instalaciones para proporcionar comentarios.
-
Instalación:
Una vez que se completa la prueba del producto en todos los aspectos, el producto puede lanzarse al mercado o instalarse en las instalaciones del cliente. En esta etapa, también se entrega la documentación completa del producto.
En el caso de nuestra escuela, se inaugura formalmente (¡de preferencia por un pez gordo!) Y la escuela comienza sus operaciones.
-
Mantenimiento:
En esta etapa, el equipo de TI soluciona cualquier problema que pueda surgir una vez que el cliente realmente comienza a usar el producto, o cuando hay una mejora del producto. La buena documentación es la columna vertebral del mantenimiento. Los problemas se corrigen modificando códigos, llamados "parches".
Si se requieren cambios importantes, el proyecto puede volver al equipo de desarrollo como un nuevo proyecto.
En nuestro ejemplo, la escuela necesita mantenimiento regular, principalmente infraestructura, por ejemplo, cableado eléctrico defectuoso o baños con fugas. Estos problemas deben abordarse de vez en cuando.
Como puede ver a estas alturas, las etapas en la gestión de proyectos de desarrollo en cascada son distintas, y aunque generalmente hay una interacción constante con el cliente, es principalmente para discutir el progreso del proyecto, no el diseño o los requisitos. Sin embargo, el modelo de gestión de proyectos en cascada había servido adecuadamente a la industria de TI durante muchos años, y para la mayoría de los proyectos, las etapas siguen siendo buenas, aunque no tan rígidas.
Sin embargo, hay varios proyectos para los cuales el Modelo de gestión de proyectos de Cascada es muy adecuado.
¿A qué tipo de proyecto se adapta la gestión de proyectos en cascada?
Definicion de Producto:
Primero, el resultado final (producto) debe ser capaz de estar bien definido desde el principio. Los proyectos en los que el propietario del producto no esté muy seguro acerca de las especificaciones exactas del producto deseado pueden seguir las prácticas de Agile Management.
Documentación:
El proyecto debe ser uno que pueda documentarse. La documentación es un requisito importante del Modelo de gestión del proyecto Cascada. Los requisitos del producto, el diseño y el código fuente deben documentarse claramente en todas las etapas. Si los miembros originales del equipo renuncian, esto forma la guía para la continuidad del proyecto.
Tiempo y recursos:
No debe haber urgencia inmediata para liberar el producto. Los plazos se establecen al comienzo del proyecto y el equipo debe poder cumplirlos. Además, debe haber amplios recursos disponibles en términos de mano de obra y tecnología.
Riesgo e incertidumbre:
Waterfall Project Management Tools no funciona bien en un entorno de riesgo e incertidumbre. Por ejemplo, la aplicación móvil es un tipo de producto que enfrenta incertidumbre constante en términos de aceptación del cliente y competencia de aplicaciones similares.
Etapas claramente definidas:
Las etapas del sistema deben estar bien definidas, ya que deben completarse en secuencia y no puede haber superposición.
Cuando se crea una nueva versión del software existente.
Fuera del dominio de TI, el modelo de gestión de proyectos de Waterfall se ha utilizado con éxito en grandes proyectos como
- Construcción de aviones
- Proyectos de infraestructura como puentes.
- Fabricación de equipos de defensa.
- Sistemas de salud en hospitales.
En proyectos de TI, Waterfall Project Management es especialmente adecuado para aquellos proyectos en los que se requiere hardware externo. Las especificaciones de esto no se pueden cambiar a mitad de camino, ya que esto provocaría la pérdida de millones de dólares.
Cuando las deficiencias en la gestión de proyectos en cascada se hicieron evidentes en la industria del software, se pensó mucho en cómo los equipos de TI pueden ofrecer el máximo valor a los clientes al tiempo que garantizan la flexibilidad en el proceso del flujo de trabajo.
Y así, nació el Sistema de gestión de proyectos ágil, que ahora está siendo adoptado por la mayoría de las compañías de software.
Gestión de proyectos en cascada frente a sistemas ágiles:
El sistema Agile Project Management es un modelo flexible que se hizo popular en la década de 1990. Implica dividir el proyecto en "mini proyectos" llamados sprints y trabajar de forma independiente en cada uno de ellos. Este tipo de modelo permite a los desarrolladores incorporar los cambios necesarios más rápido y es muy efectivo cuando el entorno del cliente es variable.
Los aspectos positivos de los pasos de la gestión de proyectos en cascada son:
- Dado que el producto final es conocido en su totalidad, la planificación y el diseño son inequívocos.
- Los posibles problemas que podrían surgir en el proyecto se pueden resolver durante la fase de diseño; antes de que se haya escrito ningún código.
- Medir el progreso del trabajo es fácil ya que las etapas están bien definidas.
- La estabilidad del equipo está ahí ya que el equipo permanece hasta el final del proyecto. En el caso de Agile, el equipo cambia constantemente y esto requiere una cierta cantidad de ajuste.
- La documentación es extensa, lo que facilita la gestión de los equipos si un miembro se va.
- Los desarrolladores encuentran que es más fácil trabajar con este modelo, ya que es fácil de entender,
- Después de la fase de Requisitos, la participación activa del cliente final solo es necesaria en la fase de prueba. Esto se debe a que todos los requisitos se han discutido raído, sin dejar ambigüedad.
- El producto se puede desarrollar como un todo, en lugar de desarrollarlo en partes.
- Los problemas de gestión de clientes y contratos se manejan mejor con el Modelo de gestión de proyectos de Waterfall.
Los aspectos positivos de Agile Project Management son:
- El cliente puede interactuar con el equipo del proyecto durante todo el ciclo y puede realizar cambios en el producto de vez en cuando para adaptarse al entorno cambiante.
- Si el producto tiene que ser lanzado muy pronto debido a las circunstancias del mercado, el equipo de Agile Project Management puede lanzar una versión básica que puede tener versiones avanzadas más adelante.
- El sistema es bastante transparente desde el punto de vista del cliente y él tiene una idea clara de la etapa en la que se encuentra su producto.
- Dado que el cliente proporciona la prioridad de las funciones, el equipo sabe que debe centrarse en las funciones que ofrecen el mayor valor comercial.
- El proceso tiene su propio impulso.
- Los equipos son fluidos y flexibles, lo que permite la ideación de cada miembro
- La documentación es mínima y, por lo tanto, el tiempo se libera de esas tareas.
Después de muchos años de que ambos modelos existan uno al lado del otro, es evidente que:
El modelo de gestión de proyectos de Waterfall es efectivo para la gestión de proyectos donde una vez que se realiza el proyecto, hay cambios mínimos.
La gestión ágil de proyectos es más adecuada para la gestión de productos, donde es importante ser flexible a los cambios.
En cualquier caso, el sistema de gestión de proyectos de Waterfall sigue siendo un componente importante de la mayoría de los proyectos de TI. No se puede decir con certeza que un proyecto en particular siga estrictamente las prácticas de gestión ágil. Por lo general, los principios ágiles se "incorporan" en los proyectos de TI.
Algunos gestores de proyectos ágiles tienen gestores de proyectos, mientras que estrictamente un modelo ágil solo tiene Scrum Masters. Se trata de combinaciones híbridas de modelos de gestión de proyectos ágiles y en cascada que algunos llaman proyectos "Agifall" o "Agency Agile".
La popularidad del sistema de gestión de proyectos de Waterfall también se debe al hecho de que los problemas de gestión de contratos y clientes se manejan mejor con los métodos de gestión de proyectos de Waterfall.
Si bien cada vez más proyectos se encuentran bajo el doblez de Agile Project Management y más empresas están viendo los beneficios de un modelo de gestión flexible, la popularidad del Modelo de gestión de proyectos de Waterfall, sin duda, está disminuyendo.
Sin embargo, es difícil imaginar un futuro para proyectos de TI que sean completamente ágiles, en el futuro cercano. Y Waterfall Project Management, que ayudó a la industria del software durante su infancia, vivirá en algunos componentes de la gestión de proyectos, al menos durante algunos años más.
Primera fuente de imagen: picjumbo.com
Artículos relacionados
- 6 etapas útiles del flujo de trabajo en la gestión de proyectos en cascada
- Consejos efectivos para la discusión grupal (asesoramiento de expertos)
- Los 10 principales mitos sobre gestión de proyectos reventados
- 6 razones eficaces por las que todos necesitan un proyecto de pasión en el trabajo
- Los 5 tipos principales de herramienta de informes de gestión de proyectos
- Gestión de productos frente a gestión de marca: diferencias útiles