Encourager les ingénieurs logiciels à suivre le temps

Comment puis-je encourager mes collègues à suivre le temps qu'ils passent à résoudre les problèmes et à implémenter les fonctionnalités? Nous avons un logiciel pour le faire, mais ils ne saisissent tout simplement pas les chiffres.

Je veux que l'équipe s'améliore à fournir des estimations de projet en comparant nos estimations passées au temps réel passé. Je soupçonne que mes collègues ne voient pas l'avantage personnel, car ils ne sont pas souvent impliqués dans la planification du projet.

Je soupçonne que mes collègues ne voient pas l'avantage personnel, car ils ne sont pas souvent impliqués dans la planification du projet.

C'est réparable.

Faites-les participer à la planification.

Joel Spolsky a écrit un article sur la planification basée sur des preuves qui peut vous aider à trouver des arguments.

Vous devez convaincre vos collègues que de meilleures compétences d'estimation peuvent les aider à produire de meilleurs logiciels. Voici quelques points en faveur du suivi du temps des tâches:

• Si vous avez un délai arbitraire fixé par la direction, de bonnes estimations vous diront ce que vous pouvez réellement accomplir pendant cette période. En prime, vous avez de jolis graphiques pour convaincre le manager que vous savez de quoi vous parlez.
• Vous devez réfléchir plus attentivement au projet. L'article que j'ai lié aux états, "vous devez casser votre programme en tâches très petites qui peuvent être mesurées en heures ." Étant donné que vous avez pensé à presque toutes les facettes du projet (j'espère écrire une spécification !), Vous êtes beaucoup moins susceptible d'être surpris par quelque chose auquel vous n'avez pas pensé.
• Cela fait de vous un meilleur développeur. Vous verrez au fil du temps quels types de tâches vous avez tendance à sous-estimer, vous pouvez donc passer du temps à vous améliorer dans ces tâches spécifiques plutôt que d'optimiser aveuglément.

Vous pouvez accomplir cela de manière standard - carottes et bâtons.

Dans ce cas, la ou les carottes pourraient être "une meilleure estimation future en comprenant notre vitesse actuelle" - mais vous devrez suivre.

Votre commentaire selon lequel ils ne sont pas souvent impliqués dans la planification du projet peut en faire une vente difficile.

Le plus performant d' entre eux, en particulier si vous avez des adeptes de PSP , c'est que vous les aidez à s'améliorer.

Le bâton le plus courant (pour les battre avec, pas pour tenir la carotte devant eux) est "c'est obligatoire, faites-le". Même si ce n'est pas vraiment une motivation; au moins la position est claire.

Enfin, le logiciel que vous utilisez contribue-t-il à leur réticence? Est-ce maladroit? Doivent-ils rechercher les codes temporels dans le système A, avant de mettre leur temps dans le système B? Est-il trop granuleux, ne permet-il pas de temps "off" et demande-t-il une comptabilité de 8 heures par jour? Rendez-le aussi sans frottement que possible pour faciliter également l'adoption.

Bonne chance

D'après mon expérience, voici les problèmes avec la plupart des logiciels de suivi du temps:

• Le développeur n'a ni la capacité ni l'autorité de décomposer une tâche en sous-tâches plus facilement estimables à la volée.
• Il n'y a aucun bon moyen de prendre en compte les sous-tâches que vous ne connaissiez pas jusqu'à ce que vous commenciez à travailler sur quelque chose, une situation qui revient tout le temps dans le développement et le débogage de logiciels.
• Le temps passé est saisi après coup, lorsqu'il est difficile de se rappeler exactement combien d'efforts ciblés ont été consacrés à une tâche et combien ont été consacrés aux réunions, aux questions des collègues, aux évaluations par les pairs et à d'autres frais généraux.
• Il n'y a aucun bon moyen de prendre en compte les tâches non suivies. À la fin de la journée, prévoyez-vous 8 heures même si 6 d'entre elles ont été consacrées à des réunions et autres?
• Il n'y a aucun bon moyen de tenir compte et de communiquer l'incertitude dans vos estimations.

J'ai résolu bon nombre de ces problèmes en commençant à utiliser la technique du pomodoro pour moi-même. Si je travaille 25 minutes sans interruption sur une tâche, elle est enregistrée immédiatement, et mes estimations sont faites en fonction de ces intervalles ininterrompus. Je travaille toujours sur l'intégration d'une planification basée sur des preuves pour communiquer l'incertitude et sur la traduction de mon propre suivi à grain fin dans les estimations de programme grossières que les PM aiment, mais cela a certainement été une amélioration jusqu'à présent.

Bonne façon

Utilisez un logiciel, ce qui rend cela facile et presque transparent, comme par exemple Mylyn. Combinez-le avec des outils comme par exemple un tableau de brûlage d'une heure.

Mauvaise façon

Obligez-les à remplir des feuilles de temps fastidieuses, où vous devez spécifier manuellement le projet, la tâche, les dates et heures exactes, etc.

Si vous n'êtes pas le chef d'équipe / PM, vous allez avoir du mal avec celui-ci. Les gens n'aiment pas écouter leurs pairs si cela les oblige à faire plus de travail que ce qui est absolument nécessaire (d'après mon expérience, c'est le cas de toute façon). Essayez de vous en occuper avec votre chef d'équipe ou votre PM, et s'ils sont d'accord avec votre cas, ils peuvent probablement rendre la journalisation obligatoire (c'est ce qui s'est passé là où je travaille actuellement).

Si vous êtes le chef d'équipe / PM, vous devez être plus énergique dans votre rôle: ces personnes sont là pour faire ce que vous leur dites (efficacement), et si vous avez besoin de plus d'informations pour faire votre travail, vous devez les amener à fournir cela information. S'ils ne sont pas disposés à vous aider à obtenir les informations, c'est probablement parce qu'ils ne comprennent pas pourquoi c'est utile, essayez d'avoir une conversation avec eux pour expliquer comment vos projets sont souvent décalés / surestimés / peu importe et pourquoi cela cause vos problèmes, voyez si vous pouvez les retourner!

Suivez votre temps ou ne soyez pas payé. Des millions de personnes le font (consultants, avocats, etc.), pourquoi pas?

Certains pourraient penser que c'est plutôt draconien, mais ce n'est pas le cas. Si vous travaillez chez Starbucks, vous devez nettoyer la salle de bain . Si vous travaillez dans une banque, vous portez un costume et une cravate pour travailler tous les jours et si vous êtes ingénieur logiciel dans une équipe qui a besoin de vous pour suivre votre temps, vous le faites !

Parfois, nous devons faire des choses dans nos emplois que nous n'aimons pas. Nous sommes tous de grands garçons et filles, je pense que nous devrions pouvoir y faire face.

De toute évidence, la meilleure réponse dépend entièrement du mélange psychologique de votre équipe. Sont-ils compétitifs? Concevez un concours récurrent qui récompense le gagnant pour avoir entré son temps dans le système. Ajustez et réglez le concours pour que les joueurs pensent que c'est juste et amusant. Faites-en un jeu.

Ils craignent peut-être que s'il y avait de la transparence sur le temps qu'ils consacraient réellement à l' exécution d'une tâche, il y aurait des conséquences négatives. Je me suis toujours interrogé sur la conception d'un "outil de suivi de l'effort" anonyme et où les compartiments étaient suffisamment élevés pour que plusieurs personnes versent des montants d'effort dans chaque compartiment pour que les contributeurs individuels ne puissent pas être distingués. Même obtenir des coûts d'effort plus précis pour des compartiments de projet de haut niveau pourrait être des données utiles pour la planification de projet et la vitesse globale de l'équipe, mais cela éviterait le "OMG, je ne peux pas croire que Joe ait pris 3 fois son estimation pour faire quelque chose de si simple .. . "ou autre chose que les gens ont peur de signaler dans un système traditionnel de suivi du temps.

Je suppose que ce ne sont que deux exemples, mais vraiment, avoir une bonne compréhension de la composition psychologique de votre équipe vous donnera la bonne réponse pour les inciter ou les encourager à contribuer leurs informations sur les coûts de l'effort.

Réfléchissez à la raison pour laquelle il se peut qu'ils ne répondent pas bien à cette demande. Ne vous contentez pas de supposer qu'ils sont paresseux ou qu'ils évitent les efforts.

Les développeurs qui évitent de produire des preuves sont généralement

• Inquiet de la façon dont il pourrait être utilisé et / ou
• Préoccupé par la validité des données

C'est pourquoi l' estimation basée sur les points et le dimensionnement des chemises ont décollé ces dernières années. Il prend en compte la nature très incertaine du processus d'estimation et permet à la «magie» (c'est-à-dire la moyenne des incertitudes) de prendre le contrôle de l'ordonnancement.

