Manejo de estimaciones como programador junior

He estado trabajando durante un par de meses en una empresa que estima (para la población general, no para los jóvenes específicamente) tareas y luego se nos da la tarea, la resuelven, pasa por dos pruebas y al final la estimación debería ser De alguna manera se reunió.

Estoy más que estresado porque algunas de las estimaciones son simplemente imposibles de cumplir. Todavía no conozco todo el sistema (porque es bastante importante), por lo que a veces la mitad del tiempo lo paso descubriendo lo que necesito hacer y dónde y para cuando termino, a veces la estimación ha terminado y todavía hay pruebas para hecho (y corrigiendo errores si fueran).

La segunda vez que tengo que lidiar con una funcionalidad similar, todo funciona mucho más rápido, pero hasta ahora siento que soy malo en la programación.

¿Hay algo que hiciste cuando empezaste que te ayudó a superar esta etapa? Me estreso tanto cuando veo el poco tiempo que hay para codificar que a veces ni siquiera puedo concentrarme adecuadamente en lo que estoy haciendo, lo que lo hace aún peor.

• Muchos desarrolladores con poca experiencia en gestión estiman las tareas utilizando su propia velocidad o la velocidad de un "mejor" desarrollador en un equipo.

• La velocidad varía con la experiencia. El desarrollador senior puede tomar 3 horas para resolver algo, cuando le tomará 2 días hábiles para resolver el mismo problema.

• Rara vez se puede evitar el estrés cuando asume un nuevo trabajo. Después de unos meses, normalmente mejora, suponiendo que trabajas lo suficiente y haces muchas preguntas relevantes.

• Es posible que sus personas mayores no sepan cómo se siente con respecto a las estimaciones, por lo tanto, es importante que les pregunte qué esperan de usted.

Por mi experiencia:

• Creo que el desarrollador sénior o un gerente deberían poder estimar una historia de usuario (requisito comercial) en términos de tamaños de camisetas (XL, L, M, S, XS).

• Es tarea de los desarrolladores dividir la historia del usuario en tareas más pequeñas y estimarlas. Una tarea grande puede llevar a un desarrollador senior un día para resolver, cuando puede llevarle una semana entera.

• Es muy importante registrar cuánto tiempo le llevó completar la tarea.

• Un buen gerente de proyecto o desarrollador senior recopilaría constantemente estas estadísticas. Cuando mejore su productividad, se darán cuenta de ello y le enviarán más trabajo.

Esto no solo hará que su vida sea menos estresante, sino que también le permitirá al departamento administrar sus recursos de manera efectiva.

Mencione esto con el líder de su equipo, el gerente de proyecto y / o quien haga su estimación; nosotros no. Las personas entienden que las cosas no requieren la misma cantidad de esfuerzo para todos, y pueden trabajar para ajustar las estimaciones cuando se asigna la tarea o al menos disipar cualquier temor que tengan sobre el período de revisión.

Esta es, en mi opinión, la razón por la cual las estimaciones deben ser realizadas por las personas asignadas a la tarea (con el aporte / colaboración de los líderes / pares). Obtiene estimaciones más precisas de cuánto tiempo llevará el trabajo realmente hacer a las personas.

No puedo imaginar una posición peor para poner un desarrollador junior que establecer una expectativa que no pueden mantener, a menos que, por supuesto, lo estén haciendo para desafiarte. ¿Ha tenido alguna repercusión real al no cumplir con las estimaciones?

Primero diría que es importante que hayas aprendido a estimar por tu cuenta. Cuando le den una tarea, calcule de inmediato lo que cree que tomaría, y luego comience a encontrar el delta entre las dos. Casi puedo apostar que la calidad se sacrifica en la estimación inicial corta. Si es simplemente que esperan que diseñe y desarrolle elementos más rápido que usted, es posible que deba conversar con alguien para resolver el problema.

En segundo lugar, comprenda que la calidad es una característica que los interesados, su jefe, deciden pagar. Puede ser algo que tendrá que sacrificar haciendo un poco para satisfacer los requisitos en el tiempo que tiene.

De cualquier manera, elimine el estrés, no es divertido continuar sintiendo que siempre está detrás de escribir código incorrecto. Espero que esto ayude.

Esto es comun.

En general, es mejor dar estimaciones más grandes que más pequeñas (la mayoría de las veces, irá por encima de la estimación). Te aconsejo que cortes la tarea en las subtareas más pequeñas posibles y las estimes con cada tarea no más de 4 horas.

Si una tarea puede tomar más de 4 horas, divídala en otro conjunto de subtareas. También agregue un búfer porcentual para tareas que no puede prever ahora (mi preferencia personal es 1 tarea inesperada por cada 2 tareas estimadas con cada tarea inesperada que toma 2 - 4h dependiendo del sistema con el que esté trabajando).

Después de eso, agregue el tiempo que pensaría que tomaría para pruebas, comunicación, análisis, etc.

Primero: si te vuelves más rápido con cada intento de un problema, probablemente no seas un mal programador. Así que eliminemos ese pensamiento del camino.

Sugeriría que este es el fracaso de sus gerentes, pero es y siempre será su trabajo gestionar las expectativas.

En lugar de castigarte por no poder cumplir con plazos poco realistas, mide cuántos días de trabajo puedes hacer en una semana. Luego explique al líder de su equipo que usted es nuevo en el negocio y el desarrollo de software y que solo se espera que obtenga n días de trabajo de desarrollador senior en una semana estándar. Al menos deberían entender esto, incluso si no les gusta.

