You are on page 1of 28

ERRORES CLASICOS del desarrollo de software Contenido 3.1. Ejemplo de errores clsicos 3.2.

Efecto de los errores en la programacin de un desarrollo 3.3. Relacin de errores clsicos 3.4. La fuga de la isla de Gilligan

EL DESARROLLO DE SOFTWARE ES UNA ACTIVIDAD COMPLICADA. Un proyecto software tpico puede presentar ms oportunidades para aprender de los errores que las planteadas a algunas personas durante toda su vida. Este captulo examina algunos de los errores clsicos que se cometen cuando se intenta desarrollar software rpidamente.

3.1. Ejemplo de errores clsicos El siguiente ejemplo es un poco como los pasatiempos de los nios, en los que intentamos encontrar todos los objetos cuyo nombre comienza con la letra << M . Cuntos errores clsicos puede encontrar en el siguiente ejemplo?

Ejemplo 3.1. Errores Clsicos Mike, un responsable tcnico de Giga Safe estaba comiendo en su oficina y mirando por la ventana una brillante maana de abril. Felicidades! Mike, ya tienes los fondos para el programa Giga Quote! Era Bill, el jefe de Mike en Giga, una compaa de seguros mdicos. Al Comit ejecutivo le ha gustado la idea de automatizar nuestras cuotas de seguro medico. Y tambin la idea de volcar cada noche las cuotas del da en la oficina principal para que siempre tengamos al da los ltimos valores de ventas. Ahora tengo una reunin, pero podemos discutir los detalles mis adelante. Buen trabajo! Mike escribi la propuesta para el programa Giga-Quote meses antes, pero estaba pensada como un programa para un solo PC, sin ninguna capacidad de

comunicacin con la oficina principal. Perfecto, esta era la oportunidad de dirigir un proyecto cliente-servidor en un moderno entorno GUI (interfaces graficas de usuario), lo que siempre haba querido hacer. El proyecto le llevara al menos un ano, y lo ocupara a tiempo completo. Mike descolg el telfono y marc el nmero de su esposa. Cario, esta noche cenaremos fuera para celebrarlo... A la maana 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 haba participado en las revisiones de la propuesta, pero no hubo tiempo de avisarle. Cuando el comit ejecutivo estudi el programa Gga-Quote, tomaron los mandos. Al comit ejecutivo le gust la idea de construir software para automatizar las cuotas de seguros mdicos. Pero queran que se pudieran transferir automticamente las cuotas locales al computador central. Y queran tener hecho el sistema antes de que se hagan efectivas las nuevas cuotas el 1 de enero. Adelantaron la fecha de finalizacin del software que propusiste del 1 de marzo al 1 de noviembre, con lo que se acort el plan propuesto en 6 meses. Mike haba estimado que el trabajo llevara 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 ests dicindome que el comit aadi 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 todo. Han aprobado el presupuesto que queras, y aadir el enlace de comunicaciones no debe ser difcil. Pediste 36 personas-mes y las tienes. Puedes reclutar a quien quiera que necesites para el proyecto e incrementar el tamao del equipo. Bill le dijo que hablase con algn otro desarrollador y que buscasen la forma de entregar el software a tiempo. Mike se reuni con Carl, otro responsable tcnico, y buscaron la forma de acortar el plan. Por que no usas C++ y diseo orientado a objetos?, coment Carl,

Sers ms productivo que con C, y el plan se acortar en uno o dos meses. A Mike le pareci bien. Carl tambin conoca una herramienta de elaboracin de informes que supuestamente acortaba el tiempo de desarrollo a la mitad. El proyecto tena bastantes informes, y por tanto esos dos cambios los llevaran basta los 9 meses. Consiguieron hardware nuevo y ms rpido, y esto les ahorraba un par de semanas. S realmente poda reclutar a desarrolladores de primerisima categora, podra bajar a 7 meses. Esto era suficientemente ajustado. Mike coment sus progresos a Bill. <Mira, dijo Bill, dejar el plan en 7 meses est bien, pero no es suficiente. El comit dej claro que el plaza de entrega eran seis meses. No me dieron opcin. Puedo daros el hardware que necesitis, pero t y tu equipo tenis que encontrar una forma de reducir el plan a seis meses, o tendris que hacer algunas horas extra para paliar la diferencia. Mike se plante el hecho de que su estimacin inicial slo fue una aproximacin y pens que quizs podra bajarla a 6 meses. De acuerdo, Bill, buscar un par de personas externas espabiladas' para el proyecto. Quizs pueda encontrar gente con experiencia en comunicaciones para que nos ayude en la descarga de datos desde el PC al mainframe. El 1 de mayo, Mike haba formado el equipo. Jill, Sue y Tomas eran buenos desarrolladores de la casa, y fueron liberados. Complet el equipo con Keiko y Chip, dos contratados externos. Keiko tena experiencia tanto en PC como en los mainframe con los que tena que conectarse. Jill y Tomas haban entrevistado a Chip y no queran contratarlo, pero Mike lo impuso. Tena experiencia en comunicaciones y estaba disponible, as que Mike lo contrat. En la primera reunin del equipo, Jill dijo que el programa Giga-Quote era estratgicamente importante para Giga Safe Corporation. Algunos de los magnates de la compaa estaran pendientes de ellos. Si tenan xito seran recompensados. Dijo que estaba seguro de que lo conseguiran. Despus de los nimos infundidos por el discurso de Bill, Mike sent con el

