Tout le monde veut savoir combien de temps prendra le projet. Dans cet article, nous expliquerons comment fournir au gestionnaire une prévision précise et incertaine à la fois en utilisant les temps de cycle et en comptant les histoires, ainsi que des conseils sur le moment où éviter complètement les estimations.

Celeste sentit la pression. Son manager Barry voulait faire une prévision trimestrielle de son équipe. La tâche a été compliquée par le fait que le groupe de Celeste a travaillé sur plusieurs produits: Barry voulait obtenir une prévision pour trois à la fois. Chacun d'eux faisait partie d'un projet différent.

Les programmeurs du groupe Celeste ne disposaient pas de suffisamment d'informations pour faire au moins quelques prévisions, notamment pour l'ensemble du trimestre.

Celeste a décidé d'avouer à Barry et de voir où ils en venaient. Elle a pris rendez-vous le lendemain et a collecté des données.

La fille est arrivée au bureau de Barry à exactement 10 heures du matin. Quand elle a frappé à la porte, Barry parlait toujours au téléphone. Il lui fit signe d'entrer et leva un doigt pour que ce soit clair: il sera prêt dans une minute.

Elle était assise sur une chaise visiteur en face de son bureau.

Barry raccrocha et se tourna: «Eh bien, discutons du calendrier des projets, non?»

Celeste acquiesça et dit: «Oui. Cela semble être ce qui peut être fait dans une telle situation. »

Barry fronça les sourcils. "Il semble?" J'ai besoin d'engagements spécifiques. Pas de "semble"! "

Celeste était assise confortablement: "Barry, est-ce que vous êtes pressé de sortir ces trois produits?"

"Comment avez-vous découvert?" - Barry secoua la tête. - Si vous écoutez les gars des ventes et du marketing, alors une catastrophe se produira si nous ne les libérons pas maintenant. Je ne sais pas quoi répondre, sauf que tout sera. "

"Mais le mois dernier, vous avez discuté d'un portefeuille de projets", a rappelé Celeste. «Je pensais que le produit A était la priorité absolue.»

«Ça l'est», a-t-il dit. «Et les produits B et C sont également une priorité absolue.»

Celeste roula des yeux: "Mais tu sais qu'il ne peut y avoir qu'une seule priorité, non?"

«Je le sais, et tu sais», a-t-il dit. "Mais mes collègues ne savent pas." J'ai besoin d'une prévision de ce que vous pouvez faire - enfin, des obligations - et ensuite vous pourrez respirer un peu tranquillement. »

"Sur quel produit devrions-nous travailler en premier lieu?", A demandé Celeste.

«Le produit A, bien sûr», a-t-il déclaré. "Il est le plus payé."

"Eh bien, c'est ce que nous allons faire", a déclaré Celeste. "Nous sommes tendus et publierons A dans un mois." Votre tâche est d'amener ces gens sympas à assister à nos présentations chaque semaine. Ils devraient voir ce que nous faisons dans une semaine. S'ils ne viennent pas à la démonstration, je refuse de leur donner des informations. "

Barry se pencha en arrière: «Attendez. J'ai compris la démo. Et les deux autres mois? Et pourquoi ne leur donnez-vous aucune information?

Celeste a déclaré: «Si nous travaillions sur un seul produit, je pourrais calculer la note en fonction de notre cycle de développement. Pour le produit A, nous publions trois à quatre histoires [code pour les tâches personnalisées] par semaine. Mais nous ne connaissons pas le véritable cycle de développement des produits B et C. "

Barry hocha la tête: "Pourquoi pas?"

"Les produits B et C sont prévus dans deux et trois mois", a déclaré Celeste. - C'est assez loin pour le marketing. Le problème est que plus le travail est long, moins le service marketing travaille avec le propriétaire du produit pour clarifier les histoires. Nous n'avons aucune idée des fonctions qui devront être mises en œuvre dans deux et trois mois. Il nous faudrait faire des hypothèses scientifiquement fondées à partir de zéro (supposition scientifique, SWAG). C'est normal, j'aime faire ça avec mes gars, mais nous avons besoin de plus de détails. Ce qui ne l'est pas. "

"Alors pourquoi ne leur dites-vous rien s'ils ne viennent pas à la manifestation?" Demanda Barry.

"Si ce n'est pas important pour eux d'observer nos progrès et de fournir des commentaires, alors ils ne se soucient pas beaucoup du calendrier", a déclaré Celeste. «Ils veulent que nous nous engagions sans donner nos obligations en retour.» Pourquoi devrais-je passer du temps à évaluer s'ils ne veulent pas contribuer? "

