Errores comunes enumerados

Algunas prácticas de desarrollo han sido elegidas tan frecuentemente, por tanta
gente, con malos resultados tan predecibles que merecen ser llamadas “errores
comunes”. La mayoría de estos errores tienen un lado seductor. ¿Se necesita rescatara
un proyecto demorado? ¡Agreguemos más gente! ¿Queremos reducir el tiempo de
desarrollo? ¡Hagamos un plan mas agresivo! ¿Uno de tus colaboradores molesta al l
resto del equipo? ¡Esperemos que termine el proyecto y lo despedimos! ¿Tenemos un
proyecto urgente para realizar? ¡Tomemos a todos los desarrolladores que tenemos
disponibles y empecemos a trabajar lo antes posible!
Desarrolladores, lideres, y clientes normalmente tienen buenas razones para
llevar a cabo las decisiones que toman, y el lado seductor de los errores clasiscos es una
parte de la razón por la cual son tan comunes. Pero como se han cometido tantas veces,
sus consecuencias se han vuelto fáciles de predecir y rara mente producen los resultados
esperados.
Esta sección enumera tres docenas de estos errores, y personalmente he visto
cometer por lo menos una vez cada uno, y yo mismo he cometido mucho de ellos.
El común denominador para esta lista es que no necesariamente lograras un
desarrollo veloz si evitas el error, pero definitivamente demoraras el desarrollo si no lo
evitas.
Si algunos de estos errores te es familiar, tómalo en serio. Mucha otra gente a
cometido los mismos errores, y una vez que entiendas su efecto en el avance del
proyecto podrás usar esta lista como ayuda para la administración de riegos y el
planeamiento de tu proyecto.
Para facilitar la consulta, la lista ha sido dividida en personas, procesos, producto
y tecnología.

Personas
A continuación algunos de los errores mas comunes relacionados con las
personas.
1. Falta de motivación. Todos los estudios han demostrado que la motivación
tiene un mayor efecto en la productividad y la calidad que cualquier otro factor.
En el caso de estudio 3-1, el líder siguió unos pasos que bajaron la moral del
equipo a lo largo del proyecto, dar una mala charla motivadora al principio,
requerir tiempo extra en la mitad del proyecto, tomarse unas largas vacaciones
cuando el equipo estaba trabando en días no laborables, o brindar bonus menores
a un dólar para las horas extra.
2. Personal débil. Después de la motivación, cada una de las capacidades
individuales de los integrantes del equipo o su relación como equipo sea
probablemente el factor que más influya en la productividad. Contratar lo que
esta al fondo del barril atentará contra el desarrollo veloz. En el caso de estudio
el personal fue contratado en base a quien estaba disponible antes en lugar de
quien estaba mejor preparado para soportar una carga de trabajo mayor. Esa
practica llevo al proyecto a tener un comienzo rápido, pero no una rápida
completitud.
3. Empleados problemáticos sin control. No poder tratar con empleados
problemáticos atenta contra el desarrollo veloz. Este problema común ha sido
bien comprendido por lo menos desde que Gerald Weinberg publicó Psicology
of Computer Programming en 1971. El no poder tomar acciones para manejar a
un empleado problemático es la queja más que el equipo le expresa a su líder. En
el caso de estudio 3-1, el equipo sabia que Chip esta la manzana podrida, pero el
líder no hacia nada al respecto. El resulta (rehacer todo el trabajo de Chip) era
predecible.
4. Actitudes heroicas. Algunos líderes de proyecto le dan mucho énfasis a las
actitudes heroicas en sus proyectos, pero creo que esto le trae más problemas
que beneficios al proyecto. En el caso de estudio la administración intermedia le
dio mas importancia a las actitudes “yo puedo hacerlo” que al progreso
constante y consistente, y al reporte de los avances. El resultado fue un patrón de
planificación arriesgada donde las desviaciones inminentes no se detectaron, ni
se dieron a conocer al managment sino hasta el último momento. Un equipo de
desarrollo chico mantuvo a toda la compañía como rehen al no admitir que iban
a tener problemas para alcanzar las fechas planificadas. Un énfasis en actos
heroicos fomenta tomar grandes riesgos, y desanima la cooperación entre todos
los stakeholders del proyecto.
Algunos líderes fomentan este comportamiento cuando se concentran solo en las
actitudes “yu puedo hacerlo”. Poniendo estas actitudes sobre el reporte de
estado, estos líderes minimizan sus posibilidades de tomar una acción correctiva
en caso de demoras. Ni siquiera saben que tienen que tomar una acción
correctiva hasta el momento en que el daño ya fue hecho. Como dice Tom
DeMarco, las actitudes t
“yo puedo hacerlo” convierten un pequeño problema en un gran desastre.
5. Agregar gente a un proyecto ya empezado. Este es quizás el error mas
frecuente de esta lista. Cuando un proyecto está demorado, agregar mas personas
puede consumir mas productividad de las que ya están que sumarla a través de
las nuevas. Fred Brooks comparó agregar gente con apagar un fuego con nafta.
6. Oficinas ruidosas y llenas. La mayoría de los desarrolladores califican su
ambiente laboral como insatisfactorio. Aproximadamente el 60 por ciento afirma
que no es suficientemente silencioso ni privado. Aquellos trabajadores que
trabajan en oficinas silenciosas y privadas, tienen a tener mucho mejor
desempeño que aquellos que operan en puestos de trabajo ruidosos y atestados o
cubículos con las mismas características. Un ambiente ruidoso y lleno hace más
el proceso de desarrollo.
7. Fricción entre los desarrolladores y clientes. Los conflictos entre los
desarrolladores y los clientes pueden surgir de varias maneras. Los clientes
pueden sentir que los desarrolladores no cooperan al no querer adherirse al
cronograma de desarrollo que ellos desean, o cuando no entregan en las fechas
prometidas. Los desarrolladores pueden sentir que los clientes insisten sin razón
para llevar cabo cronogramas imposibles o cambiar requerimientos una vez que
estos ya han sido establecidos. También pueden existir un simple conflicto de
personalidad entre las partes.
El principal efecto de esta fricción es la falta de comunicación, y los efectos
secundarios de la falta de comunicación incluyen una pobre comprensión de los
 requerimientos, un mal diseño de interfaz de usuario, y, en el peor de los casos,
