Comment puis-je suivre la productivité de la programmation au quotidien? [fermé]

Comment savoir si je développe des logiciels plus ou moins productifs que les jours précédents?

Il y a une réponse simple: vous ne pouvez pas. Et d'ailleurs, vous ne devriez pas.

Vous voulez mesurer votre propre productivité, mais vous pouvez généraliser: comment mesurer la productivité des programmeurs? Vous devez tout d'abord définir ce que vous entendez par "productivité": quantité de code produite? Quantité de conception (ou spécification) mise en œuvre? Nombre de problèmes résolus? Qualité du code produit? (Oui, la qualité est un compteur de productivité, vous pouvez produire beaucoup de mauvais code ou peu de bon code, qu'est-ce qui a été le plus productif?). Toutes ces valeurs peuvent difficilement être mises en correspondance avec une base quotidienne, et toute tentative de suivre la productivité quotidienne est dangereuse pour le projet, pour l'entreprise et pour le programmeur.

Mon conseil est de définir clairement ce que vous entendez par «productivité», puis de définir une unité de mesure et de l'appliquer sur une base hebdomadaire et mensuelle.

Je dirais que la meilleure façon de mesurer votre productivité est de fixer chaque jour un objectif pour ce que vous voulez faire ce jour-là, et si vous le terminez, considérez-le comme productif. C'est une mesure assez subjective, mais vous la trouverez probablement beaucoup plus gratifiante qu'objective.

Les deux suggestions ci-dessous peuvent être approximativement adoptées en fonction de vos besoins, mais dans les deux cas, vous devez faire des estimations à l'avance, puis les analyser ad hoc (et honnêtement, je ne suis pas sûr qu'il existe un autre moyen efficace de mesurer cela, je suis d'accord avec TheLQ que les lignes de code par période ne sont pas du tout utilisables).

Méthodologies de développement Agile
Bien que je ne sois pas sûr de l'efficacité avec laquelle il peut être appliqué à un scénario de développeur unique, certains des principes utilisés dans Agile peuvent s'avérer utiles dans ce que vous souhaitez accomplir. Agile fonctionne en cycles dans lesquels les développeurs visent à implémenter des histoires (tâches) qui sont notées (en points) en fonction de la complexité de la mise en œuvre au début d'un cycle de développement, puis analysées à la fin de chaque cycle. Cela permet de déterminer la vitesse, c'est-à-dire le nombre de points qu'un développeur ou une équipe peut compléter au cours d'un même cycle de développement.

Si la façon dont vous travaillez vous permet d'adopter certains principes et d'organiser votre travail en cycles, vous pouvez utiliser la métrique vitesse par cycle de développement pour suivre votre efficacité. Notez que les cycles durent généralement 2-3 semaines, mais vous devriez être en mesure de les raccourcir uniquement lorsque vous les utilisez. Tout se résume à si vous pouvez adopter une telle méthodologie dans votre environnement.

Planification basée sur des preuves
Même si elle est principalement destinée à améliorer les estimations, vous devriez pouvoir l'utiliser efficacement pour suivre les tendances à la baisse de la productivité.

D'accord avec Lorenzo, définissez la productivité.

J'ai également fait ceci: 1. Décomposer toutes les tâches (décomposition de haut niveau ou de bas niveau). 2. Estimez les heures de travail pour chaque tâche (n'oubliez pas de définir un tampon de retard pour chaque tâche). 3. Terminez la tâche. 4. Revoyez chaque tâche et voyez si vous êtes suffisamment productif ou non.

Voici une mesure significative et précise de la productivité qui implique de prendre plusieurs instantanés de planification basés sur des preuves :

Une fois que vous avez rassemblé quelques jours de statistiques, lancez votre simulation Monte Carlo et observez le graphique, qui devrait ressembler à ceci:

Effectuez ensuite une journée de travail supplémentaire et relancez la simulation. Si vous étiez productif ce jour-là, le graphique devrait changer quelque chose comme ceci:

Plus important encore, si vous étiez un produit ce jour-là, la probabilité de date d'expédition à une date donnée devrait augmenter depuis la dernière exécution de la simulation avant ce jour de travail. Si elle diminue, vous étiez moins productif ce jour-là.

