En su nacimiento, la gestión de proyectos software intentó imitar la gestión de proyectos de otras disciplinas, como la arquitectura, la industria o la ingeniería civil, hasta el punto de heredar y adaptar al mundo del software muchos de sus roles (p.e. arquitectos software) y tipos de organizaciones (p.e. fábricas de software).
Hoy en día una de las prácticas más discutidas y polémicas de las que se han querido heredar desde otras disciplinas es la llamada predictibilidad, también conocida como gestión de proyectos dirigida por la planificación, desarrollo tradicional o incluso también conocida como desarrollo pesado.
La predictibilidad se basa en dividir un proyecto en fases, por ejemplo, de manera simplificada, “requisitos”, “diseño” y “construcción”, y que cada una de estas fases no comience hasta que termine con éxito la anterior.
https://www.slideshare.net/JavierGarzas/agilidad-back-to-the-futurepptx
Se le llama predictibilidad porque cada fase intenta predecir lo que pasará en la siguiente; por ejemplo, la fase de diseño intenta predecir qué pasará en la programación, y esos diseños intentarán ser muy precisos y detallados, para ser cumplidos sin variación por los programadores.
Además, en este tipo de gestión, cada una de estas fases se realiza una única vez (no hay dos fases de requisitos). Y las fases están claramente diferenciadas (en teoría, está claro cuándo termina el diseño y comienza la programación), hasta el punto de tener profesionales claramente diferenciados y especializados en cada una de ellas: “analistas de requisitos”, “arquitectos de diseño software”, programadores, personas para pruebas, etc.
Normalmente cada fase concluye con un entregable documental que sirve de entrada a la siguiente fase, la “especificación de requisitos software” es la entrada al diseño, el “documento de diseño” la entrada a la construcción, etc.
La gestión de proyectos predictiva es típica en disciplinas como la arquitectura. Y desde sus orígenes, la ingeniería del software intentó perseverantemente emular a las ingenierías clásicas. Tener una fase de diseño muy claramente separada de la programación (hasta el punto de intentar tener una organización cliente que detalle los diseños y otra organización, normalmente llamada fábrica de software, que los implemente). Que la programación no comenzase hasta que terminase el diseño. Que el diseño concluya con unos planos precisos que guíen totalmente la construcción. Que una vez que se hace un diseño éste no se modifique; de hecho, notaciones como UML (Unified Modeling Language es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema) se concibieron para construir los “planos detallados” del software.
Al anterior tipo de gestión de proyectos predictiva, en el mundo del software se le conoce como ciclo de vida en cascada (ver Figura 1).
Figura 1. Ejemplo de ciclo de vida predictivo o en cascada
No hay comentarios:
Publicar un comentario