En cada proyecto existe un flujo de trabajo, en se recurren de forma secuencial varias etapas.

  1. Se genera una idea general de que debe hacer el proyecto. Por ejemplo un programa que controla los movimientos de trenes en una estación.
  2. Los ingenieros de sistema elaboran con los clientes un cuaderno de carga y traducen los requisitos a un diseño. Por ejemplo:  El programa tiene una ventana en que se puede editar el horario del tren. Tiene un botón “Aceptar” que copia los datos en la ventana en la base de datos.
  3. Los programadores escriben un código que hace esto.
  4. Los ingenieros de prueba comparan el comportamiento del programa con los requisitos en el cuaderno de carga

¿Esto no suene totalmente lógico? Pensar qué quieres, cómo lo quieres, hacerlo y comprobar si lo has hecho bien. Lógicamente es un ideal que en una empresa de alta tecnología no se puede conseguir siempre. Por lo tanto, el ciclo de desarrollo suele tener típicamente más bien el siguiente estilo.

  1. El director general de los tuyos y de los suyos firman un contrato, donde aparece por primera vez una fecha de entrega.
  2. Los ingenieros de sistema comienzan a ingeniarse un sistema y avanzan a buen ritmo.
  3. El jefe de los ingenieros de sistema se da cuenta que el buen ritmo haría duplicar el tiempo previsto para esta fase y pide que se diseñen los componentes en dos en lugar de cuatro semanas.
  4. Como los ingenieros de sistema no llegan, los programadores empiezan a programar aunque todavía no está de todo claro qué.
  5. Los programadores avanzan a buen ritmo.
  6. A la medida que los ingenieros de sistema completan el diseño del programa, los programadores deben modificar el código.
  7. Los ingenieros de prueba comienzan a probar el programa que a veces falla porque las partes en cuestión aún no están programadas.
  8. Entre fijar los errores reportados por los ingeniero de prueba y modificar el diseño del programa hay tímidos intentos de adaptar el programa para hacerlo más legible, orientado a objetos, modular y tal. Por alguna coincidencia hay de repente dos días enteros para esto porque el programa ya contiene todo para la primera entrega parcial al cliente.
  9. El cliente está contento porque ve que están todas las ventanas aunque los botones no funcionan. Los ingenieros de sistema sugieren un cambio propuesto por los programadores de reducir el número de
    los botones “Aceptar” a uno por ventana.
  10. Los programadores lo cambian.
  11. Mientras añaden componentes adicionales a la funcionalidad, el cliente se muestra preocupado por el elevado número de errores detectados por los ingenieros de prueba. El jefe del programa promete reducirlo.
  12. Como el tiempo entre arreglar errores y programar nuevas partes con más errores se hace corto, el jefe del grupo prefiere aumentar la rapidez. Lo que se podría dividir en dos ficheros también cabe en uno, además a estas alturas del proyecto ya no conviene agrupar los ficheros en directorios por tener una mejor modularidad.
  13. El cliente se da cuenta que no se puede configurar la aplicación. Pide editores para que los parámetros fijos sean variables inicializadas con un fichero de texto.
  14. Los programadores empiezan a reescribir su código para que todos los arrays sean de un tamaño variable.
  15. El jefe del programa se muestra preocupado, porque que fallan partes del código que funcionaban antes.
  16. Los ingenieros de sistema adaptan su documentación de diseño a lo que realmente hay programado.
  17. El programa se cuelga tres veces en una prueba con el cliente. Esto tiene máxima prioridad y justifica que al final, sí, se dividen los ficheros en varios directorios.
  18. Aún falta un 20% de la funcionalidad. La lista de errores ha crecido porque todos los programadores estaban ocupados por los fallos fatales de la semana pasada. Al mismo tiempo, se ponen por lo menos tres errores por anomalía reportada para que el número de errores parezca más pequeño.
  19. Un programador detecta que la ventana de configuración debe tener opciones que son técnicamente imposibles de realizar. Después que el programador descubra como se podría hacer algo similar, el ingeniero de sistema propone que el programador le diga como lo haya programado para que pueda adaptar el documento de diseño.
  20. El programa se cuelga sin más razón aparente cuatro días antes de la prueba final. Las revisiones de los programadores durante el fin de semana fallan por la documentación incompleta de bibliotecas externas. El cliente no acepta el programa a pruebas.
  21. Tras haber codificado toda la funcionalidad, el cliente quiere que todos los mensajes de textos sean leídos desde un fichero. Realmente ya lo quería desde el principio, pero como esto no añade funcionalidad, nunca se hizo.
  22. Tres programadores se quedan con los errores no resolubles. Uno de ellos tiene también la tarea de inventarse los comentarios para que parezca que al menos un 30% de líneas sean comentarios.
  23. Supuestamente, el cliente usará el proyecto y no se puede excluir que también será documentado.

¿Qué conclusiones podemos sacar? Pues, la primera es ciertamente que hagas un repaso a tus ideales juveniles pero sin deprimirte. Aunque parece imposible de cambiar el mundo entero, sí, es posible que al menos tú hagas lo mejor posible.

Por ejemplo, el cambio que podrías enfocar desde ahora es dejar de quejarte de que la imprevisión e la improvisación son la regla (a pesar de lo que diga tu jefe), sino que se planifica en tiempo real. Suene muy bien y es una pieza para obtener la actitud adecuada para que algún día tú serás el jefe.

Te deseo mucha suerte.

Anuncios