La metodología de proyectos tradicional originalmente surgió a partir de la industria de la construcción, en la que los costos prohibitivos de hacer cambios posteriores significaba que los requerimientos debían ser congelados lo más temprano posible. Se basaba en un proceso de diseño secuencial conocido como el modelo Cascada, dado que el progreso se observa como un flujo permanente hacia abajo (como una cascada) a través de las etapas del proyecto, con cada etapa basada en el trabajo de la anterior.
Requerimientos Fijos
Esta es la metodología que fue adoptada inicialmente por desarrolladores de software pero no siempre se ajustaba al proceso de desarrollo de software, donde los requerimientos podían (y con frecuencia lo hacían) cambiar durante el transcurso del proyecto.
Se hicieron varios esfuerzos para manejar esta situación, tales como la "propagación contra la corriente" en la que los cambios hechos ya avanzado el proyecto eran alimentados corriente arriba hacia las primeras etapas del proyecto y los requerimientos eran entonces cambiados.
Mientras que esto tuvo algún éxito, se necesitaba una alternativa mas radical como Desarrollo Rápido de Aplicaciones RAD, Espiral, Iterativo e Incremental. En estos, los requerimientos son desarrollados a través de la vida del proyecto y entregados a través de una serie de versiones, las cuales gradualmente agregaban más funcionalidad al cliente.
Además del problema de la rigidez metodológica había un par de problemas más con el uso del enfoque tradicional.
Participación del Negocio
En el enfoque tradicional el negocio se mantenía lejos del equipo de desarrollo. Ellos eran consultados en las primeras etapas para definir requerimientos y se involucraban al final para probar el producto terminado.
Pero si veían lo que estaba siendo realizado durante el proyecto, ellos podrían decidir qué estaba mal y pedir a los desarrolladores cambiarlo. Esto sería desastroso para el proyecto porque el re-trabajo y la consecuente necesidad de repetir las pruebas retrasaría el proyecto. Entregar a tiempo era el principal objetivo de los desarrolladores aunque era raramente alcanzado.
El problema era que entregar algo a tiempo que no era lo que el negocio necesitaba era mucho peor. Esto gradualmente convenció a la gente de que era mejor involucrar al negocio activamente en el proyecto. De este modo al menos aseguraríamos que lo que se iba a entregar era lo que el negocio necesitaba, aunque fuera un poco tarde.
Gerencia del Proyecto
Tradicionalmente, el gerente del proyecto operaba en lo que ahora se conoce como estilo de comando y control. En este el gerente del proyecto desarrollaba un plan de proyecto, identificando todas las tareas requeridas para ejecutarlo. Luego asignaba tareas a cada miembro del proyecto diciéndoles exactamente qué hacer. Si bien esto hubiera estado bien para la industria de la construcción, no extraía la mejor o más creativa solución de parte de los ingenieros y desarrolladores.
La solución fue empoderar al equipo de proyecto más y activamente involucrarlos en el desarrollo del plan detallado del proyecto. De esta forma los planes no sólo serían probablemente mejores sino que los desarrolladores se sentirían mucho más comprometidos a ellos. Además, al permitir a los desarrolladores decidir por sí mismos lo que se debía hacer para entregar los requerimientos, podían hacer mejor uso de las capacidades y conocimientos de cada miembro del equipo y probablemente obtener mucho mejor compromiso de los miembros del equipo.
Estos tipos de cambio a los métodos usados en los proyectos de desarrollo de software comenzaron a ser conocidos como métodos ligeros para diferenciarlos del viejo y pesado enfoque. Estos incluyen DSDM, Scrum, Extreme Programming, Lean Development, Agile Testing y otros más.
No hay comentarios.:
Publicar un comentario