equipo y mostr el plan. El comit ejecutivo les haba proporcionado una especificacin aproximada, y emplearon las siguientes dos semanas en completar las lagunas. Despus se emplearan 6 semanas en el diseo. lo que dejaba 4 meses para la construccin y la prueba. Su estimacin aproximada fue que el producto final tendra unas 30.000 lneas en C++. Todos los asistentes asintieron, dando su conformidad. Era ambicioso, pero lo saba cuando se comprometieron con el proyecto. A la semana siguiente, Mike se reuni con Stacy, la responsable de la prueba. Indic que debera, tener partes del producto terminadas para probarlas no despus del 1de septiembre, con el propsito de tener un producto con todas las funciones el 1 de octubre. Mike estaba de acuerdo. El equipo acab la especificacin de los requerimientos rpidamente, y se meti en el diseo. Obtuvieron un diseo que pareca hacer buen uso de las prestaciones de C++. Acabaron el diseo el 15 de junio, adelantndose al plan, y comenzaron a codificar como locos para llegar al objetivo de tener la primera versin 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 quera que nadie se acercase a su cdigo. 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 ao siguiente, el equipo descubri que tena que modificar completamente la estructura para las nuevas tasas. El nuevo mtodo de tasacin necesitaba realizar preguntas sobre hbitos de ejercicio, en la bebida, en la comida, actividades de ocio y otros factores que no se haban incluido antes en las frmulas de tasacin. Pensaron que C++ deba protegerlos de los efectos de esos cambios. Calcularon que slo tendran que incluir nuevos valores en las tablas de tasas. Pero tendran que cambiar el dilogo de entrada, el diseo 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 diseo, Mike dijo a Stacy que se retrasaran unos das en la entrega de la primera versin para la prueba. El equipo no haba terminado el 1 de Septiembre, y Mike aseguro a Stacy que acabaran en slo uno o dos das. Los das se volvieron semanas. El lmite del 1 de octubre para entregar el producto completo para su prueba lleg y fue rebasado. Desarrollo an no haba acabado el primer producto para prueba. Stacy llamo a Bill a una reunin para tratar el plan. An no tenemos nada de desarrollo, dijo, suponamos que tendramos la primera versin el 1 de septiembre, y puesto que an 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. Djame que hable con el equipo, he prometido a 600 agentes que tendramos el programa el 1 de noviembre, Lo entregaremos a tiempo para el cambio de tasa. Bill convoc una reunin con el equipo. Este es un equipo fantstico, y debera cumplir con sus compromisos, les dijo. No se que es lo que ha ido mal, pero espero que todos trabajis duro y entreguis el software a tiempo. An podis conseguir las bonificaciones, pero ahora tendris que luchar por ellas. Desde ahora os asignar un horario de 6 das por Semana, 10 horas al da, hasta que el software est hecho. Despus de la reunin Jill y Tomas se quejaron a Mike de que no haba necesidad de que los tratasen como nios, pero accedieron a trabajar las horas que Bill quera. 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 versin al grupo de pruebas cuatro semanas despus del 1 de noviembre, y se reuni para tratar algunas de las reas problemticas que

