Salut. Permettez-moi de vous parler de mon expérience dans l'évaluation de produits logiciels. Je le fais sans interruption depuis 15 ans maintenant, et je voudrais partager mon expérience et l'évolution de mes vues sur l'évaluation. Je suis sûr que ce sera utile. Commençons par l'établissement d'objectifs. Pourquoi mesurer du tout? Qui en a besoin?
La réponse est en fait très simple - les gens veulent des certitudes, en particulier la réponse à la question "quand sera-t-il prêt?" Quand puis-je partir en vacances, lorsque les ventes commencent, quand effectuer une tâche connexe. D'un autre côté - vous ne savez jamais ce que les gens veulent, pourquoi à cause du désir des autres de perdre leur temps sur cette activité?
Mais, en fin de compte, nous aimerions tous recevoir un salaire, et le salaire ne semble pas de rien, l'entreprise le prend sur le produit, dans un cas distinct - sur les investissements. Et pour que ces revenus soient générés, nous devons atteindre un objectif commercial. Et les gens qui formulent des objectifs commerciaux sont très friands de toutes sortes de formules financières - ROI, LTV et autres EBITDA. Et ces formules comportent constamment des délais. Sans eux, le crocodile n'est pas attrapé, la noix de coco ne pousse pas.
Il y a aussi une deuxième raison, légèrement moins importante: si les estimations des fonctionnalités sont claires, cela affecte leur priorité, les tâches plus simples ont tendance à recevoir une priorité plus élevée. Étant donné que dans l'approche agile conventionnelle, le backlog est régulièrement secoué, les informations d'entrée sur les évaluations des tâches contribuent à rendre le processus de redéfinition des priorités plus efficace.
En conséquence: très probablement, vous devez encore évaluer. Humiliez-vous .
Voyons maintenant comment faire cela, afin de ne pas maudire tout et tout le monde dans le processus. Comment évaluent les personnes qui ne savent pas comment évaluer le matériel informatique? Comme ça:
- Nous évaluons tous les travaux en jours-personnes.
- Ajoutez 10% au cas où.
- Divisez par le nombre de développeurs.
- Nous ajoutons le nombre de jours résultant à la date actuelle et obtenons la date finale.
- C'est tout.
Pour cette raison, les flashbacks vietnamiens de la photo de titre clignotent toujours devant mes yeux: trop de nerfs ont été perdus dans cette guerre. Et il mourra pour vous si vous commencez à évaluer de cette façon. Le problème est que c'est exactement le genre d'évaluation que l' on attend de vous:
"Ne jouez pas avec vos points de stockage, montrez votre main."
Quels problèmes seront rencontrés lors de l'évaluation
Commençons par une situation idéale:
- Nous avons une tâche atomique (simple, indivisible).
- Il n'a aucune dépendance vis-à-vis d'autres tâches, il n'est pas nécessaire de coordonner quoi que ce soit.
- Il y a une personne 100% dédiée à la tâche qui sait la faire.
Même dans ce cas, la question se pose: "Qui fera l'évaluation?" À ce moment, la machine de contrôle impitoyable démarre. Tout d'abord, le manager pense: si le développeur veut faire cela, qu'est-ce qui l'empêchera de spécifier d'énormes coûts de main-d'œuvre à berner? -> Par conséquent, le manager évalue lui-même la tâche. -> Cependant, le manager ne comprend pas suffisamment le sujet et ne voit pas (ou ne veut pas voir) les écueils. -> L'estimation s'avère irréparablement sous-estimée. -> L'équipe ne respecte pas le délai. -> Mort et décomposition.
La situation décrite ci-dessus est un problème de culture d'entreprise classique de méfiance à l'égard de ses employés. Cependant, la plupart des développeurs ont une motivation intrinsèque pour résoudre des problèmes intéressants, pour eux c'est beaucoup plus attrayant que de jouer le fou à l'ordinateur, il n'y a donc aucune raison de méfiance généralisée. En général, une entreprise doit être construite sur la base de la présomption de confiance en ses employés et ne pas tordre les processus commerciaux normaux pour ressembler à un mouton noir.
Une culture de méfiance est très courante en conjonction avec une culture d'entreprise de peur: même si un développeur évalue une tâche, que se passe-t-il dans sa tête lors de l'évaluation? Il répond à la question: "Comment mon entreprise réagit-elle à l'écart entre les dates prévues et réelles?" Si le développeur est grondé pour les délais manqués, il les surestimera. Si les évaluations ultérieures du développeur sont interrompues pour les tâches effectuées à l'avance, il ne remettra pas les tâches à l'avance.
Le dernier exemple de culture de la peur est la sortie de Cyberpunk 2077. Le jeu est sorti avec une qualité dégoûtante sur les consoles de la génération précédente. Le PDG de la société a déclaré dans un communiqué que "il s'avère que bon nombre des problèmes que vous avez rencontrés dans le jeu n'ont pas été détectés lors des tests". Ce qui, bien sûr, est un mensonge total. Les problèmes étaient visibles à l'œil nu, les testeurs ne pouvaient pas le manquer physiquement. C'est une situation typique dans une culture de la peur: les problèmes sont étouffés. Ainsi, les informations sur le chemin vers le dernier étage de la direction sont passées de «jeu non jouable sur les consoles de base» à «libérons».
Si ce n'est pas votre cas, vous pouvez évaluer davantage. Si vous n'êtes pas chanceux avec la culture de l'entreprise, ne lisez pas plus loin, car vous devez émettre des évaluations non pas pour l'exactitude, mais pour minimiser les coups de pied des autorités, et c'est une tâche complètement différente.
Et donc vous avez donné une estimation, par exemple - 1 semaine. Ce n'est que votre supposition, rien de plus. L'évaluation détermine la date d'achèvement prévue d'une tâche, mais ne peut pas déterminer quand elle sera réellement terminée. L'endroit où sera exactement le moment réel d'achèvement de la tâche est décrit par une distribution normale. Pour l'instant, rappelons-nous simplement cela comme un axiome, à la fin, il y aura une torsion de l'intrigue.
Tout est encore compliqué par le fait que certaines tâches ne sont pas fondamentalement divisées en parties, et il arrive aussi qu'elles ne puissent pas être parallélisées. Il existe également des tâches interdépendantes, il faut se plonger dans le contexte des tâches. De plus, lors du développement, l'équipe doit communiquer afin de synchroniser ses activités.
Nous ne savons pas non plus comment voir l'avenir. En conséquence, des tâches surgissent constamment que nous n'avions pas prévues et ne pouvions pas prévoir. Qu'est ce que ça pourrait être?
- Souhaits du client ou propriétaire du produit.
- Problèmes soudains, pour lesquels quelque chose doit être amélioré.
- Légal inattendu.
- Et des tonnes de trucs.
Le plus imprévisible est le problème de la vitesse différente des développeurs.
Pour les vrais développeurs de même niveau et avec le même salaire, la productivité peut différer d'un ordre de grandeur:
- Quelqu'un coupera et déboguera le code pendant une semaine, et quelqu'un vissera la bibliothèque ouverte en une demi-journée.
- Quelqu'un va fumer le débordement de pile, et quelqu'un a déjà résolu ces problèmes et commencera immédiatement à en profiter.
Du coup, notre gaussien se transforme en quelque chose comme ça (l'estimation est la même quand la tâche n'est pas suffisamment dimensionnée):
En général, tout est compliqué, on ne creuse pas de tranchées ici. Comment faire une bonne note dans de telles conditions?
Critères de bonne note:
- Rapidité d'évaluation - l'évaluation elle-même n'a aucune valeur commerciale, il est donc logique de la faire le plus rapidement possible afin de ne pas être distrait du développement.
- L'évaluation est la responsabilité de toute l'équipe, et il existe un bon principe «vous évaluez, vous le faites» qui protège l'équipe des notes plafonnées.
- N'oubliez pas tous les composants de la sortie d'une fonctionnalité en production - analyse, développement, tests unitaires, autotests, tests d'intégration, devops. Tout cela doit être évalué.
Comme vous pouvez le voir, je n'ai rien écrit sur l'exactitude. Depuis 15 ans que je fais des estimations, je n'ai pas appris à les faire avec précision, alors soyons plus modestes et essayons d'estimer au moins approximativement. L'ensemble du processus d'évaluation ressemble à ceci:
- Mettre des tâches dans le backlog du produit.
- Nous évaluons les histoires les plus prioritaires dans le backlog en utilisant n'importe quelle méthode (il existe de nombreuses méthodes, je vais en parler ci-dessous).
- Nous commençons à travailler (par exemple, sur Scrum - par sprints).
- Après plusieurs sprints, nous mesurons le nombre de points d'histoire que nous obtenons en moyenne à chaque itération. Il s'agit de notre vitesse de développement d'équipe moyenne.
- . burndown chart. , .
Mais le monde n'est pas parfait, nous fixons donc le nombre de nouvelles fonctionnalités (également estimées en points d'histoire) que notre Product Owner génère à chaque sprint. La ligne rouge montrera la croissance de l'arriéré, maintenant l'intersection des lignes rouges et bleues est la date souhaitée.
Si le Product Owner est très créatif, cela peut même être comme ceci:
Et maintenant, nous nous souvenons que l'évaluation obéit aux lois de la distribution normale, mais la torsion de l'intrigue - de tels Gaussiens s'additionnent parfaitement. Par conséquent, voici ce qui s'avère (c'est ce qu'on appelle un burndown chart amélioré):
Il semblerait que le rêve d'un jeune mathématicien soit devenu réalité: à partir d'un tas de chaos, nous avons un beau graphique et pouvons diffuser avec un regard intelligent qui " avec 50% de probabilité, nous finirons dans le sprint 14, avec 80% de probabilité dans le 17e, de 95% - dans le 19e ".
Il y a un certain nombre de pièges dans tout ce processus.
Tout d'abord, je dirai tout de suite à propos de l'éléphant dans la salle: le backlog est important, il y a beaucoup de tâches dont on ne sait rien sauf la description dans le format de la user story, donc l'estimation sera très approximative dans tous les cas. J'ai déjà montré ci-dessus à quoi ressemble une estimation approximative dans le langage des mathématiques.
Deuxièmement, le problème "les développeurs travaillent avec une productivité différente" n'est en aucun cas résolu en principe... Cela signifie que nous obtenons une augmentation très plate de la probabilité, ce qui n'aide pas beaucoup à prendre des décisions de gestion: «avec une probabilité de 50%, nous finirons au 14e sprint, avec une probabilité de 80% - au 27e, avec 95% - dans le 39e »- donc dans le langage des mathématiques, cela ressemble à« un doigt vers le ciel ».
Par conséquent, je maximise personnellement la métrique du «taux d'évaluation» et je vais maintenant vous dire les méthodes que j'ai essayées.
Planification de la méthode de poker
C'est l'une des techniques d'évaluation les plus populaires, probablement parce qu'elle est la plus ancienne.
- Les participants au processus utilisent des cartes spécialement numérotées avec des numéros de Fibonacci.
- Le Product Owner fait une brève annonce de la prochaine histoire et répond aux questions de l'équipe.
- Après avoir reçu l'information, les participants du «poker» choisissent une carte avec une évaluation appropriée, à leur avis, et ne la montrent à personne.
- Ensuite, tous sont révélés ensemble, et les participants avec les scores les plus bas et les plus élevés donnent de brefs commentaires expliquant leur choix de score.
- À la suite du processus de discussion, l'équipe prend une décision unique, puis passe à l'histoire suivante.
Au cours d'une session d'une heure de cette manière, vous pouvez évaluer de 4 à 8 histoires. C'est le plus gros problème avec cette méthode - elle est longue, les gens s'ennuient et sont distraits. Ce n'est pas pour rien que j'ai utilisé l'expression «tout est révélé ensemble».
La méthode "ordre de construction"
C'est l'approche que nous utilisons actuellement au travail. Le but est d'évaluer les tâches les unes par rapport aux autres. C'est ainsi que se construit une séquence de tâches triées par difficulté. Pour cette méthode, vous devez d'abord accumuler un pool de tâches évaluées et les placer sur l'échelle.
- Lorsqu'il est temps d'évaluer, chaque membre de l'équipe joue à tour de rôle (comme dans un jeu de société). Les mouvements peuvent être les suivants: mettez la tâche sur l'échelle, déplacez la tâche le long de l'échelle, discutez de l'histoire avec des collègues, sautez votre mouvement.
- En conséquence, les tâches se déplacent constamment sur le plateau, leur appréciation les unes par rapport aux autres est affinée jusqu'à ce qu'un état soit obtenu qui satisfasse toute l'équipe.
- Lorsque tous les participants manquent leur tour, vous avez terminé.
C'est une technique rapide. Avec son aide, vous pouvez estimer 15 à 20 histoires par heure, ce qui est généralement suffisant.
Méthode grande / petite / obscure
Je l'ai utilisé plusieurs fois, mais il n'a pas pris racine.
- Trois zones sont marquées sur le tableau: «grande tâche», «petite tâche» et «information insuffisante».
- , «/». « » = « ».
- .
La méthode a un énorme avantage - c'est super rapide. Ainsi, vous pouvez traiter 50 user stories par heure.
Ici, il y a un problème avec la traduction de ces estimations en points d'histoire, mais lorsque la vitesse de l'équipe est déjà connue, alors nous comprenons combien de points d'histoire une personne mâchera par sprint dans Jira et évaluons de petites tâches autour de cette métrique.
Quant au reste des tâches. J'ai envoyé des tâches de la zone «informations insuffisantes» à l'analyse, et des tâches de la «grande tâche» - à la décomposition, afin qu'elles puissent être réévaluées à la prochaine session.
En conséquence, dans notre produit, nous dessinons simplement une feuille de route avec des fonctionnalités que nous pensons avoir le temps d'écrire dans un proche avenir. Si nous n'avons pas le temps - eh bien, cela arrive. Et nous n'utilisons des estimations que pour les tâches immédiates, que nous avons normalisées, et même alors, pas toujours.
Peut-être suis-je engagé à jeter mon incompétence dans le domaine de l'évaluation en termes pseudo-scientifiques, mais pour moi personnellement, le processus lui-même semble plutôt stupide, comme un étrange culte du cargo auquel nous jouons pour prétendre que nous sommes la même stable et une industrie prévisible, comme une autre industrie vraiment stable et prévisible. J'aimerais lire votre expérience dans ce domaine, il me manque peut-être quelque chose.