Dígales que espera seguir mejorando y muéstreles cómo puede medir esa mejora. Y acuerde con ellos que no espera el salario de un senior hasta que pueda hacer 5 días de trabajo de desarrollador senior en una semana. Pero tampoco espera las mismas responsabilidades que un senior cuando no le pagan tanto.

Para llevar esto más lejos, esta es la razón por la que soy un gran defensor del uso de puntos de historia en lugar de horas para la estimación. es decir. Cada trabajo obtiene una cantidad de puntos, y el equipo estima cuántos puntos pueden lograr en un período de tiempo determinado. En el siguiente período, la estimación es la misma que la real del período anterior, ajustada por factores conocidos como un mes de vacaciones o un desarrollador que se va.

Como gerente, cuando llega un nuevo desarrollador (junior o senior), dejo en claro a la empresa que no aumentaremos la estimación en primera instancia. Se espera que ese desarrollador tome tanto tiempo de otros desarrolladores como ahorre. El nuevo desarrollador probablemente lo hará mejor que eso, pero el mantra no promete ni entrega demasiado.

El desarrollador mejorará con el tiempo, un senior más rápido que un junior, y la "velocidad" del equipo, la estimación mensual, mejorará junto con ella.

Mantenga la calma y continúe. Si alguna vez surge el problema de que no cumple con las estimaciones, solo dígales lo mismo que escribió en su publicación, o si se siente inseguro, hable sobre ello con su mentor / líder de equipo por su cuenta.

Las estimaciones son solo eso, estimaciones. Pueden y estarán apagados, más aún cuando estás aprendiendo las cuerdas. Y como junior, es probable que esté aprendiendo las cuerdas como miembro del equipo en ese proyecto en particular, como programador que utiliza cualquier tecnología que esté utilizando y como empleado de su empresa. Y si está trabajando con personas sensatas, esperan que se salga con las estimaciones.

Es probable que esté viendo las tareas que está haciendo "de abajo hacia arriba". Sus tareas son más importantes para usted que el panorama general del proyecto en el que está trabajando, eso es comprensible. Usted ve las estimaciones como restricciones que se le imponen y obviamente se pone ansioso cuando no las cumple.

Pero cuando observa el panorama general, verá que las estimaciones, incluso más que los "objetivos" para los desarrolladores, son "señales" para los leads / gerentes de proyecto. Romper el trabajo en tareas y estimarlas es una forma de disminuir la complejidad de administrar y estimar todo el proyecto. Realizar un seguimiento del trabajo real realizado frente a las estimaciones es un medio de realizar un seguimiento de cómo va el proyecto, pero es solo una de las métricas que se pueden aplicar. Cuando las estimaciones no se cumplen de manera regular, es una señal para el gerente que hay algo mal con el proyecto. Pero en cualquier proyecto razonable, no será el hecho de que haya un desarrollador junior en el equipo que no cumpla con las estimaciones.

Déjame presentarte a mis dos amigos, WAG y SWAG

Es decir, la "conjetura salvaje" y la "conjetura científica salvaje"

Lo creas o no, no lo inventé. En realidad son bastante comunes en los negocios. Echa un vistazo a este artículo para ver a qué me refiero.

Idealmente, es mejor llegar a una estimación firme, pero si no puede, es mejor decir que la estimación es aproximada debido a datos incompletos que mentir.

La clave es que el negocio no es la programación de computadoras. Gestionar las expectativas es más importante que la precisión. Es importante evaluar el tiempo que cree que tomaría más un 10% como contingencia para compensar cualquier problema imprevisible.

Si sobreestimas, estarán felices cuando termines con tiempo de sobra. Si subestima, no se sentirán decepcionados si cumple con el plazo o extremadamente decepcionados si algo sale mal.

El negocio es un área gris en la que algunas personas adquieren una sensación intuitiva con el tiempo. El hecho de que le estén pidiendo a un desarrollador junior que tome este tipo de decisiones de forma independiente dice una cosa. O no tienen a nadie disponible que sea más capaz de tomar ese tipo de decisiones o los gerentes no quieren asumir la responsabilidad de los fracasos.

Pondría mi dinero en esto último si estás trabajando para una gran organización. Cuando un modelo de negocio jerárquico crece lo suficientemente grande, la parte superior está tan alejada de la parte inferior que los superiores solo pueden medir el progreso por lo que reciben en papel. Es un ambiente terrible porque generalmente se dan promociones para no cometer errores. Pero las personas que reciben las promociones evitan el fracaso al imponer sus responsabilidades a los demás (es decir, la incompetencia ciega) y tomar el crédito por el éxito de las personas que están más abajo en la cadena.

Desafortunadamente, los programadores son objetivos fáciles de lanzar 'debajo del autobús' porque no importa cuán grande sea el problema, trataremos de encontrar una solución. La clave es que no pase más tiempo determinando cómo estimar el problema que implementando la solución.

Ese es un lugar difícil. Parece que estás atrapado en la etapa de "solo tienes que entregar" de esa tubería.

A lo largo de los años, he notado lo siguiente acerca de la estimación: la calidad de una estimación se puede determinar respondiendo (con un nombre propio) las siguientes tres preguntas.

• ¿Quién hizo el diseño?
• ¿Quién hizo la estimación?
• ¿Quién está haciendo la implementación?

La calidad de la estimación es inversamente proporcional al número de individuos distintos nombrados. Por ejemplo: la mejor estimación es cuando la misma persona ha realizado las tres tareas anteriores, una estimación débil es cuando una persona diseñó / estimó y otra realizará la implementación, y la peor estimación es aquella en la que las tres preguntas se responden con Un nombre único.