Estimation des conditions de développement et de test des tâches (non nécessaire)

Je teste depuis 12 ans, j'ai travaillé chez Naumen et Yandex. Maintenant, je dirige le département de test de 150 personnes dans le circuit et continue de travailler en tant que testeur dans l'une des équipes.


Après un examen des performances de six mois, les managers de différentes équipes ont indiqué les objectifs qu'ils avaient fixés pour leurs testeurs. Un sur cinq avait ceci: "Apprenez à évaluer les délais pour tester les tâches." Une telle «évaluation des délais» est souvent demandée non seulement aux testeurs, mais aussi aux développeurs.



Estimation des termes dans 95% des cas. Merci xkcd .


Je considère qu'il est absolument dangereux de pratiquer lorsque l'entrepreneur évalue les délais pour une tâche distincte. Cela est directement lié au manque d'éducation du système et aux faibles exigences pour les gestionnaires.

Je vais maintenant expliquer comment cela fonctionne.


Sur les oeuvres des classiques


Maxim Dorofeev - L'effet du redressement des délais


Je cite le livre " Jedi Techniques ", bien que l’on puisse citer la loi de Parkinson :


Un homme vient à nous, pose une tâche et demande combien de temps cela peut prendre pour l'achever. En évaluant la tâche, nous voulons bien sûr nommer la période à laquelle nous serons à temps pour sûr, et comme beaucoup de choses peuvent arriver (et nous soupçonnons que quelque chose va arriver à coup sûr), nous mettons une certaine marge de temps dans l'évaluation.

Au lieu de commencer immédiatement à achever la tâche, nous «traitons avec l'urgence», car «cette tâche n'est pas encore brûlante» - nous avons également le stock susmentionné.

La tâche commence à «fumer», et nous y allons. Si rien ne s'est passé, alors nous le faisons à temps, mais si quelque chose s'est passé ... Nous avons déjà dépensé la réserve pour ce «quelque chose» et, par conséquent, nous sommes en retard.

Par conséquent, tout délai nommé comme délai devient un délai avant lequel la tâche ne sera pas terminée. Cela entraîne des conséquences particulièrement désagréables lors du travail d'équipe, lorsque la coopération de différents spécialistes et de différents services est nécessaire pour mener à bien une tâche ou un projet.


L'homme en tant que redresseur (et diode) est une illustration des techniques Jedi. Il y a aussi une vidéo .


Tom Demarco - Le facteur humain


Dans la cinquième partie du premier chapitre, il existe des liens vers des études sur la dépendance de la productivité à l'égard de celui qui a effectué l'évaluation du temps.



En bref: le fait de l'évaluation affecte les termes pour le pire d'environ 40%.


Je recommande de le lire. Tous les facteurs énumérés dans le cinquième chapitre sont toujours pertinents.


Deming et Nive - Une expérience avec des perles rouges


Au cours de l'année écoulée, j'ai entendu à deux reprises des responsables: "Nous avons appris à respecter les délais d'évaluation des tâches, maintenant un tel programmeur ou testeur ne viole pas les délais que j'ai nommés."


Je pense que c'est un problème extrêmement grave, car cela signifie que ce programmeur ou testeur surestime systématiquement et délibérément les délais, travaille sur la relaxation et ment au manager . Dans le monde, il existe des variations et la non-violation des estimations de tâches spécifiques signifie que l'évaluation d'une telle personne est toujours à droite de la courbe de distribution de la durée réelle du travail.


Les auteurs mentionnés dans le titre disent que la seule véritable façon d'estimer les délais est de recourir à des méthodes statistiques. Un ensemble de tâches typiques doit être évalué. "Avons-nous des tâches différentes?" C'est un mensonge. À l'intervalle d'une année, il n'y aura pas autant de tâches différentes. En règle générale, une telle déclaration est le signe d'un manque de réflexion sur le processus et de l'échec des exercices: décomposition, MVP, prototypes, standardisation.


À propos des clients qui ont besoin de délais


Tout d'abord, il convient de noter que le plus souvent - et c'est drôle en soi - rien ne dépend de la réponse de l'entrepreneur, car il y a déjà des délais. Le gestionnaire ne souhaite pas savoir combien de temps nous accomplirons la tâche , mais savoir si nous serons à temps avant la date limite et ce que nous serons à temps . Ce sont des questions différentes et il faut y répondre de différentes manières.


En règle générale, la réponse à la question `` serons-nous à temps dans les délais '' est l'analytique et le MVP, une infrastructure de développement de haute qualité et l'ampleur de la dette technique, à savoir la difficulté de refactoring et la présence de tests de régression automatiques.


Encore une fois: l'estimation du timing empêche l'artiste de rattraper le délai.


