GESTIÓN DE PROYECTOS INFORMÁTICOS

DESARROLLO RÁPIDO SIN UNA ESTRATEGIA CLARA

TOMADO DE: Desarrollo y Gestión de Proyectos Informáticos. Steve McConnell. Página 10 a 12.

Mickey estaba preparado para dirigir su segundo proyecto en Square - Tech un gigante en el mundo de las hojas
de cálculo sobre PC. Su primer proyecto fue mal. El plan original preveía que su equipo entregase Square Calc
versión 2.0 en 12 meses, pero empleó 18 meses. El equipo sabía desde el principio que la fecha era agresiva, por
lo que casi durante los 18 meses completos llevaron una marcha trepidante, trabajando 12 horas al día 6 ó 7 días a
la semana. Al Final, dos de los seis miembros del equipo se fueron y Bob el desarrollador más importante del
equipo, partió desde Seattle en su bicicleta hacia un lugar desconocido. Bob dijo que no abandonaba, y envío una
postal a Mickey desde Ottumwa, de Dakota del Sur, una foto suya montado en un rodeo, pero nadie sabía cuando
volvería.
La versión 3.0 de Square Calc tenía que entregarse 12 meses después que la versión 2.0 así después de dos meses
de fin del proyecto, diagnósticos post-mortem y vacaciones, Mickey estaba dispuesto a intentarlo de nuevo. Tenía
10 meses para entrega la versión 3.0. Mickey se reunió con Kim, su jefa para discutir hasta el plan del proyecto. A
Kim se le conocía por su capacidad para aprovechar hasta el último esfuerzo de los desarrolladores a su cargo.
También estaba John, de documentación de usuario y Helen de control de calidad.
<<la versión 3.0 tiene que superar a la competencia>>, dijo Kim. <<Por tanto, en este proyecto tenemos que hacer
un gran esfuerzo. Sé que tu equipo no cree que la compañía les haya apoyado mucho anteriormente, así que ahora
la compañía está dispuesta a darles todo el apoyo que pueda. He autorizado despachos privados e individuales,
computadores más modernos y refrescos gratis durante todo el proyecto. Qué te parece?>>
<<Me parece bien>>, dijo Mickey. <<Todos los desarrolladores tiene experiencia, así que principalmente quiero
darles motivación y apoyo y entonces dejarles trabajar. No quiero controlarles estrechamente. Me gustaría que
cada uno se responsabilizase de una parte del sistema. Antes tuve problemas con las interfaces, así que quiero
dedicar algún tiempo en diseñar las interfaces entre las partes y después dejarles a su aire>>
<<Si es un proyecto de 10 meses, en 8 meses necesito una versión con aspecto definitivo del Software para tener
la documentación del usuario lista a tiempo>>, dijo John. <<la última vez los desarrolladores estuvieron haciendo
cambios hasta el final. El archivo LEAME tenía 20 páginas y además enrevesadas. Los manuales de usuario están
siendo destrozados en las revisiones. Siempre que esté de acuerdo con tener lista una versión con la interfaz
definitiva, el método de desarrollo parece correcto >>
<<Necesito la versión definitiva más o menos en la misma fecha para escribir secuencias automáticas de prueba>>,
añadió Helen. Mickey aceptó el planteamiento de la versión definitiva, Kim aprobó la estrategia global de Mickey y
le dijo que le dejase organizarse.
Cuando el proyecto comenzó, los desarrolladores andaban contentos con sus despachos individuales, sus nuevos
ordenadores y los refrescos, así que empezaron fuerte. No tardaron mucho en quedarse voluntariamente a trabajar
por la tarde.
Los meses pasaban y hacían progresos constantes. Pronto construyeron un prototipo, y continuaron generando
código. La directiva mantenía la presión. John recordó a Mickey varias veces su acuerdo de tener una versión con
aspecto definitivo en 8 meses, cosa que Mickey encontró irritante, pero todo parecía progresar bien.
En el cuarto mes del proyecto Bob volvió de su viaje en bicicleta, fresco e irrumpió en el proyecto con nuevas ideas
que había concebido mientras pedaleaba. Mickey estaba preocupado por si Bob podría implementar las funciones
que necesitaba en el tiempo disponible, pero Bob estaba comprometido con sus ideas y garantizaba la entrega a
tiempo sin importar lo mucho que tuviese que trabajar.
Cada miembro del equipo trabajaba individualmente su parte, y cómo la entrega de la versión con la interfaz definitiva
se aproximaba, comenzaron a integrar el código. Comenzaron a las 2 de la tarde del día anterior a la entrega de la
versión definitiva y pronto descubrieron que su programa no compilaba, y menos aún se ejecutaba. El código
combinado tenía varias docenas de errores de sintaxis, y parecía que cada uno que se corregía generaba otros 10.
A medianoche decidieron dejarlo así por esa noche.
A la mañana siguiente Kim se reunió con el equipo << ¿el programa está listo para entregarlo al equipo de
documentación y prueba?>>