los clientes se niegan a aceptar el producto terminado. En promedio, la fricción
entre clientes y desarrolladores es tan severa que ambas partes consideran
cancelar el proyecto. Esta fricción es tiempo consumido en potencia, y distrae
tanto a los clientes como a los desarrolladores del verdadero trabajo que conlleva
el proyecto.
8. Expectativas irreales. Una de las causas más comunes de fricción entre los
desarrolladores y sus clientes o líderes son las expectativas irreales. En el caso
de estudio 3-1, Bill no tiene razón alguna para pensar que el programa Giga-
Quote puede ser desarrollado en seis meses excepto que la compañía lo necesita
en ese tiempo. El error de Mike al tratar de corregir esa expectativa irreal fue
una fuente de problemas aun mayor. En otros casos, los lideres de proyecto o
desarrolladores se buscan problemas al ser optimistas al momento de estimar. A
veces prometen funcionalidades inalcanzables. Aunque las expectativas irreales
no alargan los tiempo de desarrollo por si mismas contribuyen a la percepción
que los planes son muy largos, y que están mal. Una encuesta del Standish
Group listo a las expectativas realistas como uno de los cinco factores clave para
asegurar el éxito de un desarrollo hecho in-site.
9. Falta de un esponsoreo efectivo. Es necesario que el proyecto sea
esponsoreado por el alto mando para poder dar soporte a muchos aspectos del
desarrollo veloz incluyendo, la planificación real, el control de cambios, y la
introducción de nuevas practicas de desarrollo. Sin un esponsoreo efectivo otro
personal del alto mando de tu organización puede forzarte a aceptar fechas de
entrega irreales o hacer cambios que boicotean tu proyecto. El consultor
australiano Rob Thomsett afirma que la falta de un esponsor asegura
prácticamente el fracaso del proyecto.
10. Los stakeholder no se comprometen con el proyecto. Todos los participantes
más importantes en un proyecto de software deben comprometerse con el
mismo. Esto incluye al esponsor, líderes técnicos, miembros del equipo,
marketing, usuarios finales, clientes, y cualquiera que tenga algo que ver con el
proyecto. La cooperación que surge solo cuando tenes a todos los involucrados
comprometidos con el proyecto permite una coordinación que es imposible de
conseguir sin ese compromiso.
11. Falta de aporte por parte del usuario. La encuesta del Standish Group
encontró que la razón numero uno para que un proyecto de software tenga éxito
es que el usuario este involucrado.
12. Política puesta por sobre el fundamento. Larry Constantine investigo cuatro
equipos, cada uno con diferente orientación política. “Políticos” especializados
en las relaciones con sus lideres. “Investigadores” concentrados en hallar y
obtener información. “Aislados” se concentran en si mismos, creando limites en
el proyecto los cuales no son expuestos a personas que no pertenezcan al equipo.
Los “Generalistas” hicieron un poco de todo, mejorarlos las relaciones con sus
lideres, llevaron a cabo actividades de búsqueda de información y coordinaron
con otros equipos durante su trabajo. Constantine observó que los Políticos y
Generalistas estaban bien estimados por sus lideres. Pero después de un año y
medio los Políticos perdieron su credibilidad. Poner la política por sobre los
resultados es fatal para el desarrollo veloz.
 13. Hacerse ilusiones. Estoy sorprendido de cómo tantos problemas en el desarrollo