Barry a accepté de «vendre» la «timebox» mensuelle aux managers qui lui ont fait pression pour fixer des délais. Celeste veillera à ce que l'équipe se concentre uniquement sur le produit A. Et elle a prévu des réunions hebdomadaires pour des démonstrations afin que l'équipe montre son travail et reçoive des commentaires.

Seriez-vous tenté de faire les choses différemment?

Estimation des termes - travail non trivial

L'estimation des délais est également un travail. De nombreuses équipes mettent une telle routine dans leur horaire de travail régulier. Cependant, une estimation trimestrielle précise nécessite souvent plus d'une heure ou deux de travail.

Il y a au moins deux problèmes pour évaluer la performance trimestrielle. Trop souvent, les exigences ne sont pas entièrement définies et, comme pour l'équipe Celeste, l'évaluation détache l'équipe des travaux urgents sur le projet.

Le problème est que planifier le développement d'un logiciel n'est pas comme planifier un road trip. Si votre ville possède plusieurs feux de circulation, vous connaissez les fluctuations du trafic. Je vis dans une banlieue de Boston, d'où un voyage à l'aéroport peut prendre à la fois 20 et 90 minutes. Le plus souvent de 30 à 45 minutes. Il s'agit d'une variation importante pour un trajet de 13 km.

Et il n'y a pas d'innovation sur un tel voyage. Je suis allé plusieurs fois à l'aéroport et je connais plusieurs façons d'y arriver. J'ai des applications mobiles qui m'aident à trouver l'itinéraire le plus rapide même en cours de route. Bien que certaines options soient un peu plus prévisibles, aucune ne peut garantir que ce voyage se terminera en 20 minutes.

Le voyage à l'aéroport se déroule sur un itinéraire prédéterminé et avec des obstacles bien compris. Mais le développement de produits est une autre affaire. C'est l'innovation. En d'autres termes, nous n'avons jamais rien fait de tel auparavant. S'il en était autrement, nous n'aurions pas à écrire une nouvelle application ou à mettre à jour un système obsolète - nous utiliserions l'ancienne.

Pour une évaluation raisonnable, nous avons plusieurs options. En fait trois:

• Vous pouvez estimer l'ordre de grandeur. Je pense que cela est utile pour l'ensemble du projet. «Nous prévoyons cinq à neuf mois de travail. Nous saurons mieux quand nous répondrons à ces questions et terminerons cette partie du travail complexe. » SWAG est bien adapté à de telles évaluations.
• Vous pouvez recueillir suffisamment d'informations sur les exigences et fournir une estimation raisonnable. L'équipe peut avoir besoin de travailler avec des user stories pour faire une prévision avec une assez petite dispersion dans le temps.
• Il existe une option pour évaluer le travail sur une courte période, par exemple, pendant une semaine ou deux. Il peut s'avérer que les prévisions finales ne sont pas entièrement correctes. Mais en général, il est assez proche du résultat pour ne pas décevoir les personnes qui ont demandé à le faire.

De quelles prévisions avez-vous besoin pour un manager?

J'ai remarqué que les gestionnaires ont souvent besoin d'une estimation de l'ordre de grandeur. Dans ce cas, l'équipe peut faire une prévision et la rapporter comme suit:

«Nous pensons que ce projet prendra cinq mois avec une confiance de 50% dans l'exactitude de ces prévisions. Nous sommes confiants à 80% dans l'évaluation de huit mois. Dix mois, c'est 90% de confiance. »

Cela aide les gestionnaires à comprendre qu'il existe une gamme de confiance. S'ils veulent une certitude à 100%, cela peut prendre plus de 14 mois.

Vous pouvez utiliser la méthode en spirale: «Nous nous concentrons sur le premier trimestre de l'année prochaine. Nous ne savons pas quand exactement au premier trimestre, mais nous pensons que nous pouvons le gérer. " Au fur et à mesure de l'avancement du projet, vous précisez: «Nous mettons à jour le devis pour une période comprise entre mi-janvier et mi-mars». Après avoir appris encore plus, dites: "Quelque part en février, si un blizzard ne se produit pas." Puis, en janvier, vous pouvez dire: "La troisième semaine de février".

Je recommanderais également une plage de trois dates: «La date optimiste est janvier. Le plus réaliste est fin février. Le plus pessimiste est fin avril. »

En tout cas, ne donnez jamais une évaluation sans ambiguïté. Cela incite St. Murphy (de la loi de Murphy) à prendre votre projet et à faire des choses désagréables.

Dans certains cas et dans certaines commandes, le client peut avoir besoin d'informations supplémentaires. Ici, vous pouvez discuter avec lui des fonctions spécifiques mises en œuvre afin de comprendre les incertitudes.

Utiliser le temps de cycle au lieu de l'évaluation

Je n'aime pas les prévisions sur la durée de mise en œuvre de projets logiciels ou d'autres projets informatiques, notamment Agile. Au lieu de cela, je préfère que l'équipe publie de très petites histoires ou évalue le travail par temps de cycle.

