Animar a los ingenieros de software a rastrear el tiempo.

¿Cómo puedo alentar a mis compañeros de trabajo a rastrear el tiempo que pasan resolviendo problemas e implementando funciones? Tenemos software para hacer esto, pero simplemente no ingresan los números.

Quiero que el equipo mejore al proporcionar estimaciones del proyecto comparando nuestras estimaciones pasadas con el tiempo real empleado. Sospecho que mis compañeros de trabajo no ven el beneficio personal, ya que no suelen participar en la programación de proyectos.

Sospecho que mis compañeros de trabajo no ven el beneficio personal, ya que no suelen participar en la programación de proyectos.

Eso es reparable.

Haga que participen en la programación.

Joel Spolsky escribió un artículo sobre Programación basada en evidencia que puede ayudarlo a encontrar algunos argumentos.

Debe convencer a sus compañeros de trabajo de que mejores habilidades de estimación pueden ayudarlos a producir un mejor software. Aquí hay algunos puntos a favor del seguimiento del tiempo de la tarea:

• Si tiene una fecha límite arbitraria establecida por la administración, las buenas estimaciones le indicarán lo que realmente puede lograr en ese momento. Como beneficio adicional, tiene algunos gráficos agradables para convencer al gerente de que sabe de lo que está hablando.
• Tienes que pensar en el proyecto con más cuidado. El artículo que vinculé a los estados, "tienes que dividir tu horario en tareas muy pequeñas que se pueden medir en horas ". Dado que pensó en casi todas las facetas del proyecto (¡espero que escriba una especificación !), Es mucho menos probable que se sorprenda de algo en lo que no pensó.
• Te hace un mejor desarrollador. Verá con el tiempo qué tipo de tareas tiende a subestimar, por lo que puede pasar un tiempo mejorando en esas tareas específicas lugar de optimizar a ciegas.

Puede lograr esto de la manera estándar: zanahorias y palos.

La (s) zanahoria (s) en este caso podría ser "una mejor estimación futura al comprender nuestra velocidad actual", pero tendría que seguir adelante.

Su comentario de que no suelen estar involucrados en la programación de proyectos puede hacer que esta sea una venta difícil.

El más funcional entre ellos, especialmente si tienes seguidores de PSP , es que los estás ayudando a mejorar.

El palo más común (para golpearlos, no para sostener la zanahoria delante de ellos) es "es obligatorio, hazlo". Si bien no es un gran motivador; Al menos la posición es clara.

Por último, ¿el software que está utilizando contribuye a su reticencia? ¿Es torpe? ¿Tienen que buscar códigos de tiempo en el Sistema A, antes de poner su tiempo en el Sistema B? ¿Es demasiado granular, no permite el tiempo "apagado" y exige un recuento de 8 horas por día. Haga que sea lo más libre de fricción posible para ayudar también a la adopción.

Buena suerte

En mi experiencia, los siguientes son los problemas con la mayoría del software de seguimiento de tiempo:

• El desarrollador no tiene la capacidad o la autoridad para dividir una tarea en subtareas más fáciles de estimar sobre la marcha.
• No hay una buena manera de dar cuenta de las subtareas que no conocía hasta que comenzó a trabajar en algo, una situación que surge todo el tiempo en el desarrollo y depuración de software.
• El tiempo dedicado se ingresa después del hecho, cuando es difícil recordar exactamente cuánto esfuerzo se concentró en una tarea y cuánto se destinó a las reuniones, las preguntas de los colegas, las revisiones de pares y otros gastos generales.
• No hay una buena manera de dar cuenta de las tareas no rastreadas. Al final del día, ¿dejas pasar 8 horas a pesar de que 6 de ellos se dedicaron a reuniones y cosas así?
• No hay una buena manera de explicar y comunicar la incertidumbre en sus estimaciones.

