Hay una cosa en la que últimamente ando muy interesado: el diseño, la planificación y en general la metodología del un proyecto. Me gustaría, sobre todo, saber cómo trabajáis en vuestro trabajo. ¿Se hace diseño real que luego se sigue? ¿Hay planificaciones más allá de una semana? ¿se sigue una metodología más o menos bien?
En mi caso, son proyectos de alrededor de uno o dos años. Se hace una planificación con el microsoft project que ni siquiera llega a los programadores. También se hace un diseño UML que tampoco llega a los programadores. Ambas cosas se hacen para hacer el correspondiente documento que se entrega al cliente al principio.
A los programadores se les de una idea vaga de un tema concreto que deben hacer y a base de mucho preguntar y hablar con el responsable del proyecto, van día a día haciendo e improvisando. Según se van viendo cosas, el resposable del proyecto o el mismo cliente, van cambiando de idea, con lo que hay que ir rehaciendo o añadiendo sobre la marcha. En general el programador trabaja aislado durante uno o dos meses, hasta que termina su tema y empieza otro. Hay algo de relación con los demás -sobre todo peleas- en los momentos de integración, en los que cada uno ha hecho bien su parte y si no funciona será culpa del otro.
¿Es esta la forma de trabajar de la mayoría de la gente?
Lo peor de todo, es que muchas de las personas, sobre todo las más antiguas que ahora son jefes, que llevan trabajando así muchos años, piensan que es la forma buena de hacerlo. Piensan que hacer el diseño es perder el tiempo, puesto que nunca se sigue, que las planificaciones son perder el tiempo puesto que nunca se cumplen y además no se puede estimar bien. Lo importante es que los programadores le echen ganas al asunto -y horas extras-, que sean espabilados y echen horas, que sean trabajadores y echen horas y sobre todo, que echen horas.
Por supuesto, no se hacen test unitarios, el código apenas se comenta y cada vez que descubrimos una de las "buenas prácticas" de programación, descubrimos que es justo lo contrario de lo que hacíamos habitualmente.
¿Es esto siempre así en proyectos largos con mucha gente?
June 12th, 2007 at 7:32 am
Bueno, efectivamente lo que cuentas es lo que pasa en la realidad.
Pero yo en parte estoy de acuerdo con esa forma de trabajar.
El producto que resulta no tiene nada que ver con el que se diseñó en un principio.
Y bueno, lo de las pruebas unitarias… si, es muy bonita esa teoría, pero en el 90% de los casos es imposible hacer una prueba unitaria de un módulo. Muchas veces el módulo a probar no recibe un dato simple y devuelve un dato simple, sino que recibe/devuelve estructuras muy complejas, que muchas veces el resultado de cada ejecución es distinto y en el que otras veces requiere cierta interacción del usuario.
Vamos, que al final las pruebas unitarias son imposibles de diseñar.
June 12th, 2007 at 8:20 am
En mi caso recuerdo mis tiempos de Indra y era como dices, después en C.A.S.A. era prácticamente lo mismo aunque cuando yo entré allí el proyecto ya estaba a medio hacer.
Actualmente trabajo en otro tipo de proyectos y hay de todo. En general la gente intenta utilizar una metodología y hay empresas que se certifican en CMMi. Recuerdo el caso más extemo en el que participe, eran proyectos relacionados con aviónica y en los documentos de diseño aparecía el pseudo-código de las funciones del estilo:
-Nombre del método y variables de entrada y salida.
-Pseudo-código: Si a es cero sumar b y c …
Y los programadores traducían ese pseudo-código al código en el lenguaje correspondiente.
En mi opinión la metodología es interesante seguirla como mínimo para conocer si las cosas van bien en el proyecto y si nos vamos a desviar, es decir, anticiparnos a los problemas que suelen surgir al final del mismo (escasez de tiempo y recursos fundamentalmente). Si no seguimos una metodología nunca podremos prever adecuadamente estos problemas y al final pasará lo de siempre: retrasos y pérdida de dinero.
June 12th, 2007 at 9:12 am
Donde yo trabajo, se desarrollan sobre todo proyectos de tamaño medio y medios-largos.
Para los de tamaño medio, suelo conocer gran parte de la planificación, como mínimo de la que te afecta. Nada de diseño, trabajas sobre unos catálogos de requisitos, unos bocetos de la interfaz… y al lío.
Para los medios-largos hay más documentación y algún diseño técnico de alguna parte un poco “especial”, que más o menos se cumple. En estos suelo perder visibilidad de las planificaciones, conozco la mía como mucho en vistas a un mes, pero tampoco se suelen cumplir.
Pero actualmente estoy en un proyecto de larga duración donde la parte de análisis y diseño lo lleva una empresa de las “gordas”, en este sí que hay diseños técnicos de toda la aplicación y otro mucho papel. El problema es que pasa lo que comentas, está completamente orientado a entregárselo al cliente pero luego lo leemos los programadores y no hay por donde cogerlo, tenemos que acabar hablando con nuestro responsable de desarrollo a ver si entre todos sacamos alguna cosa clara. Sobre la planificación, con muchos cambios de forma continua, a veces no llegas a conocer lo que vas ha hacer esa semana.
Que tranquilo me he quedado
June 12th, 2007 at 9:21 am
#1, Dios!, que las pruebas no sirven para nada!?. OMFG!. Mi experiencia es corta (aún estoy con mi pfc), pero desde luego que sin tener mi pila de test (unitarios y otros que no lo son tanto) me hubiese costado mucho, mucho más tiempo (y salud mental).
Donde estoy la verdad que creo que soy el único que hace test y el único que intenta seguir una planificación. Se hacen esquemas uml conceptuales, pero bastante lejanos a la realidad (y algunos con burradas increíbles), la metodología brilla por su ausencia. Lo más triste es que supuestamente somos todos ingenieros o en vías de serlo…
June 12th, 2007 at 9:29 am
#4 Yo soy ingeniero y hablo sobre mi experiencia.
Si haces una función que chequee que un mail es correcto pues nada, una pruebecita unitaria te va como anillo al dedo, pero es que un caso así no se da practicamente nunca.
Cuando estás en un proyecto grande al final tienes por ejemplo un procedimiento que podría exportar un objeto (hablando al nivel de negocio), desde la BBDD a un XML.
Eso no se puede probar, por ejemplo porque el estado de ese objeto es distinto, en cada momento con lo que el input es siempre distinto.
En otras ocasiones me he encontrado con que ejecutar el procedimiento X sobre la BBDD hace que cambie su estado (actualizaciones, inserciones, etc…) y la única manera de volver a ejecutar ese procedimiento de nuevo en las mismas condiciones es restaurar un backuo de la BBDD. Y creeme, he visto restauraciones de BBDD que tardaban unas 2 horas. No es viable.
June 12th, 2007 at 9:48 am
Aunque chuidiang hablaba de diseño y planificación voy a entrar a hablar de testing.
Si bien es cierto que en muchos casos el testing puede llegar a ser muy pesado hay que valorar en primer lugar la criticidad de una aplicación para decidir si el testing puede ser fundamental en nuestra planificación o simplemente algo que está ahí porque nos va a implicar un sobreesfuerzo enorme.
Aún así el testing es siempre necesario. Los programadores deben realizar un test unitario de lo que hacen y debería estar en la planificación del proyecto. Esto es fundamental porque siempre hay errores y en la medida de lo posible deberían ser encontrados cuanto antes en el tiempo mejor.
Igualmente podemos decir de los tests de integración y tests funcionales.
Un buen producto debe ser entregado con el menor número de errores posibles y esto implica el diseño de un número de tests adecuado, y para eso debería existir en la empresa un pequeño grupo especializado en testing teniendo en cuenta para ello el tamaño de la empresa y el número de proyectos que puede llevar en paralelo por supuesto.
En fin, en mi opinión testing SI en su justa medida, y cuando se hace la oferta se añade el tiempo necesario para el mismo. Que no queden las horas de testing en el olvido.
June 12th, 2007 at 12:44 pm
Solo aclarar que yo hablaba de las llamadas pruebas unitarias, las cual veo un poco inútiles.
Otra cosa es que a parte de los desarrolladores, haya un equipo de pruebas. Eso es otra cosa, y debería ser imprescindible. En la práctica…jeje