ERRORES ERRORES CLASICOS CLASICOS del desarrollo esa rrollo de softw so ftware are Contenido
3.1. Ejemplo de errores clásicos 3.2. Efecto de los errores en la programación de un desarrollo 3.3. Relación Relación de errores errores clásico clásicoss 3.4. La fuga de la isla de Gilligan EL DESARROLLO DE SOFTWARE ES UNA ACTIVIDAD COMPLICADA. Un proyecto software típi típ ico puede presenta pres entarr más oportun opo rtunidad idades es para aprender de los errores que las planteadas a algunas personas durante toda su vida. Este capítulo examina algunos de los errores clásicos que se cometen cuando se intenta desarrollar software rápidamente. 3.1. Ejemplo de de errores clásicos clás icos
El siguiente ejemplo es un poco como los pasatiempos de los niños, en los que intentamos intentamos encontrar todos los objetos cuyo nombre comienza con la letra << M ». ¿Cuántos errores clásicos puede encontrar en el siguiente ejemplo? Ejemplo 3.1. Errores Clásicos
Mike, un responsable técnico de Giga Safe estaba comiendo en su oficina y mirando por po r la la ventana una brill br illante ante mañana de abril. abril. « ¡Felicidades! ¡Mike, ya tienes los fondos para el programa Giga Quote!» Era Bill, el jefe de Mike en Giga, una compañía de seguros médicos. «Al Comité ejecutivo le ha gustado la idea de automatizar nuestras cuotas de seguro medico. Y también la idea de volcar cada noche las cuotas del día en la oficina principal para que siempre siempre tengamos tengamos al día los los últimos últimos valores valores de ve venta ntas. s. Ahora Ahora tengo tengo una reunión, pero podemos discutir los detalles mis adelante. ¡Buen trabajo!» Mike Mike escribió es cribió la propuesta propues ta para el program pro gramaa Gi G iga-Quote ga-Q uote meses meses antes, antes, pero esta es taba ba pensada como un programa programa para un solo solo PC, sin ninguna ninguna capaci capac idad de
comun co muniicaci cac ión co conn la la ofi o ficina cina pri p rinc nciipal. Perfecto, Perfecto , esta era la la oportun opo rtuniidad de d e dirigir dirigir un proyecto cliente-servidor en un moderno entorno GUI (interfaces graficas de usuario), lo que siempre había querido hacer. El proyecto le llevaría al menos un ano, y lo ocuparía a tiempo completo. Mike descolgó el teléfono y marcó el número de su esposa. «Cariño, esta noche cenaremos fuera para celebrarlo...» A la mañana siguiente. Mike quedó con Bill para discutir el proyecto. «Vamos a ver, Bill. ¿Que pasa? Esto no se parece a la propuesta cola que he trabajado.» Bill se sintió inseguro. Mike no había participado en las revisiones de la propuesta, propuesta, pero no hubo tiem tiempo po de avisarle. avisarle. Cuando el comité comité ejecutiv ejecutivoo estudió estudió el programa Gíga-Quote, tomaron los mandos. «Al comité ejecutivo le gustó la idea de construir software para automatizar las cuotas de seguros médicos. Pero querían que se pudieran transferir automáticamente las cuotas locales al computador central. Y querían tener hecho el sistema antes de que se hagan efectivas las nuevas cuotas el 1 de enero. e nero. Adelantaron la fecha de finalización del software que propusiste del 1 de marzo al 1 de noviembre, con lo que se acortó el plan plan propuesto propuesto en 6 meses. meses. » Mike había estimado que el trabajo llevaría 12 meses. No creyó que tuviese la suerte de acabar en seis meses, y así se lo dijo a Bill. «Vamos a ver si me he enterado», dijo Mike. «Parece que estás diciéndome que el comité añadió requisitos de comunicaciones a gran escala y ha acortado el plan de 12 a 6 meses.» Bill se encogió de hombros. «Se que será un reto, pero tú eres creativo y creo que puedes con con todo. todo. Han aprobado aprobado el presupuesto presupuesto que querías, querías, y añadir añadir el enlace enlace de de comunicaciones no debe ser difícil. Pediste 36 personas-mes y las tienes. Puedes reclutar a quien q uien qu quiiera que necesi neces ites para el proyecto pro yecto e incre incremen mentar tar el e l tamaño tamaño ddel el equipo.» Bill le dijo que hablase con algún otro desarrollador y que buscasen la forma de entregar el software a tiempo. Mike Mike se s e reunió reunió con co n Carl, Carl, otro responsabl respo nsablee técnico, técnico , y buscaron la la forma for ma de acortar aco rtar el plan. « ¿Por que no usas C++ y diseño orientado a objetos?», comentó Carl,
«Serás más productivo que con C, y el plan se acortará en uno o dos meses.» A Mike le pareció bien. Carl también conocía una herramienta de elaboración de informes que supuestamente acortaba el tiempo de desarrollo a la mitad. El proyecto tenía bastantes informes, y por tanto esos dos cambios los llevarían basta los 9 meses. Consiguieron hardware nuevo y más rápido, y esto les ahorraba un par de semanas. Sí realmente podía reclutar a desarrolladores de primerisima categoría, podría bajar a 7 meses. Esto era suficientemente ajustado. Mike comentó sus progresos a Bill.
equipo y mostró el plan. El comité ejecutivo les había proporcionado una especificación aproximada, y emplearon las siguientes dos semanas en completar las lagunas. Después se emplearían 6 semanas en el diseño. lo que dejaba 4 meses para la construcción y la prueba. Su estimación aproximada fue que el producto final tendría unas 30.000 líneas en C++. Todos los asistentes asintieron, dando su conformidad. Era ambicioso, pero lo sabía cuando se comprometieron con el proyecto. A la semana siguiente, Mike se reunió con Stacy, la responsable de la prueba. Indicó que debería, tener partes del producto terminadas para probarlas no después del 1de septiembre, con el propósito de tener un producto con todas las funciones el 1 de octubre. Mike estaba de acuerdo. El equipo acabó la especificación de los requerimientos rápidamente, y se metió en el diseño. Obtuvieron un diseño que parecía hacer buen uso de las prestaciones de C++. Acabaron el diseño el 15 de junio, adelantándose al plan, y comenzaron a codificar como locos para llegar al objetivo de tener la primera versión de prueba el 1 de septiembre. El trabajo en el proyecto no era una balsa de aceite. Ni a Jill ni a Tomas les gustaba Chip, y Sue se quejaba de que no quería que nadie se acercase a su código. Mike atribuyó los choques de personalidades a las muchas horas de trabajo. No obstante, a primeros de agosto, le indicaron que estaba hecho entre el 85 y el 90 por 100. A mitad de agosto, el departamento actuarial dio las tasas para el año siguiente, el equipo descubrió que tenía que modificar completamente la estructura para las nuevas tasas. El nuevo método de tasación necesitaba realizar preguntas sobre hábitos de ejercicio, en la bebida, en la comida, actividades de ocio y otros factores que no se habían incluido antes en las fórmulas de tasación. Pensaron que C++ debía protegerlos de los efectos de esos cambios. Calcularon que sólo tendrían que incluir nuevos valores en las tablas de tasas. Pero tendrían que cambiar el diálogo de entrada, el diseño de la base de datos, el acceso a la base de
datos y los objetos de comunicaciones para adaptarlos a la nueva estructura. Como el equipo estaba revuelto porque tenia que reajustar su diseño, Mike dijo a Stacy que se retrasarían unos días en la entrega de la primera versión para la prueba. El equipo no había terminado el 1 de Septiembre, y Mike aseguro a Stacy que acabarían en sólo uno o dos días. Los días se volvieron semanas. El límite del 1 de octubre para entregar el producto completo para su prueba llegó y fue rebasado. Desarrollo aún no había acabado el primer producto para prueba. Stacy llamo a Bill a una reunión para tratar el plan. «Aún no tenemos nada de desarrollo», dijo, «suponíamos que tendríamos la primera versión el 1 de septiembre, y puesto que aún no tenemos nada, por lo menos nos retrasaremos un mes respecto al plan original. Creo que tenemos un problema,>> «Es cierto, tenemos un problema» dijo Bill. «Déjame que hable con el equipo, he prometido a 600 agentes que tendríamos el programa el 1 de noviembre, Lo entregaremos a tiempo para el cambio de tasa.» Bill convocó una reunión con el equipo. «Este es un equipo fantástico, y debería cumplir con sus compromisos», les dijo. «No se que es lo que ha ido mal, pero espero que todos trabajáis duro y entreguéis el software a tiempo. Aún podéis conseguir las bonificaciones, pero ahora tendréis que luchar por ellas. Desde ahora os asignaré un horario de 6 días por Semana, 10 horas al día, hasta que el software esté hecho.» Después de la reunión Jill y Tomas se quejaron a Mike de que no había necesidad de que los tratasen como niños, pero accedieron a trabajar las horas que Bill quería. El equipo retrasó el plan dos semanas, prometiendo tener la utilidad completa construida el 15 de noviembre. Esto dejaba 6 semanas para la prueba antes de que entrasen en vigor las nuevas tasas en enero. El equipo entregó su primera versión al grupo de pruebas cuatro semanas después del 1 de noviembre, y se reunió para tratar algunas de las áreas problemáticas que
quedaban. Toma estaba trabajando en la generación de informes y se encontró con una barrera. «La página resumen de cuotas incluye un gráfico de barras. He utilizado un generador de informes que suponía generaba gráficos de barras, pero la única forma de generarlos es en páginas individuales. Uno de los requerimientos del grupo de ventas es que hay que poner gráficos de barras y texto en la misma página. He pensado que puedo trampear un informe con un gráfico de barras pasando el texto del informe como una leyenda del objeto gráfico de barras. Realmente con una trampa, pero siempre puedo volver atrás y reimplementarlo más claramente después de la primera versión.» Mike respondió: «No veo dónde está el problema. Tenemos que acabar el producto, y no hay tiempo de hacer un código perfecto. Bill ha dejado bien claro que no podemos tener más fallos. Usa ese truco.» Chip contesto que su código de comunicaciones estaba hecho al 95 por 100 y que funcionaba, pero que aun tenía que hacer algunas pruebas de ejecución. Mike vio que Jill y Tomas se miraban, pero decidió ignorarlo. El equipo trabajó duro basta el 15 de noviembre, incluyendo las noches del 14 y el 15 de noviembre, pero no pudieron hacer que la fecha de entrega fuese el 15 de noviembre. El equipo estaba exhausto, pero la mañana del dieciseisavo día, fue Bill quien se sintió deprimido. Stacy le había avisado de que desarrollo no había entregado la versión completa el día anterior, La última semana había dicho al comité ejecutivo que el proyecto estaba encarrilado. Otra gestora de proyectos, Claire, había investigado en los progresos del equipo, diciendo que había oído que no estaban cumpliendo las entregas planificadas con el equipo de prueba. Bill pensó que Claire estaba tensa y no le gustaba su informe. Le había asegurado a ella que su equipo estaba en buen camino para cumplir las entregas planeadas. Bill dijo a Mike que reuniese al equipo, y cuando lo hizo, parecían derrotados. Un mes y medio a 60 horas semanales habían sido la puntilla. Mike preguntó cuanto tiempo les llevaría acabar, pero su única respuesta fue el
silencio. « ¿Qué me estáis diciendo?», dijo. «Hoy íbamos a tener lista la versión con todas las funciones. ¿La tenemos?» «Mitra Mike», dijo Tomas. «Puedo entregar hoy mí código y decir que incluye “
toda la funcionalidad", pero probablemente necesitaré tres semanas de trabajo
de limpieza una vez que lo entregue». Mike preguntó qué quería decir Tomas con «limpieza». «No he puesto el logotipo de la empresa en cada página, ni que el nombre y el teléfono del agente aparezca al pie de la página. Son pequeñas cosas como ésa. Todo lo importante funciona bien, he acabado al 99 por 100.» «Yo tampoco he hecho exactamente el 100 por 100», admitió Jill. «Mi antiguo grupo me ha llamado para que les diese apoyo técnico, y he tenido que emplear un par de horas diarias con ellos. Además, había olvidado hasta ahora mismo que los agentes pedían poner su nombre y su teléfono en los informes. Aún no he implementado los diálogos de entrada para esos datos también tengo que hacer algunos diálogos de mantenimiento. No creía que fuesen necesarios para el hito de la "utilidad completa".» Ahora Mike también empezaba a sentirse mal. «Sí he oído lo que creo que he oído, me estáis diciendo que necesitáis tres semanas para completar el software. ¿Es correcto?» «Al menos tres semanas», dijo Jill. El resto de los desarrolladores estuvo de acuerdo. Mike pasó uno por uno y les preguntó si podrían completar su parte en tres semanas. Uno por uno, cada programador le dijo que trabajaría duro, y que pensaba que podía hacerlo. Al final de ese día, después de una discusión larga e incómoda, Mike y Bill acordaron retrasar el plan 3 semanas, hasta el 5 de diciembre, siempre que el equipo prometiera trabajar 12 horas al día en vez de 10. Bill dijo que tenía que demostrar a su jefe que estaba azuzando al equipo de desarrollo. La revisión del plan implicaba que tendrían que probar el código y preparar al personal al mismo tiempo, pero era la única posibilidad de entregar el código el 1 de enero. Stacy se quejó de que el control de calidad del software no tenía asignado el tiempo
suficiente para probarlo, pero Bill no le hizo caso. El 5 de diciembre el equipo Giga-Quote entregó el programa Giga-Quote completo al grupo de pruebas antes del mediodía, y salieron pronto del trabajo para tener su largamente esperado descanso. Habían trabajado casi constantemente desde el 1 de septiembre. Dos días más tarde, Stacy dio la primera lista de errores, y se desató el infierno. En dos días el grupo de pruebas identificó más de 200 defectos en el programa Giga-Quote, incluyendo 23 clasificados como de severidad. («Tienen que corregirse»). «No veo la forma de que el software esté listo para entregarlo a los agentes locales antes del 1 de enero», dijo. «Probablemente el grupo de pruebas necesite ese tiempo para escribir los casos de prueba de los defectos que ya ha descubierto, y está descubriendo defectos cada hora.» Mike convocó una reunión de personal a las 8 en punto de la mañana siguiente. Los desarrolladores estaban quisquillosos. Decían que había unos cuantos errores serios, pero la mayoría de los errores indicados no eran realmente errores, sino malas interpretaciones de cómo se suponía que tenía que funcionar el programa. Tomas indicó que el error #143 era un ejemplo de eso. «El informe del error #143 dice que en la página resumen de la cuota, el gráfico de barras tiene que estar en la derecha de la página en vez de en la izquierda. Esto no es un error de severidad 1. Es la típica forma en que los comprobadores sobreestiman un problema.» Mike distribuyó copias de los informes de errores. Encargó a los desarrolladores que revisasen los errores que el grupo de pruebas les había asignado y estimasen cuánto tiempo les llevaría corregir cada uno de ellos. Cuando el equipo se reunió de nuevo por la tarde, las noticias no eran buenas, «Siendo realista, estimo que necesito dos semanas completas de trabajo para corregirlos errores que ya nos han pasado», dijo Sue. «Además, tengo que acabar las comprobaciones de integridad referencial de la base de datos. En total, necesito cuatro semanas a partir de hoy.» Tomas habla devuelto el error #143 a los comprobadores, cambiando su
severidad de 1 a 3 («Cambio estético»). El grupo de pruebas respondió que los informes resumen de Giga-Quote tenían que coincidir con informes similares generados por el programa instalado en el mainframe para políticas de renovación, que era similar a los formatos de marketing preimpresos que la compañía había usado durante muchos años. Los 600 agentes de la compañía estaban acostumbrados a ver sus valores de ventas en gráficos de barras a la derecha, y tenían que quedarse a la derecha. El error se quedó con un nivel 1, y supuso un problema. « ¿Recuerdas la trampa que utilicé para que se pudiesen imprimir en la misma página el gráfico de barras y el informe?», preguntó Tomas. «Para poner el gráfico a la derecha, tengo que rescribir ese informe concreto desde el principio, lo que significa que tengo que escribir mi propio código a bajo nivel para dar formato al informe y al gráfico.» Mike tembló, y pidió una estimación aproximada de cuánto tiempo necesitaba. Tomas dijo que por lo menos 10 días, pero que tendría que verlo más despacio antes de estar seguro. Antes de volver a casa, Mike dijo a Stacy y Bill que el equipo trabajarla incluso los días de fiesta y que todos los errores encontrados se corregirían para el 7 de enero. Bill dijo que se lo esperaba y que habla aprobado un retraso en el plan de 4 semanas antes de irse a un crucero de un mes por el Caribe que tenía planeado desde el pasado verano. El mes siguiente Mike estuvo ocupado manteniendo al grupo unido. Durante Cuatro meses habían trabajado todo lo duro que se podía trabajar, y no creía que pudiesen hacer más. Estaban en la oficina 12 horas al día, pero empleaban mucho tiempo leyendo revistas, pagando facturas y hablando por teléfono. Parecía que se irritaban siempre que les preguntaba cuánto les quedaba para reducir la cuenta de errores. Por cada error que se corregía, el grupo de pruebas descubría dos nuevos. Errores cuya corrección debía haber llevado 2 minutos tenían implicaciones en el proyecto completo y podían llevar días. Pronto calcularon que no había forma de que pudieran corregir todos los defectos para el 7 de enero.
El 7 de enero Bill volvió de sus vacaciones, y Mike le dijo que el equipo de desarrollo aun necesitaba 4 semanas más. «Esto es serio», dijo Bill, «tengo 600 agentes locales que están hartos de dar vueltas alrededor de un puñado de aprendices de informáticos. El comité ejecutivo está hablando de cancelar el proyecto. Tienes que encontrar una forma de entregar el software en las próximas dos semanas, sea como sea». Mike convocó una reunión del equipo para estudiar sus opciones. Les comunicó el ultimátum de Bill y les pidió una estimación aproximada de cuándo entregarían el producto, primero en semanas, luego en meses. El equipo se calló. Ninguno se arriesgaba acerca de cuándo podrían entregar finalmente el producto. Mike no sabía qué decirle a Bill. Tras la reunión, Chip dijo a Mike que había aceptado un contrato de otra compañía y que empezaba el 3 de febrero. Mike comenzó a sentir que seria un alivio que se cancelara el proyecto. Mike buscó a Kip, el programador que había sido responsable del apartado de comunicaciones entre el PC y el mainframe, reasignado de apoyo al proyecto, y lo dedicó a corregir los errores en el código de comunicaciones del PC. Después de luchar una semana con el código de Chip, Kip concluyó que tenía algunos defectos conceptuales profundos que harían que nunca funcionara correctamente. Kip se vio obligado a rediseñar y reimplementar la parte PC del enlace de comunicaciones entre el PC y el mainframe. Puesto que Bill se salió por la tangente en la reunión ejecutiva de mitad de febrero, finalmente Claire decidió que ya había oído suficiente y mandó un <<
stop» al programa Giga-Quote. Se reunió con Mike el viernes. «Este proyecto
está fuera de control», dijo. «Desde hace meses, Bill no me ha dado una estimación fiable. Es un proyecto de 6 meses, y ya lleva más de 3 meses de retraso sin un final claro. Estáis trabajando tantas horas que no hacéis progresos. Quiero que descanséis todos un fin de semana; quiero que desarrolles un informe detallado, paso a paso, que incluya todo, y digo todo lo que queda por hacer del ,
proyecto. No quiero que forcéis el proyecto para encajarlo en un plan artificial. Si se necesitan otros 9 meses quiero saberlo. Quiero el informe del trabajo pendiente para el miércoles. No tiene que ser bonito, pero tiene que estar completo.» El equipo de desarrollo se alegró de tener un fin de semana libre, y durante la semana siguiente atacaron el informe detallado con energías renovadas. Estuvo en la mesa de Claire para el miércoles. Revisó el informe con Charles, un asesor en ingeniería del software que también había revisado las estadísticas de errores del proyecto. Charles recomendó que el equipo centrase sus esfuerzos en un puñado de módulos propensos a errores, que se iniciasen inmediatamente revisiones del diseño y la codificación para corregir todos los errores y que el equipo comenzase trabajando horas fijas, para que se pudiesen hacer métricas precisas del esfuerzo empleado en el proyecto y cuánto se necesitaría para terminarlo. Tres semanas más tarde, en la primera semana de marzo, la lista de errores pendientes bajó un poco por primera vez. La moral del equipo subió un poco, y basándose en los progresos regulares que se iban haciendo, el asesor estimó que el software podría entregarse, completamente probado y fiable, el 15 de mayo. Puesto que el incremento semestral de la tasa de Giga Safe tendría efecto a partir de 1 de julio, Claire fijó la fecha oficial de lanzamiento el 1 de junio.
Epilogo
El programa Giga Quote se entregó a los agentes locales de acuerdo con el plan el 1 de junio. Los agentes locales de Giga Safe lo acogieron con entusiasmo y algo de escepticismo. La corporación Giga Safe mostró su aprecio al trabajo duro realizado por el equipo de desarrollo dando a cada desarrollador una bonificación de $250
dólares. Unas cuantas semanas más tarde, Tomas pidió una larga baja, y Jill se fue a trabajar a otra compañía. El producto final Giga-Quote se entregó en 13 meses en vez de en 6, pasándose del límite más de mi 100 por 100. El esfuerzo de desarrollo, incluyendo las horas extras, fue de 98 personas-mes, lo que supuso un exceso del 170 por 100 respecto a las 36 persona -mes planificadas. El producto final tenía en torno a 40.000 líneas de código C++ no vacías y sin comentarios, superior en más de un 33 por 100 a las estimaciones aproximadas de Mike. Puesto que fue un producto distribuido en más de 600 puestos internos, Gíga-Quote es un híbrido entre un producto de gestión y un producto pret-a-porter. Un producto de este tamaño y este tipo normalmente se debería haber acabado en 11 meses y medio con un esfuerzo de 71 personas-mes. El proyecto sobrepasó ambas cantidades. 3.2. Efectos de los errores en la programación de un desarrollo
Michael Jackson (el cantante, no el informático) cantaba que
<<
ONE bad apple
don t spoil the whole bunch, baby>> (una manzana podrida no estropea el barril completo, pequeña). Esto puede ser cierto para las manzanas. Pero no lo es para el software. Una manzana podrida puede estropear el proyecto completo. Un grupo de investigadores de ITT revisó 44 proyectos de 9 países para examinar el impacto de 13 factores de productividad en la productividad (vos burgh et al., 1984). Los factores incluían el uso so de técnicas de programación modernas, dificultad del código, requisitos de eficiencia, nivel de participación del cliente en la especificación de los requerimientos, experiencia personal y alguno mas. Asignaron a cada factor distintas categorías que esperaban asociar con una eficiencia baja, media o alta. Por ejemplo, asignaron al factor «uso de técnicas modernas de programación» valores de bajo uso, uso medio o alto. La Figura 3.1 de la página siguiente muestra lo que descubrieron los investigadores acerca del factor «uso de técnicas modernas de programación».
Cuanto mas estudiamos la Figura 3.1, más interesante resulta. Multar un patrón general que es representativo de los descubrimientos de cada uno de los factores de productividad estudiados. Los investigadores de ITT vieron que los proyectos de las categorías que tuvieran poca productividad realmente tenían una productividad pobre, como muestra la estrecha franja de la categoría Baja en la Figura 3.1. Pero la productividad en categorías de alto rendimiento variaba mucho, según muestra la franja ancha de la categoría Alta en la figura. La productividad de los proyectos de la categoría Alta variaba desde pobre a excelente. No es sorprendente que proyectos que se espera que tenga una productividad la tengan realmente. Pero si debiera ser una sorpresa el descubrimiento de que muchos proyectos que se esperaba que tuviesen una productividad excelente tienen una productividad pobre. Lo que este grafico y otros como este muestran a lo largo de todo el libro es que aunque es necesario utilizar alguno de los métodos recomendables, no es suficiente para obtener la máxima velocidad de desarrollo. Incluso si se hacen algunas cosas bien, como la utilización de técnicas de programación modernas, aun podemos cometer un error que anule las mejoras en la productividad. Al pensar en el desarrollo rápido, resulta tentador que todo lo que hay que hacer es identificar las causas de un desarrollo lento y eliminarlas, y después obtendremos un desarrollo rápido. El problema es que no hay solo unas pocas causas del desarrollo lento. Es como preguntarse: ¿Cuál es al cusa de que no sea capaz de correr una milla en cuatro minutos? Bueno, soy demasiado viejo. Peso mucho. No estoy en forma. No me atrevo a intentarlo. No tengo un buen entrenador o capacidades físicas. No podría ir tan deprisa aunque fuese mas joven. La lista crece y crece. Cuando hablamos de proezas excepcionales, las razones de que la gente no las alcance son simplemente demasiado numerosas como para contarlas. El equipo de Giga-Quote del Ejemplo 3.1 cometió muchos de los errores que han
plagado el desarrollo de software desde los tiempos mis remotos de la informática. El camino del desarrollo de software esta lleno de baches, y los baches en que caigamos determinan la rapidez o la lentitud con que desarrollamos el software. En el software, una manzana podrida puede estropear todo el barril, pequeña. Para caer en el desarrollo lento, todo lo que hay que hacer es cometer realmente un gran error; para conseguir el desarrollo rápido tenemos que evitar cometer algún gran error. La siguiente sección enumera los grandes errores más habituales. 3.3. Relación de errores clásicos
Algunas técnicas de desarrollo inefectivas han sido elegidas con tanta frecuencia, por tanta gente, con resultados tan malos y predecibles que son dignas de ser llamadas «errores clásicos». Muchos de los errores tienen una apariencia seductora. ¿Necesitamos salvar un proyecto retrasado? Metamos a más gente ¿Tenemos que reducir el plan? Planifiquemos de forma mas agresiva ¿Alguno de los miembros clave incomoda al resto del equipo? Esperaremos hasta que acabe el proyecto para despedirlo ¿Hay que acelerar el proyecto para acabar? ¡Cogeremos cuantos desarrolladores estén ya disponibles, y que comiencen lo antes posible! Los desarrolladores, directivos y clientes normalmente tienen buenas razones para tomar las decisiones que toman, y la apariencia seductora de los errores clásicos es una de las razones de que esos errores se cometan a menudo. Pero debido a que se han cometido muchas veces, sus consecuencias se han hecho fáciles de predecir. Y los errores clásicos rara vez producen los resultados que la gente espera. Esta sección enumera alrededor de dos docenas de errores clásicos. Personalmente he visto cometer cada uno de esos errores al menos una vez, y yo mismo he cometido bastantes. Muchos de ellos aparecen en el ejemplo 3.1. El común denominador de esos errores es que el desarrollo rápido no se consigue
necesariamente si se evitan, pero si no se evitan, seguro que se consigue el desarrollo lento. Si alguno de estos errores nos resulta familiar, hay que animarse; muchos otros los han cometido antes. Una vez que comprendamos sus efectos en la velocidad de desarrollo, podremos utilizar esta lista para ayudarnos en la planificación de nuestro proyecto y en la gestión de riesgos. Algunos de los errores más significativos tienen sus propias secciones en otras partes de este libro. Otros no se tratarán más. Para facilitar la consulta, la lista se ha dividido empleando las dimensiones de la velocidad de desarrollo: personas, proceso, producto y tecnología. Personas
A continuación aparecen algunos de los errores clásicos relacionados con las personas. 1: Motivación débil.
Estudio tras estudio se ha mostrado que la motivación
probablemente tiene mayor efecto sobre la productividad y la calidad
que
ningún otro factor (Boehm, 1981). En el Ejemplo 3.1, los directivos tomaron a lo largo de todo el proyecto medidas que minaban la moral: como dar ánimos a diario al principio para pedir horas extras en la mitad, y como irse de vacaciones mientras el equipo estaba trabajando incluso los días de fiesta, para dar recompensas al final del proyecto que resultaron ser de menos de un dólar por cada hora extra. 2: Personal mediocre.
Después de la motivación, la capacidad individual de los
miembros del equipo, así como sus relaciones como equipo, probablemente tienen la mayor influencia en la productividad (Boehm, 1981; Lakhanpal, 1993). Contratar apurando el fondo del barril supondrá una amenaza al esfuerzo del desarrollo rápido. En el ejemplo, la selección del personal se hizo buscando quién podría contratarse más rápido, en vez de quién realizaría la mayoría del trabajo durante la vida del proyecto. Esta técnica consigue un inicio rápido del proyecto,
pero no determina un final rápido. 3: Empleados problemáticos incontrolados.
Un fallo al tratar con personal
problemático también amenaza la velocidad de desarrollo. Es un problema habitual, y se ha comprendido bien, al menos desde que Gerald Weinberg publicó Psychology of Computer Programming en 1971. Un fallo al tomar una decisión cuando se trata con un empleado problemático es una de las quejas más comunes que tienen los miembros del equipo respecto de sus responsables (Larson y Lafasto. 1989). En el Ejemplo 3.1, el equipo sabía que Chip era una manzana podrida, pero el jefe del equipo no hizo nada. El resultado era predecible: rehacer el trabajo de Chip. 4: Hazañas.
Algunos desarrolladores de software ponen un gran énfasis en la
realización de hazañas en los proyectos (Bach, 1995). Pero lo que hacen tiene más de malo que de bueno. En el ejemplo, los directivos de nivel medio dieron mayores aplausos a actitudes del tipo «ser capaz de» que a los progresos firmes y consistentes y a los informes significativos de progreso. El resultado fue un modelo de planificación al límite en el que las amenazas de desajuste del plan no se detectaban, ni se conocían o ni se informaban a la cadena de directivos hasta el último minuto. Un pequeño equipo de desarrollo y sus jefes inmediatos toman como rehenes a una compañía entera por no admitir que tienen problemas para cumplir su plan. El énfasis en los comportamientos heroicos fomenta correr un riesgo extremo, e impide la cooperación entre los múltiples elementos que contribuyen al proceso de desarrollo del software. Algunos directivos fomentan el comportamiento heroico cuando se concentran con demasiada firmeza en actitudes «ser capaz de». Elevando estas actitudes por encima de informes del estado exacto y a veces pesimistas, los directivos de estos proyectos coartan su capacidad de tomar medidas correctivas. Ni siquiera saben que tienen que emprender acciones correctoras hasta que el daño ya está hecho. Como dijo TOM DeMarco, las actitudes «ser capaz de» convierten pequeños contratiempos en auténticos desastres (Mareo, 1995)
5: Añadir más personal a un proyecto retrasado.
Éste es quizás el más clásico
de los errores clásicos. Cuando un proyecto se alarga, añadir mas gente puede quitar más productividad a los miembros del equipo existente de la que añaden los nuevos miembros. Fred Brooks compara añadir gente a un proyecto retrasado con echar gasolina en un fuego (Brooks, 1975). 6: Oficinas repletas y ruidosas.
La mayoría de los desarrolladores consideran
sus condiciones de trabajo como insatisfactorias. Alrededor del 60 por 100 indican que no tienen suficiente silencio ni privacidad (De-Mareo y Lister, 1987). Los trabajadores que están en oficinas silenciosas y privadas tienden a funcionar significativamente mejor que aquellos que ocupan cubiculos en salas ruidosas y repletas. Los entornos repletos y ruidosos alargan los planes de desarrollo. 7: Fricciones entre los clientes y los desarrolladores.
Las fricciones entre los
clientes y los desarrolladores pueden presentarse de distintas formas. A los clientes puede parecerles que los desarrolladores no cooperan cuando rehúsan comprometerse con el plan de desarrollo que desean los clientes o cuando fallan al entregar lo prometido. A los desarrolladores puede parecerles que los clientes no son razonables porque insisten en planes irreales o cambios en los requerimientos después de que éstos hayan sido fijados. Pueden ser simplemente conflictos de personalidad entre dos grupos. El principal efecto de esta fricción es la mala comunicación, y los efectos secundarios de la mala comunicación incluyen el pobre entendimiento de los requerimientos, pobre diseño de la interfaz de usuario y en el peor caso, el rechazo del cliente a aceptar el producto acabado. En el caso medio, las fricciones entre clientes y desarrolladores de software llegan a ser tan severas que ambas partes consideran la cancelación del proyecto (Jones, 1994). Para remediar estas fricciones se consume tiempo, y distraen tanto a desarrolladores como a clientes del trabajo real en el proyecto.
8: Expectativas poco realistas.
Una de las causas más comunes de a fricciones
entre los desarrolladores y sus clientes o los directivos son las expectativas poco realistas. En el Ejemplo 3.1. Bill no tenia razones para pensar que el programa Giga-Quote se podría desarrollar en 6 meses, pero ese era el plazo en que lo quena el comité ejecutivo de la compañía. La incapacidad de Mike de corregir esta expectativa irreal fue la principal fuente de problemas. En otros casos, los directivos o los desarrolladores de un proyecto se buscan problemas al pedir fondos basándose en estimaciones de planificación demasiado optimistas. A veces prometen un conjunto de funciones tan altas como la Luna. Aunque por si mismas las expectativas irreales no alargaran el plan, contribuyen a la percepción de que el plan de desarrollo es demasiado largo, y de que puede ser malo. Una inspección de Standish Group marcó las expectativas realistas como uno de los cinco factores principales necesarios para asegurar el éxito de los proyectos internos de software de gestión (Standish Group, 1994). 9: Falta de un promotor efectivo del proyecto.
Para soportar muchos de los
aspectos del desarrollo rápido es necesario un promotor del proyecto de alto nivel, incluyendo una planificación realista, el control de cambios y la introducción de nuevos métodos de desarrollo. Sin un promotor ejecutivo efectivo, el resto del personal de alto nivel de la empresa puede forzar a que se acepten fechas de entrega irreales o hacer cambios que debiliten el proyecto. El consultor australiano Rob Thomsett afirma que la falta de un promotor efectivo garantiza virtualmente el fracaso del proyecto (Thomsett, 1995). 10: Falta de participación de los implicados.
Todos los principales
participantes del esfuerzo de desarrollo de software deben implicarse en el proyecto. Incluyendo a los promotores, ejecutivos, responsables del equipo, miembros del equipo, personal de ventas, usuarios finales, clientes y cualquiera que se juegue algo con el proyecto. La cooperación estrecha sólo se produce si se han implicado todos los participantes, permitiendo una coordinación precisa del esfuerzo para el desarrollo rápido, que es imposible conseguir sin una buena
participación. 11: Falta de participación del usuario.
La inspección de Standish Group
descubrió que la razón número uno de que los proyectos de Sistemas de Información tuviesen éxito es la implicación del usuario (Standish Group, 1991). Los proyectos que no implican al usuario desde el principio corren el riesgo de que no se comprendan los requerimientos del proyecto, y son vulnerables a que se consuma tiempo en prestaciones que mas tarde retrasarán el proyecto. 12: Política antes que desarrollo.
Larry Constantine indicó que si hay cuatro
equipos hay cuatro tipos diferentes de orientaciones políticas (Constantine. 1995a). Los «políticos» están especializados en la «gestión», centrándose en las relaciones con sus directivos. Los «investigadores» se centran en explorar y reunir información. Los «aislacionistas» están solos, creando fronteras para el proyecto que mantienen cerradas a los que no son miembros del equipo. Los «generalistas» hacen un poco de todo: establecen relaciones con sus directivos, realizan investigaciones y exploran actividades, y se coordinan con otros equipos como parte de su modo de trabajo. Constantine indicó que inicialmente los equipos políticos y generalistas están bien vistos por los directivos de alto nivel. Pero después de un año y medio, los equipos, políticos llegan a la muerte súbita. Primar la política en vez de los resultados es fatal para el desarrollo orientado a la velocidad. 13: Ilusiones.
Estoy impresionado de ver cuántos problemas del desarrollo del
software se deben a la ilusión. Cuántas veces hemos escuchado cosas como éstas a distintas personas: «Ninguno de tos miembros del proyecto cree realmente que pueda completarse el proyecto de acuerdo con el plan que tienen, pero piensan que quizás si trabajan duro, y nada va mal, y tienen un poco de suerte, serán capaces de concluir con éxito.» «Nuestro equipo no hace mucho trabajo para la coordinación de las interfaces entre las distintas partes del producto, pero tenemos una buena comunicación
para otras cosas, y las interfaces son relativamente simples, así que probablemente sólo necesitaremos un día o dos para eliminar los errores.» «Sabemos que contamos con un desarrollador externo de poco talento para el subsistema de la base de datos, y que es difícil ver cómo va a acabar el trabajo con los niveles de personal que ha especificado con su propuesta. No tienen tanta experiencia como algunos de los demás desarrolladores externos, pero puede que compensen con energía lo que les falta en experiencia. Probablemente acaben a tiempo.» «No necesitamos reflejar la última lista de cambios en el prototipo para el cliente. Estoy seguro de que por ahora sabemos lo que quiere.» «El equipo está diciendo que realizara un esfuerzo extraordinario para cumplir con la fecha de entrega, y que no han llegado a su primer hito por pocos días, pero creo que alcanzarán este a tiempo. » Las ilusiones no son sólo optimismo. Realmente consisten en cerrar los ojos y esperar que todo funcione cuando no se tienen las bases razonables para pensar que será así. Las ilusiones al comienzo del proyecto llevan a grandes explosiones al final. Impidiendo llevar a cabo una planificación coherente y pueden ser la raíz de más problemas en el software que todas las otras causas combinadas. Proceso
Los errores relacionados con el proceso ralentizan los proyectos porque malgastan el talento y el esfuerzo del personal. A continuación se muestran algunos de los peores errores relacionados con el proceso. 14: Planificación excesivamente optimista.
Los retos a los que se enfrenta
alguien que desarrolla una aplicación en tres meses son muy diferentes de aquellos a los que se enfrenta alguien que desarrolla una aplicación que necesita un año. Fijar un plan excesivamente optimista predispone a que el proyecto falle por infravalorar el alcance del proyecto, minando la planificación efectiva, y
reduciendo las actividades críticas para el desarrollo, como el análisis de requerimientos o el diseño. También supone una excesiva presión para los desarrolladores, quienes a largo plazo se ven afectados en su moral y su productividad. Esta es la mayor fuente de problemas del Ejemplo 3.1. 15: Gestión de riesgos insuficiente.
Algunos errores no son lo suficientemente
habituales como para considerarlos clásicos. Son los llamados «riesgos». Como con los errores clásicos, Si no ejercemos una gestión activa de los riesgos, con que sólo vaya mal una cosa se pasará de tener un proyecto con un desarrollo rápido a uno con un desarrollo lento. El fallo de no gestionar uno solo de estos riesgos es un error clásico. 16: Fallos de los contratados.
Las compañías a veces contratan la realización de
partes de un proyecto cuando tienen demasiada prisa para hacer el trabajo en casa. Pero los contratados frecuentemente entregan su trabajo tarde, con una calidad inaceptable o que falla al no coincidir con la especificación (Boehm. 1989). Riesgos como requerimientos instables o interfaces mal definidas pueden ser enormes cuando un contratado entra en escena. Si las relaciones con los contratados no se gestionan cuidadosamente, la utilización de desarrolladores externos puede ralentizar el proyecto en vez de acelerarlo. 17: Planificación Insuficiente.
Si no planificamos para conseguir un desarrollo
rápido, no podemos esperar obtenerlo. 18: Abandono de la planificación bajo presión.
Los equipos de desarrollo
hacen planes y rutinariamente los abandonan cuando se tropiezan con un problema en la planificación (Humphrey, 1989). El problema no esta en el abandono del plan, sino más bien en fallar al no crear un plan alternativo, y caer entonces en el modo de trabajo de codificar y corregir. En el Ejemplo 3.1, el equipo abandonó su plan después de fallar en la primera entrega, y esto es lo habitual. A partir de este punto, el trabajo no tuvo coordinación ni elegancia, hasta el punto de que Jill empezó a trabajar parte del tiempo para un proyecto de su viejo grupo y nadie lo supo.
19: Pérdida de tiempo en el inicio difuso.
El <
transcurre antes de que comience el proyecto, este tiempo normalmente se pierde en el proceso de aprobar y hacer el presupuesto. No es poco común que un proyecto desperdicie meses o años en un inicio difuso, y entonces se está a las puertas de un plan agresivo. Es mucho más fácil y barato y menos arriesgado suprimir unas pocas semanas o meses de inicio difuso en vez de comprimir el plan de desarrollo en ese mismo tiempo. 20: Escatimar en las actividades iniciales.
Los proyectos que se aceleran
intentando acortar las actividades no esenciales, y puesto que el análisis de requerimientos, la arquitectura y el diseño no producen código directamente, son los candidatos fáciles. En un proyecto desastroso en el que participé, pedí que me enseñasen el diseño. El responsable del equipo me dijo: «No hemos tenido tiempo de hacer el diseño.» Lo resultados de este error, también conocido como «saltar a la codificación», son todos demasiado predecibles. En el ejemplo, un truco de diseño en el informe del grafico de barras fue sustituido por un trabajo de diseño de calidad. Antes de poder entregar el producto, el trabajo con truco tuvo que tirarse, y hubo que hacer de todos modos el trabajo bien hecho. Los proyectos que normalmente escatiman en sus actividades iniciales tendrán que hacer ese trabajo en otro momento, con un coste de 10 a 100 veces superior a haberlo hecho bien inicialmente (Fagan, 1976; Boehm y Papaccio, 1988). Si no podemos encontrar cinco horas para hacer el trabajo correctamente la primera vez, ¿cómo vamos a encontrar 50 para hacerlo correctamente más tarde? 21: Diseño Inadecuado.
Un caso especial de escatimar en las actividades
iniciales es el diseño inadecuado. Proyectos acelerados generan un diseño indeterminado, no asignando suficiente tiempo para el y originando un entorno de alta presión que hace difícil la posibilidad de considerar alternativas en el diseño. El énfasis en el diseño esta' mas orientado a la conveniencia que a la calidad, por lo que necesitará varios ciclos de diseño antes de poder finalizar
completamente el sistema. 22: Escatimar en el control de calidad.
En los proyectos que se hacen con prisa
se suele cortar por lo sano, eliminando las revisiones del diseño y del código, eliminando la planificación de las pruebas y realizando sólo pruebas superficiales. En el ejemplo, las revisiones del diseño y del código se eliminaron limpiamente para conseguir una ganancia considerable en el plan. Al final, cuando el proyecto alcanzó su hito de plena funcionalidad, aún tenía demasiados errores y se retrasó más de 5 meses. Este resultado es típico. Acortar en un día las actividades de control de calidad al comienzo del proyecto probablemente supondrá de 3 a lO días de actividades finales (Jones, 1994). Esta reducción va contra la velocidad de desarrollo. 23: Control insuficiente de la directiva.
En el ejemplo hay poco control de la
directiva para detectar a tiempo los signos de posibles retrasos en el plan, y los pocos controles definidos al comienzo se abandonaron cuando el proyecto comenzó a tener problemas. Antes de encarrilar un proyecto, en primer lugar debemos ser capaces de decir si va por buen camino. 24: Convergencia prematura o excesivamente frecuente.
Bastante antes de
que se haya programado entregar un producto, hay un impulso para preparar el producto para la entrega, mejorar el rendimiento del producto, imprimir la documentación final, incorporar entradas en el sistema final de ayuda, pulir el programa de instalación, eliminar las funciones que no van a estar listas a tiempo y demás. En proyectos hechos con prisa, hay una tendencia a forzar prematuramente la convergencia. Puesto que no es posible forzar la convergencia del producto cuando se desea, algunos proyectos de desarrollo rápido intentan forzar la convergencia media docena de veces o más antes de que finalmente se produzca, Los intentos adicionales de convergencia no benefician al producto. Sólo son una perdida de tiempo y prolongan el plan. 25: Omitir tareas necesarias en la estimación.
Si la gente no guarda
cuidadosamente datos de proyectos anteriores, olvida las tareas menos visibles,
pero son tareas que se han de añadir. El esfuerzo omitido suele aumentar el plan de desarrollo en un 20 o 30 por 100 (Van Genuchten, 1991). 26: Planificar ponerse al día más adelante.
Un tipo de reestimación es
responder inapropiadamente al retraso del plan. Si hemos trabajado en un proyecto durante 6 meses, y hemos empleado tres meses en llegar al hito correspondiente a los dos meses, ¿que hacer? En muchos proyectos simplemente se plantea recuperar el retraso mas tarde, pero nunca se hace. Aprenderemos mas del producto conforme lo estamos construyendo, incluyendo mas sobre lo que nos llevará construirlo. Estos conocimientos necesitan reflejarse en la reestimación del plan. Otro tipo de error en la reestimación se debe a cambios en el producto. Si el producto que estamos construyendo cambia, la cantidad de tiempo necesaria para construirlo cambiará también. En el Ejemplo 3.1, los requerimientos principales cambiaron entre la propuesta original y el comienzo del proyecto sin la correspondiente reestimación del plano de los recursos. El crecimiento de las nuevas prestaciones sin ajustar el plan garantiza que no se alcanzará la fecha de entrega. 27: Programación a destajo.
Algunas organizaciones creen que la codificación
rápida, libre tal como salga, es el camino hacia el desarrollo rápido. Piensan que si los desarrolladores están lo suficientemente motivados, pueden solventar cualquier obstáculo. Debido a las razones que se verán claramente a lo largo de todo este libro, esto está lejos de la verdad. Este enfoque muchas veces se presenta como un enfoque «empresarial» al desarrollo de software, pero realmente es sólo la envoltura del viejo paradigma a destajo combinado con una planificación ambiciosa, y esta combinación raras veces funciona. Es un ejemplo de que dos negaciones no constituyen una verdad. Producto
A continuación se muestran los, errores clásicos relacionados con la forma en la
que se define el producto. 28: Exceso de requerimientos.
Algunos proyectos tienen más requerimientos
de los que necesitan, desde el mismo inicio. La eficiencia se fija como requisito más a menudo de lo que es necesario, y puede generar una planificación del software innecesariamente larga. Los usuarios tienden a interesarse menos en las prestaciones complejas que en las de las secciones de marketing o de desarrollo, y las prestaciones complejas alargan desproporcionadamente el plan de desarrollo. 29: Cambio de las prestaciones.
Incluso si hemos evitado con éxito los
requerimientos excesivos, los proyectos sufren como media sobre un 25 por 100 de cambios en los requerimientos a lo largo de su vida (Jones, 1994). Un cambio de este calibre puede producir un aumento en el plan de al menos un 25 por 100, lo que puede ser fatal para los proyectos de desarrollo rápido. 30: Desarrolladores meticulosos.
Los desarrolladores encuentran fascinante la
nueva tecnología, y a veces están ansiosos por probar nuevas prestaciones de su lenguaje o entorno, o por crear su propia implementación de una utilidad bonita que han visto en otro producto, la necesidad no su producto. El esfuerzo requerido para diseñar, implementar, probar, documentar o mantener estas prestaciones innecesarias alarga el plan. 31: Tiras y aflojas en la negociación.
Cuando un directivo aprueba un retraso
en el plan de un proyecto que progresa más lento de lo esperado, y entonces añade tareas completamente nuevas después de un cambio en el plan, se produce una situación curiosa. La razón subyacente de esto es difícil de localizar, puesto que el directivo que aprueba el retraso en el plan lo hace sabiendo implícitamente que el plan estaba equivocado. Pero una vez que Se corrige, la misma persona realiza acciones explicitas para volver a equivocarse. Esto sólo puede ir en contra del plan. 32: Desarrollo orientado a la Investigación. Seymour Cray, el diseñador de los
supercomputadores Cray, dijo que no intentaba sobrepasar los limites de la ingeniería en más de dos áreas a la vez, porque el riesgo de un fallo es demasiado
alto (Gilb. 1988). Muchos proyectos software deberían aprender la lección de Cray. Si el proyecto fuerza los limites de la informática porque necesita la creación de nuevos algoritmos o de nuevas técnicas de computación, no estamos desarrollando software; estamos investigando en software. Los planes de desarrollo de software son razonablemente predecibles; los planes en la investigación sobre software ni siquiera son predecibles teóricamente. Si el producto tiene objetivos que pretenden aumentar los conocimientos existentes, como algoritmos, velocidad, utilización de la memoria y demás, debemos asumir que la planificación es altamente especulativa, si queremos mejorar el estado del arte y tenemos algún otro punto débil en el proyecto, recortes de personal, debilidades en el personal, requerimientos vagos, interfaces inestables con contratados externos, etc., podemos tirar por la ventana la planificación prevista. Si queremos superar el estado del arte por todos los medios, hagámoslo. ¡Pero no debemos esperar hacerlo rápidamente! Tecnología
El resto de los errores clásicos están relacionados con el uso correcto o incorrecto de la tecnología moderna. 33: Síndrome de la panacea.
En el ejemplo, se confió demasiado en las ventajas
proclamadas de tecnologías que no se habían usado antes (generadores de informes, diseño orientado a objetos y C++) y demasiada poca información sobre lo buenas que serian en este entorno de desarrollo concreto. Cuando el equipo del proyecto se aferra sólo a una nueva técnica, una nueva tecnología o un proceso rígido, y espera resolver con ello sus problemas de planificación está inevitablemente equivocado (Jones, 1994). 34: Sobreestimación de las ventajas del empleo de nuevas herramientas o métodos.
Las organizaciones mejoran raramente su productividad a grandes
saltos, sin importar cuantas nuevas herramientas o métodos empleen o lo buenos que sean. Los beneficios de las nuevas técnicas son parcialmente desplazados por
las curvas de aprendizaje que llevan asociadas, y aprender a utilizar nuevas técnicas para aprovecharlas al máximo lleva su tiempo. Las nuevas técnicas también suponen nuevos riesgos, que sólo descubriremos usándolas. Más bien experimentaremos mejoras lentas y continuas en un pequeño porcentaje por proyecto en lugar de grandes saltos. El equipo del Ejemplo 3.1 debería haber previsto como mucho un 10 por 100 de ganancia en productividad por la utilización de las nuevas tecnologías en vez de asumir que estarían cerca de duplicar su productividad. Un caso especial de sobreestimaciones de las mejoras se produce cuando se reutiliza código de proyectos anteriores. Este tipo de reutilización puede ser una técnica muy efectiva, pero el tiempo que se gana no es tan grande como se espera. 35: Cambiar de herramientas a mitad del proyecto.
Es un viejo recurso que
funciona raramente. A veces puede tener sentido actualizar incrementalmente dentro de la misma línea de productos, de la versión 3 a la 3.1, o incluso a la 4. Pero cuando estamos a la mitad de un proyecto, la curva de aprendizaje, rehacer el trabajo y los inevitables errores cometidos con una herramienta totalmente nueva, normalmente anulan cualquier posible beneficio. 36: Falta de control automático del código fuente.
Un fallo en la utilización
del control automático del código fuente expone a los proyectos a riesgos innecesarios. Sin él, si dos desarrolladores están trabajando en la misma parte del programa, deben coordinar su trabajo manualmente. Deberían ponerse de acuerdo para poner la última versión de cada archivo en el directorio maestro y verificarlos con los demás antes de copiarlas en este directorio. Pero invariablemente alguno sobrescribirá el trabajo del otro. Se desarrolla nuevo código con interfaces desfasadas, y después se tiene que rediseñar el código al descubrir que se ha utilizado una versión equivocada de la interfaz. Los usuarios avisan de errores que no podemos reproducir porque no hay forma de volver a crear los elementos que han utilizado. Como media, los cambios en el código fuente suelen ser de un 10 por 100 al mes, y con un control manual de código
fuente no deberían crecer (Jones, 1994). La Tabla 3.1, de la página siguiente, contiene una lista completa de los errores clásicos. 3.4. La Fuga de la isla de GiIIigan
Una lista completa de los errores clásicos ocuparía muchas más paginas, pero los que se indican son los más comunes y los más serios. Como indicó David Umpress, de la Universidad de Seattle, la vigilancia que la mayoría de las organizaciones realiza para evitar estos errores es como ver una y otra vez La isla de Gilligan. Al principio de cada episodio, Gilligan, el Capitán o el Profesor llegaban con un plan tonto para salir de la isla. El plan parecía funcionar inicialmente, pero, como revelaba el episodio, algo iba mal, y al final del episodio los náufragos volvían donde habían empezado, perdidos en la isla. De igual forma, la mayoría de las compañías descubre al final de cada proyecto que han cometido otro error clásico y que han entregado otro proyecto fuera de plazo, con mayor coste, o ambas cosas. Su propia lista de malos hábitos
Debe ser cuidadoso con los errores clásicos. Puede crear listas de «malos hábitos» para evitarlos en futuros proyectos. Comience por la lista que aparece en este capitulo. Vaya incrementando la lista según se vayan acabando proyectos para aprender de los errores cometidos por su equipo. Estimule este comportamiento para otros proyectos de al empresa, para aprender de sus errores. Intercambie con los colegas de otras organizaciones y aprenda de su experiencia. Exhiba en lugar visible la lista de errores, y así la gente la vera y aprenderá sin cometer de nuevo los mismos errores.
