¿Cómo puedo rastrear la productividad de programación diariamente? [cerrado]

¿Cómo puedo hacer un seguimiento de que estoy desarrollando software más o menos productivo que los días anteriores?

Hay una respuesta simple: no puedes. Y además, no deberías.

Desea medir su propia productividad, pero puede generalizar: ¿cómo puede medir la productividad de los programadores? En primer lugar, debe definir qué quiere decir con "productividad": ¿la cantidad de código producido? ¿Cantidad de diseño (o especificación) implementado? ¿Número de problemas solucionados? Calidad del código producido? (Sí, la calidad es un contador de productividad, puede producir muchos códigos malos o pocos códigos buenos, ¿qué ha sido más productivo?). Todos estos valores difícilmente pueden asignarse a una base diaria, y cualquier intento de rastrear la productividad diaria es peligroso para el proyecto, para la empresa y para el programador.

Mi consejo es definir claramente lo que quiere decir como "productividad", luego definir una unidad de medida y aplicarla semanalmente y mensualmente.

Diría que la mejor manera de medir su productividad es establecer una meta cada día para lo que quiere haber hecho ese día, y si la completa, considérela productiva. Es una medida bastante subjetiva, pero lo más probable es que la encuentre mucho más gratificante que una objetiva.

Ambas sugerencias a continuación se pueden adoptar de manera aproximada para su necesidad, pero en ambos casos debe hacer estimaciones por adelantado y luego analizarlas ad hoc (y, sinceramente, no estoy seguro de si hay otra manera efectiva de medir esto, estoy de acuerdo con TheLQ, las líneas de código por período de tiempo no son utilizables en absoluto).

Metodologías de desarrollo ágil
Aunque no estoy seguro de cuán efectivamente puede aplicarse a un solo escenario de desarrollador, algunos de los principios utilizados en Agile pueden resultar útiles en lo que pretende lograr. Agile trabaja en ciclos en los que los desarrolladores tienen como objetivo implementar historias (tareas) que se puntúan (en puntos) en función de la complejidad de la implementación al comienzo de un ciclo de desarrollo, y luego se analizan al final de cada ciclo. Esto permite determinar la velocidad, es decir, el número de puntos que un desarrollador o un equipo pueden completar dentro de un solo ciclo de desarrollo.

Si la forma en que trabaja le permite adoptar algunos de los principios y organizar su trabajo en ciclos, puede usar la métrica de velocidad por ciclo de desarrollo para seguir su eficiencia. Tenga en cuenta que los ciclos generalmente duran de 2 a 3 semanas, sin embargo, debe poder acortarlos cuando lo use solo para usted. Todo se reduce a si puede adoptar dicha metodología en su entorno.

Programación basada en la evidencia
Aunque está destinada principalmente a mejorar las estimaciones, debe poder usarla de manera efectiva para rastrear las tendencias decrecientes en la productividad.

De acuerdo con Lorenzo, definir la productividad.

También hice esto: 1. Descomponga todas las tareas (desglose de alto o bajo nivel). 2. Calcule las horas de trabajo para cada tarea (no olvide configurar el búfer de retraso para cada tarea). 3. Termina la tarea. 4. Revise cada tarea y vea si es lo suficientemente productivo o no.

Aquí hay una medida significativa y precisa de productividad que implica tomar múltiples instantáneas de programación basadas en la evidencia :

Una vez que haya reunido las estadísticas de unos días, ejecute su simulación Monte Carlo y observe el gráfico, que debería verse así:

Luego haga un día más de trabajo y vuelva a ejecutar la simulación. Si fue productivo ese día, el gráfico debería cambiar algo como esto:

Lo más importante es que si fue producto ese día, la probabilidad de la fecha de envío en cualquier fecha dada debería aumentar desde la última vez que ejecutó la simulación antes de ese día de trabajo. Si disminuye, entonces fuiste menos productivo ese día.

