Incluso si trabajamos en modalidad 谩gil, sin un presupuesto definido, tenemos ser capaces de valorar el esfuerzo que lleva una tarea, tanto para saber si cabe en un sprint como para poder decidir si se hace o no se hace.
Los programadores en general pecamos de optimistas, utilizamos el "tiempo programador" como unidad de medida, subestimando la tarea en la mayor铆a de ocasiones.
Esta ponencia pretende mostrar algunas herramientas y t茅cnicas que nos ayuden a realizar mejores estimaciones, sin olvidar que son eso, estimaciones y no pactos firmados en sangre.
En nuestra vida como programadores nos vamos encontrando con la pregunta de "cu谩nto costar谩 o cu谩nto llevar谩 hacer una cosa". Gestionar la incertidumbre y el riesgo es parte de nuestro d铆a a d铆a, pero cuando se trata de dar una cifra muchas veces no tenemos la herramientas para atrevernos a darla. El "tiempo programador", cambios de criterio y c贸mo gestionar los cambios de alcance son parte del contenido introductorio de esta charla.
El tiempo programador como unidad de medida, nuestra propio bias a la hora de hacer una estimaci贸n de un proyecto que nos gusta (o no nos gusta), la subestimaci贸n del esfuerzo y la sobreestimaci贸n de nuestras propias capacidades, afectan a nuestra manera de acercarnos a una tarea y poder definir su alcance y dificultad.
