L'équipe estime les points de l'histoire, les entreprises veulent du temps réel
Je suis sûr que ce n'est pas un thème rare. Nous avons deux équipes Scrum qui font un bon travail d'estimation des user stories à l'aide de points d'histoire (les constellations actuelles de l'équipe n'ont que 8 mois environ, bien que les membres de l'équipe aient plusieurs années d'expérience Scrum). Mais il est difficile pour la partie commerciale de l'entreprise de se rapporter aux histoires d'utilisateurs; ils veulent des unités de temps réelles (ou "une formule pour convertir les points d'histoire en heures") afin qu'ils puissent faire un plan pour quand les choses seront prêtes ( "nous devons savoir quand nous pouvons informer les clients que la fonctionnalité X sera en production ").
Moi et mes prédécesseurs du Scrum Master, j'ai bien sûr expliqué qu '"il n'y a pas de relation définie entre les points d'histoire et le temps réel" et que "les points d'histoire sont utilisés pour déterminer combien l'équipe peut tenir dans un sprint", et je suis vous pouvez deviner à quel point ils étaient satisfaits de cette réponse. Ils veulent toujours savoir, dans le temps du calendrier, quand nous arriverons à cette 27e histoire d'utilisateur sur l'arriéré.
Dans tous les cas, j'ai compilé quelques statistiques, et nos estimations SP se traduisent en de manière extravagante différentes en temps réel- les résultats dépensés (mesurés par notre logiciel Scrum Board, qui garde la trace du temps passé par les tickets dans la colonne "Travailler sur"). Pour les user stories 1-SP, il y a bien sûr un fort biais en faveur de délais très courts (avec l'explosion occasionnelle), mais surtout pour les histoires 2-SP, elles sont partout: il y a un facteur de 20 entre les finitions "les plus rapides" et les "plus lentes". Pour les 3, 5 et 8-SP histoires, la propagation est également plus qu'un facteur de 2.
Cela indique que (a) l'équipe doit être beaucoup plus cohérente dans l'estimation des user stories de (ce qui devrait être) une complexité similaire, et (b) l'équipe doit améliorer sa précision dans les rapports de temps (c'est-à-dire se rappeler de déplacer les tickets hors de "travailler" lorsqu'ils sont en réunion, au déjeuner ou en train de jouer au baby-foot).
J'ai l'intention d'améliorer à la fois (a) et (b), mais je pense que cela ne suffit pas, que l'entreprise s'attend à "plus de concret" que ce que ces initiatives produiront.
Quelles sont les bonnes stratégies pour apaiser le côté commercial, afin qu'elles n'interfèrent pas trop dans notre façon de travailler (par exemple en imposant l'utilisation d'un suivi du temps séparé, ce qui à mon humble avis serait stupide parce que cela en tout cas être moins précis que le suivi "automatique" actuel), tout en leur permettant en même temps d'obtenir une certaine mesure de la concrétisation du moment où les histoires seront faites?
(Historiquement, lors de la planification, nous avons divisé les histoires d'utilisateurs en éléments de travail qui ont ensuite été estimés individuellement en temps de travail réel , mais ce dont je parle ici sont les user stories sur le journal de dos qui n'auront pas ce niveau de détail ou de ventilation.)
Mise à jour: Mon manager avait le pressentiment qu'il y avait une sorte de distribution de la courbe en cloche des heures passées par point d'histoire, mais les données que j'ai rassemblées et les graphiques qu'il a faits l'ont complètement désabusé de cette notion . :-)
Vous avez raison, il n'y a pas de formule pour convertir les points d'histoire en heures. Vous pouvez obtenir une conversion sans perte de mètres en pieds, et vice versa, mais vous ne pouvez pas dire qu'une histoire de 3 points prendra X heures, donc une histoire de 5 points prendra Y heures (résoudre pour Y).
HorusKol a abordé cette partie suivante. Votre vitesse de sprint en équipe peut vous aider avec les livrables à plus long terme. Supposons que votre équipe soit à 50 points par sprint, et chaque sprint est de 2 semaines. Donc, 50 points par sprint multipliés par 50 semaines dans une année (en supposant que les gens prennent 2 semaines de congé pour les vacances), votre équipe actuelle peut faire un maximum de 2500 points en 12 mois.
L'entreprise vous propose donc 170 points d'histoires et d'épopées. Divisez cela par la vitesse historique de l'équipe de 50 points (une moyenne de chaque sprint jusqu'à présent) et vous obtenez 3,4 sprints. Puisque nous faisons une estimation, arrondissez à 4 sprints: 8 semaines. Deux mois, en gros. J'aime aussi prendre les 3-4 derniers sprints et faire une autre estimation. Supposons que votre équipe au cours des 3 derniers sprints ait cumulé respectivement 53, 67 et 55 points. Cela équivaut à 58 points, ce qui à ce rythme est de 2,9 sprints - donc en gros 3 sprints. On dirait que votre chronologie pour ces 170 points ressemble à 6 à 8 semaines.
Dites à l'entreprise 2 mois. Ne leur dites pas 6 à 8 semaines, car ils entendront simplement "6 semaines". Ne leur dites même pas 8 semaines, car la plupart des mois ont environ 4,5 semaines, et lorsque les gens entendent "4 semaines", ils pensent instantanément "1 mois". Une fois qu'une estimation atteint environ 4 semaines, elle devient 1 mois. Ensuite, travaillez juste en quelques mois. Si vous atteignez un an ou plus, alors honnêtement, n'évaluez pas ce travail. C'est inutile. Trop de choses peuvent changer en un an.
J'ai trouvé que c'était un moyen assez précis de convertir des points d'histoire en heures ... enfin du temps, de toute façon.
Vous obtiendrez un écart dans le temps nécessaire pour terminer des histoires individuelles. Certains développeurs travaillent plus rapidement que d'autres. Mettre tous les points d'histoire dans un bol et allumer le mélangeur pour travailler avec des moyennes aide à atténuer ces incohérences.
Oh, et n'oubliez pas la partie la plus importante:
Rassembler. Toujours.
Vous avez probablement déjà une conversion inhérente des points d'histoire aux estimations de temps - comment décidez-vous que vous avez choisi suffisamment de travail pour votre sprint? Vous avez probablement dit quelque chose comme "l'équipe peut gérer 20 (ou 40 ou autre) points par semaine". Après quelques sprints, vous devriez être en mesure de réviser cela en fonction de l'achèvement - alors maintenant c'est 15 ou 25 (ou 35 ou 50 ou ...) points par sprint - c'est votre équipe vélocité.
Pour les user stories 1-SP, il y a bien sûr un fort biais en faveur de très courtes périodes de temps (avec des explosions occasionnelles), mais surtout pour les stories 2-SP, elles sont partout: il y a un facteur de 20 entre les finitions "les plus rapides" et les "plus lentes". Pour les histoires à 3, 5 et 8 SP, l'écart est également plus qu'un facteur 2.
Une certaine variation dans le temps pour terminer des histoires spécifiques est acceptable dans les valeurs en points - la vitesse gère cette incertitude en étant une moyenne sur l'histoire récente.
Cependant, vous devrez peut-être examiner attentivement la façon dont vous attribuez des points, en particulier ces 2 points si vous obtenez une fluctuation aussi importante. Les tâches de point supérieur sont censées être incertaines (et doivent être ventilées) - mais les tâches aussi petites qu'un pointeur 2 devraient être assez cohérentes.
Étant donné que toutes les tâches affectées à la même valeur de point doivent nécessiter des efforts similaires, il n'est pas logique qu'il y ait une telle plage de temps à terminer.
Alors, regardez le pointeur 2 qui a pris le plus de temps dans votre rétrospective. Pourquoi quelque chose qui aurait probablement dû être transformé en matinée de 10 jours? Aurait-on pu signaler quelque chose ce premier matin pour dire "cela doit devenir épique et divisé en tâches plus petites"? Dès que cela se produit, bien sûr, le travail supplémentaire nécessaire doit être mis dans l'arriéré et ne pas interférer avec le reste du sprint.
Aussi, essayez de voir comment l'équipe a sous-estimé cet élément - pourriez-vous faire mieux sur les éléments futurs après l'avoir examiné?
Oui, la date de livraison sera repoussée en conséquence, ou la liste des fonctionnalités d'une mise à jour pourrait être révisée afin que la livraison ne soit pas affectée. Mais l'objectif est d'améliorer les estimations ponctuelles futures, ainsi que d'obtenir une chronologie plus précise.
C'est comme la météo: plus loin, moins fiable. C'est une analogie que tout le monde comprendrait. Les erreurs d'estimation s'additionnent.
Les ventes doivent apprendre à parler en termes Scrum aux clients. Scrum n'a pas de sens isolément, il est censé être appliqué verticalement dans toute l'entreprise et s'étend de préférence au domaine client.
En tant qu'équipe de développement, vous devez être ferme sur ce point. Vous pouvez leur donner des attentes et des suppositions, mais ne laissez pas les engagements prolonger un seul sprint.
Vous avez déjà une conversion (très grossière):
Les sprints Scrum durent (généralement) deux semaines.
Vous savez que vous pouvez terminer, disons, environ 20 points d'histoire de fonctionnalités au cours de ces deux semaines (ou comment déterminez-vous quoi et combien de fonctionnalités sont regroupées en un seul sprint?) Et vos sprints précédents confirment cette estimation (disons que vous avez terminé 18, 21, 23, 19 et 20 points d'histoire de fonctionnalités dans les cinq derniers sprints).
Disons que la fonctionnalité X (et toutes ses dépendances) a été estimée à 47 points d'histoire.
Vous pouvez donc estimer que si vous accordez la priorité à la mise en œuvre, vous devriez prendre environ 3 sprints, soit 6 semaines (mais assurez-vous que vos estimations tiennent compte de qui peut faire quoi - si 35 de ces points sont DB travailler et vous n'avez que sur DB guy vous devez réviser votre vitesse estimée pour en tenir compte).
Cela dit - communiquez fermement qu'il s'agit d'estimations brutes - il y a une raison pour laquelle les sprints sont de deux semaines et non de six. Plus votre prévision doit couvrir de choses, plus il y a d'incertitude et d'erreurs. Communiquez également fermement le coût - c'est-à-dire que cela signifierait de mettre la tâche en priorité, ce qui signifie qu'aucune autre tâche ne sera traitée. Sinon, vous pourriez rencontrer le scénario suivant:
"Quand la fonctionnalité Y sera-t-elle terminée?"
"Si nous nous concentrons sur cela la prochaine ... 12 semaines"
"12 semaines?!? Vous avez dit qu'il en faudrait 4."
"Oui, mais vous nous avez dit de prioriser la fonctionnalité X , dont nous vous avons dit qu'elle lierait toutes nos ressources et prendrait 8 semaines."
"Ne pouvez-vous pas travailler sur la fonctionnalité X et la fonctionnalité Y = en même temps? "
"gémissement"
Je fais quelques choses quand je reçois des questions comme celle-ci.
Tout d'abord, je réponds aux questions sur l'avenir en décrivant le passé. Je dirais quelque chose comme Nous parcourons environ deux de ces histoires par semaine. Donc, si rien ne change, nous nous attendons à en finir avec l'histoire 27 dans environ 14 semaines.
Deuxièmement, je veux que les clients face au client assument la responsabilité du calendrier de négociation par rapport au risque. Je dirais quelque chose comme Souvenez-vous, l'équipe d'ingénierie travaille sur la base d'estimations 50/50. Si rien ne change, il y a 50/50 chances que la fonction 27 soit prête en 14 semaines. Vraisemblablement, vous ne voulez pas pour signaler quelque chose avec ce niveau de risque à un client. Voulez-vous que j'établisse une estimation à laquelle nous avons, par exemple, une confiance de 90%? Vous devrez ensuite revoir vos preuves historiques et dire quelque chose comme: Il y a 90% de chances que l'histoire 27 se fasse en 25 semaines.
Enfin, rappelez à votre collègue qu'une fois qu'il a pris un engagement extérieur, l'entreprise est immobilisée. Faire des promesses externes sur l'histoire numéro 27 enlève toute l'agilité de l'entreprise. Vous seriez alors engagé dans une ligne de conduite particulière. Chaque fois que quelqu'un vient à vous avec une demande de changement, vous devez maintenant répondre Nous nous sommes engagés à terminer l'histoire 27 avant la date du x. Je ne peux faire ce changement que si vous contactez le client et lui dites que notre engagement n'est plus valide . Fondamentalement, prendre des engagements spécifiques pour un travail de plus d'un mois ou plus dans le futur pose de nombreux problèmes.
Le sprint est un temps défini, disons 2 semaines. Vous ne pouvez pas prédire qu'une histoire se fera plus de 2 sprints, comme vous avez votre sprint actuel et votre prochain sprint. Je suppose que vous avez préparé des histoires qui sont discutées avec l'équipe pour le prochain sprint et qui ont été priorisées par les entreprises. Donc, vous pouvez dire avec certitude que ce sont les 4 prochaines semaines de travail.
Tout ce qui dépasse 4 semaines est susceptible de changer et les entreprises peuvent créer une feuille de route qui n'est pas définie en heures. Cela devrait être planifié par sprint, disons une épopée1 (épopée comme dans un tas d'histoires groupées) et epic2 devrait être fait dans les sprints 47 et 48 et l'épopée3 devrait être fait dans le sprint 49. Épopées que j'estime approximativement en heures par moi-même pour voir si un ou deux s'inscrira dans un sprint, la chronologie va glisser de toute façon. Si les fonctionnalités ne fonctionnent pas, les entreprises doivent réduire leur portée ou accepter des solutions non parfaites qui peuvent être améliorées ultérieurement si nécessaire (qui devrait être agile, adopter la réalité au lieu de suivre le plan).
Vous pouvez créer un diagramme de Nice Gantt (c'est ce que les entreprises aiment) avec de futurs sprints et des sujets/épopées principaux pour ceux-ci.
J'aime faire la sortie à chaque sprint et ensuite je prépare la sortie avec ce qui a été fini dans le sprint (ou des trucs qui ont été signés pour une sortie par les entreprises même si ce n'était pas parfait), les trucs inachevés vont au prochain sprint. De cette façon, j'ai une livraison prévisible dans un délai d'environ 2-3 semaines (une semaine pour d'éventuelles corrections sur la version candidate).
C'est mon expérience avec une petite équipe, une petite quantité de dépendances extérieures et ce que je crois être une entreprise raisonnable. Votre kilométrage peut varier.
Pour les nouvelles fonctionnalités, il est presque impossible d'estimer le temps requis.
L'expérience du développement logiciel montre que dans la plupart des cas, il y a des détails que vous ne pouvez pas voir avant de vraiment commencer le développement. Dans le meilleur des cas, ces détails peuvent nécessiter un certain temps supplémentaire, mais dans le pire des cas, le projet peut également échouer. La raison en est la complexité du développement logiciel lui-même.
C'est la raison pour laquelle SCRUM estime uniquement la complexité du problème (points d'histoire), mais pas le temps. La seule chance que vous avez est de diviser des fonctionnalités très complexes en plus petites. De cette façon, vous pouvez minimiser le risque.
Comme une estimation du temps est presque impossible, il n'y a pas de formule convertissant les points d'histoire en estimations de temps. La vitesse ne peut être qu'une estimation très grossière, pas plus.
Dans SCRUM, le propriétaire du produit peut modifier les priorités des éléments du backlog avant chaque sprint. Par conséquent, le maître SCRUM ne peut donner aucune estimation pour plus d'un sprint. Il ne sait pas quel élément du carnet de commandes pourrait devenir important lors du prochain sprint.
SCRUM n'est pas une méthode pour faire des choses impossibles (planifier l'imprévisible) ou accélérer le développement. Il s'agit d'un système d'alerte précoce si le développement manque de temps. Il permet de réagir rapidement aux nouvelles exigences.
Au poste initial:
Vous êtes déjà très bon si vous parvenez à diviser la plupart de vos tâches en 1 SP à 5 SP histoires. Les estimations de vitesse pourraient s'améliorer si les tâches sont similaires) et votre équipe devient plus expérimentée. Mais s'il y a toujours de nouvelles pièces inconnues dans de nouveaux articles, vous devez vivre avec l'inexactitude.
Étant donné que vos développeurs consacrent normalement du temps à des travaux non liés au développement (par exemple, des réunions), vous ne devez pas prévoir 8 heures de développement par jour, mais moins, par exemple. 6 heures. Ensuite, vous obtenez une réserve pour d'autres tâches ou pour des éléments de travail prenant plus de temps.
Si vos collègues souhaitent obtenir des estimations précises (ce qui est une contradiction en soi), expliquez-leur les problèmes inhérents au développement de logiciels. Montrez-leur ensuite les avantages des méthodes agiles.