Cómo ESTIMAR tareas de Software
HTML-код
- Опубликовано: 20 июн 2022
- Participa en el Blockchain Codeathon de Rviewer, recibe feedback sobre tu código de la mano de expertos y gana premios solo por participar 👉🏼 bit.ly/3aXQcoB
👾 Redes sociales 👾
► Twitter: / bettatech
► Instagram: / betta_tech
► Canal Secundario: / @forkdebettatech
► Discord: / discord
👨🏼🏫 MIS CURSOS 👨🏼🏫
👽 Curso de iniciación a la programación con JavaScript:
► bit.ly/3kr4bTc
👽 Curso de desarrollo backend con NodeJS y Express:
► bit.ly/3n4sirS
👕 MERCHANDISING DEL CANAL:
► Tienda RUclips: / bettatech
► Tienda Teespring: teespring.com/stores/bettatec...
⭐️ AFILIADOS ⭐️
🎁 7% Descuento en HOSTINGER (Código BETTATECH)
► www.hostg.xyz/aff_c?offer_id=...
🐾 MacPaw (CleanMyMacX):
► macpaw.audw.net/c/2523912/941...
📝 Todoist:
► doist.grsm.io/martincristobal...
🎵 TODA la música es de EpidemicSound:
► www.epidemicsound.com/referra...
✉️ CONTACTO PROFESIONAL:
► Respuesta no garantizada:
bettatechyt@gmail.com
📚 LIBROS 📚
Design Patterns
► amzn.to/39XuQlq
Head First Design Patterns
► amzn.to/2uq6XUq
Refactoring
► amzn.to/2SQnf2c
Clean Architecture
► amzn.to/3bZVonJ
Clean Code
► amzn.to/32WVKq3
Introduction to Algorithms
► amzn.to/34SyVFP
Cracking the Coding Interview
► amzn.to/2QkdwC6 
Наука
Participa en el Blockchain Codeathon de Rviewer, recibe feedback sobre tu código de la mano de expertos y gana premios solo por participar
👉🏼 bit.ly/3aXQcoB
Muy bonito el video pero ya sabemos lo que pasara: el manager dira "si una mujer tiene un bebe en 9 meses, 9 mujeres lo tendran en 1" xDD
Algunos consejos:
1) Nunca, jamás, NUNCA déis sólo el dato de la fecha estimada promedio. Dad SIEMPRE las 3 estimaciones (mejor, promedio y peor). Los managers tienden a ser una especie que lo que oye es distinto de lo que se le dice. Si sólo se les informa de una fecha, por mucho que se remarque lo provisional que sea, ellos la entienden como una fecha de entrega segura e inamovible. Si al darles 3 fechas se quejan y piden una concreta, hay que saber decir NO, que esa es la estimación. Es SU trabajo gestionar con esa información.
2) Por norma general, una vez estimado el plazo del peor escenario posible, multiplicadlo x1.2-1.5. Es muy común subestimar los peores escenarios.
3) Relacionado con el primer punto, es muy importante aprender a no ceder ante un manager. Es común que pidan acortar plazos alegando que "siempre es posible esforzarse más", o que "no es necesario tener un plan de pruebas", o que "no es necesario refactorizar", etc. Hay que saber plantarse, decir NO, siempre recordando que uno es responsable de entregar algo de calidad.
Y colorin colorado este cuento se ha terminado en cuanto te dicen ó haces esto asi ó a la calle. Las bajadas de pantalones son epicas.
@@antonpirulero2836 Cuando uno se baja los pantalones como dices, al final más tarde o más temprano surgen los problemas. ¿Y quién crees que acaba tragando con la responsabilidad? ¿La empresa? ¿El manager? No. Todos los dedos acaban apuntando al programador. Y en esos casos las excusas tipo "es que me metieron prisa" no valen nada. Quien es capaz de plantarse para defender un trabajo bien hecho, al final se ahorra mayores problemas futuros, tanto para uno mismo como para el resto de la industria. Obligar a abandonar las buenas prácticas es un insulto a la profesionalidad.
Y si lo que toca es cambiar de empresa, pues se hace. Por fortuna, no es un sector en el que haya escasez de demanda. El cambiar de empresa cada pocos años es algo que incluso se recomienda. No te vas a la calle, te vas a la competencia.
Gracias bro
No, lo que dices no sirve en la realidad y tiene muchas fallas. Si el manager te pide una fecha, es porque le has dado tres fechas seguramente muy separadas que demuestra demasiada incertidumbre por la falta de análisis previo. Ese análisis se realiza mediante 1) definición clara del alcance, 2) desglose de las pequeñas tareas individuales requeridas, 3) estimación del esfuerzo de esas tareas y repartición en el equipo existente, 4) unión de todas esas estimaciones de tareas, teniendo en cuenta el solapamiento por tareas hechas en paralelo por distintos miembros del equipo, y 5) obtención de la ruta crítica que da el tiempo estimado de la tarea.
Luego de esa primera estimación base, se deben identificar los posibles riesgos, sus causas y consecuencias, estimar su probabilidad e impacto para obtener la exposición al riesgo y poder priorizarlos, y a los riesgos con mayor exposición obtener posibles medidas de mitigación (en base a las causas del riesgo) y PLANES DE CONTINGENCIA (en base a las consecuencias del riesgo). Cada uno de esos planes de contingencia tiene un trabajo asociado que se lo debe estimar de la misma manera que la de la estimación base.
La estimación base es el "mejor escenario", y la estimación base más el tiempo de los planes de contingencia de los tres riesgos con mayor exposición es el "peor escenario".
NOTA: Si aún así el manager en un p3ndejo y presiona para que le den una fecha concreta, que seguramente luego la santificará como el deadline inamovible, hay que darle la estimación del peor escenario MULTIPLICADO POR DOS
@@IngeGallito Estoy de acuerdo con el elaborado proceso que indicas, aunque me parece también muy teórico.
De todos modos, a lo que me refería yo es que los managers odian la incertidumbre. Y es normal, puesto que a mayor incertidumbre, mayor dificultad tienen para hacer su trabajo: gestionar recursos. Por ello, es responsabilidad del desarrollador (o desarrolladores) intentar reducir y acotar la incertidumbre lo más posible, en base a la experiencia previa y al análisis que describes. Pero por mucho que se intente reducir, siempre habrá algo de incertidumbre.
El problema surge cuando el manager de turno es o muy incompetente, o muy vago para lidiar con cualquier incertidumbre (cosa bastante frecuente por desgracia, hay muchísima gente en puestos de gestión que no tiene ni idea de gestionar). Y que, aprovechándose de su posición de poder, exige certeza absoluta (o interpreta lo que se le dice como si lo fuera, que para el caso es lo mismo). Gente que no comprende que las estimaciones son eso, estimaciones, y no compromisos. Pero, cuando surgen los problemas (retrasos, bugs por falta de tests completos, malos diseños que dificultan mantenimientos futuros...), los dedos acusadores siempre acaban apuntando al que desarrolla, mientras que el manager se lava las manos.
Ojo, no siempre pasa esto. Hay por ahí managers altísimamente capaces que hacen muy bien su trabajo. Pero por desgracia, también existe el otro extremo.
Edit: Releyendo tu comentario, he visto que he olvidado comentar una cosa:
Si, es cierto que puede darse el caso de que los rangos de fechas no le valgan a un buen manager por ser demasiado amplios. Ahí entran la experiencia, el conocimiento y los recursos dedicados al análisis.
Todo lo que he dicho aplica suponiendo que las estimaciones se han hecho correctamente, y que se ha reducido la incertidumbre lo más posible. Si la estimación se ha hecho como se debe y es lo más correcta que se puede, no hay que cambiarla porque otro no pueda/sepa gestionar.
Gran video, la estimacion de tareas definitivamente es de las tareas mas complejas para nosotros! :D
Muchas gracias🙌🙌🙌🙌
A futuro (y no tanto) creo que las IA's ayudarán bastante para la estimación de tareas/proyectos :)
Gracias por el video, actualmente estoy a cargo de un equipo de 7 desarrolladores y muchas veces es muy pero muy difícil estimar las fechas en la planificación
Es un tema interesante y al hay que hay que dedicarle tiempo, en mi opinión es obligatorio para mejorar como profesional. La mejor manera de realizarlo según mi experiencia profesional es lanzar estimaciones junto al equipo y pensando en las capacidades del asignado no sólo desde el punto de vista del asignador. Y siempre hay que añadir en tareas complejas mínimo un 30% adicional para cubrir la resolución de problemas (limitaciones, colisiones, etc) no identificados inicialmente.
Estimar es sin lugar a duda una de las cosas más complicadas en el desarrollo software, tanto como poner nombre a las variables xD
Nunca me ha gustado estimar pero entiendo q es necesario en muchos casos. Mi recomendación es dar los rangos optimista y pesimista en vez de una fecha fija, estimar funcionalidades en vez de tareas así tenéis más flexibilidad xq si tenéis que dejar algo pues dejar alguna funcionalidad de menor prioridad para la siguiente iteración del producto en vez de perder tiempo implementando tareas para funcionalidades q no se van a completar xq no ha dado tiempo al final, y intentar dividir todo lo posible esas funcionalidades antes de estimarlas xq cuanto más grande algo más ambiguo es y más difícil de estimar. Y por último, estimar la complejidad de la funcionalidad y con la velocidad del equipo calcular el tiempo estimado, eso os da ventaja tanto a vosotros frente a imprevistos como a vuestra compañía ya q si la compañía necesita el producto antes sabrá más o menos cuantos recursos debe destinar para llevar a cabo el proyecto, en vez de presionar a los q desarrolladores o tomar otro tipo de atajos como recortar en calidad, cosas q desgraciadamente siempre pasan
Otra video mas de mi dios del olimpo favorito 🤩
Que buen video! En la carrera de informática tuve una asignatura de gestión de proyectos pero nunca aprendí verdaderamente como estimar mis tareas y siempre termino subestimando o sobrestimando. Muy útil todo lo que has dicho 👍🏻👍🏻👍🏻
Excelente video como siempre. Solo me gustaría agregar que, si bien entendimos que la estimación que has planteado fue sólo un ejemplo, es una práctica muy arriesgada el llevar a cabo una estimación cuando la incertidumbre en el proyecto es muy grande. Es un indicador de ello el observar desviaciones del 100% o más en la estimación de tareas de alto nivel (historias de usuario). Cuando esto ocurre, lo correcto sería detener la estimación, llevar a cabo un proceso de descubrimiento, slicing o planificación más profundo, priorizar esas nuevas tareas y luego retomar la estimación, validando nuevamente aquellas historias que presentaron una gran desviación.
Saludos y gracias por tu gran trabajo!!!
¡Excelente contenido!
Este metodo puede ser usado incluso en proyectos diferentes a los relacionados con desarrollo de software.
¡Gracias por compartir tu conocimiento!
Wao esta información es oro molido! Gracias por la info!
Super util, lo mejor que he aprendido hoy. Gracias.
Gracias por comentar!
Excelente muchísimas gracias !!! me sirvió muchísimo!!!
Con mucho gusto!!
Muy buenos consejos!
La mejor estimación es: Lo que pensante, por dos, más uno.
y al cuadrado
Sé que solo es un ejemplo, pero me imaginé la cara de mi project manager al decirle que me demoraré 4 meses en crear un endpoint jajaja
Todo depende del endpoint 😂😂
Buen video, y como estimas cuando son tareas que pueden ocurrir en forma paralela?
Y qué pasa con las reuniones, días dónde explotan alguna cosas y hay que investigar, también entran dentro de la estimación?
Cómo siempre la calidad inmejorable.
Aquí servirían las técnicas de PSP0.0, 0.1 o PSP 1.0???
Una pregunta, para la carrera de ingenieria informatica es mejor estudiar fisica o estudiar química? Es decir, me quiero sacar dos asignaturas específicas del bachiller de ciencias mientras hago una fp de desarrollo web para luego entrar a la carrera. La asignatura de matemáticas es obvia que la tengo que estudiar, pero la otra, cual piensas que es mejor saber?
Yo de quimica no vi nada, pero de fisica si había una asignatura obligatoria y otra optativa (la optativa era para temas de programacion con qubits, cuantica etc)
@@BettaTech Muchas gracias! 😋
ORO PURO
Literalmente, eso me ha pasado.
Me gustó el contenido y muy buen video, pero algo raro que he notado; es que en ningún comentario se ha hablado de usar metodologías ágiles para estimar, como por ejemplo de no usar tiempo (horas, dias, etc.) para estimar, si no, de darle una ponderación al esfuerzo (normalmente con la serie de fibonnaci) y asi poder obtener una velocidad (una cantidad de puntos de esfuerzo por un periodo de tiempo) y en su defecto poder dar una fecha aproximada de entrega.
Estoy de acuerdo que también hay incertidumbre, pero lo que mas me sorprendre es que nadie lo comentara o le haga algun tipo de referencia ¿Si alguién pudiera iluminarme con mi duda? le agradecería mucho.
Este video trata de estimaciones de proyectos mas grandes, no esta enfocado al uso de agile (no siempre se usa agile). De hecho tengo otro video también de estimaciones enfocado a historias de usuario y puntos de esfuerzo!
@@BettaTech Gracias por tu respuesta.
Este video es resubido?
Nunca confieis en un tio guay, os vendera.
Estimar es timar!
Me sorprende (gratamente) que para este ejemplo se hable de 4 meses y dos semanas, en una de las empresas con las que trabajo, esto se querría para el lunes a primera hora (siendo hoy jueves y mañana festivo).
Lógicamente queda como el c*lo, no hay contratos ni tests, no hay documentación ni tdd, no hay buenas practicas, SOLID, DRY, design patterns ni nada.
Y claro, luego vienen los llantos, que si no se tuvo en cuenta esto, que si bug por acá que si fallo por allá, que si corre a parchear esto a lo loco (mientras a la vez estás con otra cosa de un dia para otro...)
No se si es que las empresas con las que he trabajado son la excepción (espero que si) o es que tengo que mandar mi CV a la tuya HAHAHAHA
En mi caso he tenido varios clientes asi, he tomado desarrollo que ha estimado otro, trabajo en software factory , y siempre que me pasa esto... les digo lo mismo. Lo podemos hacer rapido mal, que aparentemente funcione... y lo podemos hacer lento bien... y que funcione , ahora de las dos opciones la primera te sale mas barata... pero los bug te van a salir claro... y la segunda te sale mas cara y los bugs mas baratos... Casi siempre eligen la primera.... y despues yo mismo despues de varios meses de desarrollo... de parches... etc.. Les digo.. se acuerdan que se los dije.. bueno ahora hay que hacer la opcion dos... Hay una estadistica que es que mas del 75% de los proyectos de software fracasan... y no salen a produccion. y es por esto mismo... pq kieren software rapido , escalable, robustos aahhh pero 3 meses... ,, siempre te ponen de ejemplo empresas como amazon, google, whatsapp... Pero Les digo kieren app como whatsapp facebook pero no kieren hacer las cosas que hacen whatsapp facebook. google para hacer esas aplicaciones robustas
@@johanhimelymendoza4880 esta respuesta siento que soy yo, toda mi vida. Es increible que aun tras los golpes, la gente insista en hacerlo mal y no confiar en los especialistas que los contratas justo para que eviten que te vaya mal. Pero no. Ni caso. Una 'startap' va de hacer todo corriendo y reir aunque todo sea una sh*t. :) Si dices algo, eres un amargado, o estás deprimido o 'no sabes trabajar en un ambiente startup', o mil cosas más que me han dicho XD
Y eso asumiendo que el equipo tiene un nivel similar en cuanto a experiencia, estudios , conocimientos etc.... Si no ... hay que considerar un periodo de nivelación, adaptacion y rezar para que el rendimiento mejore con el pasar de los días, semanas, meses, años... xD
Estimar es timar, y no estáis obligados a estimar. Eso que sea cosa del equipo de análisis de riesgos. Sinceramente no soluciona el problema y lidiar con estas cosas así es poco profesional, a la vez que solo puede generar problemas. Y más cuando estimas algo y lleva a otras personas en la cadena. La solución es, no estimar. Ser transparente con el progreso, marcar hitos y visualizar el avance.
No times
Se enteraron que Copilot ya no es gratis, ya comenzaron a cobrar :u
Según ellos ya está lista la herramienta, aún que en la última fase de pruebas aveces arroja resultados raros y repetidos :u