Deuxièmement, il existe une série d'exercices de développement. Tous ne sont pas simples. Ils ne fournissent pas directement de réponse à la question «quand la fonctionnalité sera prête». Cependant, ils réduisent la taille de la livraison, réduisent la complexité du développement et des tests, et finalement réduisent la variabilité des termes.


  • MVP
  • dĂ©composition des tâches
  • limitation du travail inachevĂ© (le programmeur ne prend pas de nouvelles tâches jusqu'Ă  ce que les anciennes sortent)
  • versions distinctes de refactoring et fonctionnalitĂ©s ultĂ©rieures
  • version sĂ©parĂ©e du backend, du frontend et des autres parties du produit
  • sorties de canaris
  • utilisation d' indicateurs de fonctionnalitĂ©
  • capacitĂ© des testeurs Ă  sĂ©parer les dĂ©fauts importants des dĂ©fauts non importants
  • capacitĂ© d'une Ă©quipe Ă  libĂ©rer avec des dĂ©fauts sans importance

Si l'équipe effectue ces exercices et que le gestionnaire est qualifié, pour répondre aux clients, il n'a pas besoin d'exiger des exécuteurs testamentaires une date limite. Si les exercices ne sont pas effectués, alors tout terme spécifié par le manager sera probablement un mensonge.


À propos des gestionnaires incompétents


Il est très facile de confondre l'estimation des termes (quand la tâche sera terminée) et l'estimation des coûts de main-d'œuvre (combien de temps faut-il pour développer une fonctionnalité). Estimation des termes, comme nous l'avons déjà compris, sinon nuisible, du moins inutile. Mais l'évaluation des coûts de main-d'œuvre est un exercice plutôt utile.


La nécessité d'évaluer les coûts de main-d'œuvre lorsque la tâche est terminée nous oblige à faire les exercices utiles ci-dessus: principalement, la décomposition de cette tâche.


Mais il ne faut pas oublier que l' évaluation des coûts salariaux dans une équipe avec un manager incompétent se transforme très facilement en une estimation des termes . Cela implique un million de distorsions cognitives et un manque de compréhension du fonctionnement des chaînes de production.


Exemple de vie:
- Combien de temps allez-vous consacrer à cette fonctionnalité?
- Je vais écrire une semaine et demie et corriger les bugs pendant trois jours.
- Autrement dit, dans 3-4 semaines, il sera prĂŞt?

Autrement dit, la différence entre «je passerai la journée sur cette tâche» et «la tâche sera prête en une journée» est multiple et fondamentale.


Vous enseignez la vie, et qu'avez-vous accompli vous-mĂŞme?


Oui, parlons de moi et de mon équipe. Nous faisons avec succès certains des exercices énumérés, certains apprennent à le faire. Certains ne le sont pas, et c'est triste.


Je pense que nous avons appris à limiter le travail inachevé, à faire des versions préliminaires de refactoring et à séparer les bugs importants des bugs non importants.


Estimation des termes des tests que nous faisons. Nous divisons les tâches en petites, grandes et autres. Environ la moitié des petites tâches sont effectuées par le testeur en service pendant son temps libre. La petite tâche est marquée dans YouTrack avec la balise «pendant une heure» et se fait en une seule approche (d'une demi-heure à deux heures), s'il n'y a pas de complications.


Les tâches importantes sont marquées avec la balise «projet», et il est immédiatement clair que ce ne sera tout simplement pas le cas. Chaque tâche volumineuse a une piste de fonction, dont la tâche est de s'assurer que les exercices de la liste ci-dessus sont effectués.


Les tâches restantes ne sont en aucun cas marquées. Les exercices de la liste commencent à être effectués si le temps nécessaire pour y travailler dépasse une limite arbitrairement choisie et variée de 2 semaines.


Si une tâche urgente est dans la file d'attente, vous devez tout supprimer et le faire. Pas besoin d'évaluer. Cependant, il sera utile de clarifier le délai afin de comprendre quels défauts et défauts peuvent être libérés. Il y a moins de dix pour cent de ces tâches urgentes.


La dernière fois que j'ai été retardé au travail à la demande d'un manager pour libérer une tâche urgente, il y a plus de deux ans. Avant cela, à quelques reprises, en 2015 et en 2016.


PS L'une des compétences les plus importantes de notre travail est de ne pas faire de déchets inutiles. Y compris de ne pas s'engager dans «l'estimation des termes» et l'auto-tromperie. Ce que je vous souhaite aussi.


(Abonnez-vous à notre chaîne dans Telegram , c'est sympa là-bas.)

Source: https://habr.com/ru/post/fr444484/


All Articles