Si vous ne connaissez pas la terminologie:

• Les récits d'utilisateurs décrivent comment un client ou un utilisateur utilise un produit dans un but fonctionnel («Je veux réserver une place» ou «Je dois publier des données de ville intelligente pour répondre aux exigences de transparence»). Les histoires sont différentes de celles d'un développeur qui regarde un produit en termes de bases de données et d'API.
• Le temps de cycle fait référence au temps total nécessaire à une équipe pour publier le travail sur une histoire. Cela inclut à la fois le temps de développement actif et les temps d'arrêt lorsque le travail attend quelque chose.

L'idée est de comprendre le temps moyen qu'il faut pour produire quelque chose d'utile (historique).

Dans le cas de Celeste, elle savait qu’une équipe pouvait produire trois à quatre histoires par semaine pour le produit A. Pour de nombreuses équipes, le comptage d’histoires fonctionne comme les autres méthodes d’évaluation.

Si l'équipe n'a jamais travaillé sur un produit similaire, le temps de cycle précédent ne sera pas applicable à ce nouveau produit. L'équipe peut ne pas savoir comment affiner et diviser les histoires afin d'en produire plusieurs par semaine. De plus, elle peut ne pas être au courant de l'état du code et de la disponibilité d'un nombre suffisant de tests. Si votre équipe travaille sur des histoires depuis plus de trois jours, ne vous embêtez pas à prévoir. Comptez les histoires et n'essayez pas d'en faire plus que d'habitude.

Lorsqu'une équipe a commencé à traiter des histoires en un ou deux jours, vous n'êtes pas non plus obligé de faire une évaluation. Souvent, un calcul simple est plus facile et plus précis.

Pourquoi ne pas utiliser la vitesse?

Vous avez remarqué que je recommande le temps de cycle et le comptage des histoires, plutôt que la vitesse pour estimer le temps du projet. Parce que la vitesse est un substitut.

Par exemple, je marche tous les jours pour rester en forme. Je parcours le même itinéraire tous les jours, en suivant ma vitesse relative. Par une belle journée ensoleillée, je marche environ 5,6 km à l'heure. Un jour pluvieux ou chaud et humide, la vitesse tombe à 4 km / h. Dans la neige ou la glace, je ne peux pas sortir du tout, dans ce cas, ma vitesse est de 0.

Je vais sur le même chemin. (Oui, c'est ennuyeux, mais c'est mon problème). Bien que je parcours la même distance, le trajet prend des temps différents selon les conditions. Ici, les conditions sont similaires à la base de code et aux tests de votre équipe.

Si les histoires sont suffisamment petites, la vitesse correspond au temps de cycle. Mais trop souvent, les gestionnaires essaient d'évaluer des projets avec de très grandes histoires. Le comptage sera plus simple: «Nous pouvons terminer une ou deux histoires dans un cycle. Quelle ou deux histoires voulez-vous choisir? »

Refuser d'évaluer n'est pas un canular

Lorsque Barry a discuté de problèmes avec des collègues, l'un d'eux a déclaré: «Refuser d'évaluer les délais est une arnaque!»

Barry a répondu: «Ce n'est pas vrai. Vous voulez que nous sortions un produit, non? "

La réponse était «bien sûr. B et C. "

"Le problème est qu'ils doivent être effectués à tour de rôle", a répondu Barry. - Si vous avez vraiment besoin du produit A, quel est l'intérêt de faire des prévisions pour le reste? Nous pouvons nous mettre au travail et montrer nos progrès. Lorsque nous en aurons fait assez, nous répéterons la procédure pour B et C. De plus, vous aurez le temps de clarifier les exigences pour B et C afin de nous préparer des histoires. »

L'équipe de Celeste a achevé la majeure partie du projet A en un mois. La sortie du produit B a pris plus de temps - près de deux mois. Et puisque la société a reçu des revenus suffisants de la libération des produits A et B, elle a réduit la pression sur la libération du produit C.

Sachez quel grade votre manager a besoin. Présentez-la comme il a besoin. Et si vous avez peu de temps, mettez-vous au travail.

Évaluation de projets informatiques: leçons

• N'incluez aucun nombre ou date spécifique. Au lieu de cela, donnez un ordre de grandeur estimé avec confiance dans une publication en temps opportun. Ou suggérez des estimations à court terme basées sur des facteurs sous votre contrôle.
• Divisez les objectifs du projet en histoires d'utilisateurs qui définissent les fonctionnalités du logiciel. Faites ensuite vos estimations en fonction du nombre de user stories que vous pouvez traiter.
• Assurez-vous de bien comprendre les exigences avant de prendre des engagements.