L’importance et le développement d’un plan d’itération

En tant que chef de projet agile, vous faites face à beaucoup de pression pour assurer à vos parties prenantes que votre projet est sur la bonne voie. C’est vous que le client appelle en disant : « Allons-nous finir ce truc à temps ? » Il est impératif d’avoir une documentation qui peut éliminer tout doute que vous le ferez. Entrez le plan d’itération.

Qu’est-ce qu’un plan d’itération ?

Le plan d’itération sert à plusieurs fins et est un document évolutif que vous conservez tout au long du projet. Il peut afficher la feuille de route de haut niveau à l’aide de puces générales ou d’épopées, ainsi que la granularité de chaque sprint à l’aide de PBI (Product Backlog Items) individuels, de fonctionnalités ou de user stories.

Vous pouvez formater ce document de plusieurs manières en fonction de votre projet et de vos préférences personnelles, mais le squelette doit montrer le plan de sprint et chaque flux de travail impliqué dans le projet. Vous pouvez utiliser le logiciel wiki de votre projet (j’utilise généralement Confluence, illustré dans l’exemple ci-dessous), vous pouvez organiser vos PBI en sprints dans Azure DevOps ou en cartes dans Trello, ou vous pouvez même utiliser Excel. Toute partie contribuant au projet (votre équipe de développement, le client, d’autres fournisseurs ou partenaires tiers) doit être représentée dans ce document. Les dépendances et les risques sont partout !

Exemple de plan d’itération de base

Création du plan d’itération

Votre équipe de projet doit commencer à créer le plan d’itération lors de vos premières sessions de lancement ou de découverte. Ces premières discussions impliqueront des estimations pour les grandes fonctionnalités et l’identification des dépendances pour ces fonctionnalités. L’équipe déterminera également l’ordre dans lequel certaines tâches doivent être effectuées pour que les fonctionnalités soient terminées à temps.

Le plan d’itération est essentiel pour identifier et atténuer/éliminer les risques au début du projet. Les zones les plus risquées du projet doivent être démarrées le plus tôt possible pour tenter de faire face aux imprévus. Par exemple : si vous savez qu’un domaine de votre projet nécessitera une preuve de concept technique (POC), vous voudrez commencer le plus tôt possible dans le projet pour résoudre tous les problèmes qui surviennent et maintenir le projet sur la bonne voie. Les fonctionnalités risquées ou inconnues doivent être prévues pour le Sprint 0 ou le Sprint 1 dans le plan d’itération puisque les résultats informeront le reste du projet.

En tant que chef de projet, vous devez continuellement mettre à jour le plan d’itération au fur et à mesure que l’équipe complète les fonctionnalités et en apprend davantage sur les exigences du projet. Au fur et à mesure que les exigences sont définies et que les fonctionnalités changent ou sont complétées, le plan d’itération servira de feuille de route pour le reste du projet pour vous donner une idée précise de la quantité de travail qui vous attend et si vous finirez comme prévu.

Exemples de scénarios

Voici un exemple de scénario : votre projet comporte six sprints de développement, et vous avez estimé que la fonction de recherche prendrait trois sprints pour se terminer. Cela signifie que la conception approuvée et les exigences finales pour la recherche doivent être livrées avant la fin du Sprint 3. C’est là qu’il est important que toutes les parties soient impliquées dans la création de ce document – l’équipe de conception saura quel sera l’impact de leur délai la chronologie globale et la façon dont son absence pourrait avoir un effet d’entraînement important. Les dépendances pour la recherche pourraient aller encore plus loin : vous pourriez même dépendre du client pour sélectionner une technologie de recherche avant de commencer la phase de conception. Il est important que l’équipe de conception sache quelles fonctionnalités prêtes à l’emploi sont fournies avec l’outil de recherche lors de la création de maquettes.

Autres exemples de scénarios auxquels un plan d’itération peut répondre :

• Une partie du site dépend d’une API d’informations sur les produits en cours de finalisation. L’API doit être prête à être consommée par Sprint 2 pour que tout le développement soit terminé à temps. Vous déterminez que votre équipe peut livrer à temps si le client fournit des données de test au Sprint 2 et des données réelles au Sprint 4.
• Vous avez estimé que l’entrée de contenu prendrait trois sprints. Pour terminer ce travail à temps, le client doit approuver et livrer le contenu final d’ici la fin du Sprint 2. Les réviseurs de l’équipe client doivent être disponibles et prêts à réviser le contenu à partir du Sprint 4. La documentation de ces tâches montre clairement ce qui est attendu de chacun partie à chaque étape du projet.

Conclusion

Le plan d’itération est un document essentiel pour un projet agile. Il cartographie les dépendances, traite les risques et donne à toutes les parties prenantes du projet la certitude qu’il existe un plan. J’espère que cela vous aidera dans votre prochain projet !