Planification agile des sprints | Planification des itérations

Sélection des fonctionnalités (Planification de sprint – première partie)

De nombreuses équipes définissent un objectif global pour l'itération afin d'orienter la sélection des fonctionnalités. En début de réunion, les fonctionnalités prioritaires sont généralement sélectionnées à partir du plan de version. Si l'itération a un objectif global, certaines fonctionnalités de priorité moindre peuvent être retenues si elles contribuent davantage à cet objectif. La vélocité antérieure est essentielle pour permettre à l'équipe de planifier une charge de travail réaliste.

Par exemple, si l'équipe prévoyait initialement de réaliser 40 points d'effort de fonctionnalités produit, mais n'en a livré que 30, alors 30 points d'effort doivent être considérés comme la vélocité actuelle pour la prochaine itération. La comparaison des estimations de vélocité passées avec les valeurs réelles est utile au niveau de l'itération, des fonctionnalités et des tâches. Ces éléments aident l'équipe à déterminer la charge de travail qu'elle peut intégrer à la prochaine itération. Si l'itération est surchargée, le client doit sélectionner les fonctionnalités à reporter à une itération ultérieure. planification itérative Lors de cette réunion, le client discutera des fonctionnalités avec l'équipe et tentera de répondre à toutes les questions que celle-ci pourrait avoir.

Planification des tâches (Planification de sprint – deuxième partie)

L'équipe décomposera les fonctionnalités en tâches. Les développeurs s'inscriront ensuite aux tâches et les estimeront. La durée des tâches varie généralement de quatre heures à deux jours, la plupart pouvant être réalisées en une journée. Les tâches de plus de deux jours doivent généralement être divisées en sous-tâches. Il arrive parfois, lors de la planification des tâches, qu'une fonctionnalité ait été largement sous-estimée dans l'estimation initiale. plan de sortieDans ce cas, l'équipe devra collaborer avec le client pour fournir un devis corrigé et déterminer quelle(s) fonctionnalité(s) pourrait/devraient être reportées.

Ajustements d'itération

Au cours de l'itération, s'il reste du temps après la livraison de toutes les fonctionnalités, l'équipe peut demander au client d'identifier des fonctionnalités supplémentaires à ajouter. En revanche, s'il est évident que toutes les fonctionnalités ne peuvent être livrées, l'équipe collabore avec le client pour déterminer lesquelles pourraient être reportées ou éventuellement divisées afin d'optimiser la valeur ajoutée avant la date limite de l'itération.

Panneaux de signalisation

• Si, au fil des itérations, l'équipe continue de repousser les fonctionnalités à plus tard, c'est le signe qu'elle devrait prêter une attention particulière à sa vélocité antérieure afin de minimiser la surréservation continue et de maximiser la précision de la planification.
• Si l'équipe continue de mettre en avant les mêmes fonctionnalités à chaque itération, cela peut indiquer qu'elle évite délibérément certaines fonctionnalités et il convient d'en explorer les causes profondes.
• Si l'équipe s'attarde trop sur les détails et conçoit chaque fonctionnalité dans son intégralité, il serait peut-être judicieux de se concentrer davantage sur l'identification des tâches nécessaires.

Questions fréquentes

Comment gérer les dépendances entre les tâches ?

Cette question revient fréquemment. Dans le cadre de la planification des itérations, l'équipe doit s'efforcer de minimiser les dépendances entre les tâches lors de la répartition des fonctionnalités. L'excellent ouvrage de Mike Cohn regorge de techniques spécifiques. Histoires d'utilisateurs appliquéesEnsuite, l'équipe devrait s'efforcer de collaborer afin de minimiser les effets des dépendances inévitables. Les équipes agiles privilégient généralement des conceptions simples, faiblement couplées et adaptables qui minimisent les dépendances. L'ouvrage de référence de Bob Martin constitue une excellente ressource pour concevoir et affiner de telles architectures. Développement logiciel agile : principes, modèles et pratiquesLes équipes agiles utilisent également des techniques, des outils et des pratiques qui leur permettent de travailler simultanément sur des sous-systèmes et des modules interdépendants. Développement piloté par les testsLes outils de test automatisés et les objets simulés aident les équipes à minimiser et à gérer les interdépendances entre les tâches. Une collaboration étroite et continue est essentielle ; les équipes travaillant au même endroit parviennent plus facilement à résoudre ensemble les problèmes de dépendance tout au long de l’itération, et ce, au moment opportun.

Les itérations ont une durée limitée, ce qui réduit le risque qu'une simple dépendance cachée ne compromette le projet. Les diagrammes PERT et la méthode du chemin critique (CPM), bien que potentiellement utiles pour la compréhension générale du système, ont une forte tendance à s'effondrer sous la pression d'un développement logiciel itératif et rapide. Le temps et les efforts supplémentaires consacrés à la construction d'un modèle de dépendances pour une itération de deux semaines sont rarement rentables. Les tests automatisés et le code généré vous fourniront un retour d'information plus précis et exploitable au moins aussi rapidement.

À quel montant un membre de l'équipe doit-il s'inscrire ?