quedaban. Toma estaba trabajando en la generacin de informes y se encontr con una barrera. La pgina resumen de cuotas incluye un grfico de barras. He utilizado un generador de informes que supona generaba grficos de barras, pero la nica forma de generarlos es en pginas individuales. Uno de los requerimientos del grupo de ventas es que hay que poner grficos de barras y texto en la misma pgina. He pensado que puedo trampear un informe con un grfico de barras pasando el texto del informe como una leyenda del objeto grfico de barras. Realmente con una trampa, pero siempre puedo volver atrs y reimplementarlo ms claramente despus de la primera versin. Mike respondi: No veo dnde est el problema. Tenemos que acabar el producto, y no hay tiempo de hacer un cdigo perfecto. Bill ha dejado bien claro que no podemos tener ms fallos. Usa ese truco. Chip contesto que su cdigo de comunicaciones estaba hecho al 95 por 100 y que funcionaba, pero que aun tena que hacer algunas pruebas de ejecucin. 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 maana del dieciseisavo da, fue Bill quien se sinti deprimido. Stacy le haba avisado de que desarrollo no haba entregado la versin completa el da anterior, La ltima semana haba dicho al comit ejecutivo que el proyecto estaba encarrilado. Otra gestora de proyectos, Claire, haba investigado en los progresos del equipo, diciendo que haba odo 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 haba 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, parecan derrotados. Un mes y medio a 60 horas semanales haban sido la puntilla. Mike pregunt cuanto tiempo les llevara acabar, pero su nica respuesta fue el

silencio. Qu me estis diciendo?, dijo. Hoy bamos a tener lista la versin con todas las funciones. La tenemos? Mitra Mike, dijo Tomas. Puedo entregar hoy m cdigo y decir que incluye toda la funcionalidad", pero probablemente necesitar tres semanas de trabajo de limpieza una vez que lo entregue. Mike pregunt qu quera decir Tomas con limpieza. No he puesto el logotipo de la empresa en cada pgina, ni que el nombre y el telfono del agente aparezca al pie de la pgina. Son pequeas 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 tcnico, y he tenido que emplear un par de horas diarias con ellos. Adems, haba olvidado hasta ahora mismo que los agentes pedan poner su nombre y su telfono en los informes. An no he implementado los dilogos de entrada para esos datos tambin tengo que hacer algunos dilogos de mantenimiento. No crea que fuesen necesarios para el hito de la "utilidad completa". Ahora Mike tambin empezaba a sentirse mal. S he odo lo que creo que he odo, me estis diciendo que necesitis 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 podran completar su parte en tres semanas. Uno por uno, cada programador le dijo que trabajara duro, y que pensaba que poda hacerlo. Al final de ese da, despus de una discusin larga e incmoda, Mike y Bill acordaron retrasar el plan 3 semanas, hasta el 5 de diciembre, siempre que el equipo prometiera trabajar 12 horas al da en vez de 10. Bill dijo que tena que demostrar a su jefe que estaba azuzando al equipo de desarrollo. La revisin del plan implicaba que tendran que probar el cdigo y preparar al personal al mismo tiempo, pero era la nica posibilidad de entregar el cdigo el 1 de enero. Stacy se quej de que el control de calidad del software no tena asignado el t iempo

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 medioda, y salieron pronto del trabajo para tener su largamente esperado descanso. Haban trabajado casi constantemente desde el 1 de septiembre. Dos das ms tarde, Stacy dio la primera lista de errores, y se desat el infierno. En dos das el grupo de pruebas identific ms 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 reunin de personal a las 8 en punto de la maana siguiente. Los desarrolladores estaban quisquillosos. Decan que haba unos cuantos errores serios, pero la mayora de los errores indicados no eran realmente errores, sino malas interpretaciones de cmo se supona que tena que funcionar el programa. Tomas indic que el error #143 era un ejemplo de eso. El informe del error #143 dice que en la pgina resumen de la cuota, el grfico de barras tiene que estar en la derecha de la pgina en vez de en la izquierda. Esto no es un error de severidad 1. Es la tpica 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 haba asignado y estimasen cunto tiempo les llevara 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. Adems, 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 esttico). El grupo de pruebas respondi que los informes resumen de Giga-Quote tenan que coincidir con informes similares generados por el programa instalado en el mainframe para polticas de renovacin, que era similar a los formatos de marketing preimpresos que la compaa haba usado durante muchos aos. Los 600 agentes de la compaa estaban acostumbrados a ver sus valores de ventas en grficos de barras a la derecha, y tenan 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 pgina el grfico de barras y el informe?, pregunt Tomas. Para poner el grfico a la derecha, tengo que rescribir ese informe concreto desde el principio, lo que significa que tengo que escribir mi propio cdigo a bajo nivel para dar formato al informe y al grfico. Mike tembl, y pidi una estimacin aproximada de cunto tiempo necesitaba. Tomas dijo que por lo menos 10 das, pero que tendra que verlo ms despacio antes de estar seguro. Antes de volver a casa, Mike dijo a Stacy y Bill que el equipo trabajarla incluso los das de fiesta y que todos los errores encontrados se corregiran 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 tena planeado desde el pasado verano. El mes siguiente Mike estuvo ocupado manteniendo al grupo unido. Durante Cuatro meses haban trabajado todo lo duro que se poda trabajar, y no crea que pudiesen hacer ms. Estaban en la oficina 12 horas al da, pero empleaban mucho tiempo leyendo revistas, pagando facturas y hablando por telfono. Pareca que se irritaban siempre que les preguntaba cunto les quedaba para reducir la cuenta de errores. Por cada error que se correga, el grupo de pruebas descubra dos nuevos. Errores cuya correccin deba haber llevado 2 minutos tenan implicaciones en el proyecto completo y podan llevar das. Pronto calcularon que no haba 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 ms. Esto es serio, dijo Bill, tengo 600 agentes locales que estn hartos de dar vueltas alrededor de un puado de aprendices de informticos. El comit ejecutivo est hablando de cancelar el proyecto. Tienes que encontrar una forma de entregar el software en las prximas dos semanas, sea como sea. Mike convoc una reunin del equipo para estudiar sus opciones. Les comunic el ultimtum de Bill y les pidi una estimacin aproximada de cundo entregaran el producto, primero en semanas, luego en meses. El equipo se call. Ninguno se arriesgaba acerca de cundo podran entregar finalmente el producto. Mike no saba qu decirle a Bill. Tras la reunin, Chip dijo a Mike que haba aceptado un contrato de otra compaa 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 haba sido responsable del aparta do de comunicaciones entre el PC y el mainframe, reasignado de apoyo al proyecto, y lo dedic a corregir los errores en el cdigo de comunicaciones del PC. Despus de luchar una semana con el cdigo de Chip, Kip concluy que tena algunos defectos conceptuales profundos que haran que nunca funcionara correctamente. Kip se vio obligado a redisear 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 reunin ejecutiva de mitad de febrero, finalmente Claire decidi que ya haba odo 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 estimacin fiable. Es un proyecto de 6 meses, y ya lleva ms de 3 meses de retraso sin un final claro. Estis trabajando tantas horas que no hacis progresos. Quiero que descansis 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 forcis el proyecto para encajarlo en un plan artificial. Si se necesitan otros 9 meses quiero saberlo. Quiero el informe del trabajo pendiente para el mircoles. 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 energas renovadas. Estuvo en la mesa de Claire para el mircoles. Revis el informe con Charles, un asesor en ingeniera del software que tambin haba revisado las estadsticas de errores del proyecto. Charles recomend que el equipo centrase sus esfuerzos en un puado de mdulos propensos a errores, que se iniciasen inmediatamente revisiones del diseo y la codificacin para corregir todos los errores y que el equipo comenzase trabajando horas fijas, para que se pudiesen hacer mtricas precisas del esfuerzo empleado en el proyecto y cunto se necesitara para terminarlo. Tres semanas ms 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 basndose en los progresos regulares que se iban haciendo, el asesor estim que el software podra entregarse, completamente probado y fiable, el 15 de mayo. Puesto que el incremento semestral de la tasa de Giga Safe tendra 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 corporacin Giga Safe mostr su aprecio al trabajo duro realizado por el equipo de desarrollo dando a cada desarrollador una bonificacin de $250