Et, même si cela peut ne pas sembler logique, cela fonctionne surtout - au moins aussi bien qu'un système basé sur l'heure ou le jour. Il est également très difficile de battre une équipe ou un individu autour de la tête avec ce qu'ils ont accompli en un mois si cela se fait de manière arbitraire.

Scrum permet également aux développeurs de contrôler la vitesse, ce qui signifie qu'ils font une promesse de réaliser tout ce que vous choisissez parmi A, B et C ou A, Y et Z. Quand ils ont fait cette promesse, les développeurs n'aiment pas échouer; mais si vous leur faites cette promesse, ils s'en moqueront. C'est ta faute si c'est mal.

Je comprends que vous dites que vous n'utiliseriez pas les réestimations de cette façon, mais dans quelle mesure les membres de votre équipe en sont-ils sûrs?

Tout outil qui nécessite que les programmeurs consacrent encore plus de temps à la programmation n'est pas nécessairement une bonne chose. Les programmeurs ont déjà beaucoup de frais généraux, ils n'ont pas de réunions de 5 minutes, puis codent une tempête.

Si vous avez le pouvoir, vous pouvez les forcer à le faire. Mais de loin la meilleure solution est de construire un outil transparent qui le rend indolore. Je ne peux pas vous dire comment le faire pour la conception, mais pour le codage, vous souhaitez enregistrer les modifications apportées dans l'environnement de développement. Auparavant, c'était une barre incroyablement élevée, mais si vous utilisez quelque chose comme Eclipse, ce n'est pas si mal, peut-être qu'il existe déjà. De cette façon, vous pouvez mesurer le temps passé dans chaque fichier, et potentiellement en Java, chaque méthode. Il s'agit d'informations beaucoup plus fines que celles que vous obtenez en leur demandant de facturer, et cela peut être assez précis.