de software se deben a hacerse ilusiones. ¿Cuantas veces hemos escuchado cosas
como?
“Nadie del equipo creía que realmente podían completar el proyecto con el
cronograma que les habían dado, pero pensaron que tal vez si trabajaban duro,
nada salía mal, las interfaces eran relativamente simples y tenían un poco de
suerte, quizás lo podían lograr.”
“Nuestro equipo no ha hecho mucho para coordinar las interfaces entre las
distintas partes del proyecto, pero hemos tenido buena comunicación en otras
cosas, y las interfaces son relativamente simples, así que probablemente tome
uno o dos días eliminar los bugs.”
“Sabemos que fuimos con el contratista de segunda línea en el subsistema de
base de datos y era difícil de prever que completaran la tarea con el nivel de
staff que especificaron en su propuesta. No tenían tanta experiencia como los
otros contratistas, pero quizás puedan compensar esa falta de experiencia con
energía. Quizás lleguen a tiempo.”
“No necesitamos mostrarle la ultima ronda de prototipos al cliente. Estoy
seguro que ya sabemos lo que quiere.”
“El equipo dijo que va a tomar un esfuerzo extraordinario llegar a la fecha de
entrega, y que perdieron su primer hito por unos pocos días, pero creo que esta
vez llegarán a tiempo.”
Hacerse ilusiones no es solo optimismo. Es cerrar los ojos esperando que algo
funcione cuando no tienes ninguna razón para pensarlo. Hacerse ilusiones al
principio del proyecto lleva a grandes explosiones al final. Tira por la borda al
planeamiento y puede ser la causa principal de mas problemas del software que
los de todas la otras combinadas.

Procesos
Los errores relacionados con los procesos hacen más lento el desarrollo porque
malgastan el talento y esfuerzo de las personas. A continuación algunos de los peores
errores relacionados con los procesos.
14. Cronogramas demasiado optimistas. Los desafíos que tiene una persona que
lleva a cabo un proyecto de tres meses son muy diferentes a los que tiene una
persona que lleva a cabo uno de un año. Establecer un plan demasiado optimista
conduce un proyecto al fracaso, al reducir su alcance, dándole poca importancia
a un planeamiento efectivo y abreviando tareas criticas como el análisis de
requerimientos y el diseño. También pone mucha presión en los desarrolladores,
lo cual atenta contra su moral y productividad. Esto fue la mayor fuente de
problemas del caso de estudio 3-1.
15. Administración de riesgos insuficiente. Algunos errores se han cometido
tantas veces como para ser considerados clásicos. Otros son únicos para cada
proyecto. Como con los errores clásicos, si no administrar riesgos activamente,
solo una cosa tiene que ir mal para convertir tu proyecto de veloz a lento. No
administrar riesgos es uno de los errores clásicos más común.
16. Errores del contratista. Las compañías algunas veces contratan partes de un
proyecto cuando están muy apuradas como para hacer el trabajo internamente.
 Pero los contratistas frecuentemente entregan el trabajo, tarde, con poca calidad