dlares. Unas cuantas semanas ms tarde, Tomas pidi una larga baja, y Jill se fue a trabajar a otra compaa. El producto final Giga-Quote se entreg en 13 meses en vez de en 6, pasndose del lmite ms 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 tena en torno a 40.000 lneas de cdigo C++ no vacas y sin comentarios, superior en ms de un 33 por 100 a las estimaciones aproximadas de Mike. Puesto que fue un producto distribuido en ms de 600 puestos internos, Gga-Quote es un hbrido entre un producto de gestin y un producto pret-a-porter. Un producto de este tamao y este tipo normalmente se debera 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 programacin de un desarrollo Michael Jackson (el cantante, no el informtico) cantaba que <<ONE bad apple don t spoil the whole bunch, baby>> (una manzana podrida no estropea el barril completo, pequea). 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 pases para examinar el impacto de 13 factores de productividad en la productividad (vos burgh et al., 1984). Los factores incluan el uso so de tcnicas de programacin modernas, dificultad del cdigo, requisitos de eficiencia, nivel de participacin del cliente en la especificacin de los requerimientos, experiencia personal y alguno mas. Asignaron a cada factor distintas categoras que esperaban asociar con una eficiencia baja, media o alta. Por ejemplo, asignaron al factor uso de tcnicas modernas de programacin valores de bajo uso, uso medio o alto. La Figura 3.1 de la pgina siguiente muestra lo que descubrieron los investigadores acerca del factor uso de tcnicas modernas de programacin.

