por
pobrecito hablador
el Jueves, 10 Julio de 2003, 18:58h
(#196258)
Las personas a las que les haya servido caben en una cabina telefónica.
Y eso por supuesto es causa directa de que la documentación no sirve. Porque como tu eres inmortal y eterno, y siempre tendrás tiempo para enseñarselo a los más jovenes...
Resumen: Se gastaron aproximadamente 2000 horas de trabajo en realizar una labor que se utilizó para ahorrar unas 20 horas.
En definitiva, que no sabéis documentar. Y por eso, la documentación es mala. Lo que creo es que vuestro jefe de proyecto se debería reeplantear estudiar informática... esas cosas no te pasan ni haciendo prácticas...
Vamos, que es una teoría muy bonita en la que todos confiamos y que es basura
Los ignorantes desde su nivel lo ven todo muy claro... Porque quienes escriben la materia no han estudiado cientos de proyectos exitosos y tampoco saben utilizar la estadística para sacar conclusiones... Porque tu experiencia en UN SOLO proyecto (seguramente fracasado) nos ilumina la verdad. Chico, no confundas suerte y habilidad de la gente para salir del caos con algo bien hecho. ¿Cómo se llama tu empresa? Es por ir a llevar allí la basura...
Siempre que se decida alegremente que algo necesita documentación se debería evaluar muy seriamente la 'necesidad'. El 98% de las veces sólo es necesario documentar el código y el diseño del programa inicial.
Por supuesto existe un 2% en el que es absolutamente esencial por ser sistemas críticos en los que ahorrarse un minuto en la corrección de un problema es esencial. El resto es pura burocracia de foto
Chico, te has lucido. Su tu "experiencia" te ha enseñado esto, por favor publicalo en un libro. Para empezar, al igual que eres capaz de comer y no morderte la lengua al mismo tiempo, tendrías que ser capaz de escribir lo que estás haciendo. No escribiendo el Quijote, como parece que hace tu empresa, sino unas líneas que ayuden a un código legible y auto-documentado. Por supuesto, tendrás que documentar como funciona tu programa. Y si quieres que tu proyecto sea base para tu empresa, tendrás que documentar las partes necesarias. Si además tiene un ciclo de vida, y verán la luz diferentes versiones, se tendrá que indicar los cambios que se hicieron, cuando, y por quién y por qué motivo (gestión de configuración). Si no lo haces así, el cliente estará pagando las horas que tardes en entender lo que hiciste. Y en entender lo que hizo otro que tu perdiste el tiempo buscando. Y también en la calidad de un diseño y una realización que no se podrá verificar y mejorar sin perder largas horas descubiendo que hacía la clase x. Porque ESTA DEMOSTRADO que el tiempo que se gasta haciendo esto en las primeras fases de un proyecto es más barato y menos costoso que en las últimas.
Lo que está claro es que estas "meta-actividades" no deben superar un tiempo razonable ni suponer un coste de hombre/hora demencial. NO SE EXIGE para ningún proyecto un CCM de 5, pero tampoco se puede aceptar uno de 1.
MORALEJA: No engañes a tus clientes. Ni a ti mismo y mucho menos a los demás.
te suena a algo el efecto 2000?
(Puntos:0)Re:Mito de las metodologias
(Puntos:0)Y eso por supuesto es causa directa de que la documentación no sirve. Porque como tu eres inmortal y eterno, y siempre tendrás tiempo para enseñarselo a los más jovenes...
Resumen: Se gastaron aproximadamente 2000 horas de trabajo en realizar una labor que se utilizó para ahorrar unas 20 horas.
En definitiva, que no sabéis documentar. Y por eso, la documentación es mala. Lo que creo es que vuestro jefe de proyecto se debería reeplantear estudiar informática... esas cosas no te pasan ni haciendo prácticas...
Vamos, que es una teoría muy bonita en la que todos confiamos y que es basura
Los ignorantes desde su nivel lo ven todo muy claro... Porque quienes escriben la materia no han estudiado cientos de proyectos exitosos y tampoco saben utilizar la estadística para sacar conclusiones... Porque tu experiencia en UN SOLO proyecto (seguramente fracasado) nos ilumina la verdad. Chico, no confundas suerte y habilidad de la gente para salir del caos con algo bien hecho. ¿Cómo se llama tu empresa? Es por ir a llevar allí la basura...
Siempre que se decida alegremente que algo necesita documentación se debería evaluar muy seriamente la 'necesidad'. El 98% de las veces sólo es necesario documentar el código y el diseño del programa inicial. Por supuesto existe un 2% en el que es absolutamente esencial por ser sistemas críticos en los que ahorrarse un minuto en la corrección de un problema es esencial. El resto es pura burocracia de foto
Chico, te has lucido. Su tu "experiencia" te ha enseñado esto, por favor publicalo en un libro. Para empezar, al igual que eres capaz de comer y no morderte la lengua al mismo tiempo, tendrías que ser capaz de escribir lo que estás haciendo. No escribiendo el Quijote, como parece que hace tu empresa, sino unas líneas que ayuden a un código legible y auto-documentado. Por supuesto, tendrás que documentar como funciona tu programa. Y si quieres que tu proyecto sea base para tu empresa, tendrás que documentar las partes necesarias. Si además tiene un ciclo de vida, y verán la luz diferentes versiones, se tendrá que indicar los cambios que se hicieron, cuando, y por quién y por qué motivo (gestión de configuración). Si no lo haces así, el cliente estará pagando las horas que tardes en entender lo que hiciste. Y en entender lo que hizo otro que tu perdiste el tiempo buscando. Y también en la calidad de un diseño y una realización que no se podrá verificar y mejorar sin perder largas horas descubiendo que hacía la clase x. Porque ESTA DEMOSTRADO que el tiempo que se gasta haciendo esto en las primeras fases de un proyecto es más barato y menos costoso que en las últimas.
Lo que está claro es que estas "meta-actividades" no deben superar un tiempo razonable ni suponer un coste de hombre/hora demencial. NO SE EXIGE para ningún proyecto un CCM de 5, pero tampoco se puede aceptar uno de 1.
MORALEJA: No engañes a tus clientes. Ni a ti mismo y mucho menos a los demás.