o sin cumplir las especificaciones. Los riesgos como requerimientos inestables o
interfaces mal definidas pueden incrementarse cuanto se agrega a un contratista
a juego. Si la relación con el contratista no esta administrada cuidadosamente, el
uso de ellos puede alentar el proyecto en lugar de demorarlo.
17. Planeamiento insuficiente. Si planeas para lograr un desarrollo veloz, nunca
esperes lograrlo.
18. Abandono de la planificación bajo presión. Los líderes hacen planificaciones
y las abandonan cuando entran en un problema con el cronograma. El problema
no es tanto abandonar la planificación sino no crear un sustituto y luego caer en
un modelo code-and-fix. En el caso de estudio 3-1, el equipo abandono su
planificación cuando no llegaron a la primer entrega, y esto es típico. El
resultado fue que el trabajo luego de ese punto perdió la coordinación y se
volvió pesado, al punto de que Jill incluso empezara a trabajar en un proyecto
para su propio grupo sin que nadie lo notara.
19. Tiempo desperdiciado durante el prelanzamiento del proyecto. El
prelanzamiento del proyecto es el tiempo anterior al que el proyecto empiece, es
tiempo que se gasta normalmente en el proceso de aprobación y presupuesto. Es
común que en un proyecto se gasten meses o años en esta etapa y luego llega a
la puerta con un cronograma agresivo. Es mucho más fácil, barato y menos
riesgoso ahorrar algunas semanas o meses durante el prelanzamiento comparado
con comprimir un cronograma de desarrollo.
20. Acortar tareas. Los líderes de proyecto que están en apuros tratan de cortar
actividades no esenciales, y como el análisis de requerimientos, arquitectura y
diseño no producen código directamente, son blancos fáciles. En un proyecto
desastroso que tome a cargo, pregunte para ver el diseño. El equipo me dijo, “No
tuvimos tiempo para hacer un diseño.”
También conocido como “saltar a la codificación”, los resultados de este error
son muy predecibles. En el caso de estudio, un hack en el diseño del grafico de
barras sustituyo a un trabajo de diseño de calidad. Antes de que el producto
pudiera ser enviado, se tuvo que eliminar el hack y el trabajo de calidad se tuvo
que hacer de todas formas. Los proyectos que escatiman en este tipo de
actividades tienen que hacer el mismo trabajo en otro lugar pero con costos entre
10 y 100 veces superiores comparado con hacerlos como correspondía. Si no
puedes encontrar 5 horas extra para hacer el trabajo bien la primera bien ¿Dónde
vas a encontrar 50 para hacerlo bien mas tarde?
21. Diseño inadecuado: Un caso especial de acortar tareas es el diseño inadecuado.
Los proyectos en apuros estropean el diseño al no asignarle suficiente tiempo y
creando un entorno de cocina a presión que hace pensar el hecho de considerar
alternativas para el diseño. El énfasis en el diseño, según la experiencia, ayuda a
la calidad, entonces deberías necesitar muchos ciclos de diseño antes de terminar
de completar el sistema.
22. Acortar QA (aseguramiento de la calidad). Los lideres de proyectos que están
en apuros normalmente cortan los extremos eliminando revisiones de código y
diseño, pruebas de integración, y realizando solo pruebas de unidad. En el caso
de estudio, a las revisiones de diseño y código solo se les asigno un pequeño
lapso de tiempo para poder obtener un adelanto con respecto al cronograma.
 Cuando el proyecto llego a su hito de funcionalidad completa estaba lleno de
