Estoy en un desarrollo de una tarea bastante compleja que implica diseñar workflows en XML, desarrollar un función en Java que trabaje con ficheros de entrada y salida y hacer algún script sql.
La verdad que es una tarea muy completa en la que estoy aprendiendo mucho, pero me pusieron de 'estimate' 2 días y estoy tardando dos semanas.
Cómo afrontais esas situaciones? Soy nuevo en la empresa y es algo que no corre tanta prisa, pero no sé si es normal 
Desde el punto de vista del desarrollador, una empresa es tan buena como lo son las estimaciones que se hacen.
Si tu manager te ha dicho 2 dias para algo que llevaria mucho más, entonces es un pésimo manager y/o un hdp que lo hace para presionarte.
Al final el grueso de la estimación total la tiene que dar el que va a implementar ese proyecto, o sea tú. Pero siendo novato tampoco lo sabes mucho, esto se va aprendiendo a la malas y con mucha experiencia. Asi que mejor tira para largo e intenta pelear cuantos más dias mejor.
Nunca te fies de una estimacion que no es tuya. Y aunque sea tuya tampoco.
Pero si algo se esta tardando mas de lo que se tenia pensado, lo unico que se tiene que hacer es documentar el porque y comunicarlo correctamente.
No te preocupes, una estimación es eso, una estimación. Y mas al principio, las primeras siempre se van de mucho pero poco a poco se van afinando mas.
Eso si, si ves que no vas a llegar a lo estimado se ha de ir alzando la voz y avisando al manager para que tenga toda la información y tome medidas para solventarlo (reestimar/repriorizar/dar soporte)
Si eres nuevo más que en tardar poco preocúpate de aprender todo lo que puedas sobre la forma de trabajar y demás
En tu caso no creo que debas preocuparte en exceso, comentas que estás aprendiendo mucho y que además eres nuevo, ya de por sí dos factores que influyen bastante a la hora de añadir más tiempo de desarrollo del estimado. Tiempo que puede ser realista para alguien que ya lleve tiempo ahí pero no para alguien nuevo como tu caso.
En cualquier caso coméntalo con tu responsable, siempre será mejor que le digas tú de frente la razón por la que no vas a llegar a que tenga que venir él y empezar a soltar algo que suene a excusa.
Las estimaciones cuando eres nuevo son una putada. Aprende, sé eficiente, argumenta la tardanza. Después, las estimaciones son para tocarse los huevos. Ya que te dirán que vuelvas a hacer lo mismo en 2 días y será un rico copy paste adaptando la entrada y salida.
Yo el error que menos soporto es que echen la culpa al entorno de desarrollo, a que no está bien analizado, etcétera. Sé humilde y di que estás aprendiendo y que la próxima vez serás más eficiente.
Estoy con HeXaN, aun no he entregado nada tarde, lo que si me ha ocurrido es que quien ha puesto las estimaciones sin contar con mi opinión, lo ha estimado para demasiado pronto, lo cual es su fallo y no el mio.
Si alguien te dice que vas tarde según la estimación, dile que se lo pidan al que la estimó, a ver si el cabron ese la hace en 2 días.
No lo dejes para el ultimo momento, avisa con tiempo, explica adecuadamente el por que la estimacion requiere mas de lo pensado y ver si podeis encontrar una solucion.
Lo primero es ponerse en situación del que lo ha estimado. Si lo ha estimado un senior que lleva 5 años ahí y sabe cómo va todo, pues es probable. Con lo cual, como te han dicho...es una estimación, ahora, la info por delante.
Cuando acabes la tarea lo que tienes que hacer es enganchar al de la estimación y que te comente el por qué y tú le comentas todo lo que te ha ido saliendo por el camino, asi la próxima igual es más acertada.
Cuando yo he entregado algo tarde ha sido o porque ha entrado tarde al sprint de desarrollo pero ha entrado because potato o porque efectivamente lo hemos estimado mal.
La estimación por ejemplo la hace el equipo entero, hay gente que más y hay gente que menos, luego consenso y ale
Pregunto, tantos hay currando en waterfall? Ni un equipo agile aunque sea el agile chusta que se creen las empresas que tienen? Lo pregunto porque bien hecho... Si llegas tarde a entregar algo se ve a lo largo del Sprint, con lo cual te evita el agobio porque ya lo sabe todo el mundo xD
Si no llegais a tiempo la culpa es de vuestro responsable. Las estimaciones no deben hacerse por deseos de quedar bien con el cliente, hay que ver los recursos con los que se cuenta y los posibles problemas que puedan aparecer. Temas en los que no se pueden achacar responsabilidad a ls desarrolladores.
Yo he entregado 2 proyectos tarde en mi estimación. No porque no me diera tiempo sino por causas mayores como irse la luz y con ello el internet. O en una en la que pillé tal trancazo que no me podía concentrar durante varios días.
En una pagué la penalización por entregarla tarde.
En la otra la cliente entendió el retraso que supuso 1 día extra y no sufrí penalización. En el siguiente proyecto le hice descuento.
Cuando son tus estimaciones, perfecto. Si te equivocas, aprendes a hacerlas mejor y conocer tus límites. Si son hechas por alguien que no entiende o mide mal los tiempos. Es una putada porque es algo ajeno a ti.
#15 yo llevo 100 sprints a la espalda y tan contento. Nada de hacer proyectos que duren 6 meses 
En mi euqipo solo nos pasó una vez calcular mal lo que podíamos hacer. Nos dimos cuenta a mitad de sprint y pudimos cambiar el commitment que hicimos con el PO, sin puyas ni malas caras ni nada. Eso si, hay que decir los motivos de por que no se puede hacer X cosa en Y tiempo
Pero ese tiempo de retraso que estás teniendo, es porque te atascas mucho?
pregunta al resto de tu equipo si ves que algo no te sale por mucho que buscas/documentas
no te quedes callado mirando la pantalla esperando a que se solucione por arte de magia.
Yo siempre que tardaba algo más con algún trabajo lo ponía en un tocho comentario explicando todo lo que había hecho y la causa del retraso, aunque al final eso se la sudaba y no lo leían nunca.
Ahora soy yo el que analiza y aterriza los trabajos e intento siempre tirar a lo alto porque al final nunca sabes a quién le va a caer el trabajo, eso sí, eso no quita que luego haya gente que se la sople y te meta incidencias con 4h de estimación sin pararse a analizarlas xD
La clave en estas mierdas es que jamás dejes que se te vaya la fuerza por la boca. Nunca digas "NP, esto está hecho en 2 días" o "va bien bien" si cualquiera de esas cosas es mentira. Hay mucha gente que se caga pensando que van a quedar mal y dan falsas expectativas. Es infinitamente mejor ser sincero y estimar tiempo de más o expresar complicaciones que el que tus jefes crean que la cosa va de lujo y luego el día de la entrega descubran que te va de culo. Más que nada porque no vas a tener excusas ahí.
#26 Nope, la verdad. Cosas de caer en buenos proyectos con jefes que saben lo que se tardan en hacer las cosas en este ámbito (ciencia de datos).
#27 ¿Y me vas a decir que aún así nunca habeis encontrado un problema y habeis tenido que ampliar la estimación?
Porque entonces tengo dos opciones para tí: O llevas trabajando muy poco de esto o haces tareas de mono como decía xd.
Incluso con buenas estimaciones es algo inevitable, es un trabajo agil y dinamico al que hay que irse adaptando
#28 No, de verdad. Es un proyecto de ciencia de datos donde ambas partes aprenden de esta unión y tenemos el tiempo que queramos.
Es más, nos han llegado a decir que bajemos el ritmo porque les damos más cosas de las que pueden ellos probar en planta.
Pero como te digo: es un proyecto de investigación pionero en el campo y no funciona como el típico de cárnica.