He abordado muchos de esos problemas comenzando a utilizar la técnica de pomodoro para mí. Si trabajo 25 minutos ininterrumpidamente en una tarea, se registra en ese momento, y mis estimaciones se realizan en términos de esos intervalos ininterrumpidos. Todavía estoy trabajando para incorporar la programación basada en la evidencia para comunicar la incertidumbre, y en traducir mi propio seguimiento detallado en las estimaciones del horario aproximado que les gusta a los PM, pero definitivamente ha sido una mejora hasta ahora.

Buen camino

Utilice software, que en realidad lo hace fácil y casi transparente, como por ejemplo Mylyn. Combínelo con herramientas como, por ejemplo, un gráfico de horas quemadas.

Mal camino

Oblígalos a completar tediosas hojas de tiempo, donde debes especificar manualmente el proyecto, la tarea, las fechas y horas exactas, etc.

Si no eres el líder del equipo / PM, entonces tendrás problemas con este. A la gente no le gusta escuchar a sus compañeros si les obliga a tener que hacer más trabajo del necesario (en mi experiencia, ese es el caso, de todos modos). Intente hablar con el líder de su equipo o con el primer ministro, y si están de acuerdo con su caso, probablemente puedan hacer que el registro de tiempo sea obligatorio (eso es lo que sucedió donde actualmente trabajo).

Si usted es el líder del equipo / PM, debe ser más enérgico en su papel: estas personas están allí para hacer lo que usted les dice (de manera efectiva), y si necesita más información para hacer su trabajo, debe hacer que se lo proporcionen. información. Si no están dispuestos a ayudarlo a obtener la información, probablemente sea porque no entienden por qué es útil, intente hablar con ellos para explicar cómo sus proyectos a menudo se salen del horario / se sobreestiman / lo que sea y por qué está causando Si tienes problemas, mira si puedes resolverlos.

Controle su tiempo o no le paguen. Millones de personas lo hacen (consultores, abogados, etc.), ¿por qué no pueden hacerlo?

Algunos podrían pensar que esto es bastante draconiano, pero no lo es. Si trabajas en Starbucks, tienes que limpiar el baño . Si trabaja en un banco, usa traje y corbata para trabajar todos los días , y si es ingeniero de software en un equipo que lo necesita para controlar su tiempo, ¡lo hace !

A veces tenemos que hacer cosas en nuestros trabajos que no nos gustan. Todos somos grandes niños y niñas, creo que deberíamos ser capaces de manejarlo.

Obviamente, la mejor respuesta depende completamente de la combinación psicológica de su equipo. ¿Son competitivos? Diseñe un concurso recurrente que recompense al ganador por ingresar su tiempo en el sistema. Ajusta y ajusta el concurso para que los jugadores piensen que es justo y divertido. Hazlo un juego.

Quizás les preocupa que si hubiera transparencia en cuanto tiempo realmente dedicaron realizar una tarea, habría consecuencias negativas. Siempre me he preguntado sobre el diseño de una "herramienta de seguimiento del esfuerzo" que fuera anónima y donde los cubos fueran lo suficientemente altos como para que hubiera múltiples personas que viertan cantidades gastadas en cada cubo que los contribuyentes individuales no podrían distinguir. Incluso el simple hecho de obtener costos de esfuerzo más precisos para grupos de proyectos de alto nivel podrían ser datos útiles para la planificación del proyecto y la velocidad general del equipo, pero esto evitaría el "OMG, no puedo creer que Joe tomó 3 veces su estimación para hacer algo tan simple ... "o lo que sea que las personas tienen miedo de informar en un sistema tradicional de seguimiento del tiempo.

Supongo que estos son solo dos ejemplos, pero en realidad, tener una buena comprensión de la composición psicológica de su equipo le dará la respuesta correcta sobre cómo incentivarlos o alentarlos a contribuir con su información de costos de esfuerzo.

Piense por qué podría ser que no responden bien a esta solicitud. No asuma que son flojos o que evitan el esfuerzo.

Los desarrolladores que evitan producir evidencia generalmente son

• Preocupado por cómo podría usarse y / o
• Preocupado por la validez de los datos.