errores como para poder lanzarlo en cinco meses. Este resultado es típico.
Acortar un día de QA al principio del proyecto, te costará aproximadamente de 3
a 10 días mas tarde. Esta ineficiencia atenta contra la velocidad de desarrollo.
23. Puntos de control insuficientes. En el caso de estudio, había muy pocos puntos
de control que permitieran detectar advertencias de posibles demoras, y los
pocos que estaban al principio fueron abandonados cuando el proyecto presento
problemas. Antes de que puedas mantener un proyecto encaminado, debes saber
si esta encaminado.
24. Convergencia prematura o muy frecuente. Un poco antes que un producto
este planificado para ser lanzado hay presión para preparar su release, mejorar la
performance, imprimir la documentación final, incorporar la ayuda del sistema,
pulir la instalación del programa, quitar la funcionalidad que no estará lista a
tiempo y más. En proyectos en apuros, esta la tendencia a forzar la convergencia
diariamente. Como no es posible forzar a un producto a estar listo cuando uno lo
desea, algunos proyectos tratan de forzar la convergencia una docena de veces
antes de que lo logran. Los intentos de convergencia extra no benefician al
producto. Desperdician tiempo y alargan el cronograma.
25. Omitir tareas necesarias en las estimaciones. Si las personas no son
mantienen cuidadosamente registros de proyectos previos, se olvidan de las
tareas menos visibles, pero esas tareas suman. El esfuerzo omitido agrega
normalmente entre un 20 y 30 por ciento a un cronograma de desarrollo.
26. Planificar la puesta al dia para mas adelante. Si estas trabajando en un
proyecto de seis meses y te toma tres meses llegar al hito de los dos meses, ¿qué
haces? Muchos proyectos simplemente planifican la puesta al dia para más
adelante, pero nunca lo hacen. Aprendes más del producto a medida que lo vas
construyendo, eso incluye saber cuanto te va a tomar hacerlo. Ese aprendizaje
necesita ser reflejado en la planificación.
Otro tipo de error de reestimación aparece cuando un producto cambia. Si el
producto que estas haciendo cambia, la cantidad de tiempo que necesitas para
construirlo tambien cambia. En el caso de estudio 3-1, los requerimientos mas
importantes cambiaron entre la propuesta original y el comienzo del proyecto,
sin que le correspondiera reestimación alguna de tiempo o recursos. Apilar
nuevas funcionalidades sin ajustar el cronograma garantiza que no vas a llegar a
la fecha de entrega.
27. Programación code-like-hell. Algunas organizaciones piensan que codificar
rápido, flexible y “como te parezca” es una ruta para el desarrollo veloz. Ellas
afirman que si los desarrolladores estuvieran lo suficientemente motivados,
pueden sobrellevar cualquier obstáculo. Pro razones que se volverán claras en
este libro, esto está muy lejos de ser verdad. El modelo empresarial es
usualmente una fachada para el viejo paradigma code-and-fix combinado con
cronogramas ambiguos, y nunca funciona. Es un ejemplo de dos cosas malas no
haciendo nada bien.

Producto
A continuación hay algunos de los errores clásicos relacionados a la forma en
que el producto está definido.
 28. Requerimientos excesivos. Algunos proyectos tienen mas requerimientos de los
que deberían tener. A la performance se la escribe como requerimiento más
frecuentemente de lo que debería ser, y esto puede prolongar innecesariamente
el tipo de desarrollo. Los usuarios tienden a estar menos interesados en las
funciones complejas, las funciones complejas se terminan agregando de manera
desproporcionada.
29. Flujo de funcionalidad. Aun si pudiste evitar los requerimientos excesivos, un
proyecto promedio experimenta un cambio del 25 de sus requerimientos durante
su ciclo de vida. Ese cambio puede producir como mínimo un 25 por ciento de
incremento en el tiempo de desarrollo, que puede ser fatal para un desarrollo
veloz.
30. Desarrollo en exceso. Los desarrolladores están fascinados por las nuevas
tecnologías y a veces están ansiosos por probar nuevas funcionalidades del
leguaje o ambiente o para crear su propia implementación de una funcionalidad
que vieron en otro producto, sin importar si es requerido en su producto. El
esfuerzo necesario para diseñar, implementar, probar, documentar y suportar
funciones innecesarias alarga el tiempo de desarrollo.
31. Tire y afloje. Una estrategia rara de negociación ocurre cuando un líder aprueba
un desvió en el plan de un proyecto que progresa más lento de lo esperado y
agrega tareas completamente nuevas luego de que se cambie el plan. La razón
subyacente para esto es que el líder esta implícitamente aceptando que el plan
estaba erróneo. Pero una vez que ha sido corregido, la misma persona toma una
acción explicita para estropearlo nuevamente.
32. Desarrollo orientado a investigación. Seymour Cray, el diseñador de las
supercomputadoras Cray, dice que el no intenta exceder los limites de la
ingeniería en mas de dos áreas al mismo tiempo porque la exposición al riesgo
es muy alta. Muchos proyectos de software podrían aprender una lección de
Cray. Si tu proyecto roza los limites de la ciencia de la computación por la
necesidad de crear nuevos algoritmos o nuevas practicas, no estas haciendo
desarrollo de software; estás investigando. Los cronogramas de desarrollo de
software son predecibles, los de investigación no son ni teóricamente
predecibles.
Si tenés un producto que presiona al estado del arte, algoritmos, velocidad, uso
de memoria, deberás esperar una muy poca certeza en tu calendario. Si estas
presionando al estado del arte tienes otra debilidad en tu proyecto, faltas de
personal, personal débil, requerimientos vagos, interfaces inestables con los
contratistas, puedes tirar la planificación predecible por la ventana. Si queres
avanzar el estado del arte, hazlo. Pero no esperes hacerlo rápido.

