Como estimar una tarea ? Desde la perspectiva del Ingeniero de Software.
La estimación es difícil. Para los desarrolladores de software, es uno de los aspectos más difíciles, si no los más difíciles del trabajo. Debe tener en cuenta una serie de factores que ayudan a los dueños de productos a tomar decisiones que afectan a todo el equipo y al negocio. Con todo lo que está en juego, no es de extrañar que todos, desde los desarrolladores hasta la alta gerencia, sean propensos a poner sus calzoncillos al fuego al respecto.
Dicho esto, veamos algunas formas de hacer estimaciones ágiles lo más precisas posible.
Por qué cometemos errores
Hay algunas razones objetivas por las que cometemos errores en las estimaciones de tiempo y nos saltamos los deadlines:
- La gente comete errores. La razón número uno en mi opinión es que las personas tienden a cometer errores. No somos robots, podemos estar distraídos, cansados, enfermos, no prestar suficiente atención a los detalles importantes.
- Malentendidos y falta de información. Otra razón principal es la incomprensión de lo que debe hacerse. Por lo general, se debe a que la descripción de la tarea es demasiado corta y simplemente no puede obtener más detalles cuando realiza una estimación.
- Ignorar los riesgos. Siempre existe el riesgo de que pase más tiempo de lo esperado en la tarea. Solo trata de recordar la última vez que pasaste unas horas en una pequeña tarea de 15 minutos y obtendrás la idea de qué podría salir mal si los números están en miles de horas.
- Las cosas nuevas son difíciles de estimar. Tenemos que admitir que es difícil estimar cosas nuevas (investigación, tecnología de terceros y API). Y esa es otra razón de errores de estimación.
- Las personas tienen diferentes conocimientos y experiencia. Cuando trabajas en un equipo, a veces es fácil olvidar que no todos los desarrolladores tienen las mismas habilidades y experiencia. Alguien podría ser bueno y malo en algo. Por ejemplo, usted es un maestro de la API de integración, y su colega podría ser realmente bueno para crear una estructura de modelo de datos. Además, también hay una diferencia entre un desarrollador junior y un desarrollador senior.
- Responsabilidad. La última razón común que es más aplicable a los desarrolladores menos experimentados. Ocurre cuando un desarrollador no comprende completamente qué tan importante es el número que dio.
No tengas miedo de pedir ayuda
No puede ser un experto en todas las áreas de desarrollo. Es simplemente imposible, porque el mundo del desarrollo, y el back-end y el front-end en particular, es demasiado grande para saberlo todo. Para tener éxito, debes saber mucho, pero no todo. Por lo tanto, no tenga miedo de pedir ayuda: si no sabe cómo implementar algo o si tiene problemas con el tiempo.
La estimación del tiempo no se trata de predicción
Cuando calcula el tiempo, debe reunir toda su experiencia pasada, y no puede hacerlo sin los números que siguió durante el proceso de desarrollo. Presta más atención a las tareas subestimadas y sobreestimadas e intenta averiguar qué salió mal en cada caso. Para aquellos a quienes les gustan los números, tengo una fórmula especial que te ayudará a calcular tu factor de error personal:
Es así de simple. Simplemente divida el tiempo registrado por el tiempo estimado. Idealmente, obtendrá «1» como resultado. En el caso de que el número sea mayor que 1, significa que ha pasado más tiempo de lo esperado, y obviamente es algo malo. Si su factor es menor que 1, generalmente también es algo malo, desde una perspectiva de planificación.
Hablemos de los puntos de historia / tamaño de la camiseta, ¿qué representa?
Los puntos de historia representan el esfuerzo requerido para poner en funcionamiento un elemento del backlog de productos. Cada punto de historia representa una distribución normal de esfuerzo / tiempo.
mala forma de utilizar este concepto: 1 punto de historia podría representar un rango de 4 a 12 horas, 2 puntos de historia de 10 a 20 horas, etc.
Identificar una historia base
Story Points in agile es una unidad compleja que incluye tres elementos: riesgo, complejidad y repetición.
Tiempo de concentración
Es importante definir el tiempo disponible que tenemos para concentrarnos por día; Por ejemplo, en un día sin reuniones, solo tengo 6 horas disponibles exclusivamente para resolver tareas, con estas horas construyo 2 bloques de 3 horas y estos son los bloques de concentración que tengo por día.
Nunca lo olvide: las interrupciones y el trabajo no planificado serán una constante, hasta cierto punto de todos modos, sin importar dónde trabaje. Acéptalo, planifícalo
Cuando no tengo estos bloques con el total de horas disponibles (tiempo inferior a 3 horas), lo uso para resolver problemas más pequeños, responder correos electrónicos o documentos.
Matriz de estimación
Cualquier cosa que sienta que sería mayor de 13 puntos de historia debe desglosarse en tareas más pequeñas.
Intente agregar una tarea de descubrimiento para ayudar a comprender mejor el alcance del trabajo.
Bump Ups – Pruebas
- Línea de base → Cero esfuerzo de prueba adicional más allá de la práctica estándar.
- +1 paso → El esfuerzo de prueba excede la práctica estándar y es igual al esfuerzo de la implementación.
Bump Ups – Riesgo
- Línea de base → Todo el riesgo que se posee fuera de este ticket, aceptado, resuelto o mejorado.
- Paso +1 → Riesgo bajo a moderado, propiedad y aceptación como parte de esta tarea.
En ambos casos, la tarea pasa de XS → S cada vez que se debe aumentar un paso. Los términos de propiedad y aceptación se refieren al riesgo ROAM (Scaled Agile Framework -SAFe-)
Incluya otras actividades además de la codificación.
Otra parte de la estimación son los riesgos del desarrollador. Recuerde que no gasta el 100% de su tiempo en la codificación. Usualmente haces muchas cosas además de la codificación:
- Leer la documentación y la descripción de la tarea;
- Implemente y pase tiempo revisando el código.
- Tiene reuniones o llamadas en línea con el equipo y / o el cliente.
- Probablemente leas algunos recursos para mejorar tus habilidades en general.
- Y, por supuesto, toma café / té, come galletas, lee y envía correos electrónicos, tiene pequeñas conversaciones con colegas durante el día.
Todos estos son parte del proceso de desarrollo y debe incluirlos en la estimación.
Conclusión
La estimación de tareas puede ser un «arte», pero piense en estos conceptos: los riesgos, la repetitividad, el esfuerzo y la prueba de las tareas; nos ayudará a tener una visión más general del desempeño de nuestro trabajo y su calidad.
Espero que estos consejos y trucos de mi experiencia personal y profesional le hayan brindado información valiosa sobre la estimación y gestión del tiempo. Si eres un principiante en la estimación del tiempo, puede parecer algo difícil de dominar, y probablemente pasarás un tiempo para hacer de este proceso tu rutina diaria, pero al final valdrá la pena.