Es por eso que la estimación basada en puntos y el tamaño de la camisa se han disparado en los últimos años. Tiene en cuenta la naturaleza muy incierta del proceso de estimación y permite que la "magia" (es decir, promediar las incertidumbres) tome el control de la programación.

Y, aunque puede no parecer lógico, funciona principalmente, al menos tan bien como un sistema basado en la hora o el día. También es muy difícil golpear a un equipo o individuo alrededor de la cabeza con lo que han logrado en un mes si se hace de manera arbitraria.

Scrum también permite a los desarrolladores controlar la velocidad, lo que significa que están haciendo una promesa de lograr lo que elijas de A, B y C o A, Y y Z. Cuando hicieron esa promesa, a los desarrolladores no les gusta fracasar; pero si les haces esa promesa, no les importará. Es tu culpa si está mal.

Entiendo que estás diciendo que no usarías las reestimaciones de esa manera, pero ¿qué tan seguros están los individuos de tu equipo de eso?

Cualquier herramienta que requiera que los programadores dediquen aún más tiempo a la programación no es necesariamente una gran cosa. Los programadores ya tienen un montón de gastos generales, no tienen reuniones de 5 minutos y luego codifican una tormenta.

Si tienes el poder, puedes obligarlos a hacerlo. Pero, con mucho, la mejor solución es construir una herramienta perfecta que la haga indolora. No puedo decirle cómo hacerlo para el diseño, pero para la codificación, desea registrar los cambios realizados en el entorno de desarrollo. Esto solía ser una barra increíblemente alta, pero si está usando algo como Eclipse, no es tan malo, tal vez ya exista. De esta manera, puede medir la cantidad de tiempo que pasa en cada archivo, y potencialmente en Java, cada método. Esa es una información mucho más precisa que la que se obtiene al pedirles que facturen, y puede ser bastante precisa.

Del mismo modo, si tiene una herramienta para ingresar diseños, puede interceptar allí.

Depende de cómo y por qué quiere que hagan un seguimiento del tiempo, ¿también estamos contando el tiempo en la oficina o el tiempo que pasa en el viaje al trabajo pensando también en el problema?

La programación del proyecto es difícil y existe una buena posibilidad de que las métricas que obtenga no sean tan útiles como podría pensar que serían. No hay dos problemas iguales, por lo que una tarea puede tardar ocho horas mientras que otra puede tardar 32 horas en finalizar.

Es posible que desee analizar la programación basada en evidencia, ya que el desarrollador calcula la duración de una tarea y luego la ajusta con el tiempo en función de lo buenas que sean sus estimaciones; sin embargo, no es tan bueno para grandes proyectos ya que es posible que no conozca todas las tareas por adelantado. Para proyectos grandes, es mejor que mire proyectos anteriores de alcance similar y los use como criterio en lugar de tratar de agregar estimaciones individuales.

Intente presentarlos a los sistemas de organización personal como la técnica Pomodoro, por ejemplo (hay muchos otros, pero ese es el que estoy probando ahora)

La técnica utiliza un temporizador para dividir los períodos de trabajo en intervalos de 25 minutos llamados 'Pomodori' (de la palabra italiana para 'tomates') separados por breves descansos. Estrechamente relacionado con conceptos como el timeboxing y el desarrollo iterativo e incremental utilizado en el diseño de software, el método se ha adoptado en contextos de programación de pares. El método se basa en la idea de que los descansos frecuentes pueden mejorar la agilidad mental.

En lugar de convencerlos de ingresar sus números, use un software que funcione sin esfuerzo. Estoy usando ScreenAware: https://www.screenaware.com/en/ Realiza un seguimiento de su tiempo automáticamente y lo asigna a los proyectos respectivos. Así que siempre es preciso y ya nadie tiene que adivinar

¿Ha considerado usar su sistema de tickets existente? Nuestro sistema de tickets monitorea el tiempo entre la creación de un ticket y cuándo está cerrado. Si crea tickets para tareas y hace que un número de ticket sea un requisito para comprometer el código, obtendrá más dinero por su dinero.