Tecnología
Los errores clásicos que quedan tienen que ver con el uso y mal uso de la
tecnología moderna.
33. Síndrome de la bala de plata. En el caso de estudio se le dio demasiada
confianza a los beneficios publicitados por tecnologías no usadas (generador de
reportes, diseño orientado a objetos y C++) y muy poca información sobre como
ayudarían en este entorno de desarrollo en particular. Cuando los equipos de
 proyecto se atan a una sola metodología o nueva tecnología y esperan resolver
sus problemas de planificación, están inevitablemente mal encaminados.
34. Ahorros sobre estimados para las nuevas herramientas o métodos. Las
organizaciones rara vez mejoran su productividad en grandes saltos, no importa
cuan buenas o cuantas sean las nuevas herramientas o métodos. Los beneficios
de las nuevas prácticas están acotados por las curvas de aprendizaje asociadas, y
aprender a usar esas nuevas prácticas aprovechando al máximo sus ventajas
toma tiempo. Las nuevas practicas acarrean nuevos riesgos, los cuales solo
podrás descubrir al usarlas. Es mas probable experimentar pequeños y
constantes mejoras en algunos pocos proyectos que un saltos bruscos en el
incremento de la productividad. El equipo del caso de estudio 3-1 debería haber
planeado como mucho un 10% de incremento en la productividad con el uso de
las nuevas tecnologías en lugar de asumir que iba a doblar su productividad.
Un caso especial de ahorros sobreestimados aparece cuando los proyectos reusan
código de otros proyectos. Esta puede ser una aproximación muy efectiva, pero
los ahorros de tiempo rara vez son tanto como se esperan.
35. Cambio de herramientas en el medio del proyecto. Este es un viejo recurso
que rara vez funciona. Algunas veces puede tener sentido actualizarse de modo
incremental en la misma línea de productos, de la versión 3 a la 3.1 o a veces a
la 4. Pero la curva de aprendizaje, y los errores inevitables hechos con una
herramienta totalmente nueva cancelan cualquier beneficio cuando estás a la
mitad de un proyecto.
36. Falta de control automático de fuentes. No usar una herramienta de control de
fuentes automatizada expone al proyecto a riesgos innecesarios. Sin esta
herramienta, si dos desarrolladores están trabajando en la misma parte del
programa, tienen que coordinar su trabajo manualmente. Pueden ponerse de
acuerdo en poner la última versión de cada archivo en un directorio maestro y
que cada uno chequee antes de copiar archivos en ese directorio. Pero alguien
siempre pisa el trabajo de otro. La gente desarrolla nuevo código con las
interfaces desacralizadas y tienen que rediseñar su código cuando descubren que
estaban usando la versión equivocada de la interfaz. Los usuarios reportan
defectos que no puede reproducir porque no hay forma de recrear la versión que
están usando. En promedio, los cambios en el código fuente están alrededor del
10 por ciento por mes, y el control manual de fuentes no lo puede soportar.