Como (no) planificar un desarrollo software (I)
El año 2002 entré a formar parte de la empresa Altran SDB como consultor, y como tenía sólo un año de experiencia como programador, me propusieron ayudar al responsable de las pruebas (tests) de un proyecto de desarrollo software.
El software era un aplicativo web para que la empresa Amena gestionase los diferentes elementos que iban construyendo e instando en su red inalámbrica (antenas, casetas, grupos electrógenos, enlaces, etcétera). Era un aplicativo en el que se daban de alta los diferentes elementos y después se podían consultar, modificar y demás. No entraban temas de contabilidad ni demás lógica, simplemente era un aplicativo web de acceso a Base de Datos.
El problema principal del proyecto radicaba en el tiempo: el cliente quería el proyecto concluido en el menor tiempo posible, 1 MES, y era una prioridad absoluta.
Los gerentes de Altran SDB habían habaldo a los consultores y estos les habían dicho que en un mes no se podía hacer, no era viable (además, eran los meses de verano y había jornada intensiva de 7 horas diarias). A pesar de ello, los gerentes decidieron seguir adelante con el proyecto y para resolver el tema del tiempo decidieron crear un equipo de 6 personas que no tendría jornada intensiva y que trabajaría también los fines de semana.
En contraprestación, los miembros del equipo serían recompensados con subidas salariales, promociones y una generosa compensación de días de vacaciones suplementarios.
El aplicativo web contemplaba 6 elementos de red inalámbrica diferentes, y cada uno debía tener su propia página de gestión. Los 6 miembros del equipo se organizaron de manera que cada uno de ellos desarrollaría una de esas páginas en JSP y después las juntarían. Como no había tiempo que perder se pusieron rápidamente a programar.
Así empezó el proyecto.
En este punto ya se habían dado importantes errores de planificación:
El plazo de entrega se acerca pero el aplicativo aún no está completamente desarrollado. Aunque cada uno de los desarrolladores ha hecho su página y parecen funcionar todas bien, no está desarrollado el código que lo integre todo. Además, de las 6 páginas, 5 han sido desarrolladas con un código muy similar pero 1 ha sido desarrollada por un fan del código libre, y aunque el diseño de la página es similar, el código no se parece al de ninguna, ni en cuanto a estructura ni en cuanto a nomenclatura.
Ante esta tesitura, se opta por ampliar el proyecto para ganar tiempo. Hacía un timepo, el cliente había solicitado añadir una nuevo tipo de elemento de red, y aunque en un primer momento se le dijo que no, ahora se acepta añadir esta nueva funcionalidad a cambio de ampliar el plazo de fin de proyecto un mes más.
Con un nuevo plazo a la vista, los miembros del equipo de desarrollo empiezan a integrar las páginas creadas, y saltan las primeras chispas por la página que se ha desarrollado al margen de las demás: usa una nomenclatura diferente y es más difícil de comprender e integrar, lo que requiere más tiempo.
El desarrollador responsable de esta página es "relegado" por sus compañeros a la elaboración de documentación, mientras el resto del equipo desarrolla la parte que falta: el contenedor del aplicativo web.
Una vez se dispone de una primera versión completa de todo el sistema, se crea el equipo de pruebas y se inician los tests.
Se han producido errores de gestión a añadir a los anteriores:
En estos primeros tests se detectan algunos pequeños errores. La aplicación estaba compuesta básicamente por siete pantallas web, cada una de ellas con muchos campos diferentes, y en las que se realizaban validaciones de Javascript para insertar y modificar los datos.
Los primeros errores que se detectaron eran de algunas validaciones de Javascript, y no parecían muy complejos de resolver (yo me incorporé al proyecto más o menos por estas fechas). Sin embargo pronto salió a la luz un problema estructural: el mismo código estaba repetido en 20 sitios diferentes. Los campos se validaban uno a uno con un código específico, que aunque fuera el mismo, se repetía a lo mejor 3 veces en una misma página, y 3 veces más en cada una de las 6 páginas restantes.
Así, por ejemplo, para corregir un pequeño error de validación eran necesario modificar los 7 JSP en varios sitios diferentes. Cuando llegó el plazo de entrega, estos errores en las validaciones no estaban totalmente resueltos, y algunos campos no se trataban correctamente.
El cliente, después del gran desembolso que estaba realizando, quería que la aplicación estuviese perfecta y no admitió la entrega. En lugar de eso, exigió que los controles fueran mucho más completos y dijo que no admitiría una entrega con el más mínimo error.
La gerencia se comprometió formalmente y la temperatura subió unos pocos grados.
La persona que había desarrollado el JSP "diferente" fue apartado del proyecto, y la gerencia dió más peso a la persona que estaba en pruebas de sistema (a la que yo estaba echando una mano).
El software era un aplicativo web para que la empresa Amena gestionase los diferentes elementos que iban construyendo e instando en su red inalámbrica (antenas, casetas, grupos electrógenos, enlaces, etcétera). Era un aplicativo en el que se daban de alta los diferentes elementos y después se podían consultar, modificar y demás. No entraban temas de contabilidad ni demás lógica, simplemente era un aplicativo web de acceso a Base de Datos.
El problema principal del proyecto radicaba en el tiempo: el cliente quería el proyecto concluido en el menor tiempo posible, 1 MES, y era una prioridad absoluta.
Los gerentes de Altran SDB habían habaldo a los consultores y estos les habían dicho que en un mes no se podía hacer, no era viable (además, eran los meses de verano y había jornada intensiva de 7 horas diarias). A pesar de ello, los gerentes decidieron seguir adelante con el proyecto y para resolver el tema del tiempo decidieron crear un equipo de 6 personas que no tendría jornada intensiva y que trabajaría también los fines de semana.
En contraprestación, los miembros del equipo serían recompensados con subidas salariales, promociones y una generosa compensación de días de vacaciones suplementarios.El aplicativo web contemplaba 6 elementos de red inalámbrica diferentes, y cada uno debía tener su propia página de gestión. Los 6 miembros del equipo se organizaron de manera que cada uno de ellos desarrollaría una de esas páginas en JSP y después las juntarían. Como no había tiempo que perder se pusieron rápidamente a programar.
Así empezó el proyecto.
En este punto ya se habían dado importantes errores de planificación:
- Dejar que los gerentes tengan la última palabra en la planificación de los proyectos sin tener en cuenta la opinión de los desarrolladores.
- Pensar que cuanta más gente participe en el equipo menos tiempo hará falta.
- Pensar que trabajar más horas y no descansar los fines de semana conseguirá que se acabe antes el proyecto.
- Empezar a programas sin dedicar todo el tiempo necesario al diseño de la solución óptima.
Primeras Consecuencias
El plazo de entrega se acerca pero el aplicativo aún no está completamente desarrollado. Aunque cada uno de los desarrolladores ha hecho su página y parecen funcionar todas bien, no está desarrollado el código que lo integre todo. Además, de las 6 páginas, 5 han sido desarrolladas con un código muy similar pero 1 ha sido desarrollada por un fan del código libre, y aunque el diseño de la página es similar, el código no se parece al de ninguna, ni en cuanto a estructura ni en cuanto a nomenclatura.Ante esta tesitura, se opta por ampliar el proyecto para ganar tiempo. Hacía un timepo, el cliente había solicitado añadir una nuevo tipo de elemento de red, y aunque en un primer momento se le dijo que no, ahora se acepta añadir esta nueva funcionalidad a cambio de ampliar el plazo de fin de proyecto un mes más.
Con un nuevo plazo a la vista, los miembros del equipo de desarrollo empiezan a integrar las páginas creadas, y saltan las primeras chispas por la página que se ha desarrollado al margen de las demás: usa una nomenclatura diferente y es más difícil de comprender e integrar, lo que requiere más tiempo.
El desarrollador responsable de esta página es "relegado" por sus compañeros a la elaboración de documentación, mientras el resto del equipo desarrolla la parte que falta: el contenedor del aplicativo web.
Una vez se dispone de una primera versión completa de todo el sistema, se crea el equipo de pruebas y se inician los tests.
Se han producido errores de gestión a añadir a los anteriores:
- Nadie realizó un diseño del sistema completo, sino que se ha ido haciendo sobre la marcha.
- Los plazos no se han cumplido y, para ganar tiempo y ampliar el plazo de entrega, se decide "ampliar el proyecto". (Sorprendente, lo sé).
- Nadie ha coordinado el trabajo de los desarrolladores, y en el momento de integrarlo todo se han encontrado con una parte de código que no entienden.
- Las pruebas se han dejado para el final del proyecto.
Los primeros Tests
En estos primeros tests se detectan algunos pequeños errores. La aplicación estaba compuesta básicamente por siete pantallas web, cada una de ellas con muchos campos diferentes, y en las que se realizaban validaciones de Javascript para insertar y modificar los datos.Los primeros errores que se detectaron eran de algunas validaciones de Javascript, y no parecían muy complejos de resolver (yo me incorporé al proyecto más o menos por estas fechas). Sin embargo pronto salió a la luz un problema estructural: el mismo código estaba repetido en 20 sitios diferentes. Los campos se validaban uno a uno con un código específico, que aunque fuera el mismo, se repetía a lo mejor 3 veces en una misma página, y 3 veces más en cada una de las 6 páginas restantes.Así, por ejemplo, para corregir un pequeño error de validación eran necesario modificar los 7 JSP en varios sitios diferentes. Cuando llegó el plazo de entrega, estos errores en las validaciones no estaban totalmente resueltos, y algunos campos no se trataban correctamente.
El cliente, después del gran desembolso que estaba realizando, quería que la aplicación estuviese perfecta y no admitió la entrega. En lugar de eso, exigió que los controles fueran mucho más completos y dijo que no admitiría una entrega con el más mínimo error.
La gerencia se comprometió formalmente y la temperatura subió unos pocos grados.
La persona que había desarrollado el JSP "diferente" fue apartado del proyecto, y la gerencia dió más peso a la persona que estaba en pruebas de sistema (a la que yo estaba echando una mano).
Sin embargo, todo fue de mal en peor cuando se detectó que las conexiones a Base de Datos no escalaban bien ... (continua en la parte II)
__________________
URL de Trackback para este artículo
http://www.pesadillastic.com/trackback/8
Compartir experiencias
Enviado por Anonymous el Jue, 10/09/2009 - 16:59.
Es interesante este post. No sólo expones tu experiencia sinó que realizas un análisi de la misma.
Yo he vivido experiencias muy similares en múltiples proyectos a lo largo de aproximadamente 10 años, algunos de ellos también en Altran.
Me he quedado con las ganas de leer la parte II...
- responder
