Bonjour, Habr! Je m'appelle Artyom et je suis chef d'équipe chez Skyeng. Mon équipe de développement a un client, c'est un chef de produit, c'est juste Vanya. Vanya pense que notre système de notation n'est pas parfait. Par exemple, une note de 2 jours ne lui donne rien. Il verra sa tâche à la prod dans une semaine ou 10 jours ou plus. Ou moins.
Ce n'est pas parce que nous échouons aux tâches, mais parce qu'avec l'estimation traditionnelle, en réalité, nous évaluons uniquement le moment où le développeur a écrit le code. Mais il y a aussi des tests et une révision du code. Ok, mettons tout cela dans l'évaluation. Mais aussi:
- nous avons une ligne juste avant le développement et les tests,
- il y a des améliorations, nous ne sommes pas sans péché,
- les tâches urgentes arrivent,
- lorsqu'une implémentation affecte plusieurs services, nous attendons des revues d'équipes liées.
Comment apprendre à répondre à la question "Quand?" si la prévisibilité est hors de question?
Comment nous avons douté Estimation
Notre équipe, comme beaucoup dans l'entreprise, a une réunion très utile - une revue technique (ou, en bref, une revue technique ). Cela demande beaucoup de temps et d'efforts, mais cela ajoute de la prévisibilité: nous planifions une solution technique au problème à l'avance, et en même temps l'évaluons.
Puisque nous sommes toujours distants, tout se passe dans JIRA: il y a un tableau sur lequel les étapes de travail sont visualisées. La carte quitte le statut "Revue technique" et passe à "Prêt pour le développement" après avoir tout décrit et évalué. C'est à ce moment que nous nous engageons à faire le travail.
«Prêt pour le développement» a une limite WIP - il ne peut pas y avoir plus de 8 tâches en même temps. Il y a la règle inverse: dès que les tâches de la colonne deviennent moins nombreuses, on lance une nouvelle revue technique.
Réalité: Nous passons beaucoup de temps à évaluer. L'examen technique a généralement lieu deux fois par semaine; 4 tâches avec une élaboration et une évaluation détaillées peuvent prendre de 1,5 à 3 heures. Mais! Ensuite, nous pouvons encore prendre le temps de comprendre pourquoi l'estimation a été dépassée.
Cependant, ni la notation ni le débriefing n'ajoutent de valeur à notre produit. Nous perdons plutôt du temps avec eux. Et argent. Pendant longtemps, j'ai douté de la nécessité de ces procédures, et à un moment donné, j'ai mûri pour une conversation sérieuse avec le produit. Et nous avons tous deux reconnu le problème.
"La chemise est sèche et complètement ..." pas XS
Décidé: expérimentons des approches d'évaluation. J'ai suggéré de se concentrer sur la taille du t-shirt - la taille des t-shirts est utilisée comme unité de mesure dans cette technique. Vous devez trouver la plus petite tâche que vous avez à faire et la confondre avec XS. Après cela, les tâches restantes sont évaluées sur la base de "leur taille XS" - et, en fonction de cela, elles se voient attribuer la taille S, M, L ou XL.
A soudoyé l'occasion d'évaluer «à l'œil nu». L'idée était simple: nous allons collecter des statistiques sur la quantité de développement nécessaire pour accomplir une tâche d'une dimension ou d'une autre, calculer la moyenne et être en mesure de prévoir le timing.
Une erreur dans un jour ou deux sera pardonnée par le client - ce qui signifie qu'il n'y aura plus de débriefing. Et sur l'examen technique, vous n'aurez pas à perdre du temps sur le vote interactif et secret. Tout est fluide!
Nous travaillons ainsi depuis plusieurs mois, collectant des statistiques. Et seul Ivan nous regarde de travers.
Il s'est avéré que XS, comme S, nous le faisons en 1 jour, puis en 10. Et sur L nous passons 5 ou 15 jours. Car, en fait, nous prenons un peu de travail en premier, certains dans le second et d'autres dans le cinquième - et les tâches de même dimension passent des temps différents dans des états d'attente. Oups, voici la moyenne.
En bref, la dispersion ici n'est pas de quelques jours - et pour Vani, peu de choses ont changé. Nous avons trouvé l'expérience infructueuse, mais toujours l'idée que les tâches peuvent être catégorisées dans ma tête. Et j'ai commencé à penser plus loin dans cette direction.
«Tout le monde aime les gâteaux. Puff! " Âne de Shrek
Et j'aime. De plus, l'anniversaire d'un enfant est une excellente occasion! Je vais sur mon site préféré et commence à choisir:
- c'est possible, mais ce n'est pas possible,
- vous pouvez décorer, mais vous ne pouvez pas décorer,
- C'est possible pour 2 kg, et c'est possible pour 5 kg.
Je ne dévoilerai pas mes préférences gustatives, mais j'ai choisi un gâteau. Et ils l'ont amené à la date fixée. Vient ensuite la philosophie d'un chef d'équipe qui a mangé trop de gâteau.
Bien sûr, je ne suis pas Newton, et le gâteau n'est pas une pomme, mais l'inspiration est venue.
J'ai pu choisir parmi de nombreuses options, mais peu importe ce que j'ai choisi, la date de livraison n'a pas changé. J'avais besoin d'un gâteau dans une semaine. Et j'étais prêt à fournir ce service. Et la taille du gâteau, le poids et toutes sortes de gadgets n'ont pas beaucoup affecté le résultat final - plus précisément, dans ce cas, ils ne l'ont pas du tout affecté. Ce n'est pas une question de taille, comme on dit. Et dans quoi? Dans le prix.
Par exemple, les gars avaient une commande expresse: moyennant des frais supplémentaires, ils m'auraient apporté le même gâteau de fantaisie en quelques jours seulement, et non en 5. Ma commande, la plus précieuse par rapport aux autres, serait devenue hors ligne. Fondamentalement, la boulangerie a deux SLA: un pour les commandes régulières et un pour les VIP. Il y a quelque chose à penser.
L'idée du SLA s'est déclenchée parce que j'ai lu à ce sujet dans le guide Kanban
Du point de vue de la méthode Kanban, tout est un service. Et malgré le fait que nous ne fournissons pas de gâteaux, et que notre produit ne puisse être ni touché ni mangé, le développement est aussi un service. Et nous traitons également les tâches différemment.
Souvenons-nous de notre tableau: Le
service se compose de plusieurs étapes (développement, révision de code, test), et la colonne "Prêt pour le développement" est notre point de départ pour le client.
Nous faisons certaines choses à notre rythme habituel, mais lorsque des tâches de gravure arrivent, nous lâchons tout. Il reste à comprendre quels SLA nous avons, et il sera possible de conclure un accord avec Vanya.
Comment Ă©valuer le SLA de votre Ă©quipe: construire un diagramme spectral (c'est facile)
Pour comprendre quelles classes de service nous avons et quels SLA ils ont, Kanban suggère de construire le graphique suivant:
- Lead Time (LT) — . « » «».
- Y — LT1, LT2, LT3 ..
Nous avons pris les tâches qui ont été fermées au cours des derniers mois et
avons reçu ce qui suit: Nous avons fermé 3 tâches en une journée, 6 sur 2, surtout sur 5, et quelque part, nous avons du mal avec la tâche depuis plus de deux semaines ...
Eh bien, il est maintenant temps d'analyser. Quelles sont ces tâches? Pourquoi sont-ils arrivés ici? Pourquoi faisons-nous plus dans certains LT que dans d'autres, qu'y a-t-il? Vous pouvez consulter les clients et les interprètes, ainsi qu'étudier les commentaires sur la tâche.
Voici ce que nous avons réussi à dénicher. C'est notre travail habituel .
La propagation est assez grande, mais elle peut être analysée.
En général, la majeure partie des tâches était répartie dans l'intervalle de 7 à 14 jours, et un couple a volé très loin - dans cette queue, il y avait plusieurs tâches (pas toutes) des relations publiques vers d'autres services. Ces tâches qui ont été accomplies en 3-4 jours sont l'exception plutôt que la règle.
, , , 75% 10 .
Et avec une probabilité de 90%, cela prendra 14 jours. Eh bien, si le développement affecte d'autres services de l'entreprise, vous devrez attendre un peu plus longtemps - nous avons besoin d'une révision de code d'une autre équipe, puis d'un autre déploiement.
Allons plus loin. Nous avons appelé cette classe «Important» .
Pour une raison quelconque, ces tâches sont prises pour fonctionner plus tôt que d'autres: il y a soit plus de valeur, soit un prix de retard plus élevé.
Et ici, nous pouvons également exprimer le SLA: avec une probabilité de 75%, la tâche sera mise en vente dans 5 jours, avec une probabilité de 90% en 7. Continuons-nous?
Les tâches mêmes pour lesquelles nous abandonnons tout et voyons , scions, scions - bloqueurs .
Dans 100% des cas, il s'agit d'améliorations mineures que nous n'avons pas prises en compte lors de l'implémentation de la fonctionnalité principale, ou de bugs qui affectent les fonctionnalités vitales en production.
Malgré le fait que nous ayons réussi à résoudre toutes ces situations en 2 jours, nous annoncerons toujours le 90e centile. Premièrement, vous ne devriez pas promettre 100% - jamais à personne :) Deuxièmement, vous devez établir la variabilité: rappelez-vous le cas du travail régulier, lorsque plusieurs tâches ont disparu en 20 jours et plus, car il y avait une dépendance à d'autres équipes.
Terminé! Nous pouvons nous coordonner avec Vanya SLA pour toutes les classes de service:
nous avons choisi exactement 90% en termes de temps - c'est en fait la tolérance du client à la non-conformité. Autrement dit, si 1 tâche sur 10 ne respecte pas le SLA, ils sont prêts à nous pardonner.
Si votre client n'est pas si gentil, il vaut mieux exprimer le 95e centile, par exemple.
Au lieu d'une conclusion
- Qu'est-ce qui empêche Vanya de recruter uniquement des tâches importantes ou des bloqueurs?
- Limites WIP horizontales.
Nous avons convenu de limiter le nombre de tâches dans la classe de service: vous ne pouvez pas prendre plus de deux bloqueurs, vous ne pouvez pas prendre plus de deux tâches importantes. Vous pouvez avoir d'autres numéros - c'est une question d'accord avec le client. Vous ne pouvez pas définir de telles limites dans JIRA sans plugins, donc un accord verbal est absolument nécessaire. Outils outils, mais sans interaction avec les gens partout.
Merci pour votre attention et votre planification réussie!