Por supuesto, la precisión de EBS aumenta con el tiempo y la experiencia, por lo que puede ser otra razón para el cambio en el valor de probabilidad de la fecha de envío. Es por eso que desea comenzar a hacer esto al menos después de unos días de trabajo de muestreo. Sin embargo, incluso sin eso, si fue significativamente más productivo en un día u otro, la probabilidad debería aumentar notablemente.

El recuento de líneas de código es una medida imperfecta, ya que no ofrece información sobre la calidad del código, pero se puede utilizar para determinar la productividad general. Dependiendo del idioma que use, hay diferentes herramientas que contarán líneas de código para usted, pero he solicitado que BitBucket, un repositorio de Git, agregue estadísticas relacionadas con la productividad.

https://bitbucket.org/site/master/issue/4307/feature-request-contributor-statistics

Mida el tiempo que le toma sentarse en su computadora por la mañana hasta que realice cualquier actividad no relacionada con el trabajo, como 9gag, facebook, reddit, etc. Su productividad ese día es proporcional a ese número.

Suponga por un momento que ser productivo es administrar su tiempo de manera que está utilizando todo su tiempo de trabajo para completar sus tareas, y que cualquier cosa que contribuya al tiempo perdido, es decir, el tiempo dedicado a no completar sus tareas, no es productivo.

Lo único que realmente puede hacer es registrar su tiempo cuando se dedica a diversas actividades a lo largo del día. Time boxing es una técnica utilizada para diversos fines, pero se adaptaría a este esfuerzo para registrar su actividad durante un día. Pase 15 minutos en un temporizador simplemente haciendo alguna tarea. Si la tarea es algo en lo que se supone que debe estar trabajando, su tiempo fue productivo. Si te encontraste editando tu blog, leyendo un periódico o soñando despierto con esa linda chica en contabilidad, entonces tu tiempo probablemente no fue productivo. Suma tus minutos al final del día y tendrás una idea de lo productivo que eres ...

Pero hay una trampa! ¿Qué haces con esos otros minutos ... ya sabes, tomar un descanso de 5 minutos, ir a almorzar, hacer que tu jefe te interrumpa para contarte sobre ese gran pez que no atrapó en su último viaje de pesca? Registra todo eso también. El tiempo dedicado a un descanso no se desperdicia si contribuye a su salud mental y bienestar ... ¡siempre y cuando no tome un descanso de 5 minutos cada 10-15 minutos! En cuanto al resto, interrupciones, lidiar con otros asuntos relacionados con el trabajo ... todo esto puede ser rastreado.

Por supuesto, puede obsesionarse con este tipo de cosas, y que Dios lo ayude si el jefe es una de esas personas que lo ve en el tiempo y lo usa para justificar razones para acumular más trabajo o criticar sus esfuerzos. Verá, el problema con la obsesión por las horas productivas es que puede estar trabajando durante todo un día, y aún así no se hace nada de relevancia real. Algunos días puedes escribir código como si fuera mantequilla derritiéndose directamente de tu cerebro, y en ese sándwich que llamas pantalla ... mientras que otros días puedes tener un bloqueo mental grave mientras intentas 357 formas diferentes de hacer lo mismo cosa, solo para verlo fallar. Muchos dirían que las "fallas" continuas pueden ser improductivas, y eso en sí mismo no va a ser ayudado sin importar cuánto tiempo pase y registre sus horas durante el día.

La otra forma de verlo es simplemente establecer una serie de objetivos, completar durante un día y una semana, y luego trabajar para completarlos. Si realmente logra sus objetivos, puede argumentar que ha sido productivo, y si no logra sus objetivos, es posible que necesite comprender por qué no los cumplió y decidir si fue o no productivo basado en las razones reales por las que no cumplió sus objetivos. En última instancia, si entrega el código de trabajo cuando es necesario, y si puede hacer que sus pruebas pasen y se complete una tarea, entonces ha sido productivo. Las mediciones solo serán valiosas si hay una razón legítima para analizarlas estadísticamente más adelante.