Cuanto mas estudiamos la Figura 3.1, ms interesante resulta. Multar un patrn 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 categoras que tuvieran poca productividad realmente tenan una productividad pobre, como muestra la estrecha franja de la categora Baja en la Figura 3.1. Pero la productividad en categoras de alto rendimiento variaba mucho, segn muestra la franja ancha de la categora Alta en la figura. La productividad de los proyectos de la categora 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 mtodos recomendables, no es suficiente para obtener la mxima velocidad de desarrollo. Incluso si se hacen algunas cosas bien, como la utilizacin de tcnicas de programacin modernas, aun podemos cometer un error que anule las mejoras en la productividad. Al pensar en el desarrollo rpido, resulta tentador que todo lo que hay que hacer es identificar las causas de un desarrollo lento y eliminarlas, y despus obtendremos un desarrollo rpido. El problema es que no hay solo unas pocas causas del desarrollo lento. Es como preguntarse: Cul 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 fsicas. No podra 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 informtica. 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, pequea. Para caer en el desarrollo lento, todo lo que hay que hacer es cometer realmente un gran error; para conseguir el desarrollo rpido tenemos que evitar cometer algn gran error. La siguiente seccin enumera los grandes errores ms habituales. 3.3. Relacin de errores clsicos Algunas tcnicas 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 clsicos. Muchos de los errores tienen una apariencia seductora. Necesitamos salvar un proyecto retrasado? Metamos a ms 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 estn 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 clsicos 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 fciles de predecir. Y los errores clsicos rara vez producen los resultados que la gente espera. Esta seccin enumera alrededor de dos docenas de errores clsicos. 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 comn denominador de esos errores es que el desarrollo rpido 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 planificacin de nuestro proyecto y en la gestin de riesgos. Algunos de los errores ms significativos tienen sus propias secciones en otras partes de este libro. Otros no se tratarn ms. Para facilitar la consulta, la lista se ha dividido empleando las dimensiones de la velocidad de desarrollo: personas, proceso, producto y tecnologa. Personas A continuacin aparecen algunos de los errores clsicos relacionados con las personas. 1: Motivacin dbil. Estudio tras estudio se ha mostrado que la motivacin probablemente tiene mayor efecto sobre la productividad y la calidad que ningn 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 das de fiesta, para dar recompensas al final del proyecto que resultaron ser de menos de un dlar por cada hora extra. 2: Personal mediocre. Despus de la motivacin, 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 rpido. En el ejemplo, la seleccin del personal se hizo buscando quin podra contratarse ms rpido, en vez de quin realizara la mayora del trabajo durante la vida del proyecto. Esta tcnica consigue un inicio rpido del proyecto,

pero no determina un final rpido. 3: Empleados problemticos incontrolados. Un fallo al tratar con personal problemtico tambin 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 decisin cuando se trata con un empleado problemtico es una de las quejas ms comunes que tienen los miembros del equipo respecto de sus responsables (Larson y Lafasto. 1989). En el Ejemplo 3.1, el equipo saba que Chip era una manzana podrida, pero el jefe del equipo no hizo nada. El resultado era predecible: rehacer el trabajo de Chip. 4: Hazaas. Algunos desarrolladores de software ponen un gran nfasis en la realizacin de hazaas en los proyectos (Bach, 1995). Pero lo que hacen tiene ms 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 planificacin al lmite en el que las amenazas de desajuste del plan no se detectaban, ni se conocan o ni se informaban a la cadena de directivos hasta el ltimo minuto. Un pequeo equipo de desarrollo y sus jefes inmediatos toman como rehenes a una compaa 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 cooperacin entre los mltiples 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 dao ya est hecho. Como dijo TOM DeMarco, las actitudes ser capaz de convierten pequeos contratiempos en autnticos desastres (Mareo, 1995)

5: Aadir ms personal a un proyecto retrasado. ste es quizs el ms clsico de los errores clsicos. Cuando un proyecto se alarga, aadir mas gente puede quitar ms productividad a los miembros del equipo existente de la que aaden los nuevos miembros. Fred Brooks compara aadir gente a un proyecto retrasado con echar gasolina en un fuego (Brooks, 1975). 6: Oficinas repletas y ruidosas. La mayora 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 estn 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 rehsan 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 despus de que stos hayan sido fijados. Pueden ser simplemente conflictos de personalidad entre dos grupos. El principal efecto de esta friccin es la mala comunicacin, y los efectos secundarios de la mala comunicacin incluyen el pobre entendimiento de los requerimientos, pobre diseo 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 cancelacin 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 ms 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 podra desarrollar en 6 meses, pero ese era el plazo en que lo quena el comit ejecutivo de la compaa. 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 s e buscan problemas al pedir fondos basndose en estimaciones de planificacin 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 percepcin de que el plan de desarrollo es demasiado largo, y de que puede ser malo. Una inspeccin 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 gestin (Standish Group, 1994). 9: Falta de un promotor efectivo del proyecto. Para soportar muchos de los aspectos del desarrollo rpido es necesario un promotor del proyecto de alto nivel, incluyendo una planificacin realista, el control de cambios y la introduccin de nuevos mtodos 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 participacin 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 cooperacin estrecha slo se produce si se han implicado todos los participantes, permitiendo una coordinacin precisa del esfuerzo para el desarrollo rpido, que es imposible conseguir sin una buena