Un membre d'équipe ne devrait que rarement s'engager sur un nombre de tâches supérieur à l'estimation totale des tâches qu'il a pu accomplir lors de l'itération précédente. Si aucune tâche n'est prise en compte lors de la planification de l'itération, l'accent est mis sur le fait de s'assurer que l'équipe ne s'engage pas sur une charge de travail excessive, en comparant cette situation à la vélocité de développement des fonctionnalités et des tâches de l'itération précédente.

Comment planifier les itérations si la taille de l'équipe varie ?

Sans la possibilité de compter sur un effort d'équipe constant, aucune approche de projet, agile ou autre, n'apporte d'éclairage significatif. Avec le développement itératif de logiciels, en revanche, on dispose généralement d'un historique qui se constitue au fil du temps et qui sert de base à la planification. Dans ce cas, si vous avez réalisé plusieurs itérations avec une équipe de dix personnes, à une vélocité moyenne de 20 jours idéaux (soit 200 heures par itération), et que votre équipe est réduite de moitié, un simple calcul devrait vous permettre de prévoir au maximum dix jours idéaux pour l'itération suivante (du moins dans un premier temps). Si des membres clés ont été retirés du projet, ou si vous constatez une erreur, vous le saurez dans les semaines qui suivent et vous pourrez rapidement rectifier le tir pour les itérations futures.

Comment comptabilisez-vous les frais généraux (réunions, courriels, etc.) ?

Les équipes consacrent généralement peu de temps au suivi des éléments mineurs de charge de travail. Au fil des itérations, ces interruptions se traduisent par une vélocité réelle de plus en plus constante (bien qu'inattendue). Certaines équipes intègrent explicitement les interruptions et perturbations majeures dans leurs plans d'itération afin de réduire les risques et d'améliorer la visibilité.

Comment intégrez-vous la correction des bugs dans la planification des itérations ?

Il existe plusieurs façons pour les équipes de gérer la correction des bogues. L'une des plus simples consiste à intégrer explicitement les bogues à la planification des itérations, à les prioriser et à estimer les tâches nécessaires. Dans ce contexte, bogues et fonctionnalités sont considérés comme des unités de travail équivalentes pour la planification. Certaines équipes choisissent de suivre les bogues séparément, en dehors de leur processus d'itération. Cette approche est plus risquée : si l'effort de correction varie d'une itération à l'autre, la vélocité de l'équipe variera également, faussant ainsi les estimations et les plans. En revanche, si l'effort de correction reste constant, cette méthode peut s'avérer relativement efficace.

Pourquoi les itérations devraient-elles toujours avoir la même longueur ?

Les itérations de durée identique ou très proche instaurent un rythme sur lequel les équipes s'appuient pour l'estimation et la planification. Sans itérations à durée fixe, il peut être difficile d'atteindre et de mesurer une vélocité constante. L'obligation d'arrêter la production à la fin de chaque itération concentre l'attention de chacun, incitant à la simplicité des conceptions et évitant les surdimensionnements et les dérives du périmètre. L'ensemble de l'organisation s'habitue rapidement à ce flux régulier d'informations, de planification, d'exécution, de production et de rétrospective. Sans ce rythme, l'équipe est moins efficace. Il peut arriver qu'il existe de bonnes raisons d'allonger ou de raccourcir certaines itérations, pour les adapter aux échéances, aux interruptions importantes ou aux périodes de congés. Mais cela doit rester l'exception, et non la règle.

Comment comptabiliser le temps consacré aux tests et à la documentation ?

Les tests et les mises à jour de la documentation doivent être priorisés, estimés et planifiés au même titre que toute autre activité importante nécessitant le temps d'un développeur. Ils sont souvent créés sous forme de tâches liées à des fonctionnalités spécifiques, mais peuvent également être regroupés en une fonctionnalité à part entière.

Les estimations des fonctionnalités doivent-elles être révisées lors de la planification des itérations ?

Les estimations des fonctionnalités ne doivent être révisées lors de la planification des itérations que si l'estimation initiale s'avère très éloignée de la réalité et que le nouveau niveau d'effort aura un impact significatif sur la capacité de l'équipe à mener à bien d'autres tâches.

Les estimations de tâches doivent-elles être révisées au cours d'une itération ?

L'estimation initiale de la tâche ne doit pas être révisée une fois la planification des itérations terminée. En revanche, les estimations des itérations suivantes doivent être régulièrement mises à jour afin de refléter une évaluation précise du travail restant.

Toutes les équipes doivent-elles fonctionner selon le même calendrier d'itération ?

Il est avantageux que toutes les équipes travaillent selon le même calendrier d'itérations. Le regroupement des données d'avancement des itérations entre les équipes n'est pertinent que si elles suivent le même calendrier. Il est inutile de regrouper les données d'avancement d'une équipe qui débute son itération avec celles d'une autre qui est sur le point de la terminer. L'inconvénient d'un calendrier d'itérations identique pour toutes les équipes réside dans le fait que les itérations démarrent et se terminent simultanément. Si des ressources communes (par exemple, un client ou la direction) sont partagées entre les projets, un calendrier d'itérations échelonné entre les équipes peut s'avérer plus approprié.