De même, si vous disposez d'un outil pour saisir des conceptions, vous pouvez y intercepter.

Cela dépend de comment et pourquoi vous voulez qu'ils suivent le temps, aussi comptons-nous simplement le temps au bureau ou le temps consacré au trajet pour travailler en pensant également au problème?

La planification du projet est difficile et il y a de fortes chances que les mesures que vous obtenez ne soient pas aussi utiles que vous pourriez le penser. Il n'y a pas deux problèmes identiques, une tâche peut donc prendre huit heures et une autre 32 heures.

Vous voudrez peut-être examiner la planification basée sur des preuves car le développeur estime la durée d'une tâche, puis ajuste au fil du temps en fonction de la qualité de ses estimations; cependant, ce n'est pas aussi bon pour les grands projets car vous ne connaissez peut-être pas toutes les tâches à l'avance. Pour les grands projets, il serait préférable de regarder des projets antérieurs de portée similaire et de les utiliser comme critère plutôt que d'essayer d'agréger des estimations individuelles.

Essayez de les initier à des systèmes d'organisation personnels comme la technique de Pomodoro par exemple (il y en a beaucoup d'autres mais c'est celui que j'essaie maintenant)

La technique utilise une minuterie pour diviser les périodes de travail en intervalles de 25 minutes appelés «Pomodori» (du mot italien pour «tomates») séparés par de courtes pauses. Étroitement liée à des concepts tels que le timeboxing et le développement itératif et incrémental utilisé dans la conception de logiciels, la méthode a été adoptée dans des contextes de programmation par paires. La méthode est basée sur l'idée que des pauses fréquentes peuvent améliorer l'agilité mentale.

Au lieu de les convaincre d'entrer leurs numéros, utilisez un logiciel qui fonctionne sans effort. J'utilise ScreenAware: https://www.screenaware.com/en/ Il suit automatiquement votre temps et l'affecte aux projets respectifs. Donc c'est toujours précis et personne n'a plus à deviner

Avez-vous envisagé d'utiliser votre système de tickets existant à la place? Notre système de ticket surveille le temps entre la création d'un ticket et sa fermeture. Si vous créez des tickets pour des tâches et faites d'un numéro de ticket une exigence pour la validation du code, vous en aurez plus pour votre argent.