Table des matières
Sélection de fonctionnalité (planification de sprint – première partie)
De nombreuses équipes fixent un objectif global pour l'itération afin d'aider à guider la sélection des fonctionnalités. Au début de la réunion, les fonctionnalités les plus prioritaires sont généralement sélectionnées parmi les release plan. Si l'itération a un objectif global, certaines fonctionnalités de priorité inférieure peuvent être sélectionnées si elles correspondent mieux à l'objectif. La rapidité préalable est essentielle pour permettre à l'équipe de planifier une quantité de travail réaliste.
Par exemple, si l'équipe prévoyait auparavant d'obtenir 40 points d'histoire de fonctionnalités de produit, mais n'a livré avec succès que 30 points d'histoire, alors 30 points d'histoire doivent être considérés comme la vélocité actuelle pour la prochaine itération. Les estimations de vitesse passées comparées aux nombres réels sont utiles au niveau de l'itération, au niveau de la fonctionnalité et au niveau de la tâche. Tous ces éléments aident l'équipe à déterminer le montant auquel elle peut s'inscrire lors de la prochaine itération. Si l'itération est surréservée, le client doit sélectionner les fonctionnalités qui doivent être reportées à une itération future. Au cours de la réunion de planification d'itération, le client discutera des fonctionnalités avec l'équipe et tentera de répondre à toutes les questions de l'équipe.
Planification des tâches (planification de sprint – deuxième partie)
L'équipe décomposera les fonctionnalités en tâches. Les développeurs s'inscrivent ensuite pour les tâches et les estiment. Les tâches varient généralement en taille de quatre heures à deux jours, la plupart des tâches pouvant être exécutées en une journée. Les tâches de plus de deux jours doivent généralement être décomposées en tâches plus petites. Parfois, lors de la planification des tâches, il est déterminé qu'une fonctionnalité a été terriblement sous-estimée dans l'original release plan. Dans ce cas, l'équipe devra travailler avec le client pour fournir une estimation corrigée et déterminer la ou les fonctionnalités qui devront être retardées en conséquence.
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 à l'itération. Si, d'un autre côté, il est évident que toutes les fonctionnalités ne peuvent pas être livrées, l'équipe travaille avec le client pour déterminer quelles fonctionnalités pourraient être retardées ou peut-être divisées afin de fournir le plus de valeur avant la date limite d'itération.
Panneaux de signalisation
- Si, au cours d'une série d'itérations, l'équipe continue de pousser les fonctionnalités vers l'avenir, c'est un signe que l'équipe doit accorder une plus grande attention à 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 pousser les mêmes fonctionnalités vers l'avant à chaque itération, cela peut être un signal que l'équipe évite délibérément certaines fonctionnalités et les causes profondes doivent être explorées.
- Si l'équipe plonge dans trop de détails et conçoit chaque fonctionnalité dans son intégralité, il peut être possible de se concentrer davantage sur l'identification des tâches nécessaires.
FAQ
Comment gérons-nous les dépendances entre les tâches ?
Cette question revient un peu. Dans le cadre de la planification des itérations, l'équipe doit s'efforcer de minimiser les dépendances des tâches lorsqu'elle divise les fonctionnalités. Les techniques spécifiques abondent dans l'excellent livre de Mike Cohn Histoires d'utilisateurs appliquées. Ensuite, l'équipe doit s'efforcer de collaborer pour minimiser les effets des dépendances inévitables. Les équipes agiles adoptent généralement des conceptions simples, faiblement couplées et adaptables qui minimisent les dépendances. Une excellente ressource pour concevoir et affiner de telles architectures est le livre fondateur de Bob Martin Développement logiciel agile : principes, modèles et pratiques. Les é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 tests, les harnais de test automatisés et les objets fictifs aident les équipes à minimiser et à gérer les interdépendances des tâches. Une collaboration continue et étroite peut être essentielle ici ; les équipes colocalisées trouvent plus facile de résoudre ensemble les problèmes de dépendance tout au long de l'itération de manière juste à temps.
Les itérations ne sont que si longues, ce qui réduit le risque qu'une seule dépendance cachée tue le projet. Les diagrammes PERT et le CPM, bien que potentiellement utiles en termes de compréhension générale du système, ont une très forte tendance à s'effondrer sous le stress du développement de logiciels itératifs à grande vitesse. Le temps et les efforts supplémentaires consacrés à la création d'un modèle de dépendance pour une itération de deux semaines en valent rarement la peine. Les tests et le code automatisés vous donneront des commentaires plus précis et exécutables au moins aussi rapidement.
Combien un membre de l'équipe doit-il s'inscrire ?
Un membre de l'équipe devrait rarement s'inscrire pour plus que l'estimation totale des tâches qu'il a pu accomplir lors de l'itération précédente. Si les tâches ne sont pas enregistrées 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 pour trop de travail en comparant la fonctionnalité et la vitesse des tâches de l'itération précédente.
Comment planifiez-vous les itérations si la taille de l'équipe varie ?
Sans la capacité de s'appuyer sur un effort d'équipe constant, aucune approche de projet, agile ou autre, ne fournit beaucoup d'informations. Avec le développement logiciel itératif, cependant, il y a au moins généralement un historique qui se construit au fil du temps pour servir de base à la planification. Avec le développement itératif, si vous avez livré plusieurs itérations avec une équipe de dix avec une vélocité moyenne de 20 jours idéaux ou 200 heures par itération, et que votre équipe est réduite de moitié, alors un simple calcul devrait vous amener à ne pas prévoir plus de dix jours idéaux pour l'itération à venir (du moins au début). Si le personnel clé a été supprimé ou si vous vous trompez, vous le saurez dans les prochaines semaines et pourrez vous adapter rapidement aux futures itérations.
Comment comptabilisez-vous les frais généraux (réunions, e-mails, etc.) ?
Les équipes ne passent généralement pas beaucoup de temps à suivre les frais généraux mineurs. Au cours de quelques itérations, ces interruptions se traduisent par des vitesses réelles de plus en plus cohérentes (bien qu'inattendues). Certaines équipes intègrent explicitement des interruptions et des perturbations plus importantes dans leurs plans d'itération, afin de réduire les risques et d'augmenter la visibilité.
Comment comptabilisez-vous la correction des bogues lors de 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 à inclure les bogues en tant qu'entrées explicites dans la planification des itérations, en les hiérarchisant et en estimant les tâches impliquées. Les bogues et les fonctionnalités sont essentiellement des unités de travail équivalentes à des fins de planification. Certaines équipes choisissent de suivre les bogues séparément en dehors de leur processus d'itération. C'est un peu plus risqué : si l'effort de correction de bogues varie entre les itérations, la vélocité de l'équipe variera en conséquence, ce qui annulera les estimations et les plans. Mais si l'effort de correction de bogues est maintenu constant, cette méthode peut fonctionner raisonnablement bien.
Pourquoi les itérations devraient-elles toujours avoir la même longueur ?
Des itérations de longueurs identiques ou très proches fournissent un rythme sur lequel les équipes s'appuient pour estimer et planifier. Sans itérations de longueur fixe, il peut être difficile d'atteindre et de mesurer une vitesse constante. La discipline consistant à arrêter la production à la fin d'une itération focalise l'esprit de chacun, appliquant une pression pour que les conceptions restent simples et résistent au placage d'or ou à la dérive de la portée. L'ensemble de l'organisation s'habitue rapidement à un bourdonnement constant d'entrée, de planification, d'exécution, de sortie et de rétrospection. Sans ce rythme, l'équipe est moins performante. Il y aura parfois de bonnes raisons d'étirer ou de compresser des itérations spécifiques, pour les adapter aux délais, aux interruptions majeures ou aux vacances. Mais ceux-ci devraient être l'exception, pas la règle.
Comment comptabiliser le temps de test et de documentation ?
Les tests et les mises à jour de la documentation doivent être hiérarchisés, estimés et planifiés comme toute autre activité majeure nécessitant du temps d'un développeur. Ils sont souvent créés en tant que tâches sous des fonctionnalités spécifiques, mais peuvent également être regroupés en tant que fonctionnalité propre.
Les estimations de fonctionnalités doivent-elles être révisées lors de la planification des itérations ?
Les estimations de fonctionnalités ne doivent être révisées lors de la planification des itérations que si l'estimation d'origine s'avère très éloignée de la base et que le nouveau niveau d'effort aura un impact significatif sur la capacité de l'équipe à effectuer d'autres travaux.
Les estimations de tâches doivent-elles être révisées au cours d'une itération ?
L'estimation de la tâche d'origine ne doit pas être révisée une fois la planification de l'itération terminée. D'autre part, les estimations pour les itérations futures doivent être continuellement révisées pour refléter une évaluation précise du travail restant.
Toutes les équipes doivent-elles fonctionner selon le même calendrier d'itération ?
Il y a des avantages à ce que toutes les équipes travaillent sur le même calendrier d'itération. Le cumul du statut d'itération entre les équipes n'a de sens que si les équipes suivent le même calendrier. Il n'est pas utile de regrouper un statut numérique dans une équipe qui commence tout juste son itération avec une autre qui est sur le point de se terminer. L'inconvénient d'avoir toutes les équipes sur le même calendrier d'itération réside dans le fait de démarrer et de terminer les itérations en même temps. Si des ressources communes (par exemple, un client ou une direction) sont partagées entre les projets, elles peuvent apprécier un calendrier d'itération échelonné entre les équipes.