Bien sûr, la précision d'EBS augmente avec le temps et l'expérience, ce qui peut être une autre raison du changement de la valeur de probabilité de date d'expédition. C'est pourquoi vous voulez commencer à le faire au moins après quelques jours de travail échantillonné. Même sans cela, cependant, si vous étiez significativement plus productif un jour ou l'autre, la probabilité devrait augmenter de manière assez sensible.

Le comptage des lignes de code est une mesure imparfaite car il n'offre aucun aperçu de la qualité du code mais peut être utilisé pour déterminer la productivité générale. Selon la langue que vous utilisez, il existe différents outils qui compteront les lignes de code pour vous, mais j'ai demandé à BitBucket, un référentiel Git, d'ajouter des statistiques liées à la productivité.

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

Mesurez le temps qu'il vous faut pour vous asseoir devant votre ordinateur le matin jusqu'à ce que vous effectuiez une activité non liée au travail, comme 9gag, facebook, reddit, etc. Votre productivité ce jour-là est proportionnelle à ce nombre.

Supposons un instant qu'être productif consiste à gérer votre temps de telle sorte que vous utilisez tout votre temps de travail pour travailler à la réalisation de vos tâches, et que tout ce qui contribue au temps perdu - c'est-à-dire: le temps passé à ne pas terminer vos tâches - est non productif.

La seule chose que vous pouvez vraiment faire est d'enregistrer votre temps lorsque vous vous engagez dans diverses activités tout au long de la journée. La boxe horaire est une technique utilisée à diverses fins, mais conviendrait à cet effort pour enregistrer votre activité pendant une journée. Passez 15 minutes sur une minuterie à faire simplement une tâche. Si la tâche est quelque chose sur laquelle vous êtes censé travailler, votre temps a été productif. Si vous vous êtes retrouvé à éditer votre blog, à lire un journal ou à rêver de cette gentille fille en comptabilité, votre temps était probablement improductif. Additionnez vos minutes à la fin de la journée et vous aurez une idée de votre productivité ...

Mais il y a un hic! Que faites-vous de ces autres minutes ... vous savez, faire une pause de 5 minutes, aller déjeuner, demander à votre patron de vous interrompre pour vous parler de ce gros poisson qu'il n'a pas attrapé lors de son dernier voyage de pêche? Enregistrez tout cela aussi. Le temps consacré à une pause n'est pas perdu s'il contribue à votre santé mentale et à votre bien-être ... tant que vous ne faites pas de pause de 5 minutes toutes les 10 à 15 minutes !! Pour le reste, les interruptions, le traitement d'autres problèmes liés au travail .. tout cela peut être suivi.

Vous pouvez bien sûr vous retrouver obsédé par ce genre de choses, et Dieu vous aide si le patron est une de ces personnes qui vous voit faire du time-boxing et qui s'en sert pour justifier des raisons d'accumuler plus de travail ou critiquer vos efforts. Vous voyez, le problème de l'obsession des heures productives est que vous pouvez travailler toute une journée et que vous ne faites rien de vraiment pertinent. Certains jours, vous pouvez écrire du code comme si le beurre fondait directement de votre cerveau et sur ce sandwich que vous appelez votre écran ... tandis que d'autres jours, vous pouvez avoir un sérieux blocage mental en essayant 357 façons différentes de faire de même chose, seulement pour le voir échouer. Beaucoup diraient que les «échecs» continus peuvent être improductifs, et cela en soi ne sera pas aidé, peu importe le temps que vous placez et enregistrez vos heures pendant la journée.

L'autre façon de voir les choses est simplement de vous fixer un certain nombre d'objectifs, de les accomplir pendant une journée et une semaine, puis de travailler à les atteindre. Si vous atteignez réellement vos objectifs, vous pouvez affirmer que vous avez été productif et si vous n'atteignez pas vos objectifs, vous devrez peut-être comprendre pourquoi vous ne les avez pas atteints et décider si vous étiez ou non productif. en fonction des raisons réelles pour lesquelles vous n'avez pas atteint vos objectifs. En fin de compte, si vous fournissez du code de travail lorsque cela est nécessaire, et si vous pouvez réussir vos tests et une tâche terminée, alors vous avez été productif. Les mesures n'auront de valeur que s'il existe une raison légitime de les analyser statistiquement ultérieurement.