Il existe quelques directives simples pour estimer la vitesse initiale de votre équipe Scrum avant de terminer la première itération (voir la FAQ ci-dessous), mais après ce point, vous devez utiliser des mesures historiques éprouvées pour planifier les fonctionnalités. En peu de temps, la vitesse se stabilise généralement et fournit une base formidable pour améliorer la précision et la fiabilité de la planification à court et à long terme de vos projets agiles. Les cycles de livraison agiles sont très courts, de sorte que la vélocité émerge rapidement et peut être validée très tôt dans un projet, puis utilisée pour améliorer la prévisibilité du projet.
La vitesse est-elle vraiment si simple ?
Oui, c'est le cas. N’essayez pas de trop compliquer la vélocité – c’est vraiment un concept simple et une grande partie de sa valeur réside dans sa simplicité inhérente. De nombreux managers et équipes novices méthodes agiles ont tendance à suranalyser le concept de vitesse et à y accumuler trop de complexité. Après quelques mois d'expérience dans un projet agile, la plupart des gens vivront un moment « ah ha » avec rapidité, se débarrassant de tout bagage qu'ils y ont associé et appréciant sa simplicité et sa valeur intrinsèque.
Graphiques de vitesse
Avec release et les graphiques d'avancement des itérations, la mesure de la vélocité des équipes agiles s'est avérée fournir un aperçu/une visibilité considérables sur l'avancement et l'état du projet. Un graphique de vélocité montre la somme des estimations du travail fourni à travers toutes les itérations. En règle générale, la vélocité se stabilisera tout au long de la vie d'un projet, à moins que la composition de l'équipe de projet ne varie considérablement ou que la durée de l'itération ne change. En tant que telle, la vitesse peut être utilisée à des fins de planification future. Bien que généralement fiable pour quelques itérations, si vous acceptez que les priorités, les objectifs et les équipes puissent changer avec le temps et donc le niveau de confiance d'une itération dans le futur, la vélocité peut être utilisée pour planifier releases beaucoup plus loin dans le futur.
Au départ, les équipes novices dans le développement de logiciels agiles doivent simplement plonger et sélectionner une vitesse initiale en utilisant les directives et les informations disponibles. Très rapidement (aussi vite que la prochaine itération), la vitesse peut être mesurée et ajustée. La vélocité, ainsi que les fonctionnalités granulaires (par exemple, les user stories, le backlog, les exigences, etc.) et l'estimation de haut niveau et/ou relative (en termes de points, de jours idéaux ou même d'heures), simplifient et accélèrent énormément l'ensemble de la planification du projet. , estimation, suivi de l'état et processus de création de rapports.
FAQ Scrum Agile
Comment est la vitesse d'un développement agile équipe calculée ?
La vélocité est la somme des estimations des fonctionnalités livrées (c'est-à-dire acceptées) par itération.
Quelle unité est utilisée pour mesurer la vitesse?
La vitesse est mesurée dans les mêmes unités que les estimations de fonctionnalités, qu'il s'agisse de points d'histoire, de jours, de jours idéaux ou d'heures que l'équipe Scrum fournit - qui sont tous considérés comme acceptables.
Comment la vitesse de la première itération est-elle estimée ?
Pour la première itération d'une équipe agile, une règle générale consiste à planifier la vélocité initiale à un tiers du temps disponible. Si vous estimez le temps de programmeur idéal, cela tient compte des réunions, des e-mails, de la conception, de la documentation, des retouches, de la collaboration, de la recherche, etc. Par exemple, avec six programmeurs et des itérations de deux semaines, un total de 60 jours-programmeur (6 programmeurs x10 jours) sont disponibles. Dans cette situation, un bon début serait de planifier 20 jours idéaux de travail dans l'itération. Si vous utilisez le temps réel, incluez suffisamment de tampon pour tenir compte des frais généraux du projet standard 1) et 2) de l'imprécision de l'estimation. N'oubliez pas non plus que la vitesse émergera rapidement lors de la première itération. Si elle est sous-estimée, la vitesse de la première itération augmentera à mesure que de nouvelles fonctionnalités seront incluses ; et si elle est surestimée, la vélocité diminuera à mesure que les éléments seront supprimés. Pour la deuxième itération, l'équipe Scrum doit alors utiliser la première itération comme ligne directrice.
Les réunions, les appels téléphoniques, les e-mails sont-ils inclus dans la vélocité ?
Cela dépend si ces éléments sont estimés et inclus dans le plans d'itération. Ils ne sont généralement pas inclus : l'un des objectifs de la vélocité est une cohérence et une prévisibilité relatives à travers les itérations en termes de capacité d'une équipe agile à fournir des résultats.
La vélocité doit-elle être accumulée dans toutes les équipes ou tous les projets de développement agile ?
La vitesse est une mesure très localisée. En plus des différents membres de l'équipe avec différentes « personnalités » d'équipe, les projets possèdent généralement des caractéristiques uniques en termes de techniques d'estimation, de processus détaillé, de technologie, d'implication des clients, etc. Par conséquent, cela peut rendre l'analyse à l'échelle de l'organisation très imprécise. Si, d'un autre côté, toutes vos équipes estiment exactement la même chose, développent exactement la même chose, testent exactement la même chose et suivent exactement la même chose, alors vous êtes peut-être l'exception.
Et si la vitesse fluctue ?
La vitesse fluctuera généralement dans une plage raisonnable, ce qui est parfaitement bien. Si la vélocité fluctue largement pendant plus d'une ou deux itérations, l'équipe Scrum peut avoir besoin de réestimer et/ou de renégocier la release plan.
Combien de temps faut-il pour que la vitesse se stabilise ?
Pour la plupart des équipes de développement agiles, la vélocité se stabilise généralement entre 3 et 6 itérations.
Comment estimer les itérations futures ?
Les itérations futures utilisent l'historique éprouvé de l'équipe pour déterminer ce que l'équipe peut faire. Par conséquent, la vitesse est la bonne mesure à utiliser pour planifier les itérations futures.
Comment estimer la vélocité si les équipes de projet changent de taille ?
Velocity s'appuie sur la cohérence de l'équipe pour être le plus précieux. Si votre équipe agile change, faites preuve de bon sens dans la planification des futures itérations. Si 20 % de votre équipe n'est pas disponible pour quelques itérations, réduisez la vélocité planifiée d'environ 20 %. Si cela inclut quelques acteurs clés, en particulier un client qui peut être moins disponible, alors réduisez un peu plus l'estimation. Il ne faudra que la longueur de la prochaine itération pour mieux comprendre ce que l'équipe peut livrer et donc sa nouvelle vélocité.
Une vitesse maximale signifie-t-elle une productivité maximale ?
Absolument pas. Dans une tentative de maximiser la vélocité, une équipe peut en fait réaliser le contraire. Si on lui demande de maximiser la vélocité, une équipe peut lésiner sur les tests unitaires ou d'acceptation, réduire la collaboration avec les clients, ignorer la correction des bogues, minimiser la refactorisation ou de nombreux autres avantages clés des diverses pratiques de développement agiles. Tout en offrant potentiellement une amélioration à court terme (si vous pouvez l'appeler ainsi), il y aura un impact négatif à long terme. L'objectif n'est pas une vélocité maximisée, mais plutôt une vélocité optimale dans le temps, qui prend en compte de nombreux facteurs dont la qualité du produit final.
Comment mesurer la vitesse si nos longueurs d'itération changent ?
Vous ne le faites pas, du moins pas aussi facilement. La valeur de Velocity vient de sa cohérence inhérente. Une longueur d'itération fixe permet de piloter le rythme fiable d'un projet. Sans ce rythme, vous révisez, réévaluez et réconciliez constamment, et la capacité de prédire l'avenir est réduite au minimum en raison de résultats incohérents. Si, d'un autre côté, presque tout le monde doit être absent une semaine pour les vacances ou quelques jours pour des réunions à l'échelle de l'entreprise, alors utilisez simplement votre bon sens et adaptez les dates d'itération ou la vitesse en conséquence. Comme la plupart des pratiques agiles, il s'agit de lignes directrices et non de règles.