1
 GESTIÓN DE PROYECTOS INFORMÁTICOS
DESARROLLO RÁPIDO SIN UNA ESTRATEGIA CLARA
TOMADO DE: Desarrollo y Gestión de Proyectos Informáticos. Steve McConnell. Página 10 a 12.

<<Aún no>> dijo Mickey. <<Tenemos algunos problemas en la integración; podemos tenerlo listo esta tarde>> El
equipo trabajó esa tarde y por la noche, pero no consiguieron corregir todos los errores que encontraron. Al final
del día admitieron que no tenían ni idea de cuánto tiempo llevaría la integración.
Emplearon dos semanas completas en corregir todos los errores de sintaxis y tener el sistema funcionando
completamente. Cuando el equipo entregó la versión buena tras un retraso de dos semanas, los equipo de prueba
y documentación la rechazaron de inmediato. <<Es demasiado inestable como para documentarla>>, dijo John
<<Se viene abajo cada pocos minutos y hay demasiadas opciones que no pueden probarse >>
Helen añadió: <<No tiene sentido escribir un informe de errores, si el sistema es tan inestable que se interrumpe
cada vez que se hace una elección en el menú>>
Mickey estaba de acuerdo con ellos, y dijo que los esfuerzos del equipo se tenían que centrar en corregir errores.
Kim les recordó la fecha tope de 10 meses y dijo que ese producto no podía retrasarse como el anterior.
Se empleó un mes más en hacer que el sistema fuese lo bastante fiable como para comenzar la documentación y
la prueba. Por entonces solo quedaban dos semanas para el plazo de 10 meses y trabajaron aún más.
Pero la prueba encontraba defectos con más rapidez que la empleada por los desarrolladores para corregirlos. Las
correcciones en una parte del sistema frecuentemente generaban problemas en otras. No había posibilidad alguna
de acabar en el décimo mes. Kim convocó a una reunión de emergencia. <<Veo que estáis trabajando duro>>, dijo
<<pero no es suficiente. Necesito resultados. Os he dado todo tipo de ayuda, y aún no tengo ningún software que
enseñar. Si no acabáis pronto el producto la compañía podría hundirse>>
Según aumentaba la presión, bajaba la moral rápidamente. Según pasaban los meses, el producto comenzaba a
estabilizarse. Y Kim mantenía la presión. Algunas de las interfaces se volvieron extremadamente ineficientes y se
necesitaron varias semanas para mejorar la eficiencia.
Bob a pesar de trabajar contra reloj entregó su software más tarde que el resto del equipo. El código estaba
virtualmente libre de errores, pero había cambiado algunos elementos de la interfaz de usuario, y las pruebas y
documentación de usuario no encajaban.
Mickey se reunió con John y Helen <<No os gustará esto, pero las opciones son las siguientes: Podemos mantener
el código de Bob como está, y revisar las pruebas y la documentación de usuario, o podemos descartar el código
de Bob y escribirlo todo de nuevo. Bob no reescribirá su código, ni nadie del resto del equipo. Parece que tendréis
que cambiar la documentación de usuario y la secuencia de pruebas>> Después de oponer un poco de resistencia
finalmente John y Helen aceptaron de mala gana.
Finalmente, los desarrolladores emplearon 15 meses en acabar el software. Debido a los cambios de aspecto, la
documentación de usuario perdió su lugar en el programa de producción de la imprenta, así que después de que
los desarrolladores tuvieran listos los discos maestros, hubo dos semanas más de retraso en el lanzamiento mientras
que Square Tech esperaba que llegarán los documentos de la imprenta. Después del lanzamiento la respuesta de
los usuarios a la versión 3.0 de Square Calc fue poco entusiasta, y al cabo de los meses descendió del segundo al
cuarto puesto en el mercado. Mickey concluyó que había acabado su segundo proyecto un 50 por ciento de tiempo
más tarde que lo planificado, igual que el primero.

ACTIVIDAD: FECHA DE ENTREGA: 16 DE ABRIL DE 2019 4 P.M. CORREO [email protected]

1. Descripción de los hechos generales del caso

2. Identificación del problema
3. Análisis: Qué aspectos considera que estuvieron bien en el desarrollo del proyecto, Qué aspectos considera
que se dieron de manera incorrecta en el proyecto.
4. Desde su formación como Ingeniero de Sistemas, enumere una lista de 10 recomendaciones que hubiesen
podido apoyar un mejor desempeño del proyecto.