participacin. 11: Falta de participacin del usuario. La inspeccin de Standish Group descubri que la razn nmero uno de que los proyectos de Sistemas de Informacin tuviesen xito es la implicacin 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 retrasarn el proyecto. 12: Poltica antes que desarrollo. Larry Constantine indic que si hay cuatro equipos hay cuatro tipos diferentes de orientaciones polticas (Constantine. 1995a). Los polticos estn especializados en la gestin, centrndose en las relaciones con sus directivos. Los investigadores se centran en explorar y reunir informacin. Los aislacionistas estn 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 polticos y generalistas estn bien vistos por los directivos de alto nivel. Pero despus de un ao y medio, los equipos, polticos llegan a la muerte sbita. Primar la poltica en vez de los resultados es fatal para el desarrollo orientado a la velocidad. 13: Ilusiones. Estoy impresionado de ver cuntos problemas del desarrollo del software se deben a la ilusin. Cuntas 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 quizs si trabajan duro, y nada va mal, y tienen un poco de suerte, sern capaces de concluir con xito. Nuestro equipo no hace mucho trabajo para la coordinacin de las interfaces entre las distintas partes del producto, pero tenemos una buena comunicacin

para otras cosas, y las interfaces son relativamente simples, as que probablemente slo necesitaremos un da 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 difcil ver cmo va a acabar el trabajo con los niveles de personal que ha especificado con su propuesta. No tienen tanta experiencia como algunos de los dems desarrolladores externos, pero puede que compensen con energa 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 das, pero creo que alcanzarn este a tiempo. Las ilusiones no son slo 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 planificacin coherente y pueden ser la raz de ms 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 continuacin se muestran algunos de los peores errores relacionados con el proceso. 14: Planificacin excesivamente optimista. Los retos a los que se enfrenta alguien que desarrolla una aplicacin en tres meses son muy diferentes de aquellos a los que se enfrenta alguien que desarrolla una aplicacin que necesita un ao. Fijar un plan excesivamente optimista predispone a que el proyecto falle por infravalorar el alcance del proyecto, minando la planificacin efectiva, y

reduciendo las actividades crticas para el desarrollo, como el anlisis de requerimientos o el diseo. Tambin supone una excesiva presin 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: Gestin de riesgos insuficiente. Algunos errores no son lo suficientemente habituales como para considerarlos clsicos. Son los llamados riesgos. Como con los errores clsicos, Si no ejercemos una gestin activa de los riesgos, con que slo vaya mal una cosa se pasar de tener un proyecto con un desarrollo rpido a uno con un desarrollo lento. El fallo de no gestionar uno solo de estos riesgos es un error clsico. 16: Fallos de los contratados. Las compaas a veces contratan la realizacin 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 especificacin (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 utilizacin de desarrolladores externos puede ralentizar el proyecto en vez de acelerarlo. 17: Planificacin Insuficiente. Si no planificamos para conseguir un desarrollo rpido, no podemos esperar obtenerlo. 18: Abandono de la planificacin bajo presin. Los equipos de desarrollo hacen planes y rutinariamente los abandonan cuando se tropiezan con un problema en la planificacin (Humphrey, 1989). El problema no esta en el abandono del plan, sino ms 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 despus de fallar en la primera entrega, y esto es lo habitual. A partir de este punto, el trabajo no tuvo coordinacin 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: Prdida de tiempo en el inicio difuso. El <<inicio difuso es el tiempo que transcurre antes de que comience el proyecto, este tiempo normalmente se pierde en el proceso de aprobar y hacer el presupuesto. No es poco comn que un proyecto desperdicie meses o aos en un inicio difuso, y entonces se est a las puertas de un plan agresivo. Es mucho ms fcil 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 anlisis de requerimientos, la arquitectura y el diseo no producen cdigo directamente, son los candidatos fciles. En un proyecto desastroso en el que particip, ped que me enseasen el diseo. El responsable del equipo me dijo: No hemos tenido tiempo de hacer el diseo. Lo resultados de este error, tambin conocido como saltar a la codificacin, son todos demasiado predecibles. En el ejemplo, un truco de diseo en el informe del grafico de barras fue sustituido por un trabajo de diseo 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 tendrn 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, cmo vamos a encontrar 50 para hacerlo correctamente ms tarde? 21: Diseo Inadecuado. Un caso especial de escatimar en las actividades iniciales es el diseo inadecuado. Proyectos acelerados generan un diseo indeterminado, no asignando suficiente tiempo para el y originando un entorno de alta presin que hace difcil la posibilidad de considerar alternativas en el diseo. El nfasis en el diseo esta' mas orientado a la conveniencia que a la calidad, por lo que necesitar varios ciclos de diseo 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 diseo y del cdigo, eliminando la planificacin de las pruebas y realizando slo pruebas superficiales. En el ejemplo, las revisiones del diseo y del cdigo se eliminaron limpiamente para conseguir una ganancia considerable en el plan. Al final, cuando el proyecto alcanz su hito de plena funcionalidad, an tena demasiados errores y se retras ms de 5 meses. Este resultado es tpico. Acortar en un da las actividades de control de calidad al comienzo del proyecto probablemente supondr de 3 a lO das de actividades finales (Jones, 1994). Esta reduccin 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 documentacin final, incorporar entradas en el sistema final de ayuda, pulir el programa de instalacin, eliminar las funciones que no van a estar listas a tiempo y dems. 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 rpido intentan forzar la convergencia media docena de veces o ms antes de que finalmente se produzca, Los intentos adicionales de convergencia no benefician al producto. Slo son una perdida de tiempo y prolongan el plan. 25: Omitir tareas necesarias en la estimacin. Si la gente no guarda cuidadosamente datos de proyectos anteriores, olvida las tareas menos visibles,

pero son tareas que se han de aadir. El esfuerzo omitido suele aumentar el plan de desarrollo en un 20 o 30 por 100 (Van Genuchten, 1991). 26: Planificar ponerse al da ms adelante. Un tipo de reestimacin 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 reestimacin del plan. Otro tipo de error en la reestimacin se debe a cambios en el producto. Si el producto que estamos construyendo cambia, la cantidad de tiempo necesaria para construirlo cambiar tambin. En el Ejemplo 3.1, los requerimientos principales cambiaron entre la propuesta original y el comienzo del proyecto sin la correspondiente reestimacin 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: Programacin a destajo. Algunas organizaciones creen que la codificacin rpida, libre tal como salga, es el camino hacia el desarrollo rpido. Piensan que si los desarrolladores estn lo suficientemente motivados, pueden solventar cualquier obstculo. Debido a las razones que se vern claramente a lo largo de todo este libro, esto est lejos de la verdad. Este enfoque muchas veces s e presenta como un enfoque empresarial al desarrollo de software, pero realmente es slo la envoltura del viejo paradigma a destajo combinado con una planificacin ambiciosa, y esta combinacin raras veces funciona. Es un ejemplo de que dos negaciones no constituyen una verdad. Producto A continuacin se muestran los, errores clsicos relacionados con la forma en la

que se define el producto. 28: Exceso de requerimientos. Algunos proyectos tienen ms requerimientos de los que necesitan, desde el mismo inicio. La eficiencia se fija como requisito ms a menudo de lo que es necesario, y puede generar una planificacin 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 rpido. 30: Desarrolladores meticulosos. Los desarrolladores encuentran fascinante la nueva tecnologa, y a veces estn ansiosos por probar nuevas prestaciones de su lenguaje o entorno, o por crear su propia implementacin de una utilidad bonita que han visto en otro producto, la necesidad prestaciones innecesarias alarga el plan. 31: Tiras y aflojas en la negociacin. Cuando un directivo aprueba un retraso en el plan de un proyecto que progresa ms lento de lo esperado, y entonces aade tareas completamente nuevas despus de un cambio en el plan, se produce una situacin curiosa. La razn subyacente de esto es difcil de localizar, puesto que el directivo que aprueba el retraso en el plan lo hace sabiendo implcitamente que el plan estaba equivocado. Pero una vez que Se corrige, la misma persona realiza acciones explicitas para volver a equivocarse. Esto slo puede ir en contra del plan. 32: Desarrollo orientado a la Investigacin. Seymour Cray, el diseador de los supercomputadores Cray, dijo que no intentaba sobrepasar los limites de la ingeniera en ms de dos reas a la vez, porque el riesgo de un fallo es demasiado no su producto. El esfuerzo requerido para disear, implementar, probar, documentar o mantener estas

alto (Gilb. 1988). Muchos proyectos software deberan aprender la leccin de Cray. Si el proyecto fuerza los limites de la informtica porque necesita la creacin de nuevos algoritmos o de nuevas tcnicas de computacin, no estamos desarrollando software; estamos investigando en software. Los planes de desarrollo de software son razonablemente predecibles; los planes en la investigacin sobre software ni siquiera son predecibles tericamente. Si el producto tiene objetivos que pretenden aumentar los conocimientos existentes, como algoritmos, velocidad, utilizacin de la memoria y dems, debemos asumir que la planificacin es altamente especulativa, si queremos mejorar el estado del arte y tenemos algn otro punto dbil en el proyecto, recortes de personal, debilidades en el personal, requerimientos vagos, interfaces inestables con contratados externos, etc., podemos tirar por la ventana la planificacin prevista. Si queremos superar el estado del arte por todos los medios, hagmoslo. Pero no debemos esperar hacerlo rpidamente! Tecnologa El resto de los errores clsicos estn relacionados con el uso correcto o incorrecto de la tecnologa moderna. 33: Sndrome de la panacea. En el ejemplo, se confi demasiado en las ventajas proclamadas de tecnologas que no se haban usado antes (generadores de informes, diseo orientado a objetos y C++) y demasiada poca informacin sobre lo buenas que serian en este entorno de desarrollo concreto. Cuando el equipo del proyecto se aferra slo a una nueva tcnica, una nueva tecnologa o un proceso rgido, y espera resolver con ello sus problemas de planificacin est inevitablemente equivocado (Jones, 1994). 34: Sobreestimacin de las ventajas del empleo de nuevas herramientas o mtodos. Las organizaciones mejoran raramente su productividad a grandes saltos, sin importar cuantas nuevas herramientas o mtodos empleen o lo buenos que sean. Los beneficios de las nuevas tcnicas son parcialmente desplazados por

las curvas de aprendizaje que llevan asociadas, y aprender a utilizar nuevas tcnicas para aprovecharlas al mximo lleva su tiempo. Las nuevas tcnicas tambin suponen nuevos riesgos, que slo descubriremos usndolas. Ms bien experimentaremos mejoras lentas y continuas en un pequeo porcentaje por proyecto en lugar de grandes saltos. El equipo del Ejemplo 3.1 debera haber previsto como mucho un 10 por 100 de ganancia en productividad por la utilizacin de las nuevas tecnologas en vez de asumir que estaran cerca de duplicar su productividad. Un caso especial de sobreestimaciones de las mejoras se produce cuando se reutiliza cdigo de proyectos anteriores. Este tipo de reutilizacin puede ser una tcnica 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 lnea de productos, de la versin 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 automtico del cdigo fuente. Un fallo en la utilizacin del control automtico del cdigo fuente expone a los proyectos a riesgos innecesarios. Sin l, si dos desarrolladores estn trabajando en la misma parte del programa, deben coordinar su trabajo manualmente. Deberan ponerse de acuerdo para poner la ltima versin de cada archivo en el directorio maestro y verificarlos con los dems antes de copiarlas en este directorio. Pero invariablemente alguno sobrescribir el trabajo del otro. Se desarrolla nuevo cdigo con interfaces desfasadas, y despus se tiene que redisear el cdigo al descubrir que se ha utilizado una versin 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 cdigo fuente suelen ser de un 10 por 100 al mes, y con un control manual de cdigo

fuente no deberan crecer (Jones, 1994). La Tabla 3.1, de la pgina siguiente, contiene una lista completa de los errores clsicos. 3.4. La Fuga de la isla de GiIIigan Una lista completa de los errores clsicos ocupara muchas ms paginas, pero los que se indican son los ms comunes y los ms serios. Como indic David Umpress, de la Universidad de Seattle, la vigilancia que la mayora 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 Capitn o el Profesor llegaban con un plan tonto para salir de la isla. El plan pareca funcionar inicialmente, pero, como revelaba el episodio, algo iba mal, y al final del episodio los nufragos volvan donde haban empezado, perdidos en la isla. De igual forma, la mayora de las compaas descubre al final de cada proyecto que han cometido otro error clsico y que han entregado otro proyecto fuera de plazo, con mayor coste, o ambas cosas. Su propia lista de malos hbitos Debe ser cuidadoso con los errores clsicos. Puede crear listas de malos hbitos para evitarlos en futuros proyectos. Comience por la lista que aparece en este capitulo. Vaya incrementando la lista segn 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.

You might also like