#3387 Normalmente me suelen sobrar entre un 10% y un 15% de mis estimaciones.
#3389 En la estimacion de tiempos somos convencionales, si algo son 10 horas, calculamos 11.5 ~ 12 etc, pero vamos yo no hago consultoria, en la consultoria las estimaciones son practicamente irreales de lo infladas que estan. La estimacion por arriba es para no pillarte los dedos, de todas formas, tenemos como norma que si se estiman di 20 y se hace en 8, el superavit de horas se le devuelve al cliente, porque claramente la estimacion ha fallado, que pasa, no demasiado, pero pasa.
Pero vamos si yo digo que la deadline de un proyecto es el dia tal, por mis santos cojones que yo ese dia entrego, algo muy muy grave ha de pasar para no entregar a tiempo y como yo, todo mi equipo.
Las estimaciones... La segunda cosa más difícil para un programador.
La más difícil es buscarle nombres a las variables y las funciones ofc.
#3391 a ver si te entiendo, dices que en una tarea tardas 10 horas (entiendo que son horas ideales) y le aplicas una velocidad (baja no, lo siguiente) y te queda en 12 horas, estas asumiendo que como muchísimo te van a molestar o vas a tener problemas que solucionaras en 2 horas no? en serio, cuanto vales?
#3396 la "velocidad" no es ni buena ni mala, lo que es malo siempre en un desarollador es la estimación pero lo bueno es que es constante, si estimas mal, estimas mal siempre... la velocidad esta para corregir esas estimaciones precisamente y se recalculan a cada sprint, pero visto lo visto, ya no vales tanto XDD
#3397 Pero es que te has sacado de la manga que aplicamos una velocidad (baja no, lo siguiente) no te voy a sacar las graficas de velocidad pero vamos estamos en una velocidad considerada normal, hay sprints que son mas lentos o mas rapidos (entre 0,1 ~ 0.3 de coficiente).
Pero lo de aplicar velocidades bajas, te lo sacas de la manga.
#3399 entonces lo esta haciendo mal de base, tu estimas lo que vas a tardar en X tarea de manera ideal, sin complicaciones, sin que se te rompa el ordenador, ni que hayan cambiado node, o que la librería que ibas a usar no funciona, luego se le aplica una "velocidad" para saber en realidad cuanto vas a tardar, que como ya he dicho esa velocidad se recacula a cada sprint
#3400 o sea, si estimas una tarea en 10 horas ideales y son 12 horas reales me sale 0.8, de donde sacas el 0.1 ~ 0.3 ?
pd: insisto pongo "velocidad" pero se llama de otra manera xD
#3404 Imagino que ya que tu metodo es tan perfecto, llevareis un historico de speed no?
Porque cuando te hablo de la diferencia te hablo de la velocidad entre sprints, cuando hacemos los calculos si tu vas al historico puedes ver que al final del sprint, la velocidad entre uno y otro es similar.
Pero yo no voy de listo, yo he hablado sobre especificaciones, acuerdos con el cliente, he dado ejemplos de estimaciones, sin entrar en detalle en como estimamos y dando cifras ficticias de memoria y tu vienes, te la sacas y me dices que lo hacemos mal de base, que mis calculos de velocidad estan mal, que voy de listo, que cuanto valgo, que no se que...
Entonces no se que quieres que te diga, un dia te vienes a la oficina de Londres, o la de LA y hacemos un taller explicandote nuestros metodos internos si te parece y la implementacion que hacemos de SCRUM en los diferentes equipos.
Offtopic:
#3405Merkury:Entonces no se que quieres que te diga, un dia te vienes a la oficina de Londres, o la de LA y hacemos un taller explicandote nuestros metodos internos si te parece.
EPICO.
MI metodo es scrum básico, horas estimadas -> aplicas velocidad -> hora real, nada mas, con lo que me has dicho que entiendo que también haces lo mismo, has dicho que hora estimada es 10, velocidad X -> hora real 12, si despejas la X te da 0.8, esa velocidad indica que tus estimaciones son casi perfectas y nunca me he encontrado con ninguna persona así (y dudo que lo conozca aunque puede ser posible oye... alomejor en Londres o LA), luego comentas que tu velocidad es 0.1 ~ 0.3 y no lo veo con tus numeros ficticios pero me parecen reales, de echo te diría que 0.1 es que estimas como el culo xD cosa que es mas normal y que todos hacemos alguna vez
#3398 Si la gente no saca satisfacción de discutir en internet y demostrar que saben más o son mejores que los demás de dónde narices la van a sacar? De programar? xDDDDD
#3408 lo de satisfacción por discutir te lo acepto xDD pero ya no solo en internet xDDD lo de que se mas ni puta idea pero siempre puedes venirte a mis oficinas en LA y hacemos un taller interno
Las especificaciones DETALLADAS AL MÁXIMO hay que cerrarlas con el cliente siempre por escrito y firmado . Si el cliente luego quiere cambios o funcionalidades nuevas siempre se le cobra y debe estar indicado en la especificación previa. Yo siempre dejo claro "bug" => gratis, "cambio/funcionalidad" se le presupuesta aparte.
Luego nos llaman orgullosos a los programadores, y la verdad es que cuando nos faltan el respeto solo nos falta retar a un duelo.
Y ya ni os hablo cuando nos falta el respeto otro programador, ahí ya la líamos gorda.
#3413 el problema es cuando dices que va a estar para 1 mes y por X problemas necesitas 2 meses. Si has firmado eso estas jodido, de ahi que la estimación que hagas tenga que tener X tiempo extra para esos casos.
Enga ya.
Procastinando por la red me he encontrado con esto, especial atención a la parte de hardware, me